Camille had a habit she was proud of, and it was quietly ruining her. She was a German-into-English post-editor, ten years in, and she could not leave a sentence alone. Give her a machine-translated segment that said "The device shall be cleaned after each use," and she would feel a small itch: shall is stiff, must reads cleaner, and "after every use" has a nicer rhythm than "after each use." So she would change it. Then the next segment, and the next, each one a tiny improvement nobody asked for and nobody would notice. At the end of a 4,000-word file she had touched almost every line, the edit log looked like a battlefield, and she had spent six hours on a job the rate assumed would take three. The machine translation (MT) had been, by any honest reading, mostly fine. The client had bought machine-translation post-editing (MTPE), the named workflow where an engine drafts every segment and a human revises it, precisely because it was supposed to be faster and cheaper than translation from scratch. Camille had quietly converted it back into translation from scratch, except she was being paid the post-editing rate. She was the most conscientious linguist on the vendor list and the least profitable, and the two facts were the same fact. This lesson is about the discipline she never learned: post-editing without over-editing. It is about the difference between a change the file needs and a change you simply prefer, why preferential rewrites silently destroy the economics that justify the workflow, what the ISO 18587 standard means when it says a post-editor makes "no preferential changes," and a worked file where a linguist sits on her hands and lets acceptable segments be acceptable. It is honest about how hard that is, because the urge to improve is the best instinct a translator has, and post-editing asks you to govern it.

The Edit That Pays and the Edit That Costs

Start with the unglamorous economic fact that the rest of this lesson hangs on, because if you do not feel it in your gut, none of the discipline will make sense. Post-editing (PE) is priced as a discount on translation, and the discount only exists because the machine did real work you no longer have to do. The 2024-2026 numbers are consistent across the industry: MTPE typically prices at roughly 50 to 75% of full human translation, somewhere around $0.05 to $0.15 per word, with light post-editing as low as $0.02 per word, against full human translation that might run double. A hybrid workflow, MT plus a disciplined human, is supposed to lift a linguist from around 2,000 words a day to 5,000 or more. That throughput is not a bonus. It is the entire premise. The client accepted a lower price because they were promised the engine would carry the bulk of the load and the human would carry the judgment. The speed and the rate are two ends of the same handshake.

Now look at what an edit actually is, mechanically, from the standpoint of that handshake. There are two completely different kinds of edit, and they live in different economic universes even though they look identical in the file.

The first kind is the necessary edit. The machine got something wrong, or got it dangerously close to wrong, and a competent reader of the deliverable would be misled, harmed, or embarrassed if it shipped as is. A flipped negation. A wrong number. A mistranslated term the client has on an approved list. A locale convention that breaks (a date in the wrong format, a comma where the locale uses a period in a price). A sentence so garbled the meaning genuinely does not survive. These edits are the job. They are why a human is in the loop at all. Every one of them earns its keep, because the alternative is a defect shipping under your name.

The second kind is the preferential edit. The machine produced something correct, accurate, terminologically sound, locale-appropriate, and perfectly understandable, and you changed it anyway, because your version is a little better. Smoother. More elegant. More like the way you would have phrased it. The meaning was already right; you improved the prose. This is the edit that feels like craftsmanship and is, in a post-editing context, closer to leakage. It produces no value the client is paying for, it consumes the time budget that justified the discount, and it quietly turns a profitable MTPE job into an unprofitable one. Camille's whole problem was that she could not tell, in the moment, which kind of edit she was making, because both came from the same honest place: the desire to make the text good.

A necessary edit fixes something that is wrong. A preferential edit replaces something acceptable with something you like better. Post-editing pays you for the first and quietly bills you for the second.

Hold the two side by side. If MT writes "The patient should take the medication twice a day" and the source said three times a day, fixing it is necessary; the wrong number could harm someone. If MT writes "The patient should take the medication twice daily" and you prefer "twice a day," that is preferential; both are correct, both are clear, and the swap bought nothing. The skill of post-editing without over-editing is, at bottom, the trained ability to feel the difference between those two situations in the half-second before your hands move, and to keep them moving only in the first case.

