Localization QA

Localization QA for Web, Mobile, and Java Files

Localization QA is the pre-release check that confirms localized files still match the structure your product expects.

Supported: JSON, YAML, XLIFF, Android XML, Apple .strings/.xcstrings, and Java .properties.

Examples

Source JSON
{
  "checkout.total": "Total: {amount}",
  "checkout.pay": "Pay now"
}
Target JSON
{
  "checkout.total": "合計: {price}",
  "checkout.cancel": "キャンセル"
}
Expected finding
Missing key: checkout.pay
Extra key: checkout.cancel
Placeholder mismatch: {amount} -> {price}
Release impact
The checkout screen may lose its payment CTA, keep stale copy, or fail to inject the total amount.

What localization QA owns

In a 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. Supported web, mobile, and Java resource files 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 syntax is not enough

A target can have valid JSON, YAML, XLIFF, Android XML, Apple, or Java Properties syntax while still not being ready for release. Valid syntax does not prove that it contains the same entries, 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.

Related pages