What is MTPE? A translator's guide to machine translation post-editing
What machine translation post-editing is, how light and full MTPE differ, where the editing time really goes, and how to quote it without underpricing.
Most translators meet machine translation post-editing before anyone bothers to define it. A client sends a file, says the MT is "already done," and asks for a quick clean-up at two thirds of the usual rate. Whether that's a fair deal or a trap depends on things the email never mentions: which engine produced the output, how the source was written, and what quality the delivered file actually has to reach. We've watched translators lose money on MTPE jobs that looked easy and do well on jobs that looked grim. The difference is rarely the engine. It's whether anyone defined the work.
What machine translation post-editing actually means
Post-editing is the work of turning raw MT output into a text that meets an agreed quality level. That's the whole definition, and it sounds thin until you notice what it rules out.
It isn't proofreading. The errors are a different species. When a human translator gets a sentence wrong, you can usually see why: they misread a clause, they guessed at an abbreviation, they left a comment. MT output has none of those tells. It produces sentences that are fluent, confident and quietly wrong, with no visible seam between the parts that are right and the parts that aren't.
It also isn't monolingual review. Real post-editing is bilingual work, with the source open. Editing MT output without the source is a separate job with a separate risk profile, and it's the fastest way we know to ship a plausible-sounding mistranslation.
ISO 18587:2017 is the standard that covers this. It sets out requirements for the post-editing process and the competences a post-editor needs, and it defines what full post-editing has to deliver. Two things about it are worth knowing. First, it assumes the MT output already exists and the source is available for comparison. Second, it says nothing about whether the output is worth editing in the first place. That judgement is still yours, and it's the judgement most MTPE briefs skip.
The acronym MTPE just bundles the two halves together: machine translation plus post-editing. Useful shorthand, slightly misleading in practice, because it implies a single service with a single rate.
Light and full post-editing, and why the labels get abused
Full post-editing means the delivered text reads as though a human translated it. Terminology correct, register consistent, nothing dropped, nothing invented, no awkward calques left standing because the meaning technically survived.
Light post-editing means the text is accurate and understandable, with no requirement that it read well. Clunky syntax stays. Repetition stays. You fix what would mislead a reader, not what would irritate one.
That's the theory. In practice "light" has drifted from a specification into a discount label. We've seen a lot of briefs that ask for light post-editing and then come back with style complaints after delivery, because the person who wrote the brief was thinking about the price, not about what the file is for. An internal FAQ that twelve people will skim can be light post-edited. A brochure going to a print house cannot, whatever the purchase order says.
The fix is not to argue about adjectives. Ask what happens to the file after you deliver it. Published externally, under the client's brand, read by customers? That's full post-editing, and it should be priced that way. Circulated internally so someone can decide whether the full version is needed? Light post-editing is honest work and genuinely faster.
One more distinction that gets lost: light post-editing is not permission to skip the accuracy pass. Numbers, negations, names and units still have to be verified segment by segment. The savings come from leaving style alone, not from reading less carefully. If a brief asks for light post-editing at a third of your rate on a contract, it's asking you to absorb liability. Our write-up on choosing between light and full post-editing goes through the decision in more detail.
What the work actually looks like in a file
Open the bilingual view. For each segment you make one of three calls: accept as is, edit, or throw it out and translate the sentence yourself. The third call is the one inexperienced post-editors avoid, and avoiding it is expensive. Patching a bad segment into shape usually takes longer than retyping it, and the patched version tends to keep the MT sentence structure underneath, which is how documents end up reading like translations.
Then there's the layer that has nothing to do with language. We ran a 40-page German technical manual through a post-editing pass last year where the terminology came back almost perfect and the file was still unusable. Cross-references had shifted ("siehe Abschnitt 4.2" became "see chapter 4.2" while the document itself used "section" everywhere). Decimal separators came through in the German convention, so 1.500 mm appeared as a thousand and a half millimetres in English. Three table headings that were identical in the source came back in three different wordings, because the segments were processed independently and nothing enforced consistency across them.
None of that is a translation error in the usual sense. All of it is a delivery defect, and all of it lands on the post-editor. This is why we tell people to run post-editing as two passes rather than one. First pass for accuracy and terminology, segment by segment, source open. Second pass on the assembled document for the things only visible at document level: repeated headings, number formats, cross-references, stray untranslated strings, placeholders that survived.
A QA report helps here, but only if you read it as a list of things to check rather than a verdict. Automated checks catch inconsistent numbers and missing terms reliably. They do not catch a sentence that means the opposite of the source.
Where the time actually goes
The intuition most people start with is that worse MT output costs more time. It doesn't, past a certain point. Output that is obviously broken is cheap to deal with, because you delete it and translate the sentence. Output that is fluent and subtly wrong is the expensive kind, because you have to verify it, and verification is slower than writing.
This is the part of MTPE that surprises translators coming from a CAT background. A fuzzy match at 85% tells you where to look. An MT segment tells you nothing about its own reliability, so every segment gets the same attention budget until you've read both sides. On a 4,000-word document that's a few thousand small decisions, and the fatigue is different from translation fatigue. It's shallower and it arrives faster.
Source quality moves the number more than the language pair does, in our experience. A clean, consistently written source with short sentences and no embedded formatting produces output you can move through quickly in almost any direction. A source that was itself translated, or written by six people, or exported from a PDF with line breaks mid-sentence, will slow you down whether you're working into Spanish or into Japanese.
Two practical consequences. Track your actual editing speed per project for a while, in words per hour, and note the source type alongside it. After a dozen jobs you'll have your own numbers, which beats any published benchmark for quoting purposes. And when a source is visibly bad, raise it before you start rather than after. Fixing the source, or getting permission to standardise obvious inconsistencies in it, is often the single largest time saving available on an MTPE job. Our guide to post-editing AI translations efficiently covers the mechanics of the editing pass itself.
How MTPE gets priced, and why per-word rates misfire
The common model is a percentage of your translation rate, somewhere between 55% and 75% depending on who's asking. It's simple and it's wrong in a specific way: a per-word price assumes effort is distributed evenly across the words, and in post-editing it isn't. A fluent, wrong segment can cost five times what a neighbouring segment costs. Two documents of identical length and identical language pair can differ by a factor of three in editing hours.
Hourly pricing solves the measurement problem and creates a trust problem, since the client can't predict the invoice. The middle path we see working most often is a sample-based quote. Ask for 300 to 500 representative words from the actual file, post-edit them to the quality level the client needs, time it honestly, and quote from that. It takes twenty minutes and it converts an argument about percentages into an argument about a number you measured.
Rate pressure on MTPE isn't a quirk of one client. Industry trackers like Slator and CSA Research have been reporting post-editing as a growing share of language service revenue for several years, which means the discount expectation is structural. That's an argument for measuring your own effort carefully, not for accepting whatever percentage is offered.
The sample method has a real limitation. It breaks on heterogeneous documents, the ones where a dense contract is followed by a marketing appendix and a table of part numbers. Sampling the contract gives you a rate that loses money on the marketing section. For those files, either quote the sections separately or quote hourly, and say why.
When post-editing is the wrong call
Some jobs should not be MTPE at any rate, and recognising them early is worth more than editing faster.
Transcreation is the clearest case. We took on a 1,800-word French marketing brochure as a post-editing job once, and the MT output was grammatically clean. We rewrote roughly 70% of it, because clean sentences that land flat in the target market are still unusable. The effective hourly rate came out below what a from-scratch translation would have paid. The honest move, which we now make up front, is to decline the MTPE rate and quote translation.
Short, high-visibility text is the second case. Taglines, slide titles, button labels, chapter headings. There's no volume to amortise the overhead, and the per-word logic of MTPE collapses when the unit is six words that someone will read on a screen behind a speaker.
Then the practical blockers. Scanned or OCR'd sources, where you're correcting recognition errors and translation errors at the same time. Certified and sworn work, where you're signing for the result regardless of how it was produced. Confidential material where the engine in the chain hasn't been approved by the client. And language pairs or domains where you already know from experience that the output needs more rebuilding than editing.
Saying no to one of these isn't lost work. It's declining to subsidise a client's cost saving with your hours.
Setting up MTPE so it holds up across projects
Three things before you start: a glossary with the client's terminology, written agreement on the target quality level in plain words rather than the labels "light" or "full", and a timed sample. Three things after: the QA checks run on the assembled document, a short note of what you changed systematically and why, and your own recorded editing speed for the next quote.
If the MT step is yours to run rather than the client's, the shape of that step changes how much editing you inherit. SnapIntel takes a DOCX, XLSX or PPTX, holds translation until you've reviewed and approved the glossary and the translation prompt, and returns the translated file along with a QA report and a quality rating. There's a neutral source/target XLSX export if you'd rather do the post-editing pass in your own CAT tool. It doesn't post-edit for you, and nothing does. What it changes is whether you're editing output you specified or output somebody else generated with defaults.
The takeaway is one habit. On the next MTPE enquiry, ask for 400 representative words before you quote anything. Post-edit them to the level the client actually needs, time it, and build the quote from that number. If the client won't send a sample, quote your translation rate and explain that you'll revise it once you've seen the file. Post-editing is the one service where quoting blind reliably goes against you, and a sample costs you twenty minutes to find out.