Quality ยท Core concept
Localization QA
Localization QA is the structured check of localized content before release: linguistic accuracy, terminology consistency, truncation, placeholders, layout, and functional behavior in the real interface.
Also known as: localization qa, lqa, linguistic qa, linguistic testing
How QA teams grade errors, and how severity decides what blocks release
| Severity | Example | Consequence |
|---|---|---|
| Critical | A mistranslated legal term on the checkout screen | Blocks release; fixed immediately |
| Major | Unapproved terminology on a marketing page | Fixed before release |
| Minor | An extra space after punctuation | Fixed in the next cycle |
Linguistic vs functional QA
Linguistic QA checks the words: accuracy, terminology, register, cultural fit. Functional QA checks the experience: truncation, broken placeholders, missing hotkeys, layout breakage, and whether clicking a localized button actually does what it says. Both are localization QA; they catch different failure modes.
Where QA happens
In-context review inside the real product catches what file-based review cannot: text expansion breaking a layout, a label that reads wrong next to its control, strings assembled at runtime in the wrong order. The closer QA happens to the real UI, the fewer issues reach users.
Reviewing machine-translated output
MT output shifts the QA focus: the reviewer judges adequacy and fluency per segment and decides what to correct versus re-translate. Error severity grading matters more, because a minor flaw in low-traffic content may be accepted while the same flaw on a payment screen is not.
Common mistakes
Treating QA as a final polish instead of a design input. Reporting issues without severity, which forces stakeholders to re-triage everything. Skipping functional QA because the strings look right in a spreadsheet.