QA for machine-translation post-editing: what changes when a human edits, not writes

Machine translation post-editing (MTPE) is a specific workflow, not just raw MT output shipped as-is: a machine translation engine produces a first draft of every string, and a human post-editor works from that draft rather than from a blank page. The order matters. A translator writing from scratch and a post-editor correcting a draft are doing different cognitive tasks, and the errors that slip through differ accordingly.

Understanding what changes under MTPE is the difference between a QA process that still assumes human-authored-from-scratch text and one that actually catches what MTPE tends to produce.

Light vs. full post-editing

Post-editing is usually described on a spectrum of how much the editor is expected to change. Light post-editing aims for output that is accurate and comprehensible with minimal intervention — fix meaning errors, leave awkward-but-correct phrasing alone. Full post-editing aims for quality indistinguishable from human translation from scratch — style, tone, and naturalness are all in scope, not just correctness.

The distinction matters for QA because it sets the bar a reviewer should be checking against. Flagging a slightly stiff but accurate sentence as a defect in a light-post-editing pass is checking against the wrong standard; missing the same stiffness in a full-post-editing pass is a real gap.

Fluent but wrong is harder to catch

The core QA challenge with MT output is that it is often grammatically fluent even when it is semantically wrong. A human translator making a meaning error under time pressure tends to also produce awkward phrasing around it — the awkwardness is a visible flag that draws a reviewer's eye to the line. Machine-translated errors frequently read smoothly in the target language, with no surface signal that anything is off. A reviewer skimming for naturalness alone can pass right over a mistranslation that changes what an item does or what a quest requires, because nothing about the sentence sounds wrong.

This means a review pass over MTPE output has to check meaning against source more deliberately than fluency alone would suggest is necessary — fluency is not evidence of correctness here the way it more often is with human-authored errors.

Terminology drift within a single file

An MT engine has no persistent memory of how it rendered a term three rows earlier unless the pipeline explicitly supplies a glossary or translation memory as context. Without that, the same source term can come back translated two or three different ways within one file — an item name rendered one way in its tooltip and another way in a quest description, for instance. A human translator working through a file sequentially tends to self-correct toward consistency without being told to; an MT engine has no such tendency unless it is engineered in.

Catching this requires either a terminology-consistency check that scans the whole file for a given source term's translations, or a post-editor deliberately checking terms against a glossary rather than trusting the draft's internal consistency.

Format tokens can break during the MT step itself

Placeholders, tags, and other format tokens are exactly the kind of content MT engines were not primarily built to preserve — a token like {0} or <b> can be dropped, duplicated, reordered relative to natural word order, or have its surrounding whitespace altered by the translation step, before a human ever sees the text.

source: "Deal {0} damage to all enemies within {1}m."
MT out: "{1}m以内のすべての敵に{0}ダメージを与える"  // fine here
MT out (drift case): "すべての敵にダメージを与える範囲は{1}メートル"  // {0} dropped

Format checks stay necessary after post-editing

It is tempting to assume that once a human has reviewed a string, format problems are covered along with everything else. In practice they are not, because a post-editor reading for meaning and fluency is not reliably paying attention to token-level details — a missing placeholder in an otherwise fluent, correct-meaning sentence is easy to read past, since the sentence still makes sense without it.

This is why an automated format check (placeholder parity, tag balance) belongs after post-editing as well as before it, independent of whether a human has already reviewed the text. The two checks are looking for different classes of problems and neither substitutes for the other.