Not all vendors carry the same risk. This is a walkthrough of a two-round approach to vendor risk assessment to figure out who’s actually risky (and why).
Round 1: Profile Screening
Before a vendor touches a project, build a profile: language pair, specialization, CAT tool proficiency, years of experience. This tells you if someone could be a good fit. It doesn’t tell you if they will be.
Take a legal translation project. It needs frequent communication with subject matter experts and a responsive quality review process. A profile confirms legal specialization. It can’t confirm communication skills.
Round 2: Performance Data
Chart: Vendor Performance, Turnaround Time vs. Linguistic Accuracy
Past performance fills that gap: turnaround time, accuracy, responsiveness. In the chart above, Vendor A is fast and accurate, low risk for urgent legal work. Vendor D is slow and less accurate, high risk even with a strong profile. Vendors B and C depend on what the project prioritizes: speed or accuracy.
The limit
Profile and performance data work together. Most teams don’t run this level of assessment on every linguist, since it takes time. It shows up mainly for larger operations, where one unreliable vendor affects many projects at once.
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.
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 (or multilingual) translation, a dedicated native-speaker review, and a final review pass. 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.
More on the LQA discipline, that fair judgement on what gets fixed on the following post with some examples.
