A 150-page technical manual lands in your queue. Deadline: two weeks. Budget: slashed 40%. That’s the scenario pushing half the localization industry toward MTPE for technical content instead of waiting for—or quoting—full human translation rates.
But MTPE for technical manuals isn’t just dumping text into DeepL and hoping a junior editor survives the AI artifact cleanup. It’s a coordinated workflow with real pre-work, clear quality checkpoints, properly tuned tools, and the discipline not to gold-plate the process. Here’s what actually works.
What MTPE is, and why it works for technical documentation¶
MTPE (Machine Translation Post-Editing) means running text through an AI translator, then having a human editor clean it up. Sounds like a shortcut, but for technical content, it’s the opposite of lazy—it’s systematic.
Why? Because technical writing is structural. Instructions, specifications, API docs, user manuals are terse, low on nuance, heavy on repetition. Modern MT engines handle this well. Research confirms that for technical content, MTPE typically saves 30-60% on cost and delivers 15-30% faster than pure human translation.
Compare that to marketing copy (where MT often misfires) or legal contracts (where one missed nuance is expensive). Technical docs sit in a sweet spot where MTPE yields predictable quality.
The MTPE workflow: source text to delivery¶
Most people think MTPE is “machine → editor → done.” It’s not. There are six stages; each one matters.
1. Source text preparation (pre-editing). Source quality drives 80% of MT output quality. If your technical writer says “the system can possibly process data,” the MT engine will hand you something ugly. Instead: clear terminology (consistent across the doc), short sentences with unambiguous grammar, no hedging language. Getting source quality right is the first massive time win.
2. MT engine selection and setup. Don’t just reach for Google Translate or DeepL. For technical docs, you want an engine trained—or at least fine-tuned—to your domain. Options: - Off-the-shelf (hosted): DeepL, Amazon Translate, Google Cloud Translation. Good quality for common language pairs, but zero understanding of your terminology. - Fine-tuned: For volumes >50K words/month, test fine-tuning on your own TM via Amazon, Google, or Azure. Typical gains: 20-30% quality improvement over 2-3 weeks.
3. Translation Memory (TM) + Glossary. A solid TM is half the battle. If you’ve translated similar content before, reuse it—it carries context. Glossary (terminology database) is your hard line: “Product X never translates; it’s always ‘Product X.’” Full stop.
4. MT generation. The machine makes a draft. Minutes to hours depending on volume. By here, you’ll see if your setup worked—80%+ of terms on target, sentences make sense—or if you need to adjust.
5. Post-editing. Now the editor either does light PE (fix errors fast) or full PE (refine for publication). More on this below.
6. QA pass. Final: automated checks (spelling, tags, numbers, punctuation) + human expert review. Without this, you’re shipping half-baked work.
Timeline on a typical 10,000-word technical doc: pre-edit 4 hrs, MT generation 0.5 hrs, light PE 8-12 hrs, QA 2-3 hrs. Total: ~15-20 hours. Pure human translation of the same text: 30-40 hours.
Light PE vs. Full PE: when to use each¶
MTPE comes in two flavors. Each has different speed, cost, and quality expectations.
| Factor | Light Post-Editing | Full Post-Editing |
|---|---|---|
| Goal | Correct grammar, spelling, obvious mistakes | Publication-ready: style, tone, register |
| Speed | 2-3x faster than human translation (5,000-8,000 words/day) | 15-30% faster than human translation (2,000-3,000 words/day) |
| Quality | Comprehensible, internal/reference use | Publishable, client-facing, professional |
| Edit distance | 15-25% | 30-40% |
| Best for | API docs, internal manuals, knowledge bases | User manuals, help files, customer-facing materials |
| Cost | 40-50% savings vs. human translation | 20-30% savings vs. human translation |
| Who edits | Junior editor or translator new to MTPE | Senior translator with domain expertise |
Light PE is your pick when output is for internal use, speed matters, and “good enough” is genuinely enough. Example: you’re translating API docs from English to German. Devs just need to understand how to use it. MT gets you 85% of the way; light PE adds the last 10%.
Full PE when the text goes public, stakes are high, or brand reputation is on the line. Medical device instructions, lab protocols, regulatory documentation.
Research shows that for most technical documentation, light PE + QA catch is the sweet spot. QA will catch real errors (mostly automated, with human override). You save money reformulating, and you hit your deadline.
Setting up QA: the checklist¶
Automated QA is your first defense line. Set it up once in your CAT tool (SDL Trados, memoQ, Phrase, Lokalise), and it runs on every project.
| QA Check | What It Catches | How to Set It Up | Example |
|---|---|---|---|
| Terminology | Terms not in glossary or TM | Enable “Flag not in glossary” in CAT tool | Glossary says “API”; editor wrote “Interface” |
| Formatting | Broken tags, missing line breaks, numbers | Enable tag validation, number matching | <b>Bold</b> became <B>Bold</b> |
| Spelling & Grammar | Typos, doubled words, bad agreement | Run spellcheck on target language | “programa programa” instead of “programa” |
| Numbers & Quantities | Missing or altered figures | Create rule: “number in source must match number in target” | Source: “32 MB”, Target: “3 MB” (truncated) |
| Consistency | Same term translated multiple ways | Export TM, scan for single English word with 5+ translations | “Database” translated as “база данных,” then “БД,” then “хранилище” |
| Forbidden Terms | Untranslated English words in target | Create blacklist of terms that must not appear | Russian text with “OK,” “ASAP,” “CSV” left in English |
ISO 18587:2017—the European MTPE standard—says the bare minimum is spelling, grammar, terminology consistency, and formatting. Everything else scales with ambition.
Practical starting point: Set up 5 QA rules (terminology, spelling, numbers, forbidden chars, consistency). Run QA, fix flagged items. On large projects, automated QA catches 70-80% of actual errors.
Terminology and Translation Memory: building the backbone¶
Technical text is 40% repetition. One term appears 100 times. If you translate it 100 different ways, you’re not doing MTPE—you’re doing chaos.
Translation Memory (TM) is your repository of previous translations with context. When the editor sees a new sentence, the CAT tool shows how you translated something similar before. Quality TM saves 30-40% of editing time.
Glossary is your enforcement layer: “Product X always stays as ‘Product X’; it never translates.” Glossary overrides TM—pure terminology rules.
How to set this up:
-
Get or build a TM. If you’ve translated this domain before, export all prior projects in .tmx format (standard TM format). Clean out garbage. What’s left is gold.
-
Build a glossary from your product docs. Extract every technical term your product uses and its translations. Example for an e-commerce platform: - “Shopping cart” → “корзина покупок” (Russian) / “кошик покупок” (Ukrainian) - “Checkout” → “оформлення замовлення” (Ukrainian) / “оформление заказа” (Russian) - “Refund” → “повернення коштів” (Ukrainian) / “возврат средств” (Russian)
-
Inject glossary into MT if possible. Basic APIs (DeepL, Google Translate free tier) don’t support this. Enterprise options (Azure, Amazon, custom fine-tuning) do.
-
Feed editor corrections back into TM monthly. Every well-edited segment is new knowledge. Don’t let it die in a delivered file.
Studies show that with high-quality TM (>80% fuzzy match), editing time on new projects drops 40-50%. Without TM, you’re editing blindfolded.
Productivity benchmarks: what to expect¶
Numbers people always ask:
- Light PE, new language, good MT: 250-400 words/hour (one editor)
- Light PE, with TM >70% match: 500-800 words/hour
- Full PE, technical content: 150-250 words/hour
- QA review: 1,000-2,000 words/hour (mostly automated)
For a 10,000-word project: - Pure human translation: 8-12 days (40 hours) - Light MTPE, no TM: 5-6 days (25 hours) = 40% faster - Light MTPE, with TM: 3-4 days (15 hours) = 60% faster
This assumes the MT engine is reasonably good (BLEU >25, edit distance <35%), the editor is trained, and tools are configured.
Note: these numbers apply to projects 5K+ words. On small jobs (500-1000 words), the overhead of setting up TM, glossary, and CAT config won’t pay back.
Tools: which CAT software and MT APIs to use¶
CAT software (where editors work): - SDL Trados Studio. The industry default—70% of agencies demand it. Expensive (€1,500-3,000/year), but rock-solid TM, QA, and custom MT integration. - memoQ. More affordable (€500-2,000/year), snappier UI, native MT support. Popular in Europe and CIS regions. - Phrase (formerly Memsource). Cloud-native, linguist-friendly, built-in MT engine connectors. - Lokalise. Designed for digital/software teams, CI/CD integration, but less suited to traditional MTPE workflows.
Pick based on what you (or your client) already know.
MT engines: - DeepL API. Low cost (~€50/month for 500K characters), high quality for European language pairs. No inline glossary support, but workarounds exist in CAT. - Amazon Translate. Cheap at scale, fine-tuning on your TM. Best for large-volume projects. - Google Cloud Translation. Even better quality, steeper price. Glossary support, AutoML for custom models. - Azure Translator. Inline glossary, fine-tuning, good if you’re already in the Microsoft ecosystem.
Recommendation: For your first MTPE project, start with DeepL or Amazon Translate—fast to test, reasonable quality. Once volumes justify it and tools pay for themselves, explore fine-tuning.
Common mistakes and how to avoid them¶
-
Picking an MT engine without testing. You bought Trados and threw it at Google Translate, assuming you’re now an MTPE expert. Wrong. Test 1,000 words on 3-4 engines. Edit distance varies by 20% or more depending on the engine and language pair.
-
Ignoring source text quality. MT can’t understand grammatically broken input better than a human can. If your writer says “the system can maybe contain errors,” the MT output will be garbage. Involve an editor in pre-editing (fixing source), not in recovering after MT fails.
-
Assuming MTPE works for everything. Poetry, marketing taglines, legal clauses, creative writing—MTPE isn’t the answer. Only structured content: instructions, APIs, specifications, technical reference.
-
Over-engineering the process. Twenty QA rules, a 500K-segment TM, fine-tuning, three levels of review. Result: excellent quality that costs as much as full human translation. Start lean: 5 QA rules, baseline TM, light PE. Scale after you have baselines.
-
Wrong payment model. Don’t pay MTPE editors by the word—they’ll skip errors to finish faster. Pay hourly or by “effort hours.” Tie payment to quality metrics (acceptable edit distance, zero terminology errors).
Implementing MTPE: a practical month-long roadmap¶
Week 1: Pilot and Planning - Select a 5,000-10,000-word technical project (ideally with repetitive terminology) - Test 2-3 MT engines on the first 500 words - Hire or assign an editor with MTPE experience (or train one over 2-3 days)
Week 2: Setup - Configure TM in Trados/memoQ - Build a glossary from your product documentation (50-100 key terms) - Enable 5 foundational QA rules (terminology, spelling, numbers, forbidden terms, consistency)
Week 3-4: Execution and Learning - Run MT generation on pilot content - Editor performs light PE (2-3 hours per 1,000 words) - Run QA checks, fix flagged items - Track: hours spent, cost, error count. Compare to full human translation of similar text.
Then iterate: If this 30% time savings / 50% cost savings holds, scale up. If it doesn’t, revisit MT engine choice, TM quality, or editor skill level.
FAQ¶
Is MTPE appropriate for high-risk technical content?
For critical domains (medical, nuclear, aviation), use only full post-editing with domain expertise. For moderate complexity (manuals, API docs, product specs), MTPE saves 40-60% of time with proper QA. The differentiator isn’t content type—it’s your tolerance for errors and regulatory requirements.
How do I calculate ROI?
Run a 5K-10K word pilot: track MT+editing+setup time, compare to full human translation cost. Most teams see payback by project 3, once TM accumulates value. Formula: (Hours saved × editor rate) - (MT API + CAT license) = ROI.
How long to train an editor?
Basic orientation: 2-3 days (MT artifacts, QA tools, style guides). Full competency: 2-3 real projects. After that, they work efficiently.
Which MT engine for technical docs?
DeepL (quality + affordability) or Amazon Translate (scales well). Test on a representative 500-1000-word sample. Target edit distance <35% or BLEU >25.
What does full MTPE setup cost?
CAT tool (Trados/memoQ): €1,000-3,000/year. MT API (DeepL, Amazon): €200-800/month. Glossary + TM: €500-2,000 initial setup. QA tools: often included. Typical payback: 1-2 projects.
How do I ensure terminology consistency?
Enable terminology QA in your CAT tool to flag mismatches against glossary and TM. Export the final translation and scan for “how many ways was term X translated”—should be exactly one.
What if MT output is terrible?
Check: 1) Is source text grammatically sound? 2) Is MT engine trained on technical content? 3) Is glossary configured? 4) Is TM quality? If all are solid and BLEU <20, MTPE won’t save money—stick with human translation.