Translation File Validator for Localization QA
Translation file validation checks the delivered file as an engineering artifact, not only as translated text.
Examples
{
"nav.home": "Home",
"nav.settings": "Settings",
"nav.help": "Help"
}{
"nav.home": "Inicio",
"nav.help": "Help",
"nav.legacy": "Anterior"
}Missing key: nav.settings Extra key: nav.legacy Same as source: nav.help
The target can ship with a missing settings label, stale legacy copy, and an untranslated help label.
Who uses this check
Localization PMs use translation file validation to review delivered files. Vendors use it before handoff to avoid preventable rework. Developers use it before merging resources. QA teams use it to reduce bugs that come from file integrity issues.
The owner changes by workflow, but the risk is shared: one drifted file can create engineering rejection, client comments, or a failed localized build.
Beyond JSON syntax
A file can be valid JSON and still not be the right translation file for the release. It may contain obsolete keys, omit new keys, rename placeholders, or preserve English strings by mistake.
LocaleQA compares source and target JSON as-is with deterministic rules. It does not normalize content, generate translations, or decide whether a sentence is fluent.
Manual versus automated review
Manual review is useful for language and context. Automated validation is better for exhaustive path-by-path comparisons, token preservation, whitespace drift, and repeatable reporting. The two checks should complement each other.