Why Over-Editing Quietly Destroys the Workflow

It is tempting to treat over-editing as a victimless habit. The file ships, the quality is high, the client is arguably getting more than they paid for, so where is the harm? The harm is real, it is structural, and it lands on four parties at once. Walk through each, because seeing the full blast radius is what converts "I should edit less" from a slogan into a conviction.

The harm to you, the linguist

This is the most immediate and the one linguists feel first, usually as exhaustion and confusion about why they are working so hard for so little. You agreed to a post-editing rate. That rate was modeled on an assumption of throughput, say 5,000 words a day, which is the only thing that makes $0.08 a word add up to a living. If you over-edit and your real throughput is 2,500 words a day, you have unilaterally cut your effective hourly income in half while delivering a file the client could not distinguish from the disciplined version. You did not get paid for the extra polish; you absorbed it. Do this on every job and you arrive where Camille arrived: the most careful linguist on the roster, quietly the worst-paid, privately convinced the rates are unfair, when in truth you redefined the job into something the rate was never meant to cover.

The harm to the client and the deadline

The client bought speed as much as quality, because speed is often why they chose MTPE over full human translation in the first place. A release date, a regulatory filing window, a product launch in nine languages on the same Tuesday. When you over-edit, you do not just spend your own money; you spend the schedule. A file budgeted for three hours that takes six pushes every downstream step: the reviser waits, the engineer waits, the build waits, the launch slips. And here is the cruel part: the client cannot even see what they paid for. The extra elegance is invisible to them because the acceptable version would have read fine. You delivered a cost (a late, expensive file) in exchange for a benefit they will never perceive. That is the definition of a bad trade made on someone else's behalf without asking.

The harm to the rate itself, for everyone

This one is slower and more insidious. When a vendor pool habitually over-edits, the project manager sees MTPE jobs consistently running over their time estimates. The PM has two ways to read that data, and only one of them is flattering to linguists. They might conclude "MTPE is harder than we thought, we should pay more," which almost never happens in a competitive market. Far more often they conclude "MTPE on this content is not actually saving us time, so the discount is justified by edit-distance metrics, not hours, and we will hold the rate down and squeeze the schedule." Over-editing, in aggregate, is one of the forces that drives MTPE rates toward the floor, because it makes the workflow look less efficient than it is. The linguists who cannot stop polishing are, collectively and unintentionally, arguing for their own pay cut. The discipline of editing only what matters is partly how the profession defends the price of the work.

The harm to the translation memory and consistency

There is a quieter technical harm too. Every preferential rewrite you commit lands in the translation memory (TM), the database that stores your approved segments so they can be reused. If three post-editors each impose their own preferred phrasing on the same acceptable MT output, the TM fills with three near-identical variants of the same idea, none of them wrong, all of them slightly different. Future fuzzy matches degrade. Consistency across a product's strings erodes. A terminologist or TM manager then has to spend time reconciling stylistic variants that should never have diverged. Acceptable, left alone, would have been consistent. Each post-editor's private sense of style, multiplied across a team, becomes noise in the asset that was supposed to compound quality.

Over-editing is not generosity. It is an uncompensated cost you impose on your own income, the client's deadline, the profession's rate, and the translation memory's consistency, in exchange for an improvement no one can see.

What ISO 18587 Means by "No Preferential Changes"

The discipline this lesson teaches is not a productivity hack someone invented to squeeze linguists. It is written into the international standard that governs the work. ISO 18587 is the standard that defines the requirements for the human post-editing of machine-translation output, and one of its most quietly important provisions is a rule about restraint: the post-editor should correct the machine output where correction is needed and should not make changes that are purely preferential. The standard, in its own dry language, draws exactly the line this lesson draws. A post-editor uses as much of the raw machine output as possible. They fix errors. They do not rewrite acceptable text to match personal taste.

