JSON Translator: How to Translate a Localization JSON File into Every Language

To translate a localization JSON file, upload your source file once and export one translated file per language with byte-identical structure. The translation itself is the easy part — what breaks is everything around it: nested objects flattened into dot-notation, interpolation variables translated into gibberish, and plural keys copied across languages that need a different number of forms. This guide covers the three failure modes and how to avoid all of them.

Which JSON files this covers

"i18n JSON" is a convention, not a standard, so the same file shape shows up across most of the JavaScript ecosystem:

• i18next / react-i18next — nested objects, {{variable}} interpolation, plural suffixes like item_one and item_other.
• react-intl / FormatJS — usually flat, ICU message syntax with single braces.
• vue-i18n — nested, single-brace interpolation, optional pipe-separated plurals.
• Angular and Next.js setups that read plain JSON message catalogs.
• Plain key/value JSON maintained by hand, with no library conventions at all.

All of them are the same job: translate the values, never the keys, and return the identical shape.

The three things that break

1. Nesting

A key like settings.notifications.title lives three objects deep. Tools that flatten to dot-notation and rebuild it frequently rebuild it wrong — and a translated file whose structure does not match the source does not error. It silently falls back to English, so you find out from a user, months later.

{
  "settings": {
    "notifications": {
      "title": "Notifications",
      "description": "Choose what we send you"
    }
  }
}

Key order and depth must survive the round trip exactly.

2. Interpolation syntax differs per library

The variable placeholder is not portable, and a translator — human or machine — who does not recognise it will happily translate it:

• i18next: {{count}} — double braces
• react-intl and vue-i18n: {count} — single braces
• Older setups: %s, %1$s, or {0}

Every one of these must come back verbatim. A translated {{anzahl}} is a runtime bug that renders the literal placeholder to your user.

3. Plural forms are not one-size-fits-all

English has two plural categories. Japanese, Korean, and Chinese have one. Arabic has six. i18next encodes them as key suffixes, so a source file with item_one and item_other needs six keys in Arabic and one in Japanese. Tools that mirror the English key set produce grammatically broken output in roughly a third of the languages you ship.

Translate your JSON in three steps

1. Upload your source file. Localize Your App reads nested and flat JSON, detects interpolation variables in every syntax above, and locks them so they cannot be translated, reordered, or dropped.
2. Pick your languages. Any of the 39 App Store Connect locales. Plural keys are expanded to the correct form set for each target language rather than copied from English.
3. Review, then download. Edit anything side by side against the source, then export one JSON per language with the same nesting and key order as your original.

On your next release, upload the updated source file — translation memory refills every unchanged string for free, so you only pay for what actually changed.

A few rules worth enforcing whatever tool you use

• Never translate keys. Only values. This sounds obvious and is the single most common corruption in hand-rolled scripts.
• Give translators context. A bare string "Open" is a verb or an adjective depending on the screen; without a comment, half your languages will guess wrong.
• Keep one source of truth. Edit the source language file only, and regenerate the rest. Hand-editing target files is how they drift out of structure.
• Validate before you ship. Compare key sets between source and target — a diff catches structural breakage that the app itself will hide behind fallbacks.

Framework-specific setup

If you are wiring this into React Native with i18next or react-intl, the React Native localization guide covers the i18n.js setup, device-language detection, and where the translated files go. For other formats entirely — Xcode .strings, Android strings.xml, Flutter .arb — see the file format overview.

Frequently asked questions

How do I translate a JSON file into multiple languages at once?

Upload the source file once and select every target language in a single pass, rather than running the file through a translator repeatedly. That is the only way plural forms and interpolation variables stay consistent across languages, and it means one review pass instead of one per language.

Can I use Google Translate on a JSON file?

Not directly, and not safely. Pasting JSON into a general-purpose translator translates the keys along with the values and mangles interpolation placeholders. You need something that parses the file as structured data and translates values only.

Will the translated file keep my nesting?

It has to, or your app silently falls back to the source language. Any tool worth using guarantees the output shape matches the input — check a deeply nested key in the output before you trust a new tool with your whole catalogue.