Machine translation post-editing: MTPE workflow and acceptance criteria
Define post-editing goals, review meaning before style, classify errors by consequence and deliver translations with a clear audit trail.
Why edit a machine translation that already reads smoothly? Because fluency and accuracy are different properties. A grammatical sentence can omit a condition, reverse a negative, or turn an expectation into a guarantee. Such errors are often harder to notice than obvious spelling mistakes precisely because the text sounds convincing.
Machine translation post-editing, or MTPE, checks and repairs generated translations against the source and the delivery requirements. It is not merely polishing, and it does not imply that every machine draft is worth repairing word by word. This guide organizes the work around purpose, error consequences, editing passes, and traceable acceptance.
1. Define the intended use
Internal browsing, customer support replies, and public help pages can require different acceptance standards. Establish the audience, publication scope, terminology rules, formatting requirements, and unacceptable errors before editing begins. Professional quality is not specific enough to resolve disagreements.
A team may distinguish light and full post-editing, but it must define what those labels include. Light editing still needs to correct meaning errors that interfere with the intended use. Full editing may additionally require natural expression, consistent style, and review in the final format. A label alone is neither a complete standard nor a certification claim.
The European Commission’s notice about machine translation on its websites notes that quality varies by text and language pair. Acceptance should therefore depend on the actual material, not on the fact that a translation tool successfully returned a response.
2. Inspect the source and initial draft
Confirm the source revision and look for missing sentences, undefined abbreviations, conflicting facts, and damaged structure. When the intended meaning is unclear, ask the content owner. A post-editor should not have to invent business facts to make a document appear complete.
Review a few representative passages before committing to the full job. If the draft repeatedly reverses meaning or misaligns sections, retranslating may be more reliable than repairing every segment. Decide from observed effort and risk rather than preserving a poor draft to justify the original automation decision.
Check placeholders, links, tables, and file structure early. Restore truncated or misaligned content before linguistic editing. Otherwise, an editor may improve an individually correct translation while leaving it attached to the wrong source paragraph.
3. Classify errors by consequence
| Example level | Typical consequence | Response |
|---|---|---|
| Release blocker | Changed permission, critical condition, amount, or action | Correct and review the related scope |
| Major issue | Wrong term, omission, or unclear relationship | Resolve before publication |
| Minor issue | Readability or style problem without changed facts | Apply the agreed standard |
| Preference | Several valid expressions are possible | Avoid unnecessary rework |
This is an adaptable project rubric, not a universal industry scoring formula. Severity depends on use. A mistranslated button can cause an incorrect action, while choosing between two harmless promotional adjectives may not constitute a defect at all.
An issue record should include the source location, current translation, category, explanation, and proposed correction. Comments such as bad translation do not help the next editor make a decision or turn the incident into a useful regression example.
4. Review meaning and facts first
Compare source and target segment by segment. Check the actor, action, object, conditions, scope, timing, and negation. Look for omissions, additions, and unsupported explanations. Leave stylistic improvement until these relationships are established so attractive phrasing does not distract from factual errors.
Consider the original sentence “We may extend the trial after review.” A translation must retain both the review condition and the possibility rather than certainty of extension. Replacing may with will can sound cleaner while creating a commitment the source never made.
Numbers also require relational review. No more than ten members and at least ten members contain the same number but impose opposite constraints. A numerical consistency script cannot establish that the surrounding condition is correct. Read what the quantity actually modifies.
5. Apply terminology and natural expression
Once meaning is stable, align product names, interface labels, and approved terminology. Then adjust sentence structure and connections for the target language. Splitting a long sentence can improve readability, provided that its conditions and logical relationships remain intact.
Do not rewrite every sentence merely to demonstrate effort. Correct, natural text that fits the project style can remain unchanged. Repeatedly replacing acceptable synonyms increases cost and makes it harder to distinguish necessary repairs from personal preferences.
When the glossary is incomplete or contradictory, record the issue and route a proposed decision for approval. Independent editors should not silently create competing official names. The glossary management guide explains how to maintain those decisions beyond a single project.
6. Check structure and the destination environment
Inspect placeholders, hyperlinks, list hierarchy, table associations, and protected code. For interface text, review actual screens for truncation, wrapping, and button length. For documents, check navigation, notes, headers, and footers. Text that looks complete in an editor may still be hidden or clipped in its destination.
Automation is well suited to missing variables, duplicate IDs, and unparseable files. Human review is needed for reference, tone, and factual relationships. Keep those responsibilities separate so automated checks passed is not misreported as translation verified.
When layout work requires abbreviation or deletion, recheck the meaning. A final formatting pass must not remove a limiting condition while retaining an earlier approval state. Material changes should return to the appropriate review stage, even when they occur near delivery.
7. Set review depth from risk
New language directions, heavily changed source material, important commitments, and critical operating instructions warrant stronger review. Stable, lower-risk content may use an agreed sampling approach, but a passing sample does not prove that unchecked material contains no errors.
When a serious problem appears, expand the review to content sharing the same pattern: a template, terminology rule, or production batch. Fixing only the sampled sentence may leave identical problems elsewhere. Record why the scope was expanded so the response is reproducible.
A second reviewer should receive the source, draft, change history, and unresolved questions. Reading only a polished target-language document primarily tests expression. Without the source, a reviewer cannot reliably establish whether the translation remains faithful.
8. Measure effort without assuming a fixed discount
Post-editing effort depends on draft quality, domain difficulty, formatting, and delivery requirements. Using machine translation does not establish a universal percentage saving in cost or time. Price and schedule should follow the actual scope rather than a presumed discount attached to the workflow name.
Record time spent on source clarification, meaning corrections, terminology, formatting, and final review separately. Compare equivalent content under the same acceptance standard. If much of the work involves locating source segments or repairing files, the largest problem may be workflow design rather than linguistic ability.
Edit distance also needs interpretation. Few changes may indicate a strong draft or insufficient review. Many changes may reflect necessary corrections or unnecessary stylistic rewriting. Combine change counts with defects and rework rather than treating textual difference as a standalone performance measure.
9. Deliver an auditable result
The handoff should identify the source revision, target locale, editing scope, terminology revision, resolved issues, and outstanding questions. Mark content approved only when it meets the release policy. Do not hide uncertain passages inside a final file and expect the recipient to discover them.
Retain the necessary change history and add accepted segments to the appropriate reusable asset. Unreviewed machine drafts may remain historical inputs, but should not share the same trust state as approved memory. See the memory, glossary, and cache comparison for that distinction.
TranslateHub can supply translation calls within its documented capabilities; consult the developer documentation. Human acceptance, file integrity, and publication responsibility still need explicit owners in the surrounding business process. An API integration does not automatically provide those decisions.
10. Frequently asked questions
Is post-editing simply polishing?
No. Polishing mainly improves expression. Post-editing first compares the translation with the source to correct meaning, omissions, and errors. A target-only fluency review cannot perform that function reliably.
Must a poor machine draft always be repaired?
No. Evaluate representative material and decide whether to retranslate, change the approach, or handle the task manually. Delivery quality and total effort matter more than preserving a particular production method.
Can light editing leave meaning errors in place?
It should not retain errors that compromise the agreed use. The scope may exclude optional stylistic changes, but light is not a reason to skip factual checks. Document the acceptance criteria explicitly.
Can sampling replace complete review?
That depends on risk and the agreed scope. Sampling supports quality assessment; it does not mean every segment was reviewed. Report the actual coverage and provide a process for expanding checks when systematic problems are found.