This was easy to state and easy to ignore in the original 2017 standard, partly because the standard split post-editing into two named levels, light and full, and the "no preferential changes" instinct lived most explicitly inside light post-editing. Light post-editing aimed only at understandable: fix what breaks meaning, leave everything else, do not chase style. Full post-editing aimed at indistinguishable from human translation, which gave linguists more room to touch style, and that room is exactly where over-editing breeds, because "make it read like a human wrote it" can be stretched to justify almost any rewrite you fancy.

Why the revision makes restraint harder and more important

The standard is being revised, and the revision matters for this exact discipline in two opposing ways you have to hold at once. The revised ISO 18587, in DIS ballot with publication targeted for late 2025 into 2026, expands its scope from machine translation to "non-human translation output," explicitly covering AI and large language model (LLM) engines, and it retires the rigid light-versus-full split in favor of an effort spectrum. It also insists, more firmly than before, that the post-editor hold the same linguistic competence as a professional translator, aligning with ISO 17100, the human-translation services baseline.

Read those two changes together and you find the central tension of modern post-editing. On one hand, the standard now expects you to be a full-competence translator, someone with the skill and the eye to produce a flawless translation from scratch. On the other hand, it still expects you to restrain that competence and not impose it where the machine already produced something acceptable. You are being asked to be capable of the perfect rewrite and disciplined enough to not do it when it is not needed. That is a genuinely difficult professional posture, and it is the opposite of how most linguists are trained. Translation training rewards the better word; post-editing rewards the necessary word and only the necessary word. The revised standard does not make over-editing more acceptable just because the engine is now an LLM producing gorgeous prose. If anything it makes restraint harder, because LLM output is so fluent and so close to your own voice that the temptation to tweak it into exactly your voice is stronger than ever, and the standard still says: if it is acceptable, leave it.

The spectrum is not permission to polish

One dangerous misreading deserves a direct warning. When people hear that the new standard replaces "light versus full" with a spectrum of effort, some conclude that the spectrum means "edit as much as the content seems to deserve, by feel." That is not what it means. The spectrum is about matching the amount of correction to the consequence of the content: a throwaway internal note gets the lightest necessary touch, a drug label gets exhaustive verification. It is a scale of how thoroughly you hunt for and fix real defects, not a scale of how freely you indulge stylistic preference. On every point of the spectrum, from the lightest to the most rigorous, the rule against preferential changes holds. Higher effort means you look harder for genuine errors, not that you are licensed to rewrite acceptable segments. Confusing "more effort" with "more polishing" is precisely the mistake that turns full post-editing into uncompensated retranslation.

The standard asks you to be a full translator who chooses restraint, not a light editor who lacks skill. The competence is the same; the discipline is to deploy it only where the output is actually defective.

The Acceptable Test: Deciding in the Half-Second

Discipline that lives only as a principle does not survive contact with a real file at 4 p.m. with a deadline at 6. You need an operational test you can run in the half-second before your hands move, fast enough to apply to every segment without slowing you down. Here is the one that works, framed as a single question you ask of every segment the engine drafted.

Would this segment, exactly as the machine wrote it, mislead, harm, embarrass, or fail a defined requirement if it shipped untouched?

If the answer is yes, edit it; the edit is necessary. If the answer is no, leave it, even if you can imagine something better. That is the whole test, and its power is that it is about consequence, not taste. It does not ask "is this how I would have said it." It asks "is this actually defective." Let us make the test concrete by sorting the things that trigger a "yes" from the things that tempt a "yes" but are really a "no."

Things that are genuinely necessary (edit them)

• Accuracy defects. The target says something the source did not, or fails to say something the source did. A flipped negation, an inverted condition, a dropped clause, an added claim. These are the killers, especially in the LLM era where they arrive in flawless prose. Always edit.
• Wrong numbers, dates, units, and names. A dosage, a price, a date, a measurement, a proper noun rendered incorrectly. The fluent error in a number is a recall or a lawsuit waiting to ship. Always edit.
• Terminology violations. The client has an approved term and the engine used a synonym. Even if the synonym is a perfectly good word, the approved term is a defined requirement, so using the wrong one is a defect, not a preference. Always edit.
• Locale failures. Date formats, decimal separators, currency, quotation marks, formality register where the locale mandates one. These break a defined requirement of the target locale. Always edit.
• Grammar, spelling, and broken syntax. Actual errors, not stylistic roughness. A real agreement error or a genuinely ungrammatical sentence is a defect. Edit.
• Meaning-destroying garble. The sentence is so mangled the reader cannot recover the intended meaning. Edit, but only enough to restore meaning, not to perfect it.

