A machine translation post-editing (MTPE) workflow is the process of running source text through machine translation and then having a human editor revise the output until it meets a defined quality bar. In 2026, with neural machine translation (NMT) engines routinely producing raw output that scores above 80 on COMET-style quality estimation benchmarks for common language pairs, MTPE has become the default production method for most commercial translation work. The definitive workflow has seven stages: content triage, engine selection, pre-editing, machine translation, post-editing, quality assurance, and feedback loops back into the system. This guide walks through each stage, explains where teams go wrong, and compares the main alternatives so you can decide what belongs in your pipeline.
What Machine Translation Post-Editing Actually Is
Also worth reading: How Does a Human-Reviewed AI Translation Workflow Improve Enterprise Localization? · How Should Teams Build an AI Translation QA Workflow in 2026? · What Is the Best AI Document Translation Workflow for Accuracy, Cost, and Speed?
Post-editing is not proofreading and it is not translation from scratch. It is the correction of machine-generated output against a specific standard. The industry recognizes two levels: light post-editing (LPE), which fixes only errors that block comprehension or cause factual harm, and full post-editing (FPE), which brings output to human-translation parity in style, terminology, and register. LPE typically takes an editor 30 to 50 percent of the time of translating from scratch; FPE takes roughly 60 to 75 percent depending on language pair and domain. If your editors are spending close to 100 percent of from-scratch time, your engine or your source content is the problem, not the editor.
The economics explain why adoption keeps climbing. Industry reporting through 2025 and into 2026 shows that agencies and enterprise localization teams route the large majority of high-volume content — support articles, product listings, internal documentation, user reviews — through some form of MTPE, reserving unedited human translation for marketing copy, legal filings, literary work, and regulated content. Pricing models are shifting alongside: outcome-based pricing models announced by vendors such as ModelFront in 2025 charge per accepted segment rather than per word edited, which pushes responsibility for raw quality onto the technology provider rather than the linguist.
Stage One: Content Triage and Risk Classification
Before any text touches a machine translation engine, classify it. A practical three-tier scheme works for most organizations. Tier 1 is publish-as-is or light-edit content: knowledge base articles, chat transcripts, review responses, internal memos. Tier 2 is full-post-edit content: product descriptions, help center pages, press releases, e-learning modules. Tier 3 is human-only content: legal contracts, clinical trial documentation, brand campaigns, safety-critical instructions, and anything going to a regulator.
Assign tiers using two axes: consequence of error and expected lifespan of the text. A mistranslated button label that ships for three years carries more cumulative risk than a transient social media reply. Research published in Frontiers in 2025 on cognitive bias in post-editing adds a subtler point: editors who believe a text was machine-translated edit differently than those who believe it was human-drafted, sometimes under-correcting because they assume the machine was right. Your triage process should therefore also decide what editors are told about the origin of each segment, because that framing measurably affects output quality.
Stage Two: Choosing and Configuring Your Engine
Not all NMT engines perform equally across domains and language pairs. Generic consumer-grade engines are fine for gist translation but underperform on terminology-dense material. Domain-adapted engines — trained or fine-tuned on your glossaries, translation memories, and past approved translations — typically reduce post-editing effort by another 15 to 30 percent compared with off-the-shelf output. When evaluating engines, run a pilot: take 500 to 1,000 representative segments from real past projects, translate them with two or three candidate engines, have qualified editors blind-rate the output on adequacy and fluency, and compare automatic metrics (COMET, chrF) against human judgment. Automatic metrics alone mislead; they correlate well with human judgment at the corpus level but poorly at the sentence level.
Configuration matters as much as engine choice. Load your termbase so protected terms never get translated. Set formality registers where the engine supports them (German Sie/du, Japanese keigo levels, Spanish usted/tú). Exclude segments below a minimum length threshold — short strings like "OK" or "Sign up" often translate worse than a human would in milliseconds. And decide per locale: an engine that excels in English-to-Spanish may be mediocre in English-to-Vietnamese, so engine routing should be configured per language pair, not globally.
Stage Three: Pre-Editing the Source Text
Pre-editing is the most neglected stage and one of the highest-leverage ones. Machine translation fails disproportionately on ambiguous, idiomatic, or structurally messy source text. Before translation, normalize the source: expand contractions where ambiguity matters, resolve pronouns without clear antecedents, replace culture-bound idioms with plain equivalents, fix inconsistent terminology, and break overly long sentences (anything over about 25 words degrades NMT output noticeably). Controlled authoring rules borrowed from technical writing — active voice, one idea per sentence, defined terms used consistently — can cut post-editing time by double-digit percentages before a single segment is translated.
Pre-editing scales best when it is automated. Terminology checkers, style linters, and readability scorers flag problem sentences before they reach the engine. For organizations publishing continuously, the right move is to enforce controlled-authoring rules at the point of writing rather than retrofitting them later, so every new document enters the pipeline already MT-friendly.
Stage Four: Running the Translation and Segmenting Output
With content classified and the engine configured, run the translation inside a computer-assisted translation (CAT) tool or an API-driven pipeline. Segmentation should follow sentence boundaries wherever possible; sub-sentence segmentation fragments context and produces pronoun and agreement errors. Pass translation memory matches first — exact matches (100 percent) and high fuzzy matches (85 to 99 percent) should generally bypass the engine entirely, since reusing approved human translations is cheaper and safer than regenerating them.
Modern pipelines add automatic quality estimation (QE) at this stage. QE models predict, per segment, whether the machine output needs editing, without any reference translation. Routing only low-confidence segments to human editors while auto-publishing high-confidence ones is the basis of the "MT + selective PE" model that many high-volume operations now use. Thresholds must be tuned conservatively: a QE score cutoff that lets even 2 percent of bad segments through to publication will generate customer complaints faster than the labor savings justify. Treat QE thresholds as dials you revisit quarterly, not settings you forget.
Stage Five: Post-Editing — Rules, Tools, and Editor Guidance
Post-editors need explicit instructions, or they will drift toward either over-editing (wasting time polishing acceptable text) or under-editing (letting errors through). A written style guide for post-editors should specify: which error categories are mandatory fixes (mistranslation, omission, addition, terminology violations, numbers and units, legal or safety statements), which are optional (style preferences, synonym choice), and which are explicitly out of scope for light post-editing (elegant phrasing, transcreation). The MQM error typology — accuracy, fluency, terminology, style, locale convention — gives you a shared vocabulary for categorizing and tracking errors.
Editors should work segment-by-segment in a CAT environment with the source and target side by side, spell-check enabled, and the termbase visible. Track editing time per 1,000 words and edits-per-segment ratios; both are diagnostic. High edit density concentrated in certain content types signals a source-content problem or an engine mismatch for that domain. Low edit density everywhere might signal rubber-stamping — sample-audit a percentage of lightly-edited segments monthly to verify quality holds. Research presented around AMTA 2025 emphasized exactly this: measurement of post-editing behavior, not just output, is what separates mature programs from ad hoc ones.
Comparing Your Options: Full Human, MTPE, and Raw MT
| Feature | Full Human Translation | Full Post-Editing (FPE) | Light Post-Editing (LPE) | Raw Machine Translation |
|---|---|---|---|---|
| Typical cost vs. human baseline | 100% | 55–75% | 30–50% | 5–15% |
| Speed | Slowest | Moderate | Fast | Instant |
| Quality ceiling | Highest | Near-human | Comprehension-safe | Unpredictable |
| Best content types | Legal, marketing, literary | Product docs, web content | Support, internal comms | Gist, search indexing |
| Risk level | Lowest | Low–moderate | Moderate | High if published |
| Editor time per 1k words | 250–400 min | 150–300 min | 75–150 min | 0 min |
Common Mistakes That Sink MTPE Programs
The first mistake is treating post-editors as cheap proofreaders. Skilled post-editors earn their rate because they must diagnose machine errors quickly, including subtle mistranslations that read fluently. Paying bottom-of-market rates gets you rubber-stamping, and the damage surfaces later as customer complaints or, in regulated contexts, compliance findings. The second mistake is skipping pre-editing and then blaming the engine for output problems caused by chaotic source text. The third is ignoring cognitive bias: telling editors a text is machine output changes how they edit, as the 2025 Frontiers study demonstrated, so be deliberate about what information reaches them.
Other frequent failures include no feedback loop (engine errors repeat forever because nobody reports them), no terminology governance (the termbase exists but nothing enforces it), and unrealistic QE thresholds set once and never revisited. Finally, many teams conflate word-count savings with actual savings: if post-editing takes 90 percent of from-scratch time, you saved almost nothing and added pipeline complexity. Measure end-to-end cycle time and cost per published word, not just the discount rate on the invoice.
Costs, Timelines, and When to Act
Budget expectations for 2026: commodity language pairs (English↔Spanish, French, German, Portuguese, Chinese) with FPE commonly land between $0.04 and $0.09 per word all-in through vendors, versus $0.10 to $0.20+ for full human translation; rarer pairs and specialized domains push both numbers up substantially. Engine API costs are now trivial by comparison — typically fractions of a cent per thousand characters — so the money is in human labor, tooling licenses, and program management. Building a customized engine or fine-tuning on your own data costs anywhere from a few hundred dollars with modern APIs to five figures for serious custom builds, usually recouped within months at volumes above roughly 200,000 words per year.
Timeline-wise, a pilot takes two to four weeks: assemble reference data, run engine comparisons, define tiering rules, and train editors. A production rollout across multiple locales typically takes one quarter. If you are still sending high-volume, low-risk content to full human translation in late 2026, you are paying a premium of 40 to 70 percent for quality differences that most readers cannot detect — act now. Conversely, if you are publishing raw MT to customers with zero human oversight, you are accumulating brand and liability risk that will eventually cost more than every dollar you saved. The disciplined middle path — triage, adapted engines, targeted post-editing, measured QA, and continuous feedback — is the workflow that has become the industry standard for good reason.