What is i18n-keyless?
Updated
i18n-keyless is an internationalization (i18n) service built around a keyless approach: instead of managing translation keys and locale JSON files, you write natural-language text directly in your code and let AI handle the translations. It's aimed at agentic coding workflows, where a coding agent can get translations right the first time. You can self-host it for free, or use a hosted plan starting at €4/month. It fits teams that want i18n without the overhead of a key system, and it supports one API across twelve SDKs.
The core idea: no keys, no locale JSON
Traditional i18n systems rely on keys. You write something like header.welcome.title in your code, then maintain a separate file mapping that key to translated strings for each language.
i18n-keyless removes that layer. You write the actual text in your code, and the system translates it. According to the site, this means:
- No keys to generate or maintain. With a key system, every new key costs back-and-forth time — the site estimates roughly 1 minute per key, and at 500 keys across 2 languages that adds up to about 17 hours.
- No locale JSON to load. There's nothing to fetch or bundle at runtime in the usual way.
- No merge conflicts from translation files, because there's only one file to edit.
The stated benefit is that your brain — and your codebase — stays focused on the actual content rather than on managing an i18n system.
Why it targets agentic coding
The product is positioned specifically for "agentic coding," meaning workflows where an AI coding agent writes or edits your code. The claim is that a coding agent "gets it right the first time" with i18n-keyless, because there are no keys to invent, no JSON structure to match, and no naming conventions to follow. The agent just writes the text.
The site frames this as "Ultimate DX for i18n" — the developer experience is the point. Setup is advertised as a 5-minute implementation.
What changes in your codebase
The site contrasts the two approaches directly:
| Concern | Key-based i18n | i18n-keyless |
|---|---|---|
| What you write in code | Keys like someheader.welcome.title |
Natural-language text |
| What users see if translation is missing | The raw key | Untranslated real words |
| Reading the code | You read keys, not sentences | You read natural language |
| Fixing a grammar issue | Hard to spot, since you see keys | You see the sentence and can fix it |
| Maintaining translations | You manage them in the app | Left to AI |
The "worst case" described is that, offline, a user sees untranslated real words rather than a key string. At normal pace, the site says you "don't care about the i18n system at all."
Supported platforms
One API, twelve SDKs. The listed integrations are:
- React — React Native, Expo, Next.js, Remix, TanStack Start, Astro
- Vue — Nuxt
- Angular
- Plain HTML — Svelte, Alpine, htmx, one script tag
- Node.js
- Laravel (PHP)
- Rails (Ruby)
- Flutter (Dart)
- Swift — iOS, macOS, Vapor
- Kotlin — Android, Ktor
- Python — Django, Flask, FastAPI
- Go
There's also an MCP server, which the site describes as covering "all your i18n needs" — relevant if your coding agent connects through MCP.
Pricing and self-hosting
- Free self-hosted option.
- Hosted plans from €4/month.
The site lists a "Get API Key for One App" action, suggesting per-app API keys. Exact plan tiers, limits, and what's included at each price aren't detailed in the available page content, so check the pricing page before committing.
The shutdown question
The site explicitly addresses "What if the service shuts down?" — a fair concern for any hosted i18n dependency. The self-hosted option is the structural answer here: if you run it yourself, the service's continuity isn't tied to the vendor. If you're evaluating the hosted plan, that self-hosted path is worth keeping in mind as an exit route.
When this fits
Consider i18n-keyless if:
- You're starting a project and want i18n from day one without slowing development.
- You use coding agents and want them to handle translations without key-management errors.
- You dislike reading keys instead of natural language in your code.
- You want a self-hosted option for control, or a low-cost hosted plan.
It may matter less if you already have a mature key-based i18n system with established translation workflows, or if your process requires human translators working from key files.