6 posts tagged with "i18next"

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.

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.

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.

i18next is the de-facto standard for JavaScript i18n. It has been around since 2011, ships in tens of thousands of production apps, and has plugins for every framework you can name. So why would anyone build something different?

The short answer: i18next was designed for a workflow that most modern teams no longer have — translators receiving JSON files, glossaries, TMS pipelines, key management as a discipline. If your "localization team" is one engineer adding French because a customer just signed, the overhead doesn't pay off.

This is an honest comparison. We use i18n-keyless ourselves and we'll happily tell you when i18next is the better fit.