22 posts tagged with "Keyless i18n"

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 — <I18nKeylessText>Welcome to Acme</I18nKeylessText> — 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.

If you ask why a team migrated away from i18next or react-intl, you'll hear specific stories — not abstract critiques. "We shipped a missing-key bug to French users for three weeks." "Our PM keeps asking what homepage.cta.v2.final actually says." "We tried to add Spanish and it became a six-week project."

This article documents the real friction points, drawn from actual migration conversations. If any of these feel familiar, you're not imagining it — they're systemic costs of the key-based workflow.

Every i18n library you've used — i18next, react-intl, Lingui, FormatJS — is built around the same primitive: the translation key. You name a string, you reference it from code, you map it to translations in JSON files. This pattern has dominated for over a decade.

It made sense at the time. It doesn't anymore.

This is an opinion piece about why the assumption that you need keys is outdated, and why keyless i18n is the natural shape for modern engineering teams.

If you're on Lokalise but you've realized you're not actually using TMS features — no translators, no glossaries, no in-context review — and Lokalise has just become an expensive JSON-file storage with AI auto-translate enabled, this guide walks through migrating to i18n-keyless.

If you do use Lokalise's TMS features (translator team, glossaries, branding workflows), don't migrate. Read the comparison — Lokalise is the right tool for that workflow.

If your app is on react-intl (FormatJS) and you've decided to switch to i18n-keyless, this guide walks through the migration end-to-end: dual-run strategy, message-by-message replacement, handling ICU MessageFormat, and finally removing react-intl.

If you haven't decided yet, read the comparison first — the two libraries cover the same CLDR plural rules from opposite directions.

If you've decided to move from i18next to i18n-keyless, this is the practical guide. We'll cover the dual-run strategy (so you can ship the migration incrementally), code transformations, gotchas around namespaces / interpolation / pluralization, and how to handle existing translation files.

Read the comparison article first if you haven't decided yet.

If you've already decided i18next isn't the right fit, the question isn't whether to migrate — it's what to migrate to. The answer depends on what's actually painful about your current setup, how much migration budget you have, and what your team's localization workflow looks like.

This guide is a decision framework for picking the destination.

i18next is the default i18n library in the JavaScript ecosystem. It's also a workflow choice that doesn't fit every team — key management, JSON file maintenance, and TMS-shaped pipelines are overhead if your "translation team" is one engineer adding French.

Here's the honest landscape of alternatives in 2026, what each is good at, and a decision framework for picking the right one.

Crowdin is one of the most established translation management platforms — it powers localization for products like Khan Academy, Discord, Trello, and a long tail of open-source projects. It's particularly strong at community translation (volunteers contributing translations for a project they care about) and at integrating with engineering pipelines.

i18n-keyless is a smaller, more opinionated tool that solves a different problem: making your app multilingual without managing translation as a workflow at all.

If you're trying to decide between them, the question to answer is who translates your strings?

Comparing i18n-keyless to Lokalise is a bit like comparing Stripe to QuickBooks — they both touch money, but they're different products for different jobs.

Lokalise is a TMS (translation management system) — a platform where translators, project managers, and engineers collaborate on locale files. i18n-keyless is a developer SDK that translates strings automatically using AI, with no locale files, no translators, and no project management surface.

If you have a localization team, you want a TMS. If you don't, you want an SDK. Here's the long version.