How to Manage i18n in a React App
A practical guide to organizing translation keys, choosing a library, and keeping your localization workflow sane as your app grows.
What is i18n and why does it matter?
Internationalization (i18n) is the process of designing your app so it can be adapted for different languages and regions without code changes. The "18" in i18n stands for the 18 letters between the "i" and the "n" in "internationalization" — a classic developer shorthand.
For most apps, i18n means externalizing all user-facing strings into translation files and loading the right language at runtime. Done right, adding a new language requires zero code changes — just a new set of translation files.
Choose a library early
The two most popular i18n libraries for React are react-i18next and react-intl (part of FormatJS). Both are mature and well-maintained.
- react-i18next — simpler API, great defaults, good for most projects.
- react-intl — more powerful formatting (plurals, dates, numbers), better if you need ICU message syntax.
For most new projects, react-i18next is the right choice. It's easier to set up and its key-based approach maps well to how translation tools (including Locly) work.
Organizing your translation files
The most common structure is one JSON file per language, placed in a locales/ directory:
src/
locales/
en.json
de.json
fr.json
es.json Each file contains a flat or nested object of key-value pairs:
{
"nav.home": "Home",
"nav.pricing": "Pricing",
"hero.title": "Manage All Your App Languages",
"hero.cta": "Get started free"
} For larger apps, split by namespace (feature area) to avoid one giant file:
locales/
en/
common.json
dashboard.json
settings.json The problem with scattered JSON files
As your app grows, translation files become hard to manage. Common pain points include:
- New keys added by developers but not translated yet — causing missing strings in production.
- Stale keys that are no longer used but still live in the files, creating noise.
- Translators working in spreadsheets or emailing JSON files back and forth.
- No clear process for reviewing and merging translation changes alongside code changes.
The root cause is that translation files live in Git alongside code, but there's no tool that bridges the developer workflow with the translation workflow.
A better workflow
The solution is to connect your translation files to a dedicated tool that lets developers manage keys and translators manage values — without either group needing to understand the other's tools.
Locly connects directly to your GitHub repository. You keep your JSON/YAML files in Git as the source of truth, but Locly gives you a dashboard to add keys, manage languages, and sync changes back to your repo via a pull request. No more emailing files. No more merge conflicts from manual edits.
Key takeaways
- Pick react-i18next for most React projects — it's simple, flexible, and widely supported.
- Organize translation files by language (and by namespace for large apps).
- Use a flat key structure like
"section.element"for easy lookup. - Connect your files to a translation management tool as soon as you have more than one language or more than one person involved.
Ready to simplify your localization?
Locly connects to your GitHub repo and gives your whole team a clean interface for managing translations.
Get started free