Your Translations Are Correct. Your Product Is Still Broken.

Every string passed review. The LQA report came back clean. And the first support ticket from your German users is a screenshot of a button with half a word in it.

This is not a translation failure. It is a measurement failure, you reviewed the text, and shipped the product.

Translation quality and localization quality are different things

Translation quality asks: is this string a faithful, fluent rendering of the source?

Localization quality asks: does this product work correctly for a user in this market?

The first question can be answered by reading a spreadsheet. The second cannot be answered without looking at the running product, because most of what determines the answer is not in the string at all, it is in the container the string lands in, the screen it appears on, and the elements it sits next to.

A translation can be perfect and still be a defect:

• The word is correct but 40% longer than the button that holds it

• The term is right in isolation but contradicts the label on the previous screen

• The sentence is grammatical but the variable it interpolates produces nonsense at runtime

• The register is appropriate for marketing copy but this is an error message

• The date format is a valid rendering of the source and completely wrong for the market

Every one of these passes a string-level review, because at the string level nothing is wrong.

Why the spreadsheet loop persists

The standard localization QA workflow was designed for documents. Export, translate, review, deliver. It survived the move to software largely unchanged, even though software introduced a variable documents never had: the text is rendered by a system you do not control at review time.

The loop persists for practical reasons. Reviewers are usually external. Giving an external linguist access to a staging environment is an access-management problem. Giving them a bilingual XLIFF is not. So the industry optimized for the workflow that was easy to run, and accepted the category of errors that workflow cannot see.

The result is a quiet division of responsibility where nobody owns the gap. The linguist reviewed the text and signed off. The QA engineer tested the functionality and signed off. The layout bug that only appears in Finnish at 375px belongs to neither of them.

The economics: translation is cheap, context is expensive

The cost of producing a translated string has fallen dramatically. Machine translation, TMs, and now LLMs have made the raw text the cheapest part of the process.

What has not gotten cheaper is knowing whether that string works where it lands. That still requires someone to open the product, in that locale, on that screen, at that viewport, and to know enough about both the language and the interface to recognize a problem.

So the bottleneck moved. Teams that scaled translation volume 10x without changing how they verify context did not get 10x more localized product. They got 10x more unverified surface area.

What continuous localization QA looks like

Fixing this is less about better reviewers and more about changing where the review happens.

Review the rendered product, not the source file. The unit of inspection should be the screen a user sees, with the text in place, at real viewport sizes. Errors that only exist in context can only be found in context.

Make it continuous rather than batch. Localization debt accumulates between release cycles, in the strings that changed, in the components that were restyled, in the locale nobody re-checked because it was fine last quarter. A quarterly audit measures a snapshot. Monitoring measures drift.

Cover the full surface, not a sample. Manual review scales linearly with locales times screens times breakpoints, which is why it always ends up as sampling. Automated in-context scanning is the only approach where adding the twelfth language does not add a twelfth of a headcount.

Score consistently. Findings need a shared severity vocabulary, MQM is the established one, so that a report is comparable across releases and actionable by people who are not linguists.

The question worth asking your team

Not is our translation quality good? You probably already know the answer, and it is probably yes.

Ask instead: which categories of localization defect is our current process structurally incapable of detecting?

If the honest answer includes layout, context, and locale-convention errors, which it does for any team reviewing from exports, then those errors are not being caught late. They are being caught by users.

Start free