Things that tempt you but are preferential (leave them)

• Synonym swaps. The engine wrote "purchase," you prefer "buy." Both correct, both clear, no approved-term conflict. Leave it.
• Rhythm and flow tweaks. Reordering a clause because the cadence is nicer, splitting a sentence you would have split, joining two you would have joined. If the original reads correctly, leave it.
• Register nudges within acceptable range. The engine is slightly more formal or slightly more casual than your instinct, but still inside the appropriate register for the content. Leave it.
• Connective and filler preferences. "However" versus "but," "in order to" versus "to," "additionally" versus "also." Invisible to the reader, expensive in aggregate. Leave it.
• Your signature phrasings. The constructions you reach for because they are yours. This is the hardest category, because it does not feel like preference; it feels like quality. It is preference. Leave it.

The hard truth in that second list is that almost everything in it would make the text marginally better. That is exactly why it is dangerous. Over-editing is not the temptation to make the text worse; nobody struggles with that. It is the temptation to make the text better in ways that do not matter to anyone but you, paid for with time and money that were promised to something else. The discipline is not lowering your standards. It is aiming your standards at defects instead of at taste.

A Worked File: Camille Sits on Her Hands

Let us watch the discipline operate on a real-feeling file so the abstraction becomes muscle memory. Camille has an English target file, machine-translated from German, for a consumer kitchen-appliance manual: lower-stakes content, full post-editing requested because it is customer-facing, but emphatically not a drug label. The client has an approved-terms list (the device is always the "blender base," never the "motor unit"; the action is always "press," never "push") and a US English locale spec. Here are eight segments as the engine drafted them. Watch which ones Camille touches and, more importantly, watch her resist the ones she does not.

Segment 1

MT: "Place the blender base on a flat, dry surface before use."
Camille's instinct: She would have written "level surface" instead of "flat surface." It is a hair more precise.
Decision: Leave it. "Flat" is accurate, clear, uses the approved term "blender base," and a reader is not misled. This is a synonym preference. Hands off. (Acceptable, no edit.)

Segment 2

MT: "Do not immerse the motor unit in water."
Camille's instinct: Two problems. "Motor unit" violates the approved term, which is "blender base." And she should verify the negation against the source.
Decision: Edit. Change "motor unit" to "blender base" (terminology violation, a defined requirement). Confirm against the German that the instruction is indeed "do not immerse" and not, say, "immerse only briefly," because a flipped negation here is a safety and warranty defect. The term fix is necessary; the negation check is the heart of the job. (Necessary edit.)

Segment 3

MT: "The appliance can process up to 1.5 litres of liquid."
Camille's instinct: The number looks plausible, and "litres" is the British spelling.
Decision: Two-part. First, verify "1.5" against the source; a wrong capacity is a real defect, so she checks and confirms it matches. Second, the locale spec is US English, where the spelling is "liters." "Litres" is a locale failure against a defined requirement, so she changes it to "liters." Both moves are necessary, neither is preference. (Necessary edit.)

Segment 4

MT: "To begin blending, press the start button firmly."
Camille's instinct: She might drop "firmly" as slightly redundant, and she could imagine "To start blending" as tighter than "To begin blending."
Decision: Leave it entirely. "Press" is the approved verb. "Firmly" is accurate to the source and arguably useful guidance. "Begin" versus "start" is pure synonym preference. Every change she is tempted to make is cosmetic. This is the segment that separates a disciplined post-editor from an over-editor, and the disciplined move is to do nothing. (Acceptable, no edit.)

Segment 5

