Machine Translation Post-Editing: From Raw MT to a Clean Report
A note before you read this: everything below is a self-directed practice exercise. "Aurelia Home Goods Ltd." is a fictional company I made up for the purpose of this drill, the Q3 report is invented text, and the machine-translated version came from the free Bing Microsoft Translator (no affiliation, just the tool I had open). No real client, no real data, no real numbers. I'm sharing it because the editing process itself — spotting what raw MT gets wrong and why — is the part worth talking about.
Where This Fits Into Machine Translation Post-Editing and Linguistic QA
I had a spare hour last week and decided to run a small MTPE (machine translation post-editing) drill on myself. I wrote a short, fictional EN quarterly performance summary — the kind of internal finance memo that circulates before a leadership meeting — ran it through Bing's translator into Turkish, and then sat down with the two versions side by side in memoQ to see how far raw MT actually gets you, and what it would take to close the gap.
Short answer: closer than people expect, and further than people hope. It also needed noticeably less post-editing than a similar exercise I ran before this one — most of what follows are the exceptions, not the rule.
What the raw MT actually got right
I want to be fair to the machine here, because a lot of MTPE content online treats raw MT like it's uniformly bad, and that's not been my experience. The numbers came through untouched — every euro figure, every percentage, every date. Sentence structure held up in the vast majority of segments. If I'd needed a "get the gist" version for internal use only, this would have done the job in about four seconds instead of the forty minutes I actually spent on it.
Where it fell apart was in the places that matter most in a document like this: the parts a reader would act on.
The errors that actually mattered
1. A sentence that just doesn't work grammatically.
The source said "Q4 is forecast at €6.1M." Bing gave me "Q4'ün €6.1M olarak tahmin ediliyor." Read that out loud in Turkish and it stalls — "Q4'ün" (Q4's) is a possessive that's left hanging with nothing to possess. It needed either a noun to attach to ("Q4 geliri" — Q4's revenue) or the possessive dropped entirely. I went with dropping it and restructuring, since the rest of the sentence didn't call for extra words.
2. A mistranslation that changes what actually happened.
Source: "14 underperforming SKUs were discontinued." Bing's output translates back to something closer to "the production of 14 underperforming SKUs was discontinued." That's not a style quibble — it's a different business fact. Discontinuing a SKU (delisting it, pulling it from the catalogue) and halting its production are related but not identical events, and a reader skimming this for a leadership meeting could walk away with the wrong picture. I caught it partly because the exact same sentence structure appears again two paragraphs later, translated correctly that time — which is its own lesson: MT consistency within one document is not something you can assume, even for a repeated phrase.
3. Tone flattening on a sentence that was supposed to carry a warning.
Source: "There's been some pushback from the team on the new interface." "Pushback" is doing real work in that sentence — it's a manager signaling friction, maybe an early warning sign. Bing rendered it as neutral "feedback" ("geri bildirimlerde bulundu"), which reads like enthusiastic input rather than resistance. In a report meant to flag operational issues before a meeting, softening that word means softening the actual message. I edited it back toward something that keeps the friction — closer to "raised objections" than "gave feedback."
4. A finance term translated into the wrong register.
"Term sheet" came out as "şartname," which in Turkish usually means a technical specification document (the kind you'd see in a tender or procurement process), not a negotiation term sheet. Same general neighborhood, wrong building. I swapped it for language closer to "an outline of terms," which is what Procurement is actually waiting on in that sentence.
5. Terminology that wandered.
"Freight costs" showed up as "nakliye maliyetleri" for most of the document, then flipped to "kargo maliyetleri" once, near the end. In everyday Turkish, "kargo" leans toward parcel/courier shipping — think a package on your doorstep — while "nakliye" is the right register for B2B freight and logistics. Small drift, but the kind that makes a reader wonder if you're suddenly talking about something else. I unified it to one term throughout.
I found the same pattern with "restore the marketing budget," which appeared once as "eski seviyesine getirilmesi" (bring it back to its previous level) and once as "geri yüklemek" — a phrase that, to my ear, sounds like restoring a backup file more than reinstating a budget line. Consistency isn't just tidiness; in a document one person will read start to finish, inconsistent terminology reads as multiple authors, or worse, multiple meanings.
6. Two different ideas sharing one word.
This one only showed up after I'd already gone through a full pass — the kind of thing you catch on a second read rather than the first. The source has: "The Munich facility is now running at roughly 70% of planned capacity. Staffing is the bottleneck, not throughput." Two distinct concepts — how full the facility is running (capacity) and how much it's actually producing per unit of time (throughput). My first post-edit pass used "kapasite" for both, which collapses two separate ideas the source deliberately keeps apart. I changed the second instance to "verim" so the sentence still draws the distinction the writer intended: the problem isn't how much capacity exists, it's how much output that capacity is generating.
The screenshots
Here's the memoQ project itself, source and target side by side, with the segments I've mentioned above visible in context. (Cropped to the working grid and lightly watermarked, since this is a practice file rather than anything I'd present as authentic client output.)
Executive Summary segment, raw MT — freight and fulfillment terms first appear here. Overview section — DACH growth and the freight cost renegotiation. Revenue by Channel table and the marketplace growth note. Operational Notes into Iberia — where "pushback" and the SKU line live. Capacity/throughput line and the Q4 outlook — revised on a second pass.
How I actually worked through it
I didn't fix things in the order they appear on the page — I went through the document twice, each pass looking for a different category of problem, because trying to catch grammar, meaning, tone, and terminology all in one read means you inevitably miss one of them.
First pass — accuracy. Read every target segment against its source and ask: does this say the same thing? Not "does this sound fine on its own," because raw MT is very good at sounding fine on its own while quietly changing what happened. This is where the SKU/production issue and the "pushback" softening turned up.
Second pass — consistency and terminology. I used memoQ's concordance search to pull up every instance of a term I'd flagged (freight costs, restore/reinstate, fulfillment) and checked whether they'd been translated the same way everywhere. This is also where a termbase earns its keep — for a repeat client or an ongoing account, I'd build one from pass one onward instead of catching drift after the fact.
Third pass — read it cold, in Turkish only. No source open, just reading the target as if I were the person receiving this memo. This is where the "kapasite" repetition and a couple of clunky phrasings ("kullanıcı paylaşımlı sürücü" for "shared drive") surfaced — errors that are individually correct-ish but collectively make a paragraph feel translated rather than written.
Where this fits into MTPE and linguistic QA
This is a small, deliberately manageable example of what MTPE actually involves, and it's a direction I'm putting real time into — alongside broader linguistic QA work, which is the same skill set applied to catching not just translation errors but the review process itself (missed segments, inconsistent terminology across a project, formatting that didn't survive the round trip).
There's a distinction in the industry between "light" post-editing (fix only what's factually wrong or unreadable, leave the rest) and "full" post-editing (bring it to a standard indistinguishable from work translated from scratch, including tone and register). This exercise was closer to full post-edit — because a document like this, going in front of leadership, isn't a case where "good enough to understand" is actually good enough. The stakes of a report like this are exactly why the six issues above matter more than they'd look on paper: three of them (the SKU line, the "pushback" softening, the term sheet mismatch) could change a decision-maker's read of the quarter, not just the prose style.
If you're evaluating machine translation output for something similarly high-stakes — an internal report, a document going to a client, anything where the reader is going to act on what it says — this is roughly the level of scrutiny I'd bring to a proofreading and editing pass, whether the starting point is raw MT, a first-draft human translation, or your own EN copy.
Working on something similar? I'd be glad to talk it through — drop me a message.
Comments