Category: Uncategorized

Machine Translation Post-Editing: What It Is and Why Teams Use It

Machine translation post-editing (MTPE) is the process of having a qualified human linguist review, correct, and finish the output of an automated translation engine before it ships. The engine produces a draft; the post-editor fixes mistranslations, enforces approved terminology, repairs formatting and tags, and brings the text up to an agreed quality level. It is a translation process with a different starting point — not an automated substitute for translation judgment.

That distinction matters. Raw machine translation is unreviewed engine output: fast, cheap, and acceptable for gisting or internal triage, but unverified against your glossary, style rules, or regulatory wording. MTPE produces a deliverable someone has signed off on. The international standard for this work, ISO 18587:2017, sets requirements for the full human post-editing process and for post-editor competence, and is written for translation service providers, their clients, and post-editors alike. It was published in 2017 and is flagged for revision.

Documentation and localisation leads look at MTPE for three reasons: throughput on large or frequently updated content sets, terminology consistency across releases, and predictable cost per word.

The harder questions are when it fits, when it does not, and what quality to expect by content type — answered here for software and manufacturing content specifically, not general-purpose translation.

When Post-Editing Makes Sense and When Full Human Translation Is the Safer Choice

Two questions settle most cases: can this content tolerate an accurate but plain rendering, and is your source text clean enough that editing is faster than translating?

Post-editing is usually worth it for repetitive, tightly scoped material — UI strings, parts catalogues, maintenance procedures, release notes, support articles — where terminology is controlled by a glossary and translation memory, the source is stable between releases, and the consequence of an awkward sentence is confusion rather than injury or a failed audit. Engine quality on your own content is the pivot: a study of machine translation quality and post-editor productivity found each one-point gain in BLEU cut editing time by roughly 0.16 seconds per word (about 3–4%), while weaker output drove up effort and pushed final quality down.

Full human translation is the safer choice for safety-adjacent instructions such as warnings and lockout steps, compliance-heavy documents that support a conformity declaration or regulatory file, high-visibility customer copy where tone and brand voice carry weight, and any text that needs restructuring rather than sentence-level correction. When the editor would rewrite most segments anyway, the savings disappear.

Raw output has a narrow but real role: internal comprehension and triage — scanning a supplier email, reading a field report, deciding which documents deserve budget. It is not a publishing path.

Then check operational readiness before committing: consistent source authoring, an approved termbase, segmentable formats (XLIFF, RESX, DITA rather than flattened PDFs), and a named reviewer per language with actual capacity. ISO 18587, published in 2017 and flagged for revision, sets out requirements for the full post-editing process and post-editor competence — useful language for specifying what you expect from a provider.

The tradeoff is blunt: post-editing buys speed only when the source and the workflow are clean enough to avoid rework.

Where MTPE Fits in Software and Manufacturing Content

Post-editing works best where content is repetitive, structured, and already written with translation in mind. In software, that usually means release notes, help-center articles, UI strings, and installation guides. These share a narrow vocabulary, reuse phrasing across versions, and live in modular files, so the engine has seen the pattern before and the editor is mostly confirming terminology and fixing placeholders, plurals, and string length rather than rewriting sentences.

Manufacturing content follows similar rules. Operator manuals, product specifications, and maintenance instructions are typically written in short imperative steps with fixed component names. Where a controlled language rulebook is enforced — one meaning per term, no ambiguous pronouns, capped sentence length — machine translation output tends to arrive close to usable, and the review pass concentrates on units, part numbers, and figure callouts.

Safety-adjacent material is a different case. Warnings, lockout/tagout procedures, hazard statements, and anything feeding a declaration of conformity can still go through post-editing, but it needs a second reviewer with subject-matter knowledge and a documented sign-off. ISO 18587 describes full post-editing and post-editor competence requirements for exactly this reason.

Structure predicts effort more reliably than language pair does. Short strings, templated sections, and a stable glossary keep editing light; dense narrative, marketing-adjacent copy, and regulated text push effort toward full human translation.

The practical move is segmenting by risk rather than by file. Tag content into three buckets — light review, full post-editing, human-only — and route each accordingly. Most localisation teams find the first bucket is larger than expected.

Quality Levels, Review Effort, and the Risks That Change the Outcome

Post-editing is usually delivered at one of two levels. Light post-editing aims for accurate, understandable text: the editor fixes mistranslations, dropped content, and terms that would mislead a reader, but leaves wording that is merely clumsy. Full post-editing aims for output that reads as though it were written by a translator in the target language — consistent terminology, correct register, and syntax a technical writer would accept. ISO 18587:2017 sets requirements for the full post-editing process and for post-editor competence, and is written for providers, clients, and post-editors alike. It was published in 2017 and is flagged for revision, so treat it as a process baseline rather than a current statement of engine capability.

Review effort tracks engine quality closely. Research presented at AMTA 2016 on machine translation quality and post-editor productivity found that each one-point gain in BLEU score cut post-editing time by roughly 0.16 seconds per word — about 3–4% — and that weaker output raised effort while producing lower final quality. Poor raw output does not just cost more time; it degrades the deliverable.

That makes the workflow around the editor as important as the editor. Locked terminology lists, a subject-matter expert pass on safety and configuration content, a defined QA checkpoint, and clean file handling for structured formats all change the outcome more than the engine choice does.

The recurring failure modes in software and manufacturing content are predictable: terminology that drifts between strings and manuals, technical terms translated in their general sense, syntax that is grammatical but unnatural, and ambiguous source segments with no context for the editor to resolve.

Set the quality target by use case. A UI string, a maintenance procedure, and a regulatory declaration do not need the same standard, and no honest process promises that every post-edited segment is publication-ready.

