47 pages of machinery documentation, a 3-day deadline, and MT output that’s 80% usable - but the safety warnings are at the wrong severity level, a torque value got transposed from 25 Nm to 52 Nm, and two product codes have been “translated” when they should pass through unchanged. Technical MTPE isn’t just MTPE on harder content. It has different failure modes, different quality checks, and a different liability profile than any other content type.
This guide walks through the full 6-stage workflow and the specific quality checks that separate acceptable technical MTPE from the kind that creates warranty exposure and recall risk.
Why technical manuals are MTPE’s hardest case - and its best ROI¶
Technical manuals sit at an interesting intersection for MTPE: they’re simultaneously the most suitable content type and the one with the highest stakes for errors.
On the suitability side, technical documentation is structured, repetitive, domain-consistent, and terminology-controlled. MT engines thrive in exactly these conditions. A product manual for an industrial pump typically uses the same 300-400 terms throughout, follows predictable procedural sentence patterns, and gets revised regularly - meaning your Translation Memory builds up leverage fast. According to Nimdzi’s MTPE Efficiency Gap research, positive MTPE ROI kicks in clearly at 500,000+ words per year in a consistent domain. Technical documentation clients - manufacturers, software companies, equipment suppliers - are precisely this profile.
On the stakes side, technical manuals carry real-world consequences. A wrong term in a safety warning isn’t a style issue - it’s warranty exposure and a potential product liability trigger. A transposed number in a calibration table can cause equipment to fail in the field. As oneword.de notes in their technical MT analysis, “Relying exclusively on machine translation for technical editing and documentation would be fatal” - the key word being “exclusively.” The workflow exists to make MT the starting point and human judgment the quality gate.
Two additional constraints make technical content harder than general text:
Character limits for HMI displays. Operator panels, touchscreen interfaces, and embedded display labels have fixed character counts. MT doesn’t enforce these - post-editors must catch target text that exceeds display limits, which isn’t a linguistic error but a production failure.
Data security. Public MT APIs send source content to external servers and may use it as training data. For proprietary machine specs, pharmaceutical processes, or defense-related documentation, this is a legal and contractual risk, not just a preference. If your technical client operates under NDA or has IP concerns, they need either an on-premise MT solution or a contractually covered API arrangement - not the free tier of a public MT service.
A 2025 survey by GTS Translation found that 87.93% of professional translators now engage with MTPE regularly, up from a much smaller baseline three years ago. For technical translators specifically, the shift has been faster - the content suitability is too obvious to ignore.
MTPE workflow for technical documentation: 6 stages¶
Most descriptions of MTPE stop at three steps (translate, post-edit, deliver). For technical content, that’s missing three stages that determine whether the project is profitable or a warranty issue.
Stage 1: Source pre-editing¶
Before MT sees a single sentence, the source text needs review. This is the most consistently skipped stage and the one that causes the most preventable rework.
- Break long, multi-clause sentences into single-action sentences. MT handles these far better and the output is closer to your target document style. “Turn off the main power switch, allow the system to cool for 30 minutes, and only then open the access panel, making sure to ground yourself first” is four separate instructions - write it as four.
- Resolve ambiguous pronoun references. MT doesn’t know what “it” refers to when five components were mentioned in the preceding paragraph. It will guess, and it will be wrong half the time.
- Verify the approved glossary is applied to the source. Inconsistent source terminology produces inconsistent MT output even with term base enforcement. Fix it in the source, not in post-editing.
- Strip rogue inline formatting that creates tag noise - stray bold tags, redundant nested styles, inconsistent whitespace around variables.
Source pre-editing cuts post-editing time by 20-30% on average. It’s typically not billed as a separate line item, which is why it gets skipped. It should be priced in.
Stage 2: TM leverage before MT¶
Run the source through your Translation Memory before sending to the MT engine. Segments with ≥95% match against existing TM don’t need post-editing - they’re either exact matches or minor formatting variations of already-approved translations. Only fuzzy matches (50-94%) and new content (0%) go to MT.
On a manual you’ve translated a previous version of, TM leverage might hit 40-60%. That means the post-editor only handles 40-60% of the total word count. This is where the cost model actually works - the economics break down without a strong TM.
See the related guide on building and maintaining translation memory for technical clients for more on TM cleanup before launching MTPE.
Stage 3: Machine translation¶
MT output goes directly into your CAT tool, segment by segment alongside the source. Configure the engine before it runs:
- Feed your approved glossary as a custom dictionary where the API supports it. Unconstrained MT translates domain terms differently on every run.
- Specify domain context if the engine supports domain models. “Automotive” and “aerospace” perform differently even within the same language pair.
- Turn on tag protection. MT that corrupts DITA or XML tags creates publishing failures that take longer to diagnose than retranslating the segment.
Stage 4: Human post-editing¶
For technical manuals: full post-editing, not light. ISO 18587 defines both quality levels, and full post-editing - output that’s accurate, fluent, terminology-consistent, and free of machine-translation feel - is the required standard for any documentation that ships with a product.
The post-editor’s actual scope: - Keep MT segments that are accurate and meet style requirements as-is. Don’t touch them. - Edit segments with terminology violations, accuracy issues, or awkward constructions that would confuse a technician. - Retranslate only segments where the MT output is misleading or unusable - not as a first response to anything imperfect. - Do not edit for purely stylistic preference if the MT output is technically accurate. This is over-editing, and it’s the single biggest productivity killer in MTPE.
The post-editor must have the approved term base open throughout. Not as a reference to consult occasionally - as the active constraint on every terminology decision.
Stage 5: Automated QA¶
After post-editing, before any human review, run the full automated QA suite:
- Number and quantity mismatches between source and target
- Missing or corrupted tags
- Terminology violations against the term base
- Spelling errors and grammar issues
- Completeness check (missing translations, empty segments - MT can silently drop short table cells)
- Repeated segment consistency (the same source segment translated differently in two places)
QA tools like Xbench or Verifika complete this across a full document in seconds. Any flagged item goes back to the post-editor for resolution before LQA.
Stage 6: LQA review¶
A second linguist - not the post-editor - does a risk-calibrated review. The scope depends on content risk level:
- Standard technical manuals (product specifications, maintenance schedules): spot-check 20-30% of segments, with 100% review of all safety-related sections
- Safety-critical content (machinery with hazardous components, medical devices, pharmaceuticals, aerospace): full review, no sampling
The LQA reviewer focuses on high-risk segments: warning blocks, procedural steps, technical values, and any new content not covered by TM leverage. This is not a full retranslation check - it’s a targeted pass against the failure modes most likely to survive post-editing.
Terminology checks: the non-negotiable layer¶
In everyday translation, a synonym is a synonym. In technical manuals, “shaft” and “axle” might be completely different components. “Connector” and “plug” might refer to parts that are not interchangeable. Using the wrong one isn’t a style issue - it’s a documentation error that creates confusion in the field and potential warranty exposure.
The terminology check has three distinct layers:
Approved term base enforcement. Every source term in the term base must appear in its approved target form in every segment. QA tools flag any segment where a known source term appears without its approved target equivalent. This covers: - Component names that appear in diagrams, parts lists, and procedures (these must match exactly - the technician is cross-referencing the manual with the diagram) - Model numbers and product codes (never translate, never abbreviate, never transliterate if the source language uses the same alphabet) - UI labels (if a button is labeled “Start” in the interface, it’s “Start” in the documentation - not “Begin,” not “Initiate”)
Consistency within the document. MT engines produce consistent output within a single run but may translate the same term differently if it appears in different sentence structures. CAT tools track this, and QA tools flag cross-segment inconsistency. A component called three different things in a 200-page manual is a documentation failure regardless of whether each individual translation is technically defensible.
New terminology decisions. Source terms not in your term base require a human decision, not whatever fluent-sounding word the MT produced. Process for new terms: 1. Check whether the client has any existing reference documentation in the target language (published manuals, parts catalogs, website) 2. If no reference exists, make the decision and document it in the term base immediately 3. Flag new terms to the client for confirmation before final delivery on long-term accounts
A 2025 GTS survey found that 66% of translators describe MT output as “acceptable but requires significant edits.” For technical content, the majority of those edits are terminology-related - not fluency.
Safety warning integrity: where MTPE errors become liability¶
This is the check most technical MTPE projects handle badly, and the one with the highest real-world consequences.
Technical documentation follows strict safety warning hierarchies. Under North American standards (ANSI Z535) and the international equivalent (ISO 3864), the signal word hierarchy is:
| Signal word | Meaning |
|---|---|
| DANGER | Immediate hazard - will result in death or serious injury if not avoided |
| WARNING | Potential hazard - could result in death or serious injury |
| CAUTION | Potential hazard - could result in minor or moderate injury |
| NOTICE | Non-safety information - potential equipment damage or other consequences |
MT engines don’t understand this hierarchy. They translate “WARNING” as whatever their training data treats as the closest equivalent - and in many European languages, the most common translation is a generic word that’s weaker than the technical safety term. A DANGER signal that becomes “beware” or “note” in the target language isn’t a translation variation - it’s a safety failure that can create legal liability.
What the post-editor must verify for every warning block:
- The signal word maps to the exact approved target equivalent, not a synonym. The approved equivalent should be in the term base before work starts.
- The warning structure is complete: signal word + type of hazard + avoidance instruction + consequence. MT occasionally condenses or drops elements.
- Warning blocks haven’t been merged or split during MT processing (both happen with complex inline formatting).
- New warnings added in a revised document version are caught and properly translated (MT doesn’t differentiate between existing and new content).
For IEC/EN 82079-1 compliant technical documentation, this check is mandatory. Post-editors who aren’t briefed on safety signal word equivalents in the target language before starting will make terminology decisions on the fly - and those decisions will be inconsistent.
As one experienced technical translation reviewer noted on a ProZ forum thread about MTPE quality management:
Our QA checklist for machinery manuals has a mandatory two-pass review for any segment containing a signal word. The first pass is the post-editor. The second is a dedicated check on whether the severity level was preserved correctly. We found that MT was consistently downgrading DANGER to WARNING-equivalent phrasing in our primary language pair, and it took us two completed projects to catch this systematically.
This is a systematic MT failure mode, not an occasional slip. Build the check into the workflow, not the post-editing judgement.
Number, unit, and tag quality checks¶
These three categories have failure modes in technical MTPE that don’t exist in other content types.
Numbers and quantities¶
Transpositions (25 Nm → 52 Nm) and decimal separator confusion (a pressure value of 1,500 kPa becoming 1.500 kPa in a locale where the period is the thousands separator) are among the most common MT errors in technical content - and the easiest to miss reading for fluency, because the surrounding text is correct and the number looks plausible.
Required check: a dedicated QA tool number consistency pass (Xbench, Verifika, or built-in CAT QA) that flags every instance where a number in the source doesn’t appear unchanged in the target. Then a manual review of all numeric values in: - Procedural steps (torque values, pressure settings, temperature ranges) - Calibration tables and technical specifications - Part numbers and model codes
Cross-reference target values against the source document, not against your memory of what the value should be.
Units of measurement¶
MT engines don’t convert units and don’t consistently preserve unit notation. The check covers:
- Metric vs. imperial: if a specification says “200 lb” and the target audience uses metric, this is a source error to flag - not something to convert in translation without client authorization
- Unit notation consistency: “kPa,” “KPa,” and “kilopascals” are all defensible, but only one should appear in a given document
- Locale-specific unit presentation: whether spaces appear between numbers and units, and which symbols are used, varies by target locale and client style guide
Temperature, voltage, torque, and pressure values go directly into equipment calibration. A mislocalized value is not a documentation error in the abstract - it can cause equipment to operate outside safe parameters.
Tags and formatting integrity¶
In DITA and structured XML environments, inline tags carry functional meaning - bold text in a warning is not aesthetic, subscript in a chemical formula is not optional formatting. Tag errors in technical MTPE include:
- Dropped tags (the text is present but the formatting is gone - invisible in most review environments)
- Duplicated tags (double-bold, double-tagged - visible, but easy to miss at speed)
- Misplaced tags (formatting applied to the wrong portion of text, creating incorrect emphasis)
- Tag corruption (broken tag syntax that fails the publishing build - these are found in the production pipeline, not in review)
Most CAT tools run tag validation automatically. The critical process step is not skipping this check because “the text looks correct.” A dropped tag in a DITA conditional processing attribute can change which content variant gets published without changing the visible text at all.
ISO 18587 in practice: what the standard actually requires¶
ISO 18587:2017 is the governing standard for MTPE - the process equivalent of ISO 17100 for human translation. Clients increasingly ask whether your MTPE process is ISO 18587 compliant. Here’s what that actually means.
Feasibility assessment before every project. ISO 18587 requires assessing whether the specific source content and language pair are suitable for MT + post-editing before starting. You cannot apply MTPE universally. Content that fails the feasibility test includes: highly specialized content in low-resource language pairs (where MT training data is thin), handwritten or very poor-quality scanned material, and content where there’s no existing MT quality baseline for the domain.
Post-editor qualifications. ISO 18587 specifies that post-editors must have: advanced proficiency in both languages, domain expertise in the subject matter, and practical understanding of MT system error patterns. This last requirement is operationally significant - a translator unfamiliar with how MT fails in their specific language pair will over-edit some errors and miss others systematically.
Two quality levels, defined: - Light post-editing: correct only what impedes understanding or is clearly wrong. Output does not need to read as human translation. Appropriate for: internal use, gisting, content not published externally. - Full post-editing: output must be “semantically accurate and complete, grammatically correct, naturally fluent without a machine translation feeling, culturally appropriate, and consistent in terminology.” This is the required standard for technical manuals.
Documentation requirements. Certified ISO 18587 organizations must maintain: project specifications and client instructions, post-editor qualifications and assignment records, QA procedures and audit results, version control and revision history, and client feedback/issue resolution logs. These must be auditable.
What ISO 18587 does not specify: acceptable error rates or numeric quality thresholds. The quality specification in those terms is the client-specific part of the agreement, typically using a framework like TAUS DQF or a client-supplied LQA scorecard. ISO 18587 defines the process; the client defines the acceptance criteria.
For an in-depth look at the standard’s requirements, see the dedicated guide on ISO 18587 for MTPE.
Rates and productivity expectations for technical MTPE¶
The economics of technical MTPE are different from general content, and the variance is wider than most rate guides suggest.
Market rate ranges (2025):
| Service | Per-word rate | Notes |
|---|---|---|
| Human translation, technical content | $0.20-$0.30+ | Baseline for comparison |
| Full post-editing, technical manuals | $0.08-$0.15 | Standard for published documentation |
| Light post-editing | $0.02-$0.05 | Not appropriate for safety-critical content |
| Post-editing, hourly | $20-$50+ | Use when per-word underestimates effort |
For a 50,000-word service manual: full MTPE at $0.10/word averages $5,000 versus $10,000+ for human translation. The 40-60% cost reduction is real - but only when the content is suitable (structured, repetitive, good TM leverage) and the workflow is properly configured.
Productivity ranges for technical content: - Post-editor throughput: 1,500-3,000 words/hour - Human translation throughput: 250-400 words/hour
The productivity gain depends almost entirely on MT output quality in your specific language pair and domain. For some combinations, post-editors exceed 3,000 words/hour. For others, they don’t meaningfully exceed human translation speed.
The pricing tension. A 2025 industry survey found that 49% of translators report MTPE has significantly lowered client pricing expectations, while roughly half refuse to discount for MTPE at all, arguing full post-editing requires comparable cognitive effort to translation from scratch. If you’re quoting MTPE to clients, base rates on your actual measured post-editor throughput from a pilot project, not on industry rate cards. See also: MTPE pricing models compared.
Five mistakes that kill technical MTPE projects¶
These are the specific failure modes in technical MTPE, in order of frequency and impact on output quality.
1. Over-editing. Post-editors rewrite technically correct, fluent MT output because they find it stylistically “unnatural” by their personal standard. This is the #1 productivity killer - ISO 18587 is explicit that full post-editing means accurate and fluent, not identical to what a human translator would have produced from scratch. “Tighten the bolt to 25 Nm” doesn’t need to become “Apply a torque of 25 Nm to the fastener” if the first version is accurate and a technician would understand it. Define written acceptance criteria before the first project starts.
2. Skipping source pre-editing. Long, ambiguous source sentences produce confused MT output that takes longer to post-edit than translating from scratch. Pre-editing gets skipped because it’s not separately billable. The result: post-editors spend 30-40% of their time on problems that should have been fixed upstream. Build source pre-editing into your project timeline and price it in.
3. Ignoring the term base during post-editing. Post-editors correct “wrong-sounding” MT terminology to synonyms that aren’t in the approved term base. Automated QA then flags these as violations - creating a revision cycle that wipes out the time savings. Enforce term base use as a workflow requirement, not as a QA catch-after-the-fact.
4. Missing safety warning severity degradation. MT consistently produces weaker equivalents for safety signal words. Without a dedicated check at post-editing and LQA, these pass through. The post-editor briefing must include the approved signal word equivalents in the target language before work starts - not as a general reminder, but as a specific list attached to the project brief.
5. Per-word pricing when MT quality is unpredictable. Per-word rates work when MT output quality is consistently usable. When quality varies significantly - new language pair, thin domain training data, unusual document structure - post-editors effectively price themselves below minimum wage on the hard segments. Use per-hour pricing when MT quality is unpredictable. Use per-word rates only once you have pilot data showing consistent throughput.
Tools for technical MTPE workflows¶
What you actually need, without vendor pitch:
CAT tools: SDL Trados Studio and memoQ are the standard in enterprise technical translation. Wordfast is common among freelancers. Across is standard in many German-market industrial documentation accounts. All provide TM leverage, tag protection, and term base enforcement - these three features are non-optional for technical MTPE.
MT engines: Benchmark at least two on your actual client content before committing. DeepL for EU language pairs. ModernMT if you have an ongoing technical client with large TM assets and can benefit from adaptive engine improvement. Microsoft Azure Translator or Amazon Translate if you need custom terminology API control. memoQ’s evaluation guide provides a solid framework for the benchmark process.
QA tools: Xbench and Verifika are the most-used standalone tools for technical content. Both run number checks, tag validation, and term base enforcement. Built-in QA in Trados and memoQ covers most of the same ground. For a final QA pass on a delivered document outside the CAT environment, ChatsControl’s standalone QA validator checks for number mismatches, name consistency, terminology errors, and omissions - useful as a lightweight spot-check layer before sending the final file to the client.
TMS: Phrase (formerly Memsource) and XTM Cloud for LSPs managing high-volume MTPE pipelines. memoQ Server for memoQ shops.
Terminology management: SDL MultiTerm integrated with Trados, memoQ TermBase, or your TMS’s built-in termbase. The engine should be able to query the termbase at translation time - passive reference after the fact doesn’t prevent MT terminology errors.
FAQ¶
Can I use light post-editing for technical manuals?¶
Light post-editing - correcting only obvious errors and basic fluency - is not appropriate for technical manuals that ship with products. ISO 18587 is explicit: light PE is intended for internal use and gisting, not for published documentation where accuracy is safety-critical. If a client wants MTPE pricing but the content requires accuracy that only full PE can provide, you have two options: price for full PE, or decline the project.
What’s the realistic productivity gain on a typical technical manual?¶
For well-structured repetitive content with strong TM leverage, post-editors typically hit 1,500-3,000 words/hour. Human translation from scratch runs 250-400 words/hour for comparable technical content. The realistic gain on a real project - accounting for source pre-editing, QA, and LQA time - is often 2-3x faster overall, not the 5-7x sometimes cited for highly repetitive content. Measure your own throughput on a pilot before committing to client timelines.
How should I handle source errors I find during post-editing?¶
Don’t fix them in the target - flag them. A post-editor who corrects a source error in the translation has created an undocumented divergence between the source and target documents. The client needs to know the source contains an error, update the source, and approve the target correction. Keep a log of source errors found during post-editing; it’s part of the value you deliver as a professional, and it protects you if the error later causes a field problem.
How long does a technical MTPE project take versus human translation?¶
At 2,000 words/hour post-editing versus 300 words/hour human translation, a 50,000-word manual takes roughly 25 hours of post-editing versus 165 hours of human translation. Add pre-editing (4-6 hours), QA (2-3 hours), and LQA (5-10 hours depending on risk level) - still significantly faster. The caveat: these numbers assume suitable MT output quality. If MT quality is poor for your language pair, post-editing throughput drops toward human translation speed and the economic case collapses.
What metrics should I track on technical MTPE projects?¶
Track: edit distance per segment (how much the post-editor changes MT output), words per hour per post-editor, number of QA flags per 1,000 words, and error category distribution (terminology, numbers, tags, safety warnings separately). Edit distance is the most actionable metric - consistently high edit distance means the MT output is poor for this content type or language pair, and switching engines or adding source pre-editing will have more impact than briefing post-editors differently.