Where LQA actually sits in the localization pipeline
My take: LQA — sometimes called ICR, In-Context Review — isn’t a standalone check. It’s a specific, late-stage gate in the pipeline, positioned deliberately after strings are translated, reviewed, and built into their final layout. That timing matters: by the LQA stage, the rule is no preferential changes. The job isn’t to make the translation “better” — it’s to catch what’s actually broken once text lives in context: truncation, layout breaks, honorific mismatches, anything Review couldn’t have caught in isolation.
Static/poster and multimedia projects follow a similar shape, but often loop: review → DTP → ICR → implement → ICR again, sometimes several rounds. ICR here is usually done via annotated screenshots for a single static asset, or a spreadsheet with a severity column for video — and that severity rating is what keeps a QA round from turning into an open-ended stylistic negotiation.
The failure mode across every workflow is the same: if a translation error slips through this late, someone has to go back and update the Translation Memory, or the TM falls out of sync with what actually shipped — risking the same error resurfacing in future content pulled from that TM. That’s why LQA discipline — catching only true bugs, rating them clearly — isn’t process for its own sake. It’s what keeps the whole pipeline from quietly breaking downstream.
Example: LQA tracking sheet
Below is an example of the format I use to log and prioritize issues during LQA — pairing a screenshot reference with the problematic text, the corrected text, a plain description of the issue, and a severity rating.
A few things this format is built to solve:
- Severity first. Every issue gets classified — Launch Blocker, Major, Minor, or Preferential — right away. This keeps a review round from turning into an open-ended stylistic debate. A Preferential change (something that reads slightly better but isn’t wrong) doesn’t hold up a release the way a Launch Blocker (text bleeding out of a button, font corruption breaking legibility) does.
- Rounds are tracked separately. Fixes get implemented, then re-checked in a follow-up round — an issue flagged as a Launch Blocker in Round 1 can reappear in Round 2 at a lower severity, showing the fix improved the issue without fully resolving it.
- Screenshot-first, not just text. For static/poster assets, the screenshot reference is critical — the same string can look completely fine on its own and still overflow, wrap wrong, or clip once it’s laid into the actual visual.
How it looks in game localization
Game localization follows the same core logic but adds real steps upstream and layers in more QA touchpoints before LQA.
- Pre-production work most general UI localization skips — receiving the actual build and design docs, playtesting to build a style sheet, and assembling a task force based on genre (an RPG and a mobile puzzle game need different linguistic instincts).
- Three separate QA touchpoints before LQA — bilingual translation, a dedicated native-speaker review, and a final review pass — versus a single generic Review stage. Games lean harder on native-speaker judgment earlier, since tone, honorifics, and genre voice are harder to get right the first time than straightforward UI copy.
- LQA here means in-app build review — checking translated text inside the actual running game, not a mockup. Same core discipline as before: catch what’s broken in context, don’t relitigate style.