MT: "Clean the blender base with a damp cloth. Never use abrasive cleaners, as this can damage them."
Camille's instinct: "Them" has no clear singular antecedent; "the blender base" is singular, so "them" is a genuine grammatical error, not a style nit.
Decision: Edit. Change "them" to "it." This is an actual agreement error that a careful reader would notice and that fails basic correctness. She fixes the pronoun and nothing else; she does not also rewrite the sentence to be prettier. Minimal, surgical, necessary. (Necessary edit.)

Segment 6

MT: "This product is intended for household use only and is not suitable for commercial operation."
Camille's instinct: Long-ish. She could split it into two sentences for punch, or trade "is not suitable for" for "should not be used in."
Decision: Leave it. It is accurate, clear, grammatical, on-term, on-locale. The split and the rephrase are both improvements that improve nothing the reader needs. Hands off. (Acceptable, no edit.)

Segment 7

MT: "Allow the appliance to cool for at least 15 minutes before disassembly."
Camille's instinct: The number "15" and the safety instruction both demand verification, because cooling time before handling is a burn-risk instruction.
Decision: Verify against the source. If the German says 15 minutes, leave the segment exactly as written; it is correct, clear, and safe. The act of verifying is the necessary work; the absence of an edit afterward is the correct outcome. Verification is not the same as editing, and a verified, untouched segment is a job well done, not a job skipped. (Verified, no edit needed.)

Segment 8

MT: "If the appliance does not work, please ensure that it is properly plugged in and that the lid is not securely closed."
Camille's instinct: This one reads perfectly and is therefore the most dangerous segment in the file. "The lid is not securely closed" is almost certainly a flipped meaning; a troubleshooting step should tell the user to ensure the lid is securely closed.
Decision: Edit, after checking the source. The German will say to ensure the lid is closed. The engine dropped or inverted the logic and rendered the inversion in flawless, confident prose, which is exactly the silent critical error pattern. She changes "is not securely closed" to "is securely closed." This is the single most important edit in the file, and the casual over-editor who was busy swapping "press" for "push" in Segment 4 might be too fatigued or too distracted to catch it. Restraint elsewhere is what preserves the attention this segment demands. (Necessary edit, the critical one.)

The tally

Across eight segments, Camille edited four and left four untouched (one of those four she actively verified and then left alone). An over-editing version of Camille would have touched all eight, "improved" the four acceptable ones, and spent perhaps 40% more time, while running a real risk of being so deep in cosmetic changes that she rushed Segment 8 and shipped the flipped lid instruction. The disciplined version is faster and safer, and that is not a coincidence. The attention you save by not polishing acceptable segments is the attention you spend catching the fluent, confident, deadly error. Restraint is not the opposite of quality. On an MT-first file, restraint is how you fund quality.

Editing fewer segments is not editing less carefully. It is concentrating your care where a defect actually lives, and refusing to spend it where the machine already got it right.

Building the Habit When the Urge Will Not Quit

Knowing the rule and obeying it at 4 p.m. on the ninetieth segment are different skills, and the second one is the one that pays. The urge to improve acceptable text does not go away; it is the same instinct that makes you a good translator, and you would not want to kill it. You want to govern it. Here are the practical handles that turn the principle into a reliable working habit.

Name the edit before you make it

The single most effective intervention is to force a one-word classification before your hands move: necessary or preferential. Say it internally. "This negation is wrong, necessary." "This is just a nicer word, preferential, leave it." Naming it interrupts the automatic reach. The over-editor's problem is that the edit happens below the level of conscious decision; the cursor is already changing the word before any judgment runs. Inserting a named decision, even a half-second one, is enough to catch most preferential edits in the act. If you cannot honestly name an edit "necessary," it is preferential, and the honest answer is to leave it.

Watch your own edit-distance honestly

Most CAT tools and translation-management systems (TMS) can show you how much you changed the raw MT, often as an edit-distance metric. Use it as a mirror, not a target. If you are editing 60% of segments on content the quality estimation flagged as clean, something is off; either the engine is genuinely bad on this content (possible and worth flagging to the PM) or you are over-editing (more likely if it is a pattern across clients and engines). A linguist who never looks at their own edit rate cannot tell the difference between "this MT needed a lot of work" and "I cannot leave anything alone." The data is not there to police you; it is there to let you see a habit you cannot feel from inside it.