What the Standards and Workflow Evidence Say About MTPE Effort

There is a formal reference point for this work: ISO 18587:2017, Translation services — Post-editing of machine translation output — Requirements. It sets out requirements for the full human post-editing process and for post-editor competence, rather than treating editing as an undefined cleanup step. The standard was published in 2017, and ISO’s catalogue entry lists it as under revision, so treat it as a stable baseline for process design rather than a current statement on engine capability.

Its intended audiences matter as much as its contents. ISO frames the document for translation service providers, clients, and post-editors alike — which makes it usable on the procurement side, not just inside a provider’s production team. If you are writing a statement of work, it gives you shared vocabulary for defining what "post-edited" means, who is qualified to do it, and what the deliverable should look like before it reaches your documentation set.

The productivity evidence is more specific. In a 2016 AMTA paper, Machine Translation Quality and Post-Editor Productivity, researchers found that each one-point gain in BLEU score cut post-editing time by roughly 0.16 seconds per word — about 3–4% — and that weaker raw output raised editing effort while lowering the quality of the final text.

The practical reading for localisation leads: post-editing is not a fixed-cost shortcut. Its cost curve bends with source-text quality and engine output quality, which means review planning has to be estimated per content type and per language pair. Budget editing hours against measured engine performance on your own material, not against a blanket percentage discount.

Cost, Speed, and Quality: What Buyers Should Expect from MTPE

Post-editing sits between raw machine translation and full human translation on both cost and turnaround. Vendors report meaningful gains: POEditor’s blog claims post-editing can cut delivery times by roughly half, and Crowdin reports that around half of companies now post-edit their machine translation output rather than publishing it untouched. Treat those figures as vendor benchmarks, not guarantees — your savings depend on the engine, the language pair, and the content.

Speed is a function of how much editing the text actually needs. Research presented at AMTA 2016 on quality and post-editor productivity found each one-point gain in BLEU score reduced post-editing time by about 0.16 seconds per word, roughly 3–4%, with weaker engine output driving both higher effort and lower final quality. Clean, consistent source text, a maintained termbase, and segment-level context move that number more than any pricing negotiation will.

On quality, set expectations plainly: post-edited output is publication-ready only after review. ISO 18587:2017 defines requirements for full human post-editing and post-editor competence precisely because the review step is the deliverable, not an optional extra.

For budgeting, map content to risk. Raw machine translation suits internal or throwaway text; post-editing fits high-volume documentation with stable terminology; regulated, safety-critical, or brand-facing copy still warrants full human translation.

FAQ: Common Questions About Machine Translation Post-Editing

What is post-editing, in one sentence?
It is the process of having a qualified linguist review and correct raw machine translation output until it meets an agreed quality level — light for internal or short-lived content, full for published documentation.

Is it cheaper than full human translation?
Usually, but not automatically. Savings come from the engine doing enough of the work that the editor is correcting rather than retranslating. Weak source text, unstable terminology, tagged file formats, or a low-quality engine can push editing effort close to human translation levels — at which point you are paying for two steps instead of one. Research presented at AMTA 2016 on machine translation quality and post-editor productivity found that as engine output quality improved, post-editing time per word fell measurably, while poorer output raised effort and lowered final quality.

How much faster is it?
Faster on most repeatable content, though the gain varies by language pair, domain, and how clean the source is. Treat any single percentage figure as a vendor average, not a forecast; measure your own throughput on a pilot batch before committing a release schedule to it.

What quality can you expect for software and manufacturing content?
With controlled terminology, a trained engine, and defined QA checkpoints, full post-editing targets output comparable to human translation — the outcome ISO 18587:2017 describes for full post-editing and post-editor competence. Safety notices, regulated labelling, and marketing-facing copy still warrant human translation.

If you want a second opinion on where your content falls, Mesa Translation’s team can review a sample.

What the localisation process looks like from source file to final review

Translation is one step inside a longer chain. A working localisation process starts with source extraction — pulling strings, topics, or manual chapters out of a CMS, repository, or DITA source — and continues through segmentation, translation, bilingual review, in-context QA, file reassembly, and long-term maintenance of the language assets you generated along the way. Microsoft’s globalisation documentation describes the file-level plumbing behind this: XLIFF standardises the localisable data passed between tools, while TMX is the common exchange format for translation memory data.

Documentation and localisation leads rarely judge that chain on speed alone. What matters is repeatability across releases, governance over who approves terminology and who signs off on a language, throughput when a product ships in twelve locales at once, and terminology control so that "fastener," "actuator," or "tenant" resolve the same way every time.

Translation memory sits inside that chain as a control point, not a bolt-on feature. The same Microsoft documentation defines a translation memory as a database of source segments paired with their translations, where a segment may be a word, sentence, or paragraph. That positioning raises the operational questions worth answering before you buy anything: where reuse genuinely pays off, where it quietly degrades quality, and how memory, glossaries, and machine translation should be sequenced.

How translation memory works in a localisation workflow

A translation memory (TM) is a database that stores source segments paired with their translated segments in one or more target languages. Microsoft’s localization documentation describes it in exactly those terms, and notes that a segment can be a word, a sentence, or a whole paragraph depending on how the content was split during preparation. That segmentation step is the first place the localisation process either helps or hurts you: badly segmented source files produce fragments that never match cleanly again.

In production, the TM sits inside a computer-assisted translation (CAT) tool alongside terminology databases, spelling and grammar checkers, and machine translation engines. When a translator opens a file, the tool queries the memory segment by segment. An exact match means the incoming string is identical to something already approved. A fuzzy match means it is close but not identical — a changed part number, a reworded step — and the translator edits the stored version rather than starting over. Wikipedia’s overview of translation memory covers the same match logic and the scoring thresholds tools use to rank suggestions.

