Skip to main content

The complete guide to keyless i18n in 2026

· 11 min read
Arnaud Ambroselli
Founder of i18n-keyless

If you've ever shipped a multilingual app, you know the pattern: a t("homepage.hero.title") call in your JSX, a JSON file with that key mapped to "Welcome to Acme", a translator who needs to fill in the same key for each locale, and a code review where someone asks "what does homepage.hero.title actually say?".

Keyless i18n flips this. You write the source string directly in your code — <I18nKeyless>Welcome to Acme</I18nKeyless> — and the library handles translation, caching, and locale switching for you. No keys. No JSON files to sync. No translator filling in spreadsheets.

This guide walks through what keyless i18n is, when it makes sense, when it doesn't, and how it compares to traditional key-based libraries.

TL;DR​

  • Keyless i18n uses the source-language string itself as the lookup key — no t("some.key") indirection.
  • It removes ~80% of the manual work in a typical i18n setup: no key naming, no JSON file maintenance, no missing-key bugs.
  • AI translation (via the keyless service) handles new strings automatically; humans can override anything that needs nuance.
  • It's a great fit for early-stage apps, MVPs, indie SaaS, and any team where engineers ship faster than translators can keep up.
  • It's not a great fit for high-volume marketing sites with a dedicated translation team using TMS workflows — Lokalise/Crowdin are still the right call there.
  • The trade-off is real: you give up some control in exchange for an order-of-magnitude faster setup and zero key-management overhead.

What "keyless" actually means​

In a key-based library like i18next or react-intl, translation is a two-step lookup:

// 1. You define a key
// en.json: { "hero.title": "Welcome to Acme" }
// fr.json: { "hero.title": "Bienvenue chez Acme" }

// 2. You reference the key in code
<h1>{t("hero.title")}</h1>

In keyless i18n, the source string is the key:

import { I18nKeyless } from "i18n-keyless-react";

<h1><I18nKeyless>Welcome to Acme</I18nKeyless></h1>

When the user's locale is the source language (say, English), the component renders the string as-is. When it's anything else, the library looks up the translation by the source string, falls back to the source if missing, and asynchronously requests a translation from the backend (which is then cached for every future user).

The mental model is: your code is the source of truth, not a JSON file.

Why key-based i18n exists in the first place​

Key-based i18n wasn't a mistake — it solved real problems for the era it was built in:

  1. Translation files were the source of truth in pre-2020 workflows where translation teams used desktop tools (TMS like SDL Trados, MemoQ) and engineers received finished JSON/PO/XLIFF files to drop into the codebase.
  2. Keys gave translators context-free strings to work with — they didn't need to read your code.
  3. A consistent key naming scheme made it possible to refactor copy without touching every locale file — change the value at hero.title, all locales pick it up.
  4. Static analysis could detect missing keys at build time.

These benefits are real but they assume a workflow where (a) a translation team owns the locale files, (b) a content/product team writes copy upstream of engineering, and (c) the project is large enough that key reuse pays for itself.

For most apps under, say, 50,000 monthly active users, none of those assumptions hold. Engineers write the copy in the JSX. Translation is "ship to French ASAP because we just signed a French customer." There's no TMS, no translator, no review workflow. Key management is pure overhead.

What you actually gain with keyless i18n​

1. Setup time drops from days to minutes​

A typical key-based i18n setup involves: picking a library, configuring the loader, defining a key naming convention, setting up your build to bundle locale files, choosing a locale-detection strategy, wiring up a language-switcher, and writing a contributing doc so future devs follow the convention.

A keyless setup is: install the SDK, paste your API key, wrap strings. See the quick-setup guide — most teams are translated in under 10 minutes.

2. The code stays readable​

Compare:

// Key-based
<button>{t("checkout.payment.confirm.cta")}</button>

// Keyless
<button><I18nKeyless>Confirm payment</I18nKeyless></button>

You don't have to context-switch to a JSON file to understand what the button says. New engineers onboard faster. Code review is easier. PRs that change copy are self-documenting in the diff.

3. No missing-key bugs​

In a key-based system, deleting a key from en.json but forgetting to delete it from fr.json (or vice versa) is a class of bug that ships silently. Keyless i18n doesn't have keys, so the bug class doesn't exist.

4. Translations are automatic by default​

When the SDK encounters a string it hasn't seen before in the requested target locale, it asynchronously requests a translation. That translation is then cached and served to every other user in that locale — you don't pay the latency twice. You can override any specific translation manually from the dashboard when nuance matters.

5. Adding a new locale is a config change, not a project​

  languages: {
    primary: "en",
-   supported: ["en", "fr"],
+   supported: ["en", "fr", "de", "es", "it"],
  },

The library handles the translation generation for every existing string, in the background. No "spin up a 3-week translation project" meeting.

What you give up​

