5 posts tagged with "react-intl"

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 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 — react-intl genuinely wins for ICU-heavy use cases.

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.

react-intl (part of the FormatJS ecosystem) is the i18n library that takes the ICU MessageFormat standard seriously. If you've ever needed to write {count, plural, one {# item} other {# items}} and have it Just Work in Polish, Arabic, and Russian, react-intl is what you reach for.

i18n-keyless takes a different bet: most product strings don't need ICU. They need to be translated, cached, and not require a JSON file. So we optimize for that path.

This is an honest comparison. Both libraries are good at different things.