In the last post, I talked about LQA discipline — flagging only what’s actually broken, rating it clearly, and how getting this wrong in either direction can quietly contaminate the Translation Memory. Here’s what that judgment actually looks like in practice, using a sample localization sheet.
Image: Sample Localization Sheet
The “obvious” bug that isn’t
At a glance, this line below looks like the kind of thing LQA is supposed to catch:
“Fire Mage Jun believes he inherited the primordial flame. He burns everything with the fire fire burning fire of passion. Fiiire!”
Repeated word, broken sentence structure, non-standard punctuation. Flagging it would be the wrong call. The notes column specifies that the character is meant to sound grammatically unhinged, fixated on the word “fire,” as a personality trait. The “error” is the character voice, not a mistake.
This is the core judgment call in LQA: recognizing when something that pattern-matches to “broken” is actually intentional — and knowing to check the context before assuming otherwise.
The \n convention: know the format before you flag it
The same sheet uses \n as an explicit line-break command, noted directly in the source: “\n indicates a line break — the second sentence will appear on the next line.” Without that note, a reviewer unfamiliar with the convention might read \n as a literal typo or a stray character needing removal, rather than a formatting instruction that renders correctly once implemented in-game. Small detail, but exactly the kind of thing that trips up a reviewer moving fast. And when you are checking translated text inside the actual running game, you can tell if they are correctly broken down.
Invented names: there’s no “correct” spelling to check against
The sheet also introduces two fantasy names — Jaan and Belnor — with a note stating they’re invented terms with no fixed romanization. A reviewer checking these against a “standard” transliteration would be checking against something that doesn’t exist. Flagging inconsistent spelling here would be a false positive, not a catch.
Note: These names still need to stay consistent once a spelling is chosen — the flexibility is in the initial romanization, not in switching spellings project to project. Ideally, this is exactly the kind of thing that should be defined upfront in a glossary or style guide, rather than left to each translator’s judgment call in the moment. A missing glossary entry here isn’t a translator error — it’s a process gap worth flagging back to the client or PM.
Why this matters beyond these (much simplified) cases
None of these are genuine bugs. Flagging them would waste a fix-cycle — and if the wrong “fix” got implemented and fed back into the Translation Memory, it could quietly overwrite the writer’s actual intent in future content pulling from that same source. Good LQA isn’t just about catching what’s broken. It’s about knowing, with context, what isn’t.