Guide
Machine Translation for Technical Content
By Benjamin Thomas · Technically reviewed · Last updated: July 2026
Neural engines have become good enough that the interesting question is no longer whether machine translation works, but on which technical documents it works and who checks the output. This guide answers both, including the cases where we tell clients to keep the machine out of it.
![Post-editor comparing raw machine output with a source maintenance procedure](https://techniwords.us/wp-content/uploads/2026/08/machine-translation-solution.webp")
Modern engines produce text that reads well even when a negation or a clause has quietly disappeared. Fluency is not accuracy.
Safety warnings, regulatory submissions, and anything a court could read are translated and revised by two linguists, with no engine in the loop.
Post-edited work is quoted as post-edited work. We never bill machine output at human translation rates, and we tell you which process was used.
What a neural engine is actually doing to your sentence
A neural machine translation engine predicts the most probable target sentence given the source sentence and whatever context window it was given. It has no model of your product, no access to the drawing on the facing page, and no way to ask a question. That prediction step is why the output sounds confident whether or not it is right. The engine cannot flag uncertainty the way a translator flags an ambiguous source line for the author.
Two properties follow from that, and they shape everything else in this guide. First, quality tracks how much similar text the engine saw during training, which is why English into German or Spanish behaves very differently from English into Korean or Norwegian. Second, errors are not random noise. They cluster in predictable places: numbers, negations, terminology, anything short and context free, and anything the engine has to guess about because the source was ambiguous.
Machine translation on technical documents is therefore not one decision. It is a decision per document type, per language pair, and per consequence of being wrong. A company that answers it once, at the policy level, ends up either paying too much for content nobody reads or exposing itself on the content that matters.
It also helps to separate the engine from the workflow around it. Generic public engines, engines trained on a client's own approved material, and engines constrained by a termbase behave differently on the same source file. The gap between a generic engine and a well fed one on a repetitive parts catalog is large enough to change the post-editing budget by a third. Most of the disappointment we hear about comes from a comparison made against the wrong engine.
Where machine translation works on technical documents
We recommend machine translation with post-editing, usually shortened to MTPE, more often than clients expect. When the content is high volume, repetitive, written in controlled English, and headed for an audience that needs to understand rather than certify, the economics are hard to argue with. A 400 page service manual for internal field technicians in Spanish is a good candidate. A 12 page installation notice that ships in the box with a machine sold in Germany is not.
| Content | MTPE fit | Why |
|---|---|---|
| Internal maintenance documentation, field notes | Strong | High volume, tolerant audience, errors are correctable in the next revision |
| Spare parts catalogs, BOM descriptions | Strong | Short repeated strings, heavy terminology control, low syntactic complexity |
| Support articles and internal knowledge bases | Strong | Volume grows weekly, shelf life is short, readers can ask a human |
| Training material, e-learning scripts | Moderate | Works with full post-editing, needs a human pass on tone and examples |
| Operator manuals sold with the product | Weak | Liability follows the document, safety sections carry legal weight |
| Safety data sheets, regulatory submissions | Not recommended | Phrase level legal wording, mandated formats, zero tolerance for drift |
| Software UI with variables and length limits | Not recommended | Placeholders break, no context per string, truncation in the build |
Language pair matters as much as content type. English into German, French, Spanish, Italian, and Portuguese produces raw output that a specialist can repair efficiently. English into Japanese or Korean produces output where the post-editor often spends longer untangling the machine sentence than writing a fresh one, because the word order and the honorific register have to be rebuilt from scratch. For low resource pairs, MTPE frequently costs more than human translation once you count the editing hours. We say so at quoting stage rather than after.
Where it fails, and why the failure is hard to spot
The dangerous scenario is not the obviously broken sentence. It is the sentence that reads perfectly and says the opposite of the source. A reviewer skimming a fluent target text will pass over it, because nothing on the page signals a problem. That is the specific reason we do not hand raw output to clients for internal review and call it a draft.
Five error families account for most of what we correct in technical MT output.
- Dropped or flipped negation. "Do not restart the pump until the pressure has fallen below 30 psi" comes back as an instruction to restart the pump. This appears most often when the source sentence is long and the negation sits far from the verb.
- Numbers, units, and separators. Engines sometimes convert values when nobody asked, or move a decimal separator. A German target that renders 1,500 as 1.500 is correct locally and disastrous if the surrounding text was left in the US convention. Torque values, wire gauges, and tolerance ranges are the usual casualties.
- Silent omission. A subordinate clause vanishes and the remaining sentence is grammatical. In our experience this is the single hardest error to catch without a segment by segment comparison, which is precisely what a post-editor does and a quick read does not.
- Terminology drift. The same source term, "housing", becomes three different words across chapters because each sentence was translated independently. Engines have no memory of chapter 2 when they reach chapter 9. A validated termbase pushed into the workflow fixes part of this, never all of it.
- Broken placeholders and tags. Variables such as %s or {count}, inline formatting tags, and cross reference fields get translated, reordered, or deleted. The string then fails at build time or, worse, displays a wrong value at runtime.
There is a sixth category that rarely gets discussed: modal verbs in regulated text. English "shall", "should", "may", and "must" carry different obligations in standards and contracts, and engines flatten them toward whatever sounds natural. In a quality manual or a validation protocol, that flattening changes what an auditor reads as a requirement.
A quick test before you trust a sample. Take a raw machine output your provider sent and check three things only: every number matches the source, every negation is present, and every warning statement is complete. If the sample fails on any of those, the rest of the fluency is beside the point.
The published research backs this caution: a JAMA Internal Medicine study found Google Translate reached 92% accuracy on Spanish medical discharge instructions but only 81% on Chinese — with some errors carrying potential for clinically significant harm. Adoption is racing ahead anyway: corporate language departments doubled their generative AI use in a single year, from 30% to 64%. The full picture is on our machine translation statistics section.
Light post-editing versus full post-editing under ISO 18587
ISO 18587 is the standard that describes the post-editing of machine translation output and defines the competences a post-editor is expected to have. It distinguishes two service levels, and the gap between them is wider than most price lists suggest. Buying the wrong one is a common source of disappointment, because the client pictured full post-editing and paid for light.
| Dimension | Light post-editing | Full post-editing |
|---|---|---|
| Goal | Understandable, accurate content | Output comparable to human translation |
| Style and flow | Left alone if meaning is intact | Rewritten where the machine phrasing is unnatural |
| Terminology | Corrected where clearly wrong | Aligned with the client termbase throughout |
| Typical effort vs human translation | Roughly 40 to 60 percent | Roughly 65 to 85 percent |
| Sensible use | Internal reference, short shelf life | Published documentation, customer facing |
Two things are worth noting about those effort figures. They are ranges because the real driver is raw output quality, which varies by language pair and by how clean the source was. And full post-editing on a bad raw output can exceed the cost of translating from scratch, which is why we measure a sample before committing to a rate rather than applying a standard discount. Our approach to pricing is set out on the rates and pricing page, including how post-edited work is quoted separately from human translation.
One practical consequence for buyers: ask which level you are being quoted, in writing, and ask what happens if the raw output is worse than the sample suggested. A provider who has thought about post-editing has an answer ready, usually a re-measure and a revised rate. A provider who has not will discover the problem at delivery, and you will be the one reading the result.
The confidentiality problem nobody puts in the proposal
Free web based translation engines are not confidential channels. Depending on the terms of service in force, submitted text may be retained, reviewed, or used to improve the service. For a marketing blurb, few people care. For an unpublished patent application, a validated cleaning procedure, or a supplier agreement, pasting the text into a public engine is a disclosure event, and it is one that a client's legal team will treat seriously once it surfaces.
We have seen the consequence more than once: a document arrives for review that has already been through a public engine, and the client now has to decide whether an unfiled invention was published. That is a conversation nobody wants. For any project where machine translation is used at Techniwords, it runs through a contracted engine with no retention of client content and no reuse for training, and every linguist works under a signed confidentiality agreement. If your internal policy forbids machine translation entirely, we run the project human only and note it on the quote.
Is your document a candidate for MTPE?
Run through this in order. A single no in the first four questions usually settles it.
- If a sentence is wrong, can someone get hurt? Warnings, lockout procedures, and hazard statements go to human translation with independent revision.
- Does a regulator, notified body, or customs authority read this document? Regulatory content is drafted against fixed phrasing that engines do not respect.
- Does the document carry contractual or warranty language? If a clause can be litigated, the machine has no place in it.
- Is the source in an editable format with clean, complete sentences? Scanned PDFs, drawings, and fragmentary table cells starve the engine of context.
- Is the language pair well resourced? Western European pairs behave; East Asian and low resource pairs often do not.
- Is there real volume? Below roughly 10,000 words, the setup, sampling, and quality measurement overhead eats the savings.
- Is the source written consistently, ideally with a style guide and a termbase in place?
- Does an existing translation memory already cover part of the content? Reusing approved segments beats machine output on the parts it covers, so the MT candidate is only what remains.
- What is the shelf life? Documentation replaced every quarter tolerates light post-editing. A manual that ships for eight years does not.
- Who signs off in country, and do they have the time to review? A named reviewer changes the risk profile substantially.
Documents that pass all ten are genuinely good MTPE candidates and we will say so, even though the invoice is smaller. Documents that fail on question one or two are quoted human only. Everything in between is a conversation about how much post-editing to buy, which is where the post-editing service page gets specific about deliverables.
How Techniwords uses machine translation
We have been translating technical documentation since 2011, and our default has not changed: translation by a specialist native speaker, then independent revision by a second qualified linguist. Machine translation is an option we propose when the document profile supports it, not a substitute we apply quietly to protect a margin. Three commitments make that concrete.
We disclose the process on every quote, so you always know whether you are buying human translation with revision or post-edited machine output. We never present post-edited content as human translation, including in certificates of accuracy. And when a client asks for MTPE on content we consider unsuitable, such as an SOP that will be used in a GMP environment, we explain the specific failure modes and let the client decide with the information in hand.
The checks that sit on top of post-edited work are the same ones described in our quality control workflow: automated verification of numbers, terminology, and tags, then a human pass. Automation catches the mechanical errors reliably. It does not catch a fluent sentence that means the wrong thing, which is why a person still reads the file before it leaves.
Machine translation questions we get
How much cheaper is MTPE than human translation?
For a well suited document in a well resourced language pair, expect somewhere between 20 and 40 percent below the human translation rate for full post-editing, and more for light post-editing. The savings shrink fast when the source is messy or the pair is difficult. We measure a sample before quoting a discount, because a promised percentage that ignores raw output quality is a promise that gets broken at delivery.
Can I run the machine translation myself and have you just fix it?
Yes, and it is a common request. Two conditions apply. We need the source files alongside the output so the editor can compare segment by segment, and we quote after reviewing a sample, since editing effort depends entirely on the raw quality. If the output came from a generic engine with no terminology control, editing it sometimes costs more than starting over, and we will tell you when that is the case.
Will anyone be able to tell the document was machine translated?
After full post-editing by a subject matter specialist, a reader generally cannot tell. After light post-editing, an attentive native speaker usually can, because sentence rhythm and idiom stay closer to the source. That is acceptable for internal documentation and visible on a customer facing manual, which is the main reason we match the post-editing level to where the document ends up.
Do you use machine translation without telling clients?
No. The process appears on the quote and on the delivery note. If a project is quoted as human translation with independent revision, that is what is performed, and no part of it passes through an engine. We consider undisclosed post-editing sold at human rates to be the central integrity problem in this industry.
Does machine translation work with our translation memory and glossary?
Partly. Segments matched by the translation memory are reused directly and never sent to the engine, which protects your approved wording. Termbase entries can be enforced in the engine or checked afterward, depending on the setup, and the check afterward is more reliable. Terminology remains the area where post-editors spend most of their correction time.