Two standards govern how this data moves. TMX is the common exchange format for the memory itself, and XLIFF standardises the localizable content passed between tools during a project. Microsoft Learn cites TMX 1.4b, published in 2005, as the current specification — old enough that support varies in practice. Before migrating a memory between systems or handing it to a new provider, export a sample, re-import it, and confirm that metadata, language pairs, and context fields survive the trip.

Where translation memory reduces rework across manuals, UI strings, and updates

Translation memory pays off wherever the same sentences come back. Microsoft’s globalization documentation describes a translation memory as a database that stores source segments paired with their translated equivalents, where a segment can be a word, a sentence, or a paragraph. That granularity is the whole point: an installation warning written once in an operator manual can be reused in the quick-start guide, the help centre article, and the tooltip that references it.

Two match types do the work. Exact matches return previously approved wording verbatim; fuzzy matches surface near-identical segments so a linguist edits rather than retranslates. For versioned documentation, the practical win is carryover — when a revised file goes back through the tool, unchanged segments come through already translated, and reviewers only see what actually moved. A firmware release that touches 40 of 900 UI strings becomes a 40-string review, not a full pass.

Consistency across languages is the second benefit, and it matters most where wording is compliance-sensitive. Hazard statements, regulatory phrasing, part names, and safety verbs need to stay stable across every update and every target language. A translation memory enforces that at the segment level, while a glossary governs terminology below it.

Be honest about the conditions. This part of the localisation process helps most with recurring content, structured file formats such as XLIFF, and frequent revisions against a stable source. Rewritten marketing copy, scanned PDFs, and one-off content produce few usable matches — and a memory built from unreviewed output propagates errors just as efficiently as it propagates good translations.

When translation memory is not enough on its own

Reuse only pays off when there is something to reuse. A memory earns its keep on revised manuals, release-note updates, and interface strings that shift a few words at a time. It does very little for a brand-new white paper, a heavily rewritten safety chapter, or marketing copy that is meant to be re-created rather than matched. Poor segmentation has the same effect: if source files are broken into fragments that split sentences across tags or table cells, the stored pairs stop lining up and match rates fall even on content that has been translated before.

A memory also does not govern terminology, approve anything, or clean up files. Microsoft Learn describes translation memory as one component alongside terminology tools, checkers, and machine translation inside a computer-assisted translation environment — it is a database of source and target segments, not a quality system. Termbases still need an owner, review still needs a qualified linguist, and file preparation still decides what the memory ever sees.

Machine translation fills the gap where no match exists. Paired with a glossary that constrains key terms and a human review pass sized to the risk of the document, it handles the untranslated remainder that reuse cannot cover.

The quality of any memory tracks the discipline behind it: clean source content, corrections pushed back after review, and periodic cleanup of duplicate or outdated segments. Reuse is a real lever in the localisation process. It is not a substitute for the controls around it.

How glossary control, machine translation, and review fit around TM

Translation memory stores and reuses approved segments, but it does not decide which term is correct. That job belongs to the glossary — the termbase that fixes preferred renderings for product names, UI strings, part numbers, safety terms, and regulated phrasing, then applies them across every project and target language. Microsoft’s globalisation documentation describes computer-assisted translation environments as bundles of translation memory, terminology tools, checkers, and machine translation, and that bundling is the point: terminology control sits alongside the memory, not inside it. Without it, a memory will happily propagate an old term at 100% match confidence.

Machine translation belongs earlier in the chain, where draft speed matters. A common sequence is memory first, machine translation for what the memory does not cover, then glossary enforcement and quality checks on the merged output. Segments below a useful fuzzy threshold go to raw drafting; exact matches from approved content do not need re-drafting at all.

Review is the gate that catches what automation cannot see: a segment that is grammatically fine but wrong in context, terminology drift introduced by unreviewed machine output, broken placeholders or tags, and length overruns in a compressed interface. For software and manufacturing content — release notes, operator manuals, declarations of conformity — that gate is also where compliance evidence gets created, through recorded reviewer sign-off.

Seen this way, a memory is one control point in a wider localisation process.

What to maintain so translation memory stays useful over time

A memory is only as good as the segments inside it. Left unmanaged, it accumulates duplicates, competing versions of the same sentence, and translations tied to product names or interface labels that no longer exist. Plan for periodic cleanup: deduplicate entries, resolve conflicting matches so linguists aren’t choosing between two "approved" options, update terminology when a product or regulatory term changes, and retire segments from discontinued features rather than letting them surface as fuzzy matches.

Segmentation and file handling quietly decide how much of that memory you can reuse. If one project segments by sentence and another by paragraph, matches stop landing even when the source text is identical. Inconsistent extraction from the same file type — a help centre export one quarter, a flattened document the next — produces near-duplicates that dilute leverage across the whole localisation process.

Compatibility deserves the same attention. TMX is the standard exchange format for memory data, and XLIFF carries localizable content between tools; Microsoft’s globalisation documentation notes that the current TMX specification, 1.4b, dates from 2005. Older formats travel, but metadata such as context, creation date, and approval status often does not, so test a migration on a sample file before committing a full memory.

Before relying on a memory in production, ask concrete questions: Who owns the memory and can you export it in full? How are matches reviewed and approved? Which segmentation rules apply? How are terminology updates pushed back into existing content? What happens to the memory if you change providers?

Treated as a managed asset with clear ownership and a maintenance schedule, translation memory keeps paying back. If you’d like help auditing an existing memory and terminology set, Mesa Translation’s team can review it as part of project scoping.

