A project manager once forwarded me a QA report with a note: "Only 96% — can you fix the rest before EOD?" There was no "rest." The four percent was a list of false positives the checker had flagged on a Turkmen file, and "fixing" them meant either ignoring them or, worse, breaking correct text to make a green light appear. That's the trap. The score became the deliverable, and the actual translation became an afterthought.
I've watched this shift over fifteen years. QA in a CAT tool used to be a tool the translator ran for themselves — a last sweep before delivery. Now it's a report that gets exported, attached to an email, and read by someone three time zones away who doesn't speak the language and treats the percentage as a grade. That's a category error, and it costs everyone.
The number is not the quality
Every serious tool — Trados, memoQ, Phrase, Xbench running on top — produces a QA pass with a count of "issues." Terminology mismatches, number inconsistencies, tag problems, double spaces, untranslated segments, length overruns. Useful stuff. But the total is a sum of things that aren't comparable. One genuine mistranslation and forty false morphology flags come out as forty-one "issues," and the report ranks the clean-but-nagged file below a file that's fluent garbage.
For Turkmen this is brutal. The checkers key off surface strings. Turkmen agglutinates — a root plus a stack of suffixes for case, possession, number, tense. So the term you locked in the glossary as ulgam shows up in the text as ulgamyň, ulgama, ulgamlary, and the consistency check screams "term not used" every single time. The translation is right. The report is wrong. And the person reading the report can't tell the difference.
So what gets reported up the chain isn't quality. It's the tool's opinion of quality, filtered through a language it was never tuned for, presented as a decimal. The decimal travels well. The context doesn't.
What I actually check, and in what order
When I run QA, I don't chase the score to zero. I triage. There's a hierarchy of harm, and the checker doesn't know it, so I have to.
First, the things that are objectively wrong and objectively dangerous: numbers, units, dates, currency. A checker catches these well and they matter absolutely — a misplaced decimal in an oil-and-gas spec or a legal figure is the kind of error that ends contracts. I clear every number flag by hand, no exceptions. This is where automated QA earns its keep.
Second, tags and placeholders. In software strings a broken {0} or a dropped %s will crash a build or print nonsense to a live user. Also a genuine, high-value check. I trust the tool here more than I trust myself at 11pm.
Third — and this is where judgment starts — terminology. The tool flags a hundred term "misses." I read them, and maybe three are real: a place where I drifted, used a synonym, forgot the client's preferred word. The other ninety-seven are inflected forms doing exactly what Turkmen grammar demands. I fix the three. I leave the ninety-seven. And I do not report ninety-seven as a problem, because it isn't one.
Last, cosmetics: double spaces, trailing punctuation, capitalization. Real but trivial. Batch-fix and move on.
Notice what's missing from any of this: mistranslation, register, whether the text actually reads like something a Turkmen speaker wrote. The QA checker can't see any of that. Not one line of it. The most important layer of quality is invisible to the report that gets emailed as proof of quality. That should bother people more than it does.
The fix is a habit, not a feature
The vendors keep adding smarter checks and AI-assisted quality estimation on top of the old rule-based passes. Fine. Some of it helps — quality-estimation scoring can flag a segment that reads as low-confidence and point you at where to look, which beats scanning cold. But estimation is a spotlight, not a verdict, and the moment an agency turns it into a KPI it becomes the same broken game with a shinier interface.
Here's what I'd ask of PMs, concretely. Don't forward me a QA percentage and ask me to raise it. Ask me which flags are real. Better: build a project profile that suppresses the checks that misfire on the target language before the file ever reaches me. In memoQ and Trados you can tune which QA rules run and set regex-based exceptions — for an agglutinative language, turning off strict full-string term matching and switching to root-based or stem checking cuts the noise by more than half. That's a fifteen-minute setup that saves an hour of false-positive dismissal on every file after.
And stop treating a clean report as delivery-ready. A file can pass QA at 100% and still be unusable. A file can sit at 94% and be perfect, held down by a checker that doesn't understand suffixes. The number tells you the tool ran. It tells you nothing about whether the translation is good.
The report is a to-do list I write for myself. The minute it becomes a scorecard someone else grades me on, we've both stopped paying attention to the only thing that matters — the words.