Adriano Raiano

Posted on Apr 13 • Originally published at locize.com

i18next in Production: Managing Translations at Scale

#javascript #development #typescript #webdev

i18next scales from a weekend project to a production app with millions of users — but the way you manage translations needs to evolve as your project grows. At prototype scale, a locales/en/translation.json file in your repo is all you need. At production scale — 10 languages, multiple teams, thousands of keys — manual file management becomes the bottleneck, not i18next itself.

This post covers the practical problems that appear when managing translations at scale, and the i18next ecosystem patterns that solve them.

Problem 1: Translation files in the repo become a bottleneck

At prototype scale, translation JSON files live in your repo. A developer adds a key, translates it, commits, done. At production scale, this becomes a problem:

Merge conflicts. Two developers add keys to the same namespace. Every PR that touches translations conflicts with every other one.
Translators need repo access. Your German translator shouldn't need to know how to create a Git branch.
Translations block deploys. A feature is done but the French translations aren't ready. Do you ship with missing translations or wait?

Pattern: Decouple translation delivery from code delivery

Instead of bundling translations in your build, load them at runtime from a CDN:

import i18next from 'i18next'
import Backend from 'i18next-http-backend'

i18next.use(Backend).init({
  fallbackLng: 'en',
  backend: {
    loadPath: 'https://cdn.example.com/locales/{{lng}}/{{ns}}.json'
  }
})

With this pattern, translations update independently of your app. Fix a typo, add a language, adjust tone — all without touching code.

The i18next-locize-backend takes this further: translations are served from a managed global CDN with built-in cache invalidation and versioning. No CDN configuration needed on your side.

import Backend from 'i18next-locize-backend'

i18next.use(Backend).init({
  fallbackLng: 'en',
  backend: {
    projectId: 'your-project-id'
  }
})

Problem 2: Nobody knows which keys are missing

At prototype scale, one developer manages all the keys. At production scale, different teams own different namespaces, and nobody has a complete picture of what's translated and what's not.

Common symptoms:

Users see untranslated keys in production (the checkout.confirmButton incident)
A new feature ships with 12 languages but only 8 have translations
Nobody knows that the emails namespace hasn't been touched in 3 months

Pattern: saveMissing + coverage tracking

i18next's saveMissing feature detects untranslated keys at runtime and reports them:

i18next.init({
  saveMissing: true,
  backend: {
    projectId: 'your-project-id',
    apiKey: 'your-api-key' // dev only
  }
})

When a missing key is encountered, it's automatically sent to your translation management system. No manual extraction step, no "did someone add this key?" questions.

With Locize, missing keys appear in the dashboard immediately. Combined with automatic translation, new keys can be translated into all target languages without any manual intervention — using your configured AI or MT provider with styleguide and glossary context.

For build-time key extraction (SSG, SSR, or when saveMissing isn't suitable for your runtime), the i18next-cli scans your source code and extracts all t() calls.

Problem 3: Translation quality drifts over time

At prototype scale, one person writes all translations and they're internally consistent. At production scale, different people translate different parts at different times. "Cancel" becomes "Dismiss" in one dialog and "Abort" in another. Your brand's name for a feature is translated three different ways.

Pattern: Glossary + Translation Memory + Styleguide

These three features work together to maintain consistency:

Glossary: Define approved and forbidden terminology. "Drive" means cloud storage, not driving. "Workspace" is always "Espace de travail" in French, never "Zone de travail."
Translation Memory: When a translator works on a new key, they see how similar strings were translated before. Fuzzy matching surfaces past translations with character-level diffs.
Styleguide: Define tone, formality level, target audience, and usage rules once. Applied automatically to all AI translation providers.

In Locize, all three are injected into AI translation prompts automatically — so even AI-generated first drafts are consistent with your established terminology and brand voice.

Problem 4: No review process for translations

At prototype scale, translations go straight to production. At production scale, a wrong translation in a legal disclaimer or a payment screen is a business problem.

Pattern: Review workflow

Enable per-language review so changes go through approval before going live:

A translator (or AI) creates or modifies a translation
The change is marked as "pending review"
A reviewer accepts or rejects the change
Only accepted translations are promoted to production quality

In Locize, the review workflow is configurable per language. Enable it for customer-facing languages (German, French, Japanese) while keeping it off for internal/developer languages where speed matters more than perfection.

Problem 5: No way to test translations before releasing

At prototype scale, "testing" means refreshing the page. At production scale, you need to verify translations in a staging environment without affecting production users.

Pattern: Branches and versions

Translation branches work like code branches:

Create a translation branch when you create a feature branch
Translate new strings in isolation
Test in staging against the branch translations
Merge the translation branch when the feature ships

In Locize, branches mirror your Git workflow. Each branch has its own CDN endpoint, so your staging environment can point to the branch translations while production serves from the main version.

Problem 6: SaaS customers need different translations

If you build a SaaS product, your customers may need to customize translations — different terminology, different tone, different branding. Managing a separate translation project per customer doesn't scale.

Pattern: Multi-tenant overrides

Locize supports multi-tenant localization: a parent project holds base translations, and each tenant gets a child project that inherits everything but can override specific keys. Each tenant has its own CDN endpoint.

This means:

Base translations are maintained once
Each customer can customize only the strings they care about
Overrides are served efficiently — only the diff, not the full translation set
Tenant users have isolated access — they can't see other tenants or the parent

Problem 7: Translation updates require a deploy

This is the most common friction point at scale. A translator fixes a typo. The fix sits in the TMS waiting for a developer to download the file, commit it, open a PR, get it reviewed, merge it, and deploy. Days pass. The typo is live in production the whole time.

Pattern: CDN delivery with instant publish

When translations are served from a CDN instead of bundled in your build, updates go live without deploying:

Translator fixes the typo in the editor
Clicks "Publish" (or auto-publish is enabled)
CDN cache is invalidated
Next time a user loads the app, they get the fixed translation

In Locize, publishing takes seconds. For the standard CDN, translations propagate globally within minutes. No code change, no build, no deploy, no PR.

The complete production setup

Here's what a production-grade i18next setup with Locize looks like:

Development:
  saveMissing: true → keys auto-appear in Locize
  Auto-translate → AI generates first drafts

Staging:
  Translation branch → isolated from production
  Review workflow → translators verify AI output

Production:
  CDN delivery → translations update without deploy
  Glossary + TM → consistency across 50K keys
  Multi-tenant → per-customer overrides
  MCP server → AI agents manage translations

Each piece is optional — you can adopt them incrementally as your project grows. Start with CDN delivery and saveMissing. Add review workflows when quality matters. Add branches when you have staging environments. Add multi-tenancy when your customers need it.

Getting started

If you're running i18next in production with local JSON files and want to move to a managed workflow:

Register for free — no credit card required
Migrate your project — the CLI imports your existing JSON files
Switch to i18next-locize-backend — one config change, same API
Enable saveMissing — new keys auto-appear in Locize
Enable auto-translate — AI translates new keys automatically

The entire migration takes less than an hour for most projects.

DEV Community