Why certifications matter when you buy technical translation for software and manufacturing

The real question a buyer faces is not whether a provider can write a readable sentence in German or Japanese. It is whether that provider can move multilingual technical content through a controlled process — traceable revisions, stable terminology, documented reviewer qualifications, and confidentiality that holds up when someone asks for records months later. Certification is the shorthand most buyers reach for, and it is a reasonable starting signal, provided you know what it proves.

What it proves is process, not domain knowledge. A certificate says a provider has documented procedures and review controls that an auditor has checked; it does not say the translator understands your PLC error codes or your API reference. Both matter, and they fail in different places. Software releases break on terminology drift and version control between builds. Manufacturing documentation breaks on inconsistency across manual revisions and gaps in the audit trail.

The standards worth understanding are ISO 17100 for translation services, which the ISO 17100 agency-selection guidance describes as requiring qualified translators, independent revision by a second person, and documented project management; ISO 18587 for post-editing machine translation output; ISO 9001 quality management; and ASTM F2575-25, a standard practice for language translation.

What follows is how to verify those claims — the evidence to request, and where quality and compliance signals stop being useful.

The core certifications and standards to look for

Start with ISO 17100. It is the main translation-services standard, and it is the one worth naming explicitly in a request for proposal. Certification does not grade individual sentences; it attests that a provider runs a documented process. Guidance published at iso17100.com describes what a certified agency should be able to show: translators with verified qualifications, independent revision by a second linguist, documented project management, appropriate technical resources, and a defined procedure for handling client comments and corrections.

The workflow behind that certificate is where the value sits for technical content. It runs from analysis of the source files and quotation through agreement, assignment to named resources, translation, the translator’s own check, revision by a different person, final verification against the brief, delivery, and post-delivery handling of feedback. Ask a prospective provider to walk you through each stage against a real project of yours. If revision and final verification collapse into the same person, the certificate is describing a process the team no longer runs.

Is ISO 17100 sufficient on its own? Not once machine translation enters the pipeline — and for software strings and manufacturing documentation, it usually does. ISO 18587 is the companion standard covering post-editing of machine translation output, and TÜV SÜD lists both together in its certification services. If a provider proposes machine translation for your release notes or parts catalogues, ask which post-editing level they apply, who performs it, and how the edited output is reviewed before sign-off.

ASTM F2575-25, the standard practice for language translation available from ASTM International, is a useful second reference for buyers who want a broader benchmark for specifying a translation project, particularly around agreeing requirements up front.

One distinction worth holding firmly: ISO 9001 is a quality-management system standard. Many providers hold it, and it signals disciplined internal governance, but it says nothing specific about bilingual revision or translator competence. Treat it as supporting evidence of quality and compliance maturity, not as a substitute for translation-specific certification.

How to verify a provider’s claims before you sign

A certification logo on a website is a claim, not proof. Ask for the certificate as a document, and check four things on it: the issuing body (an accredited certification body, not a self-declared membership), the exact scope of the certification, the sites or entities it covers, and the validity period. Scope matters more than most buyers realise — a certificate can cover a head office but not the subsidiary that will handle your product manuals. Ask when the last surveillance audit took place and when recertification is due; certification bodies such as TÜV SÜD run ISO 17100 and ISO 18587 assessments on a recurring audit cycle, so a provider should be able to name dates without hesitation.

Audit trail checklist. Ask to see, on a real (anonymised) project:

• Version history for source and target files, including which source version each translation was built from
• Revision records showing who revised what, and what changed
• Documented approval steps before delivery
• Evidence of post-delivery handling — how a reported error was logged, corrected, and fed back into the terminology base

That last item is the one buyers skip. The ISO 17100 guidance for choosing a certified agency describes a defined sequence from analysis and quotation through translation, the translator’s own check, revision by a second person, final verification, delivery, and post-delivery handling — ask the provider to walk you through their version of it with artefacts, not slides.

Translator qualification evidence. Request anonymised profiles for the linguists who would actually work on your account: years in the specific language pair, subject-matter background in software or manufacturing, and how competence is documented and reassessed. Ask who performs independent revision and how terminology disputes are escalated and resolved.

Document control and confidentiality. For unreleased software builds and manufacturing instructions, confirm where files are stored, who has access, how long they are retained, and what the non-disclosure terms cover. ASTM F2575-25 is a useful reference point when specifying these requirements in writing.

Finally, ask directly how machine translation is used, on which content types, and where human post-editing enters the workflow — a provider serious about quality and compliance will answer with a process, not a disclaimer.

When certification matters most, and when process maturity and domain expertise matter more

Certification earns its weight when you need formal controls you can hand to someone else. If procurement requires evidence of supplier vetting, if an auditor will ask how a translation was reviewed, or if your release process depends on repeatable steps rather than individual goodwill, a certified provider gives you a documented answer. ISO 17100 is built around exactly that structure: qualified translators, independent revision by a second person, documented project management, and a defined route for handling comments and corrections. Where post-edited machine translation is part of the workflow, ISO 18587 covers that output specifically. For regulated documentation — safety instructions, labelling, anything tied to a conformity file — that paper trail is not optional.

Domain expertise outweighs a certificate alone when the risk sits in the terminology rather than the paperwork. A certified vendor with no experience in PLC programming, CNC tooling, or your product’s UI string conventions can still produce a compliant-looking translation that a field engineer will not recognise. Ask for translator qualification evidence in your subject area, sample revisions, and the glossary they would inherit or build.

Process maturity is often the more honest signal. A provider who can show stable workflows, revision records, and named ownership of terminology is demonstrating the same discipline a certificate attests to — just directly.

