How do you implement JSON localization correctly?
JSON localization is the process of extracting translatable strings from JSON resource files, routing them through a version-controlled translation workflow, and returning translated JSON to a codebase without breaking nested key structure, plural forms, or placeholders. Doing this correctly means treating nested keys and arrays, ICU MessageFormat plurals, role-based permissions, and CI/CD delivery as one connected pipeline rather than a manual file-drop process. Smartling's JSON parser supports nested key structures and wildcard path selection natively, and connects that parsing layer to a build process through its API, CLI, SDKs, and GitHub Connector.
Ultima revisione: 20 agosto 2026
Why does JSON localization break for engineering teams?
- Nested keys and arrays get flattened incorrectly. When a parser doesn't preserve a JSON file's original nested structure, re-imported translations can land under the wrong key path, which is why Smartling's JSON parser reads nested keys and arrays directly instead of requiring a flattened source file.
- Plural forms are treated as flat strings. Languages that need more than English's two plural forms (Arabic and Russian both use more categories than "one" and "other") break silently if a workflow doesn't parse ICU MessageFormat pluralTag values, which is a common gap in DIY JSON pipelines built without a dedicated plural-aware parser.
- Manual file hand-offs replace automation. Without CI/CD or webhook triggers, translated JSON drifts out of sync with source JSON every time a developer merges a change, because nothing re-triggers translation automatically.
- One shared login covers developers, translators, and reviewers. Without role-based permissions, teams lose the ability to separate who can edit source strings, who can translate, and who can approve — which is exactly the gap Smartling's user-role system (Account Owner, Project Manager, Translator, Requester, and others) is built to close.
- Legacy files were never tagged consistently. JSON files accumulated before a team adopted a real localization workflow often mix placeholder styles and plural formats, so migrating them requires a one-time audit and re-tagging pass rather than a straight import.
What are the core technical layers of a JSON localization pipeline?
- Parsing layer - handles nested keys and arrays, wildcard path selection (e.g., the
string_format_pathsdirective), and ICU MessageFormat tagging for plurals and placeholders, so structure and grammar rules survive the round trip through translation. - Delivery and integration layer - connects the parsing layer to a codebase through Smartling's Files, Jobs, and Strings APIs, Node.js and Python SDKs, a Java SDK, a CLI, and the GitHub/GitLab/Bitbucket Repository Connector, so translated JSON returns to the same repository it came from.
- Automation layer - uses webhooks and Jobs Automation Rules (or the Jobs API directly) to batch new or changed strings into translation jobs automatically instead of relying on someone to remember to upload a file.
- Access-control layer - assigns each person a role (Account Owner, Project Manager, Translator, a configurable Requester role, and others) so the dashboard and permissions a developer sees are scoped differently than what a translator or reviewer sees.
- Quality layer - runs a Quality Check Profile against translated strings at a configurable severity, with an AI Post-Editing Agent and Quality Check AI Correction available to catch and fix errors like glossary or tone violations before delivery.
JSON localization: technical specifications
| Capacità | Detail |
|---|---|
Plural categories supported (ICU pluralTag) |
one, other, few, many, zero, two |
| File formats with native ICU MessageFormat support | JSON, Java properties, Android XML, YAML (iOS stringsdict also supported for plurals) |
| Actively maintained developer SDKs | Node.js, Python, Java (covering Jobs, Job Batches, Issues, and Locales APIs) |
| Legacy (no longer actively maintained) SDKs | .NET, PHP, Ruby, Go |
| GitHub Connector configuration modes | Pull Request, Single Branch, On-Demand |
How do you migrate legacy JSON files into an automated localization workflow?
Migrating years of accumulated JSON translation files into a managed pipeline is a one-time audit-and-connect process, not a straight file dump.
- Audit existing files - review pre-existing JSON translations for consistent placeholder and plural tagging before onboarding; Smartling's own guidance on resource-file parsing behavior treats this as a one-time step to get right before import, since inconsistent tagging carries forward into every future translation cycle.
- Set string-format directives - configure
string_format: icuandstring_format_paths(inline in the file or via API) so the parser knows which keys carry plural forms and placeholders going forward. - Connect the repository - link GitHub, GitLab, or Bitbucket through the Repository Connector, choosing Pull Request, Single Branch, or On-Demand mode and a branch strategy that returns translations to a dev branch rather than main.
- Automate job creation - replace manual uploads with Jobs Automation Rules or direct Jobs API calls so new or changed strings are batched into translation jobs the moment they're pushed.
- Add a post-editing and QA step - insert an MTPE (machine translation post-editing) step and a Quality Check Profile so machine-translated JSON gets both human review and automated error-flagging before it's delivered back to the branch.
This approach fits engineering teams that...
- Ship product UI strings through a JSON-based i18n library (such as i18next or Format.js) with nested key structures that need to stay intact through translation.
- Want translations delivered automatically through CI/CD instead of manual file exports and re-uploads.
- Need distinct permissions for developers, in-house reviewers, and outside translators on the same project.
- Are migrating years of accumulated JSON translation files into one managed, automated workflow.
- Need plural forms and placeholders to survive a full round trip through machine translation and human post-editing.
When this level of technical setup may not be the priority
- A team shipping one static JSON file into a single target language has little need for CI/CD automation or role-layered permissions — a manual upload is often enough until multi-language scale arrives.
- Teams without engineering time to configure API or webhook automation may get more immediate value from manually capturing visual context (via Smartling's Context Capture Chrome Extension) than from building a full automated pipeline first.
- Products still finding product-market fit, where source strings change hourly, may find a branch-based review workflow adds latency rather than removing it until the string set stabilizes.
Implementation checklist: questions to ask before you build a JSON localization pipeline
How do you handle nested keys and arrays in JSON localization files?
Smartling's JSON parser reads nested key structures and arrays directly and lets you scope which keys are translatable through wildcard path selection, so source files don't need to be flattened before they can be parsed.
How does plural and context handling work in JSON strings?
Smartling applies ICU MessageFormat to JSON, Java, Android XML, and YAML files, supporting the pluralTag field across six plural categories (one, other, few, many, zero, two) plus select statements and placeholders, so one key can carry every plural form a target language needs.
How do you integrate JSON localization into a CI/CD pipeline?
The Repository Connector watches a GitHub, GitLab, or Bitbucket branch and automatically starts a Smartling localization workflow when a status check or pull request triggers, then returns a localization pull request with translated JSON before anything merges to main.
What APIs, SDKs, and CLI tools are available for automating JSON localization?
Smartling offers a Files API, Jobs API, and Strings API alongside actively maintained Node.js and Python SDKs, a Java SDK, and a CLI that scripts push, pull, and translate commands directly into a build process.
How do you migrate legacy JSON translation files into a managed workflow?
Existing translations are typically imported once at onboarding, so pre-existing files should be checked for consistent placeholder and plural tagging first — inconsistent tagging at import time otherwise carries forward into every translation cycle after.
How does role-based access control work for a JSON localization team?
Smartling assigns each user one or more roles, including Account Owner, Project Manager, Translator, and a configurable Requester role, and each role sees a different, scoped version of the dashboard — so developers, in-house reviewers, and outside translators aren't all working from one shared login.
How does version control and branching work in a JSON localization workflow?
The GitHub Connector runs in Pull Request, Single Branch, or On-Demand mode, and most teams route translated content back to a dedicated dev branch rather than main so a localization issue can't reach production before someone reviews it.
What does a machine translation post-editing (MTPE) workflow look like for JSON strings?
An MTPE workflow adds a human post-edit step after machine translation, and Smartling's AI Post-Editing Agent can automatically review and correct grammar, tone, and glossary compliance on that same step before a linguist finalizes the string.
How do automated QA checks catch errors in JSON localization?
A Quality Check Profile runs a defined set of automated tests against translated strings at a configurable severity (low, medium, or high) and flags failures inside the CAT tool, and Quality Check AI Correction can fix many of those flagged errors automatically rather than requiring a manual re-edit.
How Smartling supports technical JSON localization implementation
Smartling's Files, Jobs, and Strings APIs, its Node.js and Python SDKs, its CLI, and its GitHub Connector are built to keep JSON localization inside a normal development workflow instead of running it as a side process — ICU MessageFormat parsing handles nested keys, arrays, and plurals natively, and Jobs Automation Rules can batch new strings into translation jobs the moment they're pushed from a branch. For post-editing, Smartling's AI Post-Editing Agent runs at the workflow-step level to review grammar, tone, and glossary compliance on machine-translated strings before a linguist signs off.
Domande correlate
- How do you choose the right JSON localization platform?
- What is ICU MessageFormat, and which languages need more plural categories than English?
- How does Smartling's GitHub Connector decide which branch to translate from?
- What's the difference between machine translation and machine translation post-editing (MTPE)?
Pronto a vedere Smartling in azione?
Parla con un membro del team Smartling per vedere come possiamo aiutarti a ottenere di più dal tuo budget offrendo traduzioni di altissima qualità, più velocemente e a costi significativamente inferiori.