What a structured QA model checks, why error categorisation matters more than a subjective quality score, and how to read a QA report.
- The problem with "quality"
- What gets categorised
- How to use a QA report
The problem with "quality"
Asked whether a translation is good, two reviewers will often disagree, and neither can show their working. That is not a workable basis for a supplier relationship or for an audit.
A structured QA model replaces the judgement with categorised, countable observations: what kind of error, how severe, where. Two auditors applying the same model to the same file should arrive at broadly the same result.
What gets categorised
Broadly: accuracy (does it say what the source says), terminology (does it use the approved term), language (grammar, spelling, register), style (does it follow the guide), and formatting or markup integrity.
Severity matters as much as category. A minor style inconsistency and a reversed safety instruction are both errors; treating them as equivalent makes the score meaningless.
How to use a QA report
The count is less useful than the distribution. Errors clustered in terminology point at a termbase problem, which is fixable at the source. Errors clustered in accuracy point at reviewer or domain fit.
Over time the distribution tells you whether the process is improving. A vendor that cannot show you the categorisation is giving you an opinion with a number attached.