Guide
What Is Technical Translation? A Complete Guide
Technical translation converts specialized documents such as manuals, datasheets, and safety procedures into another language without losing accuracy, terminology, or compliance. This guide explains how it differs from other translation, who does it well, and where the risks hide.
What separates a technical text from a general one, and why that distinction decides who should translate it and how it should be checked.
Two documented cases where a translation error reached patients and operators, and what they teach about review and terminology control.
How professional technical translation is actually produced, and a candid look at where machine translation belongs in the picture.
What is technical translation? A working definition
Technical translation is the translation of documents produced by and for people who work with technology: engineers, machine operators, maintenance crews, lab technicians, regulators. The category covers user manuals, safety data sheets, engineering drawings, patents, standard operating procedures, datasheets, and dozens of other technical document types. What defines it is neither the file format nor the industry. It is the fact that the text carries information someone will act on, often with their hands, sometimes at real physical risk.
That single trait changes everything about how the work should be done. A slightly loose translation of a travel blog costs nothing. A slightly loose translation of a torque specification, a hazard statement, or a contraindication can cost a warranty claim, a regulatory finding, or an injury. Technical translation therefore optimizes for one value above all others: the reader in the target language must be able to do exactly what the reader of the original could do, with the same result.
A second trait follows from the first. Technical texts rely on controlled terminology. A "valve" in a P&ID is not interchangeable with a "fitting". German distinguishes Schraube from Bolzen where everyday English says "bolt" for both. The translator has to know which term the target-language industry actually uses, because the maintenance technician reading the output certainly does.
How technical translation differs from other translation work
Buyers often meet translation as one undifferentiated service, priced per word. In practice the profession splits into branches with different goals, different skills, and different definitions of success. The table below compares the four you are most likely to encounter.
| Branch | Primary goal | Tolerance for deviation | Who judges quality |
|---|---|---|---|
| Technical | Exact transfer of instructions, data, and terminology | Near zero on facts, numbers, and terms; style is secondary | Engineers, operators, auditors, regulators |
| General | Faithful, readable rendering of everyday content | Moderate; natural phrasing outranks literal fidelity | The average reader |
| Marketing / transcreation | Reproduce persuasive effect, even by rewriting | High by design; the copy may change completely | Brand and sales teams, ultimately the market |
| Literary | Recreate voice, rhythm, and artistic intent | A matter of interpretation | Critics and readers |
The practical consequence: a brilliant marketing translator can be a liability on a lockout procedure, and a fine technical translator will usually produce flat advertising copy. Agencies that claim equal excellence across all four branches with the same people deserve skepticism, a point we expand in our guide on choosing a technical translation company.
What counts as technical content
The range is wider than most first-time buyers expect. Typical projects include:
- Operating and maintenance documentation: user manuals, service manuals, spare parts catalogs, troubleshooting guides.
- Safety and compliance documents: safety data sheets under GHS, lockout/tagout procedures, machine safety labels, EHS training materials.
- Engineering deliverables: drawings and their annotations, specifications, test reports, commissioning dossiers, quality plans.
- Regulatory and legal-technical texts: patent specifications, instructions for use for medical devices, declarations of conformity.
- Software connected to hardware: HMI strings, PLC messages, embedded device interfaces, API documentation.
- Training and knowledge content: e-learning modules for operators, work instructions, onboarding materials for multilingual crews.
Industries follow the same logic. Manufacturing, energy, aerospace, medical devices, chemicals, automotive, and construction generate most of the volume, each with its own standards and vocabulary. Our industry pages break down what changes from one sector to the next.
The scale behind that volume is measurable: the language industry weighed $72.6 billion globally in 2025, and 70 million US residents speak a language other than English at home. We keep the verified numbers — market size, workforce, safety data — on our technical translation statistics page, every figure sourced and dated.
The skills a technical translator actually needs
The defining requirement is double competence. Language skill alone produces text that reads well and fails quietly. Domain knowledge alone produces text that is accurate and unreadable. A working technical translator needs both, plus a third skill that gets little attention: knowing when to stop and ask.
The strongest profiles tend to share a background pattern. They trained or worked as engineers, technicians, or scientists first, then moved into translation, keeping one foot in the domain. They translate into their native language only, because terminological instinct in the target language is what catches the subtle errors. And they specialize narrowly. A translator who handles semiconductor cleanroom SOPs on Monday should not be translating cardiology protocols on Tuesday. The translators we name on this site follow exactly this pattern, which is why we publish their engineering degrees and sector histories rather than a generic promise of "expert linguists".
Asking questions matters more than buyers assume. A source manual that says "tighten firmly" hides a decision: does the target text keep the vagueness or query the client for a torque value? Good technical translators surface these problems in a query sheet instead of guessing. The volume and quality of the questions you receive during a project is one of the most reliable signals of the vendor you hired.
What changes from one language pair to the next
Technical translation is not one uniform difficulty. The same 5,000-word manual behaves differently depending on where it is going, and the differences are concrete enough to plan for before the project starts.
Length is the first. German typically runs 25–35 percent longer than English once compounds and separable verbs land on the page, which breaks fixed-width table cells, drawing title blocks, and HMI buttons sized for the original. Russian and Finnish expand as well. Chinese and Japanese contract, sometimes close to half, leaving gaps in layouts built for English. A translator can tighten phrasing, though only so far before an instruction loses its precision, so the layout question belongs in file preparation rather than in a panic the day before delivery.
Terminology density is the second. Where a target-language industry has a long manufacturing history, the vocabulary is settled and the translator's job is to use the term the shop floor already uses: German machine building, Japanese electronics, and French aerospace all have decades of fixed usage behind them. In newer domains the target language may have no accepted term at all. The choice then lies between the English loanword technicians say out loud and a native coinage the regulator expects to see in the file. That call is made with the client, not by the translator alone.
Conventions come third, and they generate more delivery corrections than vocabulary does. Decimal commas replace decimal points across most of continental Europe. Thousands separators change shape. Date order flips. Korean and Japanese instructions carry a sentence-final register that signals whether the reader is being warned or merely informed. Spanish splits into variants where a single wrench can carry three names, so the target market has to be specified rather than assumed.
Script and direction close the list. Arabic and Hebrew read right to left, which reverses figure callouts, arrow directions, and the visual flow of numbered steps, and requires layout work no translation memory can automate.
Where standards enter the picture
Technical documents rarely stand alone. They cite and depend on standards, and the translation has to respect two layers of them.
The first layer sits inside the content. A drawing annotated to ASME Y14.5 uses geometric tolerancing conventions that differ from ISO practice; the translator has to know whether to convert or preserve them. Hazard communication follows GHS, which fixes the exact wording of hazard and precautionary statements in each language. Units may need conversion from imperial to metric, or deliberate retention. Citations of DIN, JIS, or KS standards must stay traceable, because the referenced document is what the reader will pull up.
The second layer governs the translation service itself. ISO 17100 defines competence requirements for translators and revisers and mandates independent revision of every translation. ISO 18587 covers post-editing of machine translation. These process standards do not guarantee talent, but they do guarantee structure, and structure is what catches human error. We cover both layers in depth elsewhere; here it is enough to say that a vendor who cannot explain which standards apply to your document has not read it carefully.
What a bad technical translation costs
Failure in this field is well documented, and two cases have become reference points precisely because they were so ordinary in origin.
The first happened in a German hospital in 2006 and 2007. Packaging for knee prostheses described the femoral component in English as "non-modular cemented". The in-house rendering into German dropped the sense, and staff read the implants as suitable for use without cement. Forty-seven patients received incorrectly implanted prostheses and many needed revision surgery. No exotic vocabulary was involved. One mishandled phrase on a label, unreviewed, reached the operating room.
The second pattern recurs across engineering failure reviews rather than in one famous incident: unit and number errors that survive translation. A maintenance value quoted in foot-pounds gets reinterpreted as newton-meters, a decimal comma becomes a decimal point, a pressure limit migrates between gauge and absolute. Investigations of industrial equipment damage repeatedly trace back to a translated manual or datasheet where a figure was transcribed into the wrong convention and nobody was assigned to check numbers as a distinct step. The lesson both cases teach is the same. The errors were catchable, and a mandatory independent revision plus a numeric QA pass is exactly the net designed to catch them.
The uncomfortable rule of thumb: a technical translation error almost never announces itself. The text reads fluently, the layout looks right, and the mistake sits silently in a number, a negation, or a term until someone acts on it. This is why quality in this field is a process property, verified step by step, and never a vibe.
These cases are not isolated. The documented record — from the $71 million Ramirez settlement to the labeling errors behind roughly one in five FDA drug recalls — is compiled with sources in our statistics on what translation errors cost.
How professional technical translation is produced
A mature workflow runs in stages, each with a defined check. Files are first analyzed and prepared: text extracted from drawings or layouts, repetitions counted, reference material collected. Key terminology is agreed before translation starts, ideally with the client's engineers arbitrating. A sector-matched native speaker then translates, logging questions as they arise. A second, independent linguist revises the full text against the source. Automated QA tools sweep for number mismatches, broken tags, inconsistent terms, and formatting faults that human eyes skip. Layout is checked last, and the delivery includes updated translation memory and termbase so the next project starts from accumulated knowledge rather than from zero.
None of these stages is decorative. Each exists because a known failure mode escapes the previous one. If you want the full walkthrough with timelines and client-side responsibilities, our process page covers all six steps.
When machine translation is enough, and when it is not
Neural machine translation has genuinely changed the economics of some technical work, and pretending otherwise would date this guide badly. For large, homogeneous, low-risk volumes such as internal knowledge bases, supplier correspondence, or triage of incoming foreign documentation, raw or lightly post-edited MT can be rational. The output is imperfect, but the alternative was often no translation at all.
The calculus flips wherever the text meets safety, liability, or regulators. MT engines make errors that are hard to spot because they are fluent: silently dropped negations, omitted sentence parts, units left unconverted, the same component named three different ways across a manual. On a safety data sheet or an IFU those are unacceptable at any price. There is also a confidentiality question, since content pasted into free public engines may be retained and reused. The honest position, which we hold even when it costs us a sale, is that MT is a tool to be chosen deliberately per document, with human post-editing sized to the risk, and never resold as human translation. Our machine translation guide includes a decision list for classifying your own documents, and our pricing page shows how the cost difference actually plays out per word.
Frequently asked questions
Is technical translation the same as scientific translation?
They overlap but differ in purpose. Scientific translation deals with research output such as journal articles and study reports, where argument and nuance dominate. Technical translation deals with applied documents that people act on, such as manuals and procedures, where instructions and terminology dominate. Many translators handle both within one field; few handle both across many fields.
Does a technical translator need an engineering degree?
Not always a degree, but always genuine domain grounding. Years spent working in an industry can substitute for formal engineering training. What does not work is a linguist with no technical background relying on dictionaries, because the hardest choices in technical texts are between terms a dictionary lists as equivalent.
What does technical translation typically cost?
Pricing is normally per source word and varies with language pair, subject difficulty, file formats, and deadline. Common US market ranges run from roughly $0.14 to $0.30 per word for professional human translation with independent revision, with repetitions and previously translated matches discounted. Rates below that range usually mean single-pass work or unedited machine output.
Can our bilingual engineer just translate the documents?
They can, and for short internal notes it may be fine. For published documentation it usually is not, for three practical reasons: translation into a non-native language reads awkwardly, engineers rarely have time to translate at professional speed, and there is no independent revision step. The better use of a bilingual engineer is reviewing terminology, where their knowledge is irreplaceable.
How is technical translation different from localization?
Translation converts the text. Localization adapts the whole product experience for a market, which can include units, date formats, screenshots, regulatory content, and interface layout. A technical translation project often includes localization tasks, such as adapting a manual's referenced standards or reshooting software screens in the target language.