Localization QA for JSON Translation Files
Localization QA is the pre-release check that confirms localized files still match the structure your product expects.
Examples
{
"checkout.total": "Total: {amount}",
"checkout.pay": "Pay now"
}{
"checkout.total": "合計: {price}",
"checkout.cancel": "キャンセル"
}Missing key: checkout.pay
Extra key: checkout.cancel
Placeholder mismatch: {amount} -> {price}The checkout screen may lose its payment CTA, keep stale copy, or fail to inject the total amount.
What localization QA owns
In a JSON localization workflow, developers usually own the source file structure, localization PMs own handoff completeness, vendors own delivery quality, and QA or reviewers own release readiness. The same file can pass through all four groups, so small structural mistakes often appear between export, translation, review, merge, and final build.
LocaleQA checks the file-level issues that break releases: keys, placeholders, tags, whitespace-sensitive strings, same-as-source values, and glossary requirements. It does not score translation quality, rewrite copy, or replace human linguistic review.
Why valid JSON is not enough
A target file can parse as valid JSON while still being not ready for release. Valid JSON only proves the syntax is readable; it does not prove the target contains the same keys, preserves runtime tokens, or avoids stale strings.
Manual review can catch obvious problems in small files, but it becomes unreliable when a release contains hundreds of nested keys or multiple handoffs. Automated file QA applies the same checks every time and produces a report that teams can review without turning it into a language review.
When to run it
Run localization QA after translation or vendor delivery, before merging files into a release branch, before product QA starts, and before sending delivery reports. The best moment is late enough to include the delivered target file, but early enough that a missing key does not become an engineering rejection.