Separate verification from polishing in your head

Over-editing thrives when verification and improvement blur into a single read. You start checking a segment against the source, notice a phrasing you would change, and the checking and the changing become one motion. Pull them apart. The first job on every segment is a verification question: does this say what the source says, with the right terms, numbers, and locale? That question has a yes or no answer and nothing to do with style. Only if it surfaces a real defect do you edit, and then you edit only the defect. Keeping the verification pass clean of stylistic judgment is most of the discipline. You are a fact-checker first and a stylist almost never.

Respect the brief and the risk tier

The acceptable bar moves with the content, and you must read the brief to know where it sits. A high-volume internal knowledge-base article on a light-PE brief has a low acceptable bar: if the meaning is correct and clear, ship it, full stop, even if it is plain. A customer-facing manual on a full-PE brief has a higher bar, but "higher" still means "free of defects," not "rewritten to my taste." A regulated drug label is not on this lesson's playing field at all; that content gets exhaustive verification or full human translation and is often MT-forbidden. Matching your effort to the tier is the legitimate version of the spectrum, and it never includes a license to indulge preference. Read the brief, find the bar, edit to the bar, and stop.

Forgive the instinct, then redirect it

Be honest about why this is hard, because pretending it is easy makes you worse at it. The urge to polish is not a character flaw; it is professional pride doing its job in the wrong place. You spent years learning to find the better word, and now a workflow is asking you to often not use that skill, which feels like being asked to be worse. Reframe it. The skill is not gone; it is redeployed. The same judgment that finds the better word is what finds the flipped negation in flawless prose. Your craft did not get smaller in the MT era. Its target moved, from "make every sentence as good as I can" to "find and fix the sentences that are actually wrong, and have the discipline to let the rest be." That second target is rarer, harder, and worth more, because the engine can polish but it cannot decide what matters. That decision is the human's, and refusing to make it on every acceptable segment is what keeps the whole economics, and the profession, standing.

Key Takeaways

• Two edits, two universes. A necessary edit fixes something genuinely wrong (accuracy, number, term, locale, real grammar, meaning-destroying garble). A preferential edit replaces acceptable text with text you like better. Post-editing pays for the first and silently bills you for the second.
• Over-editing destroys the MTPE economics. The post-editing rate (roughly 50 to 75% of full translation, around $0.05 to $0.15 per word) is justified only by the throughput the engine enables (about 5,000 words a day versus 2,000). Rewriting acceptable segments halves your effective income, blows the deadline, and pushes the rate down for everyone.
• ISO 18587 codifies the rule. The standard explicitly directs the post-editor to fix errors and make no purely preferential changes, using as much of the raw machine output as possible.
• The revision raises the tension, not the license. The revised ISO 18587 (DIS ballot, targeted late 2025 into 2026) demands the post-editor hold full professional-translator competence and replaces light-versus-full with an effort spectrum, but the spectrum scales how hard you hunt for real defects, never how freely you indulge style. Restraint still holds at every point on it.
• Run the acceptable test. Ask of every segment: would this, untouched, mislead, harm, embarrass, or fail a defined requirement? If no, leave it, even if you can imagine something better. The test is about consequence, not taste.
• Restraint funds quality. The attention you save by not polishing acceptable segments is the attention you spend catching the fluent, confident critical error (the flipped negation, the wrong dosage) that hides in perfect prose. Editing less is how you catch the thing that matters most.
• Name the edit before you make it. Force a one-word call (necessary or preferential) before your hands move, watch your own edit-distance as a mirror, keep verification separate from polishing, and edit to the brief's bar, then stop.
• Your craft did not shrink; its target moved. The judgment that finds the better word is the same judgment that finds the silent mistranslation. In an MT-first world the engine can polish but cannot decide what matters. Deciding, and refusing to over-edit the rest, is the human's job and the value the machine cannot replace.