The tradeoffs cut both ways. A certified provider may still need to prove subject-matter depth; a specialist engineering translator may have deep product knowledge and a thinner certification footprint. In practice, buyers get the best result by combining both: certification for structure and auditability, domain expertise for technical accuracy, which is how quality and compliance hold together over repeated releases rather than one project.

How quality management systems support consistency in technical translation

Certification to a translation-specific standard tells you a provider has defined roles and revision steps. A general quality management system tells you whether those steps hold up across hundreds of jobs and several years. ISO 9001 is the common example: it covers process documentation, internal monitoring, corrective action, and management review for an organization as a whole. It says nothing about translator qualifications or bilingual revision, so it is not a substitute for ISO 17100 — but it does signal that the provider treats its own workflow as something to measure and fix.

Longevity is the useful signal here. The German technical documentation firm DOCTEC, for instance, states it has held ISO 9001 certification since 2004 and undergoes annual monitoring plus recertification audits — a claim a buyer can ask any provider to match with certificate dates and audit reports.

That cadence matters because software and manufacturing content is never finished. A machine manual gets a new safety notice; a user interface adds forty strings. Repeatable handling of updates depends on documented procedures for terminology approval, translation memory maintenance, version control against the source, and re-review of changed segments only. When a mistranslated warning surfaces, a corrective action record shows whether the provider traced the cause or simply patched the file.

Ask for three things: the procedure documents that govern these steps, the date of the last external audit, and a completed corrective action from the past year. Documented quality and compliance practices are only worth what the evidence behind them shows.

FAQ: common questions about certified translation providers

Does a technical translation agency have to hold ISO 17100?
It is the clearest single signal, but not the only one. ISO 17100 requires qualified translators, independent revision by a second person, documented project management, appropriate technical resources, and a procedure for handling comments and corrections. An uncertified provider can run the same controls — the difference is that nobody outside the company has audited them. If a provider isn’t certified, ask for the equivalent evidence: translator qualification records, revision records showing who checked what, and a written process covering analysis, quotation, assignment, translation, the translator’s own check, revision by another person, final verification, delivery, and post-delivery handling.

What’s the difference between a certified provider and a certified translation?
A certified provider is a company whose processes have been audited against a standard such as ISO 17100. A certified translation is document-level: a signed statement that the translation is complete and accurate, sometimes with a sworn translator’s seal or notarisation. Requirements are jurisdiction-specific, and a certified provider does not automatically produce a translation a given court, patent office, or notified body will accept. Confirm the receiving authority’s format before ordering.

How does machine translation fit into a controlled workflow?
It fits when post-editing is defined, staffed, and recorded. ISO 18587 covers post-editing of machine translation output, and TÜV SÜD lists it alongside ISO 17100 among its certification services. Practical questions for a provider: which engine is used, whether your content is retained or used for training, whether the post-editing level is light or full, and who performs the final verification. Machine translation is a tool inside the process — the audit trail still has to exist.

Is ISO 9001 on its own enough?
ISO 9001 shows general quality management discipline, including corrective action and recurring audits — DOCTEC, for example, states it has held ISO 9001 since 2004 with annual monitoring and recertification audits. What it does not address is translator competence or mandatory two-person revision. Pair it with translation-specific controls: ISO 17100, ISO 18587 where post-editing applies, and practice standards such as ASTM F2575-25.

Read three things together before you decide: the exact scope on the certificate (which services, sites, and language pairs), how revision and final verification actually run, and whether the provider has handled your content type — software strings, machine safety instructions, service manuals. Certification narrows the field; domain evidence picks the winner. If you want a second read on a shortlist, Mesa Translation’s team can walk through scope, revision records, and the quality and compliance questions specific to your documentation set.

What machine translation, MTPE, and human translation mean for engineering documentation

Three approaches sit behind most quotes for technical content, and the labels are often used loosely.

Machine translation is translation generated by software — engines like DeepL, Google Translate, or a custom model trained on your own data. It produces a draft fast, but for engineering content that draft is a starting point, not a deliverable.

Machine translation post-editing (MTPE) is what happens next: a human editor works through the raw output and corrects it. ISO 18587:2017, a 15-page standard published in April 2017, frames post-editing exactly this way — a human process applied to content that has already been processed by a machine translation system, with requirements aimed at providers, clients, and post-editors alike.

Human translation means a qualified translator writes the target text directly, without an engine draft underneath it.

The documents at stake here are engineering manuals, installation guides, service bulletins, and anything governed by controlled terminology — parts names, safety warnings, units, and interface strings that must match across versions.

Choosing between the approaches comes down to five practical factors: accuracy, terminology control, turnaround speed, cost, and how much review effort lands on your team afterwards.

One 2026 caveat: ISO/DIS 18587, a 23-page draft replacement, is in the enquiry phase. Confirm current workflow expectations with your provider rather than assuming the 2017 text is settled.

When machine translation is not enough for manuals and engineering content

Raw machine translation fails in engineering documentation at exactly the points where errors are most expensive. A warning that shifts from "do not energise before lockout" to a permissive phrasing, a torque figure carried over with a decimal separator swapped, a numbered installation sequence reordered because the source sentence used a subordinate clause, or a component that appears as three different names across the assembly manual, the label artwork, and the service bulletin — each of these is a defect a reader will act on before anyone notices.

Controlled terminology is the first thing to break. Engines translate sentence by sentence, so the same part can be rendered differently in section 4 than in section 9, and neither version may match the wording etched on the machine. Formatting suffers too: symbols, units of measure, cross-references, and callout numbers keyed to exploded diagrams often survive the translation step but stop pointing at the right thing.

