A QA report with zero flags is the easiest thing in this job to fake. Not fake as in cheat — fake as in it looks like proof of quality when it's proof of nothing except that I remembered to run the check. I've delivered files where Trados's QA tab was spotless and the translation still had a mistranslated clause sitting right in the middle of a payment term. The panel never saw it. The panel can't read.
That gap is the whole thing I want to talk about. Project managers increasingly ask for the QA log alongside the file, and I get it — you need something auditable. But somewhere along the way the log stopped being a tool and started being the evidence. Those are not the same.
What the checks actually catch
Be honest about the category of problem a CAT QA engine solves. It's mechanical. Number mismatches between source and target. Missing or doubled tags. Inconsistent translation of a segment that appears twice. Terminology that doesn't match the termbase. Trailing double spaces, empty target segments, forgotten placeholders. In software strings, a %s that got dropped or a {0} that turned into {О} with a Cyrillic O — that last one my checker does catch, and thank God, because the human eye slides right over it.
This is real work and I keep most of these on. For an oil & gas spec with forty tables of figures, the number-consistency check earns its keep in the first ten segments. I'm not going to eyeball 1,200 pressure values and feel confident. Let the machine count.
But notice what every one of those checks has in common. None of them require understanding the sentence. They compare strings, match patterns, count tokens. A segment can pass all of them and mean the opposite of the source. The engine is checking that I typed carefully, not that I translated correctly.
Where it goes quiet, and where it lies
Turkmen breaks the term checker constantly, and I've written about this before — the language is agglutinative, so my glossary term shows up with six case endings glued to the back of it and the checker screams "terminology mismatch" on a perfectly correct word. After the fortieth false positive you stop reading the flags. That's the real danger. Not the noise itself, but what the noise trains you to do: ignore the panel. Then the one true flag in a sea of garbage slides past because you've been clicking "ignore" on autopilot for an hour.
So I tune. Hard. I kill the term check on long Turkmen jobs and run a separate pass against a shortlist of terms that genuinely must be exact — the ones in the contract where the client specified the rendering. I keep number, tag, and consistency checks always. I turn off the "sentence should end with punctuation" check because half my UI strings are button labels. A QA profile you never adjust is a QA profile that's lying to you in a consistent direction.
And here's the part that should bother anyone treating the log as proof: the checks that look most impressive are often the ones doing the least. Fuzzy-match quality estimation, the colored bars that tell you a 85% match is "probably fine" — that confidence is about string distance, not meaning. A 100% match from the memory can still be wrong for this context, and no QA pass will tell you, because as far as the engine knows the database already blessed it. I've covered that trap too. The memory is not a quality authority. It's a record of past decisions, some of them bad.
Run it early, read it like a skeptic
Two things changed how I use these tools, and neither is a feature.
First, I run QA before I think I'm done, not after. Running it at the end makes it a rubber stamp — you want to deliver, so you dismiss flags to clear the list. Running it at the 70% mark, the flags are information: oh, I've been rendering this term two different ways, let me fix that pattern everywhere before I go further. Same check, completely different relationship to it.
Second, I write a line in my delivery note saying what I turned off and why. "Term check disabled on free-text segments due to morphology; ran targeted check on the eight client-specified terms, all verified." Thirty seconds. It tells the PM I'm not hiding behind a green panel, and if there's a later complaint about terminology, there's a paper trail showing judgment, not negligence. A clean log with no note means "I ran the default profile." A log with a note means "I thought about this file."
The engine can prove I didn't drop a tag. It cannot prove I understood the source. When the report lands on your desk with no flags, the honest question isn't "did it pass QA" — it's "which checks were even on, and who decided the sentence was right." That second question doesn't have a checkbox. It has a name at the bottom of the file, and the name is mine.