Honest list:

  • You lose static analysis. You can't fail a build because a translation is missing — there's no "missing key" concept. Mitigation: the dashboard shows you which strings have been seen but not yet manually reviewed, so you can audit production usage.
  • You give up TMS-style review workflows (assigned reviewers, glossaries, translation memory across projects). If you have a five-person localization team, you want Lokalise or Crowdin, not us.
  • You're betting on a service. Keyless i18n needs a backend to look up translations and call the AI. That's a SaaS dependency. Mitigation: client SDKs cache aggressively, so a backend outage degrades to "static fallback to source language" rather than an outright break.
  • Pluralization and ICU MessageFormat are simpler but less expressive. If your product genuinely needs {count, plural, =0 {no items} =1 {one item} other {# items}}, key-based libraries handle that more elegantly. Keyless can interpolate values (see the value replacement guide), but ICU plural rules are a known limitation.

When keyless i18n is the right call​

✅ You're an early-stage SaaS or indie product. ✅ Engineers write the copy directly in JSX/TSX. ✅ You want to add 3+ languages this quarter without a dedicated localization budget. ✅ Your team is fewer than 20 engineers and there is no localization team. ✅ Your translations are mostly product UI copy (buttons, labels, short paragraphs), not long-form marketing or legal text.

When key-based i18n is the right call​

✅ You have a TMS workflow with assigned translators per locale. ✅ Your product is a CMS, e-commerce platform, or marketplace where content is user-generated (not engineer-written). ✅ Your legal/marketing department needs to review every copy change before it ships. ✅ You're targeting 30+ locales with consistent terminology across all of them — at that scale, glossaries and translation memory matter.

How keyless i18n compares to specific tools​

We have full comparison articles for each of these — short summaries here:

  • vs i18next — i18next is the React/JS standard. Keyless wins on setup speed, readability, and zero key management. i18next wins on ecosystem, ICU plural rules, and TMS integration. Read i18n-keyless vs i18next.
  • vs react-intl (FormatJS) — react-intl shines on ICU MessageFormat and FormatJS's number/date formatting. Keyless wins on the developer experience for product UI. Read i18n-keyless vs react-intl.
  • vs Lokalise — Lokalise is a translation management platform; we're a developer SDK. Different products. Lokalise is right for teams with translators; keyless is right for teams without. Read i18n-keyless vs Lokalise.
  • vs Crowdin — Same shape as the Lokalise comparison: Crowdin is a TMS optimized for distributed translation teams. Keyless is for engineering teams who want translation as infrastructure. Read i18n-keyless vs Crowdin.

If you're researching alternatives broadly, the best i18next alternatives in 2026 roundup compares the full landscape.

Migrating to keyless from another library​

If you already have a key-based setup and you're tired of maintaining it, there's a clean path forward. We have step-by-step guides for the common migrations:

The general approach: dual-run for a sprint (both libraries active, keyless serves new strings, old library serves legacy keys), then sweep through and replace t("hero.title") calls with <I18nKeyless> components.

How keyless i18n works under the hood​

Three moving parts:

  1. The client SDK (i18n-keyless-react, i18n-keyless-node) — wraps your strings, reads from a cache (localStorage, IndexedDB, MMKV, AsyncStorage, or your own adapter), falls back to the source language if a translation is missing, and asynchronously requests new translations.
  2. The translation API — receives a source string + target locale + optional context, looks up an existing translation, calls Mistral AI if it doesn't exist, and stores the result. Tokens are tracked for billing.
  3. The dashboard — manage projects, view usage, override translations, manage manually-curated entries, configure supported locales.

The key invariants:

  • The source string is the cache key — same string + same target locale = same translation, deterministically cached.
  • Cache invalidation is timestamp-based — last_translation_updated_at on the project tells the SDK when to re-fetch (with a 10-minute buffer to avoid thundering-herd refresh races).
  • Two parallel database tables (one keyed on French, one on English) handle the primary-language branching efficiently.

A worked example: "Welcome, {name}!"​

import { I18nKeylessText } from "i18n-keyless-react";

function Welcome({ user }) {
  return (
    <h1>
      <I18nKeylessText replace={{ '{name}': user.name }}>
        {"Welcome, {name}!"}
      </I18nKeylessText>
    </h1>
  );
}

If the user's locale is fr, the SDK looks up "Welcome, {name}!" in the French translations, gets back "Bienvenue, {name} !", and substitutes user.name for {name}. If the translation doesn't exist yet, it queues a request and renders the source string in the meantime.

For more on interpolation patterns, see the value replacement guide.

FAQ​

Is keyless i18n production-ready?​

Yes. The architecture is intentionally simple: SDK with local cache + server-side translation API. The failure mode is "fall back to source language", not "crash." Several SaaS products run on it in production today.

What happens if the translation service goes down?​

Cached translations keep serving. New strings render in the source language. No errors.

Can I override an automatic translation?​

Yes — every translation can be manually overridden from the dashboard. AI generates the first draft; you have final say.

How is this different from just calling Google Translate at runtime?​

Two big differences: (1) translations are cached server-side and shared across all your users, so you don't pay per-call per-user; (2) you can override and review translations, version them, and track usage per string.

Does it work with Server Components / SSR?​

Yes — the Node.js SDK (i18n-keyless-node) handles server-side translation. Use awaitForTranslation to fetch translations during render.

What languages are supported?​

Currently: English, French, Dutch, Italian, German, Spanish, Polish, Portuguese, Romanian, Swedish, Turkish, Japanese, Chinese, Russian, Korean, Arabic, Hungarian, Czech. Adding a new language is a backend change — request via support if you need one.

Next steps​