Quality feedback is most useful when reviewers can explain the impact of an issue. A shared error taxonomy helps teams prioritize corrections and learn across projects.
Why a shared taxonomy helps
Without agreed categories, one reviewer’s “mistranslation” is another’s “style.” Scores become hard to compare, and translators receive feedback they cannot act on.
A taxonomy also makes quality discussable with clients. Instead of a general impression, both sides can see which issues occurred, how serious they were and what changed as a result.
Established frameworks offer a starting point. The W3C Internationalization Tag Set (ITS) 2.0 ↗ includes a Localization Quality Issue data category with issue types such as terminology, mistranslation and omission. The MQM (Multidimensional Quality Metrics) framework ↗ provides an error typology and severity levels that teams can adapt to their own content.
Define the categories
Distinguish accuracy, omission, terminology, grammar, locale convention, formatting and style. A style preference should not be scored like a wrong amount or a missing warning.
- Accuracy: the meaning differs from the source, including additions and mistranslations.
- Omission: source content is missing from the target.
- Terminology: an approved term is not used, or a term is used inconsistently.
- Grammar and spelling: the target text breaks language rules.
- Locale convention: dates, numbers, units or addresses do not follow the target market.
- Formatting: tags, layout or links are broken or displaced.
- Style: tone or register does not match the agreed style guide.
Include examples for each category so different reviewers apply them consistently. Link terminology issues to the approved termbase maintained through terminology management.
Add severity and context
Severity depends on where the content will appear and what a reader might do with it. A typo in a draft may be minor; a mistaken dosage or legal deadline is not.
Agree a small number of severity levels, such as critical, major and minor, with a plain definition for each. Too many levels invite debate; too few hide the difference between a slip and a risk.
Reviewers should record the source span, proposed correction and reason. This makes each finding verifiable and helps the translator understand the impact instead of only the change.
Keep feedback fair
Some changes are editorial preferences, while others repair objective errors. Ask reviewers to distinguish the two and reference an approved style guide when possible.
A balanced record helps the team improve without turning every preference difference into an apparent quality failure. It also supports a reasoned dialogue when the translator disagrees with a finding.
Some findings turn out to be correct translations of an unclear source. In that case the reviewer’s note should lead to a source query rather than a penalty.
Use results constructively
Analyze recurring patterns, update glossaries and refine source instructions. Automated checks catch some consistency errors, but final decisions need human judgment, as described in our article on human and AI terminology QA.
The same taxonomy can guide machine output review. Severity helps decide whether AI output needs light review, rewriting or human translation, a choice explored in when AI output needs a different review level. Keep feedback concise enough that translators can act on it.
Look at trends across several projects rather than a single review. One unusual job can distort a score, while a pattern across files shows where training, terminology or source quality needs attention.
A checklist for setting up linguistic QA
- Agree categories and examples. Define each error type with at least one real example.
- Set severity levels. Describe what makes an issue critical, major or minor for this content.
- Assess impact in the use context. Consider where the text appears and what readers will do with it.
- Record evidence. Capture the source span, proposed correction and reason for every finding.
- Separate preference from error. Reference the style guide before marking a style issue.
- Feed repeated issues back into the workflow. Update glossaries, instructions and checks after each review cycle.
This structure underpins our quality process, where every revision decision has a clear owner.
Further reading: W3C: Internationalization Tag Set (ITS) 2.0 ↗; MQM Council: Multidimensional Quality Metrics ↗.