What is localization QA (LQA)? Two different checks people lump into one term

Localization QA, usually shortened to LQA, is the umbrella term for verifying that translated text is both correct and usable inside the actual game. In practice it covers two kinds of check that have almost nothing in common except that they both happen to involve translated text: whether the language is right, and whether the text works.

Treating these as one undifferentiated task is where most LQA processes lose efficiency — one half needs a human who speaks the language, the other half can and should be automated.

Linguistic quality: is the language right?

Linguistic quality is about the content of the translation itself: does it accurately convey the source meaning, does it read naturally in the target language, is the tone appropriate for the context (a menu label and a villain's taunt call for different registers), and is terminology used consistently with the rest of the game.

None of this can be verified by a machine in any general sense. It requires a person who reads the target language fluently, understands the game's context, and can judge whether a translation that is technically accurate also sounds like something a real speaker of that language would say.

Functional and format quality: does the text work?

Functional or format quality is about whether the translated string behaves correctly as a piece of software, independent of whether the wording is good. Placeholders are a clear example: a template's variable tokens have to survive translation exactly, in a form the code can still parse.

• Placeholders present and correctly formed — no dropped, renamed, or malformed variable tokens
• Text fits its container — no overflow, clipping, or overlap once the (often longer) translated string is rendered
• Encoding is correct — no mojibake or missing glyphs when the target script's characters are displayed
• No missing text — no entry silently left untranslated, blank, or still showing a placeholder value
• Rich-text markup intact — tag pairs and nesting preserved, covered in more depth elsewhere

Where each belongs in the pipeline

Because these two checks need entirely different resources, they belong at different points and cadences in a QA pipeline. Format and functional checks are cheap and deterministic, so they should run on every single string, on every build, automatically — there is no reason to spend a human reviewer's time on something a script verifies in milliseconds.

Linguistic review is expensive and requires scheduling a qualified person's time, so it makes sense to run it less frequently and more selectively — on new or changed strings rather than the whole file every time, and ideally with the help of a checklist so different reviewers apply the same standard.

In-context review vs. file review

A translation can read perfectly in a spreadsheet and still fail once it appears on screen — a synonym that is technically correct but too long for its button, a term that reads fine alone but clashes with the tone of the scene around it, an overflow that only exists because of the specific font at the specific size the UI uses.

In-context review — looking at the text inside the actual running game, not just in a file — catches this category of problem that file review structurally cannot. It is more expensive to set up, which is exactly why teams tend to under-invest in it, but it is the only review method that reflects what the player will actually see.

Why format checks can be automated and linguistic checks cannot

The dividing line is not arbitrary: format and functional checks are structural comparisons — does this token exist, does this string fit this space, is this encoding valid — that have a single correct answer regardless of who is asking. Linguistic quality is a judgment call about meaning, tone, and naturalness in a specific cultural and narrative context, which is exactly the kind of judgment that still requires a human who lives in that language.

A practical LQA process keeps this distinction explicit: automate every check that has a deterministic right answer, and spend human review time only on the checks that genuinely need a person — with a checklist as the bridge that keeps both halves consistent across reviewers and over time.