5 posts tagged with "React"

If you searched for "how to add i18n to a React app", most results will walk you through react-i18next — install, configure, set up a key naming convention, write locale JSON files, wire up a language switcher, and you're translated. Two days of work for an MVP-stage app.

This guide shows the modern alternative: i18n-keyless. You'll go from zero to multilingual in 5 minutes. We'll cover the setup, the core API, language switching, edge cases, and how to handle interpolation.

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.

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.

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.

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.