Light vs full post-editing: choosing the right MTPE level for each project
Light vs full post-editing explained: how to pick the right MTPE level, write instructions editors can follow, price each level, and verify what you got.
Most briefs we read say "post-editing" and stop there. That one word covers two different jobs, and the distance between them is where projects quietly go wrong. The choice between light vs full post-editing decides how many hours a linguist spends per thousand words, what the client can legitimately do with the delivered file, and whether anyone has grounds to reopen the quality question three weeks later. We have watched an agency lose its margin because a job quoted as light was reviewed as though it were full. We have also seen a client publish a lightly post-edited brochure and then ask why the writing felt so flat. Neither problem came from the MT engine. Both came from an MTPE level that nobody wrote down.
What light vs full post-editing actually means
Full post-editing has a definition you can point at. ISO 18587 sets out requirements for post-editing machine translation output to a standard comparable with human translation: accurate, terminologically consistent, grammatical, appropriate in register, with no raw MT artefacts left in the file. The standard describes that one level in detail, and it exists partly so that buyers and suppliers stop arguing about what "edited" means.
Light post-editing has no equivalent definition. It is an industry convention, which means every client ordering it has a private idea of what it covers. The working version most teams settle on is: fix anything that changes meaning, remove anything unintelligible, correct terms that are wrong, and leave everything else alone even where you would have phrased it differently. The result is understandable and factually right. It does not read as though a native speaker wrote it, and it should not be sold as if it does.
That asymmetry matters more than it sounds. When a purchase order says full post-editing, both sides can check the delivery against a published standard. When it says light, the only shared reference is whatever your own instructions contain. So we ask for one sentence about what the file is for before agreeing on a level. That sentence settles the question faster than any discussion of quality tiers.
There is a third situation worth naming, because teams keep forcing it into one of the two: output that is good enough for its purpose without any editing pass at all. Treating that as light post-editing wastes an editor's afternoon and gives the client a number to anchor on next time.
One more point of confusion, since it reaches us almost weekly. Neither level is a proofreading pass on a human translation, and neither is a bilingual review of somebody else's work. MTPE is editing raw machine output against the source, with the source open, and an editor who only reads the target language cannot do it at either level. Agencies that staff light post-editing as monolingual tidying get files that read well and contradict the original.
The level follows the reader, not the engine
The common mistake is picking the level from how good the raw machine translation looks. A clean-reading draft tempts people into light post-editing on documents that needed full, and a rough draft pushes teams into full post-editing on documents nobody will read twice.
Start from the reader instead. Four questions settle most cases: who reads this, how long does it stay in circulation, what happens if one sentence is misunderstood, and does the text carry the client's voice to somebody outside the company.
A concrete case from last spring. A manufacturer sent us a 400-page equipment service history, Japanese into English, for an internal engineering team running a plant audit. Nobody reads a service history end to end. They search it for part numbers, failure descriptions and dates. We ran light post-editing with terminology checked hard and style ignored completely, and the file went back in two days. Full post-editing would have added a week and changed nothing about the decision those engineers made.
Compare that with a 12-page summary of a distribution agreement for the same client's sales team. Same language pair, same engine, full post-editing, because those sentences get pasted into email and read by people deciding whether to sign something.
Two limits on this reasoning. Regulated content does not follow it: for labelling, safety instructions, clinical and pharmaceutical texts, the level comes from the regulation and the client's own procedures, not from a judgement about readership. And some content sits below the threshold for an editing pass entirely, which we have written about separately in gisting vs publication quality.
Writing post-editing instructions an editor can act on
A level name is not an instruction. "Light post-editing, please" leaves every borderline decision to the editor, and two competent editors will resolve those decisions differently. What we send with a light job reads more like a rule set:
- fix mistranslations, omissions, invented content, wrong numbers, wrong dates, wrong units
- apply the approved glossary everywhere, including headings and table cells
- fix grammar that breaks meaning, leave grammar that is merely clumsy
- do not reword a sentence that is correct but not how you would have said it
- do not restructure paragraphs and do not improve on the source
- flag what looks like a source error rather than fixing it silently
For full post-editing the list inverts. Register, flow, sentence length and client voice all come into scope, and the only thing still out of bounds is writing content the source does not contain.
Two details prevent most of the later argument. The first is the glossary. A light pass with no approved term list is not light post-editing, it is proofreading with guesswork, because the editor ends up inventing terminology decisions that belonged to the preparation stage before translation ever started. The second is the preference rule, written out in plain words: correct sentences do not get changed to preferred alternatives. That one line is what keeps a light job light, and it also gives the editor cover when the file comes back with stylistic comments from a reviewer who never saw the instruction.
None of this is about working faster through the file. That is a separate skill, and we covered the mechanics of it in how to post-edit AI translations efficiently.
Where light post-editing turns into full post-editing
Level drift is the most expensive failure in MTPE, and it is rarely anyone's fault. Experienced translators have spent years making text read well. Asking them to leave a clumsy but correct sentence alone works against the instinct they were hired for. So a light job gets delivered at full quality, invoiced at the light rate, and the hours disappear into nobody's budget.
Measure it rather than arguing about it. Count what share of segments the editor changed. On a light pass over output from a well-prepared project, we expect a minority of segments touched. When an editor reports changing most of the file on a light job, the level is not the problem, and telling them to edit less will not fix it.
An example of that. A French into German technical manual came back from a light pass with almost every segment modified. The editor had not overworked it. Compound terms were wrong throughout, and fixing a wrong compound in German usually forces the clause around it to be rebuilt, so terminology corrections cascaded into rewriting. The actual defect was upstream: the glossary had been approved without the client's compound forms in it. We fixed the term list and the prompt, re-ran the translation, and the second light pass behaved like a light pass.
Drift runs the other way too. A client orders full post-editing at a light price, or sends a light job and returns it with a page of style comments. The answer in both cases is the instruction set you agreed on, quoted back, with the extra pass priced separately as its own line. That conversation is uncomfortable once. Repricing the same job silently is uncomfortable every month.
What each MTPE level costs in time and money
Most bad MTPE economics come from fixed discount percentages off a human translation rate. The discount is fixed, the effort is not, so the supplier absorbs every bad draft and the client never learns which content types are cheap to post-edit.
Price from your own throughput instead. Track edited words per hour by content type and language pair across several projects, separately for light and full, and you will have numbers that describe your work rather than somebody's procurement template. Publish nothing until you have enough projects that one unusual file cannot move the average. Hourly pricing suits light post-editing better than per-word pricing does, because the variance between a clean draft and a poor one is wider at that level than clients expect.
Both levels need an abandonment threshold written into the agreement. Full post-editing on a bad draft can cost more than translating the document from scratch, and when that point arrives somebody has to be allowed to say so without renegotiating the whole contract. We write it as a named condition: if the editor judges that retranslation is faster, the project switches to a translation rate with the client notified the same day.
If you would rather not build guideline documents from nothing, GALA and TAUS both publish post-editing guideline frameworks you can adapt, and Slator and CSA Research publish rate and adoption surveys that are useful for seeing where the market sits. Use them for structure and direction. The throughput figures that matter for your pricing have to come from your own projects, because they depend on your engine, your glossary discipline and your editors.
Checking that the level you paid for is the level you got
Both sides of an MTPE job tend to assume the level was respected. Verifying is cheap. Sample the delivery instead of reading all of it: a fixed share of the word count, floor of a page or two, taken from across the document rather than the opening pages where everyone is most careful.
Score the sample by error category and keep the categories separate, because the level decides which ones count. Accuracy and terminology findings count against acceptance on a light job. Fluency and style findings get recorded but do not justify rejection, since you asked the editor to leave that material alone. On a full job all four count. Mixing them is how a light delivery gets rejected for doing exactly what it was told.
Record the result per vendor and per content type. After a dozen projects the pattern is usually obvious: one editor is excellent at light passes and overworks full ones, a content type fails terminology checks whatever the level, a language pair needs full post-editing on everything. That record is what lets you assign the next job instead of guessing.
Without a CAT tool, a source and target table in a spreadsheet is enough: two columns, one row per segment, a third column for the reviewer's category and comment. It reviews faster than a formatted document, and comments stay attached to specific segments instead of becoming a vague note about tone. Give reviewers the category list as well: they score far more consistently picking from four labels than writing free comments.
If the AI translation step is part of your own workflow, this is roughly what SnapIntel is built around. You upload a DOCX, XLSX or PPTX, work through domain analysis, glossary and translation prompt, and approve the glossary and prompt before translation starts, which is what keeps the terminology decisions out of the editor's hands. Each project returns the translated file along with a quality rating and a QA report, plus a neutral source and target XLSX export that you can open as a review table or import into any CAT tool for the post-editing pass. More at snapintel.io.
What to do on your next MTPE project
Pick the next job in your queue that is described only as "post-editing" and do four things to it.
Write one sentence about who reads the file and how long it stays in use, then choose the level from that sentence. Replace the level name in the purchase order with the rule set for that level, including the line about not changing correct sentences. Check that an approved glossary exists before the translation runs, and if it does not, build one first, because a light pass without a term list will come back looking like a failed project. Then, on delivery, sample a page or two and score it with accuracy and terminology kept apart from fluency and style.
The first project done this way takes an extra half hour. After that you have a template, a defensible level in writing, and throughput numbers of your own to price the next one from.