This is where quality becomes a compliance question rather than a stylistic one. ManufacturingTomorrow’s argument that technical translation must be accurate for manufacturers also notes that translation on its own may not be enough — market-specific units, regulatory phrasing, and audience-appropriate instructions need localisation, not just language transfer. Documentation that supports a declaration of conformity or a liability defence has to read as if it were written for that market.

A reasonable line: raw output can serve low-risk internal reference material — engineering notes, ticket threads, draft specifications read by colleagues who can spot nonsense. Anything that guides assembly, maintenance, or operator safety needs human-led work from the first pass.

MTPE vs human translation: accuracy, terminology, speed, cost, and review effort

Neither approach wins across the board. The right answer depends on what your source content looks like and what happens if a sentence is wrong.

Accuracy. Post-editing works best when the source is clean, consistent, and repetitive — parts lists, maintenance steps, UI strings, revised sections of an existing manual. When meaning is dense, ambiguous, or safety-critical (warnings, residual-risk statements, procedures where sequence matters), full human translation holds up better, because the translator resolves ambiguity in the source rather than reproducing it. ManufacturingTomorrow makes the same point from the manufacturer’s side: accurate technical translation is a requirement, not a nice-to-have, and translation without localisation can still leave a document unusable.

Terminology control. Human translation generally gives tighter control over preferred terms, especially where a part name, a hazard word, or a regulated phrase must match your approved glossary exactly. Machine translation output can be brought to a similar standard, but only if the glossary, termbase, and style guide are enforced in the engine and re-checked during post-editing — not assumed.

Speed. For high volumes of repetitive content, post-editing is usually faster and scales better under release deadlines. Human translation takes longer per thousand words, but often reduces the correction cycles that follow, so the calendar difference narrows once review is counted.

Cost. Post-editing lowers the first-pass price. Total cost is the first pass plus subject-matter expert review, quality assurance, terminology fixes, and rework. On complex or poorly structured source text, that tail can erase the saving — which is why the per-word rate alone is a weak basis for a decision.

Review effort. Both need technical validation by someone who knows the product. The difference is linguistic: post-edited content requires a defined post-editing step under a documented process, which ISO 18587:2017 specifies for content processed by machine translation systems. Human translation typically needs less linguistic cleanup, but the engineering review does not go away.

The process is built around quality, compliance, and controlled terminology, so it is a stronger fit for regulated documentation than for buyers whose main constraint is the lowest possible first-pass cost.

How to choose MTPE, human translation, or a hybrid workflow for engineering documentation

The decision rarely comes down to language pairs. It comes down to what happens if a sentence is wrong.

Choose MTPE when the content is repetitive, the terminology is already controlled in a termbase or glossary, and the schedule allows a structured post-editing and quality assurance pass. Parts catalogues, UI strings pulled into help topics, revision histories, and reference tables usually fit. ISO 18587:2017 is the anchor here: it defines post-editing of machine translation output as a human process and sets requirements for providers, clients, and post-editors, which is why a post-editing brief should be written down rather than assumed. A draft replacement, ISO/DIS 18587, is in the enquiry phase, so buyers signing multi-year contracts in 2026 should ask which version their provider works to.

Choose full human translation when the passage is safety-critical, legally sensitive, genuinely ambiguous in the source, or written to be acted on — warnings, lockout and tagout steps, commissioning procedures, torque and tolerance instructions, declarations of conformity. ManufacturingTomorrow has argued that accuracy in manufacturing documentation is non-negotiable and that translation without localisation can still fall short; that risk profile does not suit raw engine output plus a light edit.

Choose a hybrid workflow when a single document set mixes both, which most manuals do. Route low-risk reference sections through MTPE and send hazard statements, procedures, and regulated passages to human translation, with the split defined at the section or content-type level in your authoring system so it survives the next release.

Subject-matter expert review sits on top of all three paths. A linguistic review catches grammar and terminology drift; it does not confirm that a described sequence matches the machine. For engineering content, plan an engineer or field service reviewer on the safety-critical passages regardless of which method produced the draft.

A short selection checklist keeps the choice defensible:

Factor	Question to answer before routing
Content risk	Could an error cause injury, damage, or non-compliance?
Audience impact	Is the reader acting on this, or just consulting it?
Terminology maturity	Is the termbase current and approved?
Turnaround time	Does the release date allow a real review cycle?
Review resources	Is an SME actually available, with hours booked?

Tie the result to your release plan. Corrections after publication cost more than the review you skipped — reprints, service bulletins, and re-approval cycles included.

What regulated and safety-critical manuals need from translation workflows

Safety and compliance content raises the bar on three things at once: terminology control, traceability, and depth of review. A marketing page can tolerate a synonym drift; a lockout procedure, a torque specification, or a residual-risk warning cannot. For these documents you need a locked glossary, a record of who changed what and why, and a named person accountable for the final technical read.

Post-editing of machine translation output can meet that bar, but only when four conditions hold together: a clean, unambiguous source text; enforced terminology and a maintained glossary; post-editors qualified in the subject matter, not just the language pair; and a technical validation step by someone who understands the equipment. Remove any one of those and the workflow stops being controlled.

Mixed treatment is normal and defensible. Installation steps, parts lists, and maintenance tables often run well through post-edited machine translation while warnings, safety instructions, and declaration text are translated and reviewed fully by humans within the same document set.

When evaluating a provider, ask for the written workflow, reviewer qualifications and credentials, how glossaries and translation memories are maintained between releases, and the specific quality assurance checks applied before delivery. ISO 18587 defines post-editing as a formal process for machine translation output — useful as a baseline, but it describes the process, not whether your content suits it. That judgement stays with you.

