JSON Localization QA Checklist Before Release
A pre-release JSON localization check compares the exact source and target files that will be shipped, after translation and before merge or delivery.
Supported: JSON, YAML, XLIFF, Android XML, Apple .strings/.xcstrings, and Java .properties.
Examples
{
"cart.count": "{count} items",
"cart.checkout": "Checkout",
"cart.help": "Read <link>help</link>"
}{
"cart.count": "{total}点の商品",
"cart.help": "<link>ヘルプを読む",
"cart.legacy": "以前のカート"
}Missing key: cart.checkout
Extra key: cart.legacy
Placeholder mismatch: {count} -> {total}
Tag mismatch: closing </link> missingA valid JSON file can still ship a missing CTA, use the wrong runtime value, retain stale copy, or break linked text.
1. Confirm the files being compared
Use the finalized source JSON from development and the actual target JSON intended for delivery or merge. Comparing against an older export can produce a clean-looking review while the current release still contains missing or obsolete paths.
Confirm that both files belong to the same product, release, locale, and JSON structure. LocaleQA compares matching formats as provided; it does not guess that two differently named keys are equivalent.
- Final source file
- Actual delivery target
- Matching release or branch
- Matching JSON structure
2. Check structure before wording
First review missing source paths and target-only stale paths. A missing and extra key with similar names can indicate that someone renamed an application key while translating instead of preserving it.
This is separate from linguistic review. The target can read naturally and parse successfully while still failing to provide the entries the application expects.
3. Protect runtime content
Compare placeholder names and counts, inline tags, whitespace-sensitive values, and newlines. Japanese input can also change ASCII placeholder characters into visually similar full-width forms, which the application will not recognize as the original token.
- Placeholder names and multiplicity
- Opening and closing tags
- Full-width token mutation
- Leading, trailing, and internal whitespace
- Line endings
4. Review candidates and keep a record
Review same-as-source values rather than automatically treating every match as an error. Brand names and codes may intentionally remain unchanged; buttons, instructions, and error messages often require attention.
After corrections, rerun the same source-target pair and retain the resulting report with the delivery record. CAT tools and TMS platforms can remain the translation workspace; this final-file check verifies the exported artifact that moves to the next team.