Is post-editing acceptable for regulated or safety-critical manuals? Yes, for lower-risk sections under a documented process with qualified reviewers and terminology control. For passages where a mistranslation causes injury or non-compliance, keep full human translation.

FAQ: MTPE, human translation, and engineering documentation in 2026

Is post-editing acceptable for regulated or safety-critical manuals?
Partly. For descriptive content — component lists, routine maintenance steps, UI strings already covered by an approved glossary — post-edited output can meet the same quality bar as a fully human pass. For warnings, residual-risk statements, lockout procedures, and anything a notified body or auditor will read line by line, treat human translation as the default and post-editing as the exception. ISO 18587:2017, published in April 2017 and currently being replaced by a draft update in its enquiry phase, sets requirements for the post-editing process itself; it applies only to content processed by machine translation systems and does not certify that any given passage is safe to automate. That judgement stays with you.

Should raw output ever ship without review?
Not for engineering documentation. Even where the source is clean and the terminology base is mature, unreviewed output carries no accountability trail, and a mistranslated torque value or negation is indistinguishable from a correct one to a reader who does not speak the source language.

How much review is normally needed afterwards?
It varies with three things: the risk class of the passage, how mature your termbase and translation memory are, and the document type. A service bulletin built from reused, previously approved segments needs far less intervention than a first-release installation guide in a new language pair.

Is human translation always more expensive?
Per word, usually yes. Per release, not necessarily. Once you count reviewer hours, terminology corrections that propagate across every future version, and the cost of reissuing a manual, the gap narrows — and on short, high-risk documents it can invert.

How do you decide quickly under release pressure?
Split the deliverable, not the standard. Route low-risk, high-reuse sections through post-editing, reserve human translation for safety and compliance content, and hold the release on the smaller human-translated portion rather than diluting review across everything.

The underlying rule is simple: match the workflow to what the content can do if it is wrong, not to how many words there are. If you want a second opinion on where your own documentation set falls, Mesa Translation can review a sample and map it against risk before you commit to a workflow.

What technical accuracy means in medical device translation

Technical accuracy is not the same thing as correct wording. A sentence can be grammatically clean, idiomatic, and still wrong for the market it ships into. In practice, accuracy means the translated content preserves the device’s intended use, its functional description, every warning and contraindication, and the exact sequence of steps a user follows — so that a clinician in Munich and a technician in São Paulo act on the same instruction.

Software content and medical device content share one requirement: consistency. A string translated three ways across a user interface, a help centre, and a training deck creates support tickets. Device materials add a second layer. Labeling sits inside a regulatory framework — the FDA’s general device labeling requirements point to 21 CFR Part 801 and require the label to carry the name and place of business of the manufacturer, packer, or distributor, with intended use reflected in the labeling itself. That means translated text is subject to approval, traceability, and version control, not just editorial preference.

Quality and compliance come from a controlled workflow rather than one review pass before release. The stages that follow — source-text review, terminology control, subject-matter expert review, regulated-content checks, and final sign-off — each close a specific gap. This article shows where errors usually enter, and how providers reduce release risk at each handoff.

How source-text review, terminology control, and SME review work together

Technical accuracy in device content is decided before a single sentence is translated. The first control point is source-text review: a linguist and a project lead read the English manual, instructions for use (IFU), label copy, or software strings and flag what will break in translation — ambiguous instructions, warnings written as fragments, the same component called three different names, screenshots with no context, and strings whose meaning depends on a variable the translator cannot see. Those queries go back to the documentation owner and are resolved in the source. Fixing them once upstream prevents the same defect from being replicated across every target language.

The second control is terminology. Device names, component names, user actions, warning phrasing, and any wording tied to intended use get approved by the manufacturer and locked in a termbase before production translation begins. That approved list travels with the content, so the same concept is rendered the same way in a service manual, an IFU, a carton label, and the interface strings the user reads on the device itself. Translation memories keep sentence-level consistency across revisions and document types; a style guide covers register, units, date formats, and market-specific conventions that a termbase cannot capture. Together they are what stops drift between documents and between markets.

Subject-matter expert review is the third layer, and it is targeted rather than universal. Reserve it for content where a wrong reading has consequences: device functions and operating sequences, clinical claims, contraindications, warnings and cautions, and user-facing instructions. Because labeling must reflect intended use under the FDA’s general device labeling requirements in 21 CFR Part 801, a reviewer with clinical or engineering background — not only linguistic skill — should confirm the translation still carries that intent.

Keep the two review roles separate. The expert verifies meaning and technical intent; the language team owns consistency, terminology adherence, formatting, and local conventions. Mixing them produces edits nobody can trace, which is precisely what quality and compliance records need to show.

What regulated-content checks medical device translation needs

Technical accuracy in a medical device file is only half the job. The other half is proving it — showing an auditor which source version a translation came from, who reviewed it, and who approved the version that shipped.

Start with what the label must carry. Under FDA general device labeling requirements, the label has to identify the manufacturer, packer, or distributor by name and place of business, and the labeling must reflect the device’s intended use. Those rules sit inside 21 CFR Part 801, the general labeling framework for devices. In practice this means certain content is not open to stylistic improvement: regulated statements, intended-use wording, warnings, and identifying details must carry over exactly, with the translator’s judgement applied to clarity elsewhere, not to the regulated text itself. The FDA’s guidance on medical device patient labeling makes the same point for lay-language versions: rewriting must not alter the intent of indications, contraindications, warnings and precautions, or introduce claims absent from the professional label.

Traceability is what makes that checkable. A workable setup keeps each source file under version control, records tracked changes through translation and review, logs reviewer comments with the reviewer’s name and date, and stores an approval record per market release. If a source instruction changes in version 4.2, the German and Japanese files should show which version they derive from and when they were re-approved.

Sign-off then ties the chain together: source version, translated version, reviewer comments and their resolution, and the approved deliverable formats — print-ready artwork, structured content, or software resource files — recorded as one release package.

Scope the checks across everything that reaches the market, not just the manual: labels and artwork, instructions for use, on-device and software interface strings, warnings and safety symbols, and any market-specific variants. Treating quality and compliance as a single release gate, rather than two separate reviews, is what keeps a multilingual set consistent at launch.

Where technical translation fails most often, and how teams prevent it

Most accuracy problems in medical device content are traceable to five recurring failure points. Each one has a control that catches it before release.

Ambiguous source text. A vague instruction ("tighten securely"), a torque value with no unit, or three spellings of the same product name will multiply across every target language. The control is a source review before translation starts: flag missing units, undefined abbreviations, and inconsistent naming, then fix them in the source rather than patching them ten times downstream.

Terminology drift. Manuals, carton labels, and the software interface are often updated on separate cycles, so a term renamed in the user interface quietly contradicts the printed instructions for use. Prevention is a locked, approved glossary applied across all content types, with the term base versioned alongside the product release — not maintained per document.

Unchecked machine translation. Raw machine translation output can be fluent and still invert a warning or normalise a controlled term. Post-editing by a qualified linguist, an automated terminology check against the glossary, and subject matter expert validation for clinical or safety-critical passages are what make the output usable. Ad Verbum describes a comparable sequence — reusing existing translation assets, generating an AI draft, then layering expert oversight and verification against relevant standards.

Missing traceability. If you cannot show which language version was approved for which market and when, you have a documentation problem regardless of translation quality. Recording reviewer identity, date, source version, and sign-off per locale is what turns a file into evidence.

Weak final approval. Compliance checks belong before delivery: confirm that labelling content reflects the intended use and carries the manufacturer, packer, or distributor name and place of business, as the FDA’s general device labeling requirements set out under 21 CFR Part 801.

Together these five controls are the practical mechanics of quality and compliance in a multilingual content programme.

What buyers should ask a translation provider before approving medical device content

Claims about accuracy are easy to publish. Evidence is harder, so ask for it before a single file moves.

Request five artefacts during evaluation:

• A sample workflow for one comparable project — source-text review, linguist and subject-matter expert assignment, translation, bilingual review, QA, and delivery format. Ask who performs each step and what qualifies them.
• Terminology governance — the glossary and termbase for your device class, how new terms get approved, and who owns the decision when a clinical term and a marketing term conflict.
• Reviewer roles in writing — the difference between a linguistic reviewer, a subject-matter expert, and your own in-country reviewer should be defined, not assumed.
• Traceability records — version history, change logs, and the audit trail that shows which approved source version produced which translated file.
• Named final sign-off — a person or role that releases content per market, not a generic "QA complete" stamp.

Regulated content raises the bar on the first and last steps. Labeling obligations under 21 CFR Part 801, described on the FDA’s general device labeling requirements page, attach to the content itself — so a provider needs to show how a source change triggers retranslation and re-approval, not just how a file gets translated once.

ISO-aligned quality management is a reasonable baseline, and several providers cite ISO 9001 certification. Treat it as useful only when paired with documented QA steps and market-specific release controls you can inspect.

Strengths differ honestly. Some providers are faster or better at complex publishing formats such as InDesign and structured XML; others are stronger on regulated traceability, which usually costs more time. Mesa Translation is built for the second profile — technical translation and localisation with quality and compliance controls documented per project. Verify any workflow, including ours, against your device class and target markets.

FAQ: What do translation companies do to keep medical device content accurate?

How do translation companies ensure technical accuracy in medical device content?

Accuracy is produced by a chain of controls, not by one careful linguist. A credible provider starts with a source-text review — flagging ambiguous warnings, undefined abbreviations, and strings that will break in layout — before a word is translated. Terminology is fixed in an approved glossary and locked into the translation environment, so a device component or warning phrase renders the same way in every manual, label, and interface string. Translation is assigned to linguists with relevant subject-matter background, then reviewed by a second specialist, then checked in a structured quality assurance pass covering numbers, units, symbols, and formatting. Nothing ships until a named reviewer records approval. When a process is real, each of those steps leaves an artefact you can inspect: a query log, a glossary version, a QA report, a signed approval record.

How are quality and compliance maintained across regulated markets?

By treating regulated content as content you may not quietly improve. United States labeling rules under 21 CFR Part 801 require, among other things, that the label carry the name and place of business of the manufacturer, packer, or distributor, and that labeling reflect the device’s intended use — so translators preserve those elements rather than paraphrase them. Add traceability (which source version produced which target file), version control across document and software releases, and market-specific sign-off by a reviewer who knows the destination market’s requirements. That combination of quality and compliance controls is what an auditor, or a notified body, actually asks to see.

Is this different from software localisation?

The consistency demands overlap, and the same terminology and translation memory discipline applies to both. Medical device work adds stricter handling of warnings, contraindications, intended-use statements, and release records, where an unapproved rewording is a regulatory event rather than a style preference.

Can machine translation be used?

Yes, when it is controlled: trained on approved terminology, confined to defined content types, and always followed by qualified human review and recorded approval. Unreviewed machine translation output has no place in labeling or instructions for use.

When you compare providers, ask for the artefacts — glossaries, QA reports, approval logs — rather than assurances. If you want a walkthrough of how Mesa Translation documents each step, request a sample QA and approval record.