Technical Translation System | Terminology, Units, Drawings, Safety & QA

Technical translation is the disciplined transfer of engineering, scientific, industrial and product information from one language to another without changing the identity, quantity, function, safety meaning or configuration of the thing being described. People searching for technical translation, technical translator, engineering translation, scientific translation, technical manual translation, instruction manual translation, specification translation, technical terminology, units and symbols in translation, drawings and diagrams translation, software documentation translation, or quality assurance for technical translation are usually trying to solve a problem that is much larger than vocabulary: how do you move a technical system across languages without changing the system itself?

A complete technical translation system has to preserve relationships among prose, terminology, part numbers, versions, units, tolerances, equations, drawings, tables, warnings, procedures, standards, interfaces and revisions. Current standards reinforce that systems view. ISO 17100:2015 remains the published translation-services standard while Edition 2 is under development; ISO 704:2022 defines principles and methods for terminology work across scientific, technological and industrial fields; ISO 10209:2022 defines vocabulary for technical product documentation; and IEC/IEEE 82079-1:2019 remains the published general standard for preparation of information for use while its next edition is under development. Technical translation therefore belongs at the intersection of language, terminology, documentation engineering, product configuration and risk control.

The hidden problem is that a technically fluent target can still be wrong in ways ordinary prose review will not catch. A translator can render every sentence naturally and still change 0.5 mm to 5 mm, turn a maximum into a nominal value, translate a part number, reverse a tightening sequence, remove a safety condition, convert a unit without authorization, rename a drawing view, confuse a model with a series, merge two distinct technical terms, or use a new revision’s terminology inside an old product manual. Technical translation quality therefore depends on traceability: every target statement should remain connected to the correct source requirement, object, version and evidence.

Architecture node: EDKSG-TRANS-MASTER-WORLD-140. Return to the map: Master Art of Translation | The Complete System for Moving Meaning Between Languages.

The 50-second technical translation route

Start by identifying the exact source package and revision. Classify what can be translated, what must remain exact, what may be converted only under an approved rule, and what requires specialist review. Build or load the approved terminology. Protect identifiers, units, formulas, code, drawing references and safety elements. Translate prose by meaning and function, not by word substitution. Compare every quantity and logical condition. Run automated QA on numbers, tags, variables and terminology. Review the target against drawings, tables, screenshots and procedures. Finally, verify that the delivered file belongs to the correct product version and that every late correction propagates to translation memory, terminology and released documentation where appropriate.

What this article owns in the Master Art of Translation architecture

This node owns technical translation as a complete system. It covers source packages, specifications, technical terminology, identifiers, units, quantities, tolerances, formulas, drawings, tables, charts, instructions, safety information, software and hardware documentation, configuration control, standards, translation memory, machine translation, human review, QA, change control, release and technical-document maintenance.

It does not replace the specialist existing leaves for VINs, UDI, CAS numbers, part numbers, tables, charts, logarithmic scales, statistical methods, file formats, APIs or individual engineering concepts. Those pages own narrow technical objects. This master node owns the architecture that connects them and tells the translator when to route outward rather than duplicating each specialist guide.

The hidden problem: technical language describes a controlled reality

Ordinary language often tolerates paraphrase. Technical language frequently does not. “Approximately five metres” is not equivalent to “five metres” when the approximation matters. “Maximum operating temperature” is not the same as “recommended operating temperature.” “Compatible with model A200” is not the same as “compatible with the A-series.” “Tighten until seated” is not necessarily the same as “tighten firmly.” Technical prose is constrained by the reality of products, processes and measurements.

This does not mean technical translation should be literal. A source noun string may need to become a clause. A passive may become active. A long sentence may be split. A term may need an established target-language designation rather than a transparent word-for-word equivalent. Technical fidelity concerns controlled relationships, not copied syntax.

A useful principle is to separate the technical invariants from the linguistic variables. Invariants include the product identity, revision, parameter, unit, threshold, sequence, condition, warning level, technical concept and cross-reference. Linguistic variables include syntax, word order, article use, punctuation and many aspects of style. The translator is free to change the linguistic variables when necessary to make the target precise and usable, but should not change the invariants without explicit authority.

Begin with the exact source package

Technical translation should start with a controlled source package, not with a copied paragraph whose context is unknown. Record the document title, product or system, document number, revision, source language, target locale, publication status and related files. If the translation belongs to a release, record the software, hardware or product version. A technically accurate target of the wrong revision is still the wrong document.

The source package may include more than one file. A machinery manual can depend on drawings, parts lists, labels and risk-analysis terminology. Software documentation can depend on UI screenshots, error strings, API schemas and version-specific behavior. A scientific report can depend on tables, graphs, equations and cited methods. The translator should know which artifacts are authoritative and which are only explanatory references.

Distinguish source from reference. The source is what the target is accountable to. A previous translation, competitor manual or older release can be useful evidence, but should not silently override the current source. Mark each resource with authority: current source, approved terminology, current master translation memory, previous edition, reference-only.

Source freeze and change control

Technical content often changes while translation is in progress. A source freeze reduces churn. When change is unavoidable, use a version diff. Do not ask translators to detect changes by visually comparing two long manuals. A change log should identify added, deleted and modified sections, and the localization workflow should mark affected targets for re-review.

Late technical changes deserve special care. Replacing a product name can be simple. Changing a tolerance, warning condition or software behavior can invalidate several downstream sections. The technical translation system should propagate the change to every locale and every dependent asset, not only the sentence where the engineer made the edit.

Source defect versus translation defect

Technical sources contain errors too. A table may list 12 V while the prose says 24 V. A drawing may show a different part identifier from the bill of materials. A numbered instruction may skip a step. The translator should not silently repair technical reality from intuition. Raise a query. If an authorised owner corrects the source or instructs the target to use the corrected value, record that decision.

This distinction protects both sides. The translator is not blamed for faithfully carrying a defective source, and the target does not become an undocumented engineering change. Technical translation should not become shadow product engineering.

The technical translation brief

A strong brief can include:

source document and revision;
target language and locale;
product/system and version;
audience;
purpose;
domain;
authoritative terminology;
do-not-translate identifiers;
unit policy;
number/date policy;
standards references;
format/file type;
software variables or tags;
safety classification;
review level;
subject-matter expert contact;
release date;
and final approver.

The brief is not bureaucracy. It is how the project decides whether “5,000” means five thousand or five depending on locale, whether inch values should remain or be converted, whether a term must match a regulated label, whether drawing callouts are translated, and whether the target is a reading translation or a publication-ready instruction set.

The standards layer: current published authority versus drafts

Technical translation commonly sits inside other standards rather than inside one universal “technical translation standard.” The translation-service process itself can be governed by ISO 17100:2015, which remains the published current edition in 2026 even though a second edition is under development. Technical terminology work can use ISO 704:2022, whose scope includes scientific, technological and industrial fields and whose conceptual model distinguishes objects, concepts, definitions and designations.

Technical product documentation uses its own standards. ISO 10209:2022 provides vocabulary relating to technical drawings, product definition and related documentation. IEC/IEEE 82079-1:2019 remains the published general standard on preparation of information for use for products ranging from simple consumer items to complex industrial machinery; its third edition is under development. ISO 20607:2019 remains the published general drafting-principles standard for safety-related instruction handbooks for machinery, while a replacement is expected. The translator should distinguish currently published requirements from drafts that signal future direction but are not yet replacements.

Safety symbols and labels also live inside standards systems. ISO 3864-1:2011 remains current for design principles for safety signs and markings, ISO 3864-2:2016 for product safety labels, and ISO 3864-3:2024 for graphical symbols used in safety signs. ISO 7010:2019 remains the published registered-safety-sign standard while Edition 4 is under development. A technical translator should not casually translate, redraw or substitute standardized symbols as if they were ordinary prose.

Technical invariants: what must not drift

Before translation, mark the elements whose function depends on exact identity or controlled meaning.

Identifiers

Examples:

part numbers;
serial numbers;
model numbers;
revision codes;
firmware versions;
drawing numbers;
ticket IDs;
SKUs;
asset IDs;
chemical identifiers;
medical-device identifiers.

Do not translate an identifier merely because it contains letters that resemble words. Translate the label around it if needed. Preserve the identifier string unless the responsible technical system explicitly defines localization rules.

Quantities

Numbers are not decoration. Protect:

decimals;
signs;
ranges;
percentages;
ratios;
tolerances;
minimum/maximum values;
significant figures;
scientific notation.

A decimal point or minus sign can carry more technical meaning than an entire paragraph.

Units

Preserve the relationship between value and unit. Conversion is not automatically translation. If conversion is required, use an approved conversion rule, preserve necessary precision, and avoid converting values whose tolerances or regulatory status depend on the original unit representation.

Logic

Protect words and structures such as:

not;
only;
unless;
if;
at least;
no more than;
before;
after;
until;
may;
must;
should.

These can define technical state or safety behavior.

Sequence

Procedures are ordered systems. Moving step 4 before step 3 can be dangerous even when each sentence remains accurate.

Reference

Protect:

Figure 3;
Table 2;
Section 5.4;
connector J12;
port P3;
drawing callout A-A.

Cross-references should remain resolvable after translation and layout.

Technical terminology is concept-first, not word-first

ISO 704:2022 is useful because technical terminology is built around relationships among objects, concepts, definitions and designations. A technical translator should ask which concept the source term names in this domain, not which dictionary equivalent appears first.

One source word may have several technical senses. “Bus” in electronics is not a vehicle. “Lead” may be a metal, a wire, a connector, a timing relation or an action. “Ground” can refer to electrical reference, earth connection or physical terrain. “Bearing” can be a component or a direction. “Pitch” can concern threads, blades, acoustics or motion. Technical meaning comes from system context.

Concept identification

Before choosing a target term, ask:

What object or process is being described?
What field?
What is the definition?
What neighbouring concepts must remain distinct?
Is there an official target term?
Does the client use a controlled term?
Is the source term itself ambiguous or inconsistent?

One term per concept is a policy, not a universal language law

Controlled technical authoring often benefits from stable terminology. But the target may still require inflection, grammatical adaptation or established variation. Do not confuse conceptual consistency with blind string repetition.

Synonym risk

In ordinary prose, synonyms can improve style. In technical documentation, variation can create false distinctions. If “housing,” “casing” and “enclosure” are distinct components in the product architecture, using them interchangeably can corrupt meaning. If they are merely source-author variation for one concept, terminology normalization may be appropriate under project policy.

Deprecated terms

Technical organizations change terminology. A previous approved translation can become obsolete. Current termbase should outrank old translation memory where policy says so.

Definitions

A definition can be more authoritative than a bilingual equivalent. When two target candidates compete, compare each against the concept definition and authentic target-domain usage.

Technical translation is a family of document systems

Technical translation can include:

specifications;
requirements;
engineering reports;
manufacturing instructions;
installation manuals;
maintenance manuals;
service bulletins;
software documentation;
API documentation;
datasheets;
safety data sheets;
drawings;
test reports;
validation protocols;
quality documents;
scientific papers;
patents and patent-adjacent technical prose;
training materials;
labels and user instructions.

Each document type has different invariants and review expectations. The technical translation system should route accordingly rather than pretending one style guide governs everything.

Audience and purpose control technical style

A maintenance engineer, end user, regulator, developer and research scientist may need different target language for the same underlying product.

End-user instructions may prioritize direct actions and hazard avoidance.

Engineering specifications may prioritize exact requirements and controlled terms.

Research reports may preserve hedging, methods and evidential status.

Developer documentation may prioritize API names, code, parameters and examples.

The technical translator should know which document they are producing rather than converting every source into one generic “technical” register.

The repeatable technical translation method

Step 1: identify the source and revision.

Step 2: classify the document and risk.

Step 3: inventory protected identifiers, numbers, units, formulas and references.

Step 4: load authoritative terminology and prior approved references.

Step 5: inspect drawings, tables, UI or product context.

Step 6: translate by concept and function.

Step 7: preserve sequence, conditions and warnings.

Step 8: run automated hard-detail QA.

Step 9: perform bilingual technical review.

Step 10: involve subject-matter expert where concept risk justifies it.

Step 11: inspect final rendered file or product.

Step 12: release the correct version and update reusable assets.

This method is simple enough to remember and strong enough to scale.

Route outward when the narrow technical object already has an owner

The eduKateSG ecosystem already contains specialist translation guides for technical identifiers, scientific quantities, tables, charts, statistical concepts, APIs and many other technical objects. The purpose of this master system is not to rewrite them. It is to diagnose the layer and route outward.

If the issue is a model, part, serial or version string, use the dedicated identifier guide. If it is a table or graph, use the data-structure guide. If it is a statistical construct, route to the specialist statistical translation article. If it is terminology governance, use the Terminology System. If it is a translation-quality decision, use the Translation Quality System.

That routing keeps the architecture deep without cannibalising the technical leaves already doing narrower work.

Technical terminology governance: one concept can control an entire system

Technical translation becomes unreliable when terminology is treated as a late proofreading task. A product, machine, software platform or scientific method can contain hundreds of concepts that interact. If the target uses two different words for one controlled component, a reader may infer two different objects. If the target uses one word for two distinct source concepts, a warning, drawing or maintenance instruction may become ambiguous. Terminology therefore belongs near the beginning of the workflow.

ISO 704:2022 is useful because it frames terminology around concepts and designations rather than around isolated bilingual word pairs. In practical translation terms, that means a glossary entry should ideally answer more than “X = Y.” It can identify the concept, domain, definition, preferred term, admitted synonym, forbidden term, abbreviation, product scope and relevant notes.

Build terminology from the product architecture

Suppose a machine has an outer enclosure, an internal housing and a removable cover. In casual English these words can overlap. In the engineering design they may identify three different physical components. A target language that collapses all three into one generic word can make assembly and service instructions impossible to follow.

The termbase should therefore reflect the product architecture. The entry for each term can include:

concept ID;
source term;
target term;
definition;
component or subsystem;
drawing reference;
status;
version;
example;
and source of authority.

This makes terminology traceable to the system rather than merely to a translator’s memory.

Term authority hierarchy

A practical authority order can be:

current regulated or standardized term;
current client-approved termbase;
current product documentation;
approved master translation memory;
older release documentation;
general bilingual dictionary;
web frequency.

The exact hierarchy varies by project. The important point is that an older translation or a popular web phrase should not silently override a current engineering decision.

Terminology conflict

If the termbase says one thing and the current source drawing labels another, do not choose silently. Raise a terminology query. Perhaps the engineering team renamed the part. Perhaps the drawing is stale. Perhaps one label refers to the assembly and the other to a subcomponent. A technical translator should surface the conflict before the target hardens it into another layer of inconsistency.

Concept drift across revisions

A product name can remain identical while its function changes. A “controller” in revision A may become a “gateway controller” in revision C. The target terminology should follow the concept and configuration, not only the source string.

Abbreviations and acronyms

Technical documents are dense with abbreviations. Before expanding one, confirm what it means in this document. “DC” may mean direct current, data center, duty cycle or a project-specific code. “CAN” may refer to Controller Area Network or an ordinary word in nontechnical context. Keep an abbreviation list tied to the domain.

Do-not-translate terms

Some technical elements may remain in source form:

registered product names;
software commands;
API method names;
protocol names;
code identifiers;
model designations;
standard numbers.

Mark them explicitly. Otherwise translators may waste time deciding repeatedly or accidentally localize something that must remain exact.

Identifiers: translate the label, preserve the identity

Technical documentation often combines ordinary language with machine-readable identity. A sentence can contain a model name, serial number, firmware version, part number and human description. The description may require translation. The identity strings usually do not.

Model numbers

“Model XR-220” should not become “Model XR-220 translated into target script” unless the manufacturer has an official localized naming policy. The identifier is part of product identity.

Part numbers

A part number can look semantic—AB-VALVE-01—but still function as an identifier. Do not translate internal components of the code unless engineering defines a transformed target format.

Serial numbers

Never reformat a serial number for local digit grouping. A serial number is not a quantity.

Revision strings

Rev B, v2.1.4, firmware 5.06 and build 2318 have different structures. Preserve them exactly unless a display policy says otherwise.

Drawing numbers

A drawing number can resemble a section reference. Confirm whether “DWG-1042” is identity rather than text.

Technical identity audit

Before release, compare all identifiers source-to-target mechanically where possible. Exact-string QA is more reliable than expecting a reviewer to notice one changed digit inside a 20-character code.

Numbers, units and tolerances: language wrapped around measurement

Technical translation often fails through hard details rather than prose. A unit can be copied correctly while the decimal changes. A range can collapse. A tolerance can be detached from its nominal value. A sign can disappear. These errors can be detected systematically.

Value plus unit is one meaning unit

Read “24 V” as one technical statement, not as the number 24 plus a decorative symbol. A translated sentence should preserve the value-unit relationship.

Decimal separators

Locale may change decimal presentation. A source “1.5 mm” may become “1,5 mm” in some target conventions. That formatting change should happen under a locale rule, not through casual manual editing. The numeric value remains one point five.

Thousands separators

“1,500” can mean one thousand five hundred in one convention and be misread in another. Store or process numbers as data when possible and format deliberately.

Ranges

“2–8 °C” is a range. Losing the dash creates 28 °C. QA should detect changed punctuation around numbers.

Minimum and maximum

“At least 10 N” means 10 N or greater. “No more than 10 N” means 10 N or less. “Nominal 10 N” is different again. Preserve the operator, not only the value.

Tolerances

“10.00 ± 0.02 mm” must retain nominal value, plus/minus relationship and tolerance. Do not round one side independently. Do not convert units unless the resulting tolerance precision is engineered and approved.

Significant figures

A source value of 3.00 can communicate more precision than 3. Translators should not remove trailing zeros casually when those figures matter technically.

Scientific notation

“3.2 × 10⁻⁶” should not become “3.2 × 10⁶.” Superscript and minus signs require careful format handling.

Unit symbols versus unit names

SI symbols such as kg, m, s and V are standardized symbols, not ordinary words. Do not pluralize symbols with an added “s.” Written-out unit names can follow target-language grammar.

Unit conversion

Conversion requires a rule. Ask:

Is conversion requested?
Is dual display required?
What rounding?
What precision?
Which unit is legally or technically authoritative?

A user manual may display inches and millimetres. A manufacturing drawing may require the original engineering unit. The translator does not decide conversion policy by personal preference.

Temperature

°C and °F conversion changes numeric value. A safety threshold should not be converted manually without checking rounding and source authority.

Pressure

bar, kPa, MPa, psi and other pressure units appear across industries. Do not mix gauge and absolute pressure if the source distinguishes them.

Torque

N·m is not interchangeable with force. A mistranslated torque instruction can damage a fastener or assembly.

Angles

Degrees and radians must remain distinct. A degree symbol can disappear during encoding or copy-paste.

Frequency

Hz, kHz, MHz and GHz differ by powers of one thousand. Prefix integrity matters.

Prefixes

milli, micro, kilo, mega and giga are not stylistic. A wrong prefix can change value by orders of magnitude.

Equations, formulas and mathematical notation

Technical translation may leave the mathematical expression unchanged while translating the prose around it. That does not make formulas trivial. Variables, labels and explanatory text must remain aligned.

Variable identity

If the equation defines T as temperature, do not change the target prose to call T “time.” Check variable definitions.

Subscripts and superscripts

V_in, V_out, x² and x⁻¹ can be corrupted by format changes. Verify rendered output.

Operators

≤, ≥, ≠, ≈ and ± carry meaning. A missing stroke can change a requirement.

Equation references

“See Equation (4)” should point to the correct equation after layout. Automated numbering can shift.

Function names

sin, cos, log and ln have established mathematical conventions. Do not translate them as ordinary prose unless the target technical convention explicitly differs.

Formula prose

“Where m is the mass…” may be translated. Keep the mapping between symbol and definition exact.

Tables, drawings and diagrams: technical meaning has geometry

Technical meaning can be spatial. A row belongs to a column. A callout belongs to a component. An arrow belongs to a direction. A legend belongs to a symbol. Translation that ignores geometry can preserve all the words and destroy the information.

Tables

Check:

column headers;
row headers;
units;
footnotes;
merged cells;
decimal alignment;
special values;
cross-references.

Never translate cells independently without understanding the table’s dimensions.

Charts

Axes, legends, series names and units form one system. A translated legend should still map to the correct visual series.

Technical drawings

ISO 10209:2022 supplies technical-product-documentation vocabulary. Drawings can contain:

views;
sections;
details;
dimensions;
tolerances;
surface symbols;
notes;
callouts;
datum references;
part labels.

Translate human-readable notes according to project policy while preserving standardized symbols, geometry and identifiers.

Callouts

A callout can combine item number and description. Protect the item number.

Leader lines

If translated text expands, ensure the leader still points to the correct object.

Drawing views

Terms such as section, detail, plan, elevation and exploded view may have established target-domain equivalents. Use technical-documentation terminology rather than everyday words.

Exploded diagrams

Part order and labels matter. Translation should not reorder item numbers to match target text order.

Schematics

Electrical and process schematics use symbols and tags. Translate explanatory text cautiously; equipment tags generally preserve identity.

P&IDs and process diagrams

Instrument tags and line numbers are controlled data. Do not localize them like prose.

Flowcharts

Translate decision text while preserving yes/no branches and process sequence.

Procedures: preserve action, order, condition and result

Instructions are technical logic expressed in language. Each step can contain:

actor;
action;
object;
location;
condition;
quantity;
tool;
expected result.

A good translation keeps all of these relationships stable.

Imperatives

“Press the RESET button” should remain an instruction, not a description that reset may occur.

Conditional steps

“If the indicator remains red, disconnect power.” The condition controls the action. Do not separate them so the action appears unconditional.

Sequence

“Disconnect power before opening the cover” is not equivalent to two unordered bullet points.

Prerequisites

A step may depend on completion of another task. Keep prerequisite language explicit.

Expected result

“The LED flashes twice” may be a verification condition. Do not translate it as a command.

Optional steps

“If required” and “optional” should not become mandatory instructions.

Parallel procedures

When two procedures share steps, do not copy a target from one version without checking the differences.

Maintenance procedures

Component names, tool sizes, lubricants, torque and intervals need exactness.

Troubleshooting

Symptom → probable cause → action is a structured relation. Preserve column alignment and causal distinctions.

Warnings, cautions and safety communication

Safety-related technical translation deserves stronger controls because language can influence physical action.

ISO 20607:2019 addresses safety-related content in machinery instruction handbooks, while ISO 3864 and ISO 7010 provide parts of the wider safety-sign architecture. These standards do not mean every product uses identical signal-word conventions. Follow the product’s governing standards and market requirements.

Hazard

What can cause harm?

Consequence

What can happen?

Avoidance

What action prevents harm?

A translated warning should preserve all three where present.

Signal words

Danger, warning, caution and notice may be controlled categories in particular systems. Do not treat them as stylistic synonyms.

Negation

“Do not operate without guard installed.” A missing “not” can create a critical error.

Sequence in safety

“Lock out power before removing the panel.” The order is itself safety information.

Standardized symbols

Do not redraw or substitute safety symbols casually. Verify that the correct registered symbol is used according to applicable standards and product rules.

Safety label layout

Text expansion can break hierarchy or separate a warning from the relevant symbol. Review final artwork.

Translation of hazard terminology

Hazard terms should match regulatory/product terminology in the target market where required.

Software and digital technical documentation

Software documentation introduces new invariants:

UI labels;
menu paths;
code;
commands;
parameters;
file paths;
API endpoints;
HTTP status codes;
JSON keys;
error messages;
version-specific behavior.

UI labels

If the product UI is localized, documentation should use the actual target label, not a translator’s invented equivalent.

Menu paths

“Settings → Security → Keys” should reflect the target product’s navigation.

Code

Do not translate code syntax. Translate comments or user-facing strings only when in scope.

Commands

Command names generally remain exact. Explanatory prose can be translated.

Parameters

Parameter identifiers remain exact unless API design says otherwise.

Examples

Code examples can contain user-facing sample data. Know what can change.

API documentation

Preserve endpoint paths, methods, headers, schema keys and status codes. Translate explanations.

Error messages

If the software itself has localized error messages, documentation should match them.

Version-specific docs

An instruction valid for v4 may fail in v5. Translation should stay tied to product release.

Scientific and laboratory technical translation

Scientific technical translation protects:

method;
sample;
instrument;
measurement;
uncertainty;
statistical relation;
claim strength.

Methods

“Samples were incubated overnight” should not become a fabricated exact duration if source does not define one.

Uncertainty

“May indicate” should not become “proves.”

Statistical terminology

Use field-specific definitions. P-value, confidence interval, credible interval, effect size and correlation are distinct concepts.

Instrument names

Brand/model identifiers remain controlled.

Chemical names

Follow authoritative nomenclature/project policy. CAS or UN identifiers should remain exact.

Laboratory units

Microlitre versus millilitre errors can be critical.

Sample identity

Do not translate sample IDs.

Manufacturing and industrial translation

Manufacturing documents connect language directly to repeatable operations.

Work instructions

Preserve station, part, tool, quantity, sequence and acceptance criteria.

Bill of materials

Part identities and quantities should not be altered by prose translation.

Inspection criteria

Pass/fail thresholds must remain exact.

Nonconformance language

Terms such as defect, deviation, concession and rework can have controlled quality-system meanings.

Process parameters

Temperature, pressure, time, speed and concentration require hard-detail QA.

Change notices

Engineering change orders or notices can alter exactly which revision the target should describe. Link translation updates to configuration change.

Configuration control: technical translation belongs to a product state

A technical document describes a configuration. That configuration can include:

hardware revision;
software release;
firmware;
optional modules;
regional variant;
regulatory version.

Translation memory can tempt a team to reuse a sentence from another configuration because the words look similar. Configuration control asks a more important question: does that sentence remain true for this product state?

Baseline

Identify the approved source baseline.

Change request

When source changes, identify target impact.

Traceability

Know which target file maps to which source revision.

Release

Do not publish target before engineering/content approval state allows it.

Obsolete content

Prevent obsolete target segments from re-entering master memory as if current.

The technical translation doctrine

Technical translation is controlled language change around controlled technical invariants.

The translator can and should improve target-language clarity, structure and usability.

The translator should not silently change the product, process, quantity, risk or version being described.

That distinction is the foundation of the whole system.

Technical translation failure laboratory

The following cases show how a target can sound professional and still become technically wrong. Each case separates the visible wording from the system-level consequence.

Failure 1: decimal point disappears

Source: 0.5 mm. Target: 5 mm. Consequence: tenfold dimensional change. Repair: automated source-target numeric comparison plus human verification.

Failure 2: minus sign disappears

Source: −20 °C. Target: 20 °C. Consequence: operating limit reversed across zero. Repair: treat sign as part of numeric data.

Failure 3: range dash disappears

Source: 2–8 °C. Target: 28 °C. Consequence: range becomes a single temperature.

Failure 4: maximum becomes nominal

Source: maximum pressure 8 bar. Target: pressure 8 bar. Consequence: upper limit presented as ordinary operating value.

Failure 5: minimum becomes exact

Source: at least 30 minutes. Target: 30 minutes. Consequence: lower bound becomes exact duration.

Failure 6: “up to” disappears

Source: up to 10 A. Target: 10 A. Consequence: capability/limit overstated.

Failure 7: percentage versus percentage points

Source: increased by 3 percentage points. Target: increased by 3%. Statistical meaning changes.

Failure 8: ratio inverted

Source: 2:1 resin-to-hardener. Target describes 1:2. Process mixture fails.

Failure 9: unit prefix changes

Source: 50 µm. Target: 50 mm. Magnitude changes by one thousand.

Failure 10: unit copied but value converted

Source: 1 inch. Target numeric value becomes 25.4 but unit remains inch. Double conversion error.

Failure 11: value copied but unit converted

Source: 10 psi. Target says 10 kPa. Same number, different physical pressure.

Failure 12: tolerance rounded away

Source: 10.00 ± 0.02 mm. Target: 10 ± 0.0 mm. Precision destroyed.

Failure 13: significant zero removed

Source: 3.00 V. Target: 3 V. Potential precision information lost.

Failure 14: exponent sign changes

Source: 1 × 10⁻⁶. Target: 1 × 10⁶. Twelve orders of magnitude separate them.

Failure 15: inequality reverses

Source: x ≤ 5. Target: x ≥ 5. Requirement inverted.

Failure 16: “not” omitted in warning

Source: Do not operate with guard removed. Target: Operate with guard removed. Critical safety error.

Failure 17: “only” omitted

Source: Use only approved lubricant. Target: Use approved lubricant. Exclusivity weakened; alternatives appear permissible.

Failure 18: “unless” mistranslated

Source: Do not reset unless the valve is closed. Target changes condition. Procedure may become unsafe.

Failure 19: “before” becomes “after”

Source: Disconnect power before opening panel. Sequence reversed.

Failure 20: optional becomes mandatory

Source: If required, install spacer. Target: Install spacer. Configuration changes.

Failure 21: mandatory becomes advisory

Source: Operator must wear eye protection. Target: Operator should wear eye protection. Requirement weakened.

Failure 22: capability becomes permission

Source: Device can operate at 24 V. Target: Device may be operated at 24 V. Depending on context, capability and authorized use can differ.

Failure 23: model family replaces exact model

Source: X200. Target: X-series. Compatibility scope broadened.

Failure 24: serial number localized

Arabic digits or letter forms replaced inside identity string. Database lookup fails.

Failure 25: part-number hyphen removed

AB-102 becomes AB102. If systems treat strings differently, identity changes.

Failure 26: version string normalized

v2.01 becomes v2.1. Human meaning may appear same; software release identity may not.

Failure 27: drawing number mistaken for section number

DWG-5.4 localized/reformatted as “Section 5.4.” Cross-reference breaks.

Failure 28: UI label translated independently from product

Documentation says “Preferences” while target UI says “Settings.” User cannot find control.

Failure 29: command translated

CLI command RESET_CONFIG becomes localized text. Command fails.

Failure 30: API endpoint translated

/users/create becomes localized path despite API remaining source form. Integration breaks.

Failure 31: JSON key translated

“user_id” becomes target-language key. Parser fails.

Failure 32: code comment and code confused

Translator changes string inside code that was executable rather than a comment. Build fails.

Failure 33: placeholder altered

{temperature} becomes translated token. Runtime cannot substitute value.

Failure 34: XML tag translated

<warning> renamed while schema expects original tag. Validation fails.

Failure 35: HTML entity corrupted

Technical symbol or ampersand becomes malformed markup. Rendering breaks.

Failure 36: escape sequence changed

\n or \t altered as ordinary text. Output formatting changes.

Failure 37: file path localized

C:\ProgramData\Vendor becomes translated folder name that does not exist.

Failure 38: environment variable translated

PATH, HOME or project-specific variable renamed. Procedure fails.

Failure 39: SQL field name translated

Database query no longer matches schema.

Failure 40: HTTP status code described incorrectly

404 called authorization failure instead of not found. Troubleshooting logic changes.

Failure 41: protocol acronym expanded incorrectly

CAN interpreted outside Controller Area Network context. Technical concept changes.

Failure 42: “ground” gets wrong sense

Electrical ground translated as physical soil. Safety/electrical meaning lost.

Failure 43: “lead” gets wrong sense

Wire lead translated as leadership or metal depending context. Domain sense must be established.

Failure 44: “bearing” gets wrong sense

Mechanical bearing translated as direction/bearing. Component identity lost.

Failure 45: “pitch” gets wrong sense

Thread pitch translated as acoustic pitch. Measurement context ignored.

Failure 46: controlled term varied for style

One component appears as enclosure, housing and casing in target even though source product architecture distinguishes them.

Failure 47: one target term collapses two source concepts

Sensor and transducer both become one word despite different roles in system.

Failure 48: old terminology wins through translation memory

Current source uses renamed component. Exact TM match inserts deprecated target term. Current termbase should override.

Failure 49: glossary forces wrong grammatical form

Approved term inserted mechanically without required case/inflection. Technical term correct, sentence wrong.

Failure 50: source author uses wrong term and translator normalizes silently

Translator suspects “inlet” should be “outlet” and corrects target without engineering confirmation. Translation becomes undocumented engineering change.

Failure 51: table header separated from unit

Column “Pressure (MPa)” becomes “Pressure” while unit is lost. Values become uninterpretable.

Failure 52: row shift

Translated text expansion causes values to align with wrong row labels. All words remain correct; data relationship fails.

Failure 53: chart legend reordered

Series labels no longer match line colors. Visual data meaning changes.

Failure 54: axis unit translated incorrectly

“Time (ms)” becomes seconds. Data appears one thousand times slower.

Failure 55: figure callout points to wrong component after layout

Text moved but leader line not updated.

Failure 56: exploded-view item numbers renumbered

Target editor makes list sequential in reading order, breaking bill-of-materials mapping.

Failure 57: schematic tag translated

P-101 pump tag changed to local abbreviation. Plant identity breaks.

Failure 58: drawing view term mistranslated

“Section A-A” rendered as general “part A-A.” Technical drawing relation obscured.

Failure 59: datum reference treated as ordinary letter

Target typography changes datum label or removes box. Dimensional-control meaning affected.

Failure 60: formula variable redefined accidentally

Source defines t as thickness. Target prose says time. Equation remains unchanged; explanation becomes wrong.

Failure 61: equation number changes but references do not

Layout renumbers equations. Text still points to old number.

Failure 62: superscript lost in equation

m² becomes m2. Could be read incorrectly or appear unprofessional.

Failure 63: subscript lost

V_in becomes Vin as prose. Variable identity less clear.

Failure 64: mathematical symbol replaced with similar character

Greek mu, micro sign and Latin u can behave differently in systems/fonts. Technical review required.

Failure 65: warning signal word softened

Controlled WARNING becomes “Note.” Hazard classification disappears.

Failure 66: warning signal word strengthened

A caution becomes danger without authority. Risk hierarchy distorted.

Failure 67: standardized safety symbol replaced by emoji

Visual looks understandable but no longer follows product safety-sign system.

Failure 68: avoidance action omitted

Warning names hazard but loses instruction for avoiding it.

Failure 69: consequence omitted

User no longer knows why action matters.

Failure 70: safety label split across pages

Signal word and avoidance instruction separated after DTP. Final production QA required.

Failure 71: numbered procedure reordered for target style

Editor groups similar verbs together. Physical sequence breaks.

Failure 72: expected result translated as command

“The LED flashes twice” becomes “Flash the LED twice.” Verification becomes action.

Failure 73: troubleshooting cause and remedy swapped

Table layout error. User applies wrong fix.

Failure 74: “disconnect” and “switch off” collapsed

Electrical isolation may require physical disconnection, not merely pressing power button.

Failure 75: “remove” becomes “loosen”

Physical action incomplete.

Failure 76: “inspect” becomes “replace”

Maintenance scope changes.

Failure 77: lubricant brand generalized

Source specifies approved product. Target says generic grease. Compatibility risk.

Failure 78: material grade simplified

Stainless steel grade 316 becomes “stainless steel.” Material requirement weakened.

Failure 79: fastener class omitted

Bolt grade/property class disappears. Mechanical strength requirement lost.

Failure 80: thread designation localized

M8 × 1.25 reformatted incorrectly. Hardware mismatch.

Failure 81: chemical identifier altered

CAS or UN number changes digit. Substance identity changes.

Failure 82: chemical name translated without checking official nomenclature

Common-name equivalent maps to different substance.

Failure 83: pH described as linear quantity

Target explanation implies pH 6 is “one unit less acidic” in an ordinary additive sense. Logarithmic meaning lost.

Failure 84: decibel value converted like ordinary linear unit

dB relationships mishandled. Specialist guide should own the detailed concept.

Failure 85: “statistically significant” becomes “important”

Research claim changes from statistical property to practical importance.

Failure 86: “correlated” becomes “caused”

Causal meaning invented.

Failure 87: “randomized” becomes “random” casually

Study design property can be weakened or misunderstood.

Failure 88: null/N/A/zero collapsed

Missing, inapplicable and actual zero values become one display. Data semantics corrupted.

Failure 89: confidence interval becomes certainty range

Statistical interpretation distorted.

Failure 90: firmware instruction from wrong version reused

Exact TM match says menu item exists. Current UI removed it.

Failure 91: screenshot from old release used as context

Translator correctly follows stale screen. Documentation now mismatches product.

Failure 92: product variant ignored

European model lacks feature present in global source. Target describes unavailable control.

Failure 93: regional electrical rating copied incorrectly

Source variant 120 V reused in 230 V product manual. Configuration control failed.

Failure 94: engineering change not propagated

Source warning changed after translation freeze. One locale remains old.

Failure 95: target change not written back to termbase

Reviewer corrects critical technical term in one document. Future projects repeat old term.

Failure 96: target fix remains only in PDF

Source localization file and translation memory remain wrong. Next release regresses.

Failure 97: automated number QA flags legitimate locale formatting and reviewer disables all number checks

Bad tuning leads to no protection. Better: distinguish format transformation from value change.

Failure 98: machine translation hallucinates missing instruction

Source fragment is incomplete. Model “helpfully” completes it. Unsupported technical action added.

Failure 99: AI explains a technical acronym incorrectly with confidence

Fluency masks concept error. Verify from authoritative source.

Failure 100: translator assumes current standard status from memory

A draft standard is cited as published or an old edition used when replacement exists. Technical standards status is time-sensitive. Verify current authority before publication.

What the failure laboratory reveals

Technical translation errors enter through several layers:

source;
terminology;
numbers/units;
logic;
identity;
format;
software;
drawings;
safety;
configuration;
review;
release.

A mature workflow diagnoses the layer before applying a fix. Rewriting the sentence cannot fix a wrong source revision. A terminology edit cannot fix a wrong unit conversion. A better MT engine cannot fix stale screenshots. Technical quality is systemic.

The source-target checksum

For high-risk technical sentences, ask:

Same object?
Same action?
Same condition?
Same sequence?
Same quantity?
Same unit?
Same limit?
Same version?
Same warning force?
Same cross-reference?

This short checksum catches a surprising number of severe errors.

Technical translation workflow profiles

Different technical documents need different review and QA profiles. The technical translation system should classify the document before choosing the workflow.

Profile 1: machinery instruction handbook

Primary risks:

safety;
sequence;
maintenance;
component terminology;
units;
warnings;
life-cycle instructions.

Recommended controls:

technical termbase;
bilingual revision;
hard-detail QA;
subject-matter review for safety-critical material;
final layout review.

Profile 2: installation manual

Primary risks:

site conditions;
dimensions;
orientation;
connections;
torque;
sequence;
commissioning.

Check drawings and installation environment.

Primary risks:

feature claims;
performance;
compatibility;
specification drift.

Creative copy can vary; technical facts cannot.

Human technical review: language expertise and domain expertise are complementary

A technical translator needs strong language and research competence. A subject-matter expert knows the domain. Neither role automatically replaces the other.

Translator responsibility

Understand source meaning.

Use approved terminology.

Preserve hard details.

Write competent target language.

Raise technical queries.

Reviser responsibility

Compare source and target independently.

Check omissions, additions, conditions and terminology.

Subject-matter expert responsibility

Verify technical concept, process and domain usage.

Confirm whether a disputed target term corresponds to the real object.

Engineer responsibility

Own product truth.

Resolve source contradictions and engineering changes.

Technical writer responsibility

Own source clarity, information architecture and document usability where assigned.

Localization engineer responsibility

Own file extraction, tags, variables, round-trip and build integrity.

Release owner responsibility

Confirm the correct source/target versions and required quality gates.

The technical query system

Technical translators should not guess silently when the source is inconsistent or a term controls product meaning.

Strong technical query structure

Source location.

Observed issue.

Current evidence.

Possible interpretations.

Consequence of each.

Question to owner.

Example query: conflicting value

“Section 4.2 gives maximum inlet pressure as 8 bar, while Table 6 gives 10 bar for the same model and operating state. Which value is authoritative for Revision C?”

Example query: component name

“Drawing 102 calls item 14 ‘retaining ring’; the current termbase uses ‘locking ring.’ Are these the same component or distinct parts?”

Example query: procedure

“Step 6 instructs the user to power on before the guard is installed, while the safety section requires the guard before power. Should Step 6 be corrected in the source?”

Query closure

When answer arrives, update:

target;
termbase;
source if authorized;
TM if needed;
decision log.

CAT tools in technical translation

Computer-assisted translation tools can improve consistency and speed, but their matches are evidence rather than truth.

Segmentation

CAT tools divide content into segments. Bad segmentation can separate:

condition from action;
table header from unit;
warning from consequence.

Translation memory

TM is valuable for repetitive technical text. Always compare current source delta and configuration.

Exact matches

An exact textual match may still be wrong if:

product version changed;
locale changed;
terminology changed;
context changed.

Fuzzy matches

Pay special attention to the changed portion. One small word—“not,” “maximum,” “except”—can be the entire technical difference.

Context matches

Previous/next segment context can strengthen reuse confidence but still does not override current product truth.

Concordance

Useful for seeing how a term has been translated elsewhere. Check authority and date.

QA in CAT tools

Enable checks for:

numbers;
terminology;
tags;
untranslated text;
inconsistency;
punctuation;
placeholders.

False positives

A locale-formatted number may differ legitimately. QA warnings require human interpretation.

Translation memory governance for technical content

Technical TM can become a high-value asset or a high-speed error amplifier.

Master TM

Contains reviewed approved target.

Working TM

Can contain current draft segments.

Reference TM

Historical or external data that should not override master.

Locale separation

Do not mix regional variants indiscriminately.

Product separation

One client/product may use same source term differently.

Revision metadata

Where tooling permits, preserve source/project/version context.

Promotion rule

Only promote target to master after required review.

Deprecation

Remove or mark obsolete segments so old safety/technical language does not reappear.

Machine translation and AI in technical translation

Technical text can be a strong candidate for machine assistance because it often contains repetition and controlled terminology. It can also be high risk because fluent output hides hard-detail errors.

Good candidates

low-risk repetitive documentation;
internal drafts;
large support corpora;
standard UI/help text with terminology control.

Higher-risk candidates

safety warnings;
medical-device instructions;
legal/regulatory technical content;
critical operating limits.

Glossary control

Feed approved technical terms where tooling supports it.

Context

Provide product/version/domain context.

Prompt constraints for LLM translation

Do not add technical information.

Preserve all numbers and units.

Preserve negation and modality.

Do not translate identifiers.

Use supplied terminology.

Flag ambiguous source rather than guessing.

AI source analysis

AI can identify likely ambiguities, but verify against engineering evidence.

AI hallucination

Generative systems can complete incomplete source, invent compatibility or normalize a suspected typo. That behavior is especially dangerous in technical content.

AI as QA assistant

Useful for proposing possible omissions or terminology inconsistency. Deterministic checks remain better for exact values, tags and identifiers.

Human post-editing

Post-editor should compare source and target, not merely polish target fluency.

Deterministic QA before generative QA

If a rule can be checked exactly, automate it exactly.

Number set comparison

Extract source and target numbers and flag differences.

Identifier comparison

Exact strings.

Tag comparison

Opening/closing tags, variables, markup.

Unit pattern comparison

Flag changed unit symbols.

Cross-reference validation

Verify figures/tables/sections exist.

Forbidden terminology

Search deprecated target terms.

Required terminology

Search critical concepts.

Source residue

Find untranslated source text.

Build validation

Compile or parse localized resource files before release.

Layered technical review

A single rereading should not try to catch everything.

Pass 1: completeness

All sections, tables, captions, notes, UI strings?

Pass 2: technical identity

Models, parts, versions, names, codes.

Pass 3: quantities

Numbers, units, ranges, tolerances, signs.

Pass 4: logic

Conditions, negation, sequence, modality.

Pass 5: terminology

Concepts and approved forms.

Pass 6: target-language quality

Grammar, clarity, controlled style.

Pass 7: document structure

Tables, figures, references, layout.

Pass 8: in-context use

Can the user follow procedure on real product?

Subject-matter expert review

SME review is especially valuable where a language professional cannot safely validate the physical or technical concept alone.

What SME should review

technical concept;
process;
component;
domain term;
plausibility of translated instruction.

What SME should not automatically own

target-language grammar and style unless qualified.

SME-linguist collaboration

Translator asks concept question.

SME explains system.

Translator produces natural target.

Technical release gate

Before release, verify:

correct source revision;
correct target locale;
terminology current;
critical queries closed;
identifiers unchanged;
numbers/units verified;
safety review complete;
required bilingual revision complete;
SME review complete where needed;
automated QA passed;
figures/tables checked;
final format checked;
approval recorded.

Release confidence

Release confidence does not mean a claim of perfection. It means the team has evidence that the target belongs to the correct product state and has passed the controls appropriate to its risk.

A high-confidence technical release might state:

Source Manual Rev C verified.
Target de-DE.
Termbase v8 applied.
Bilingual revision complete.
Safety sections reviewed by product safety engineer.
Numeric/unit QA passed.
Figures and cross-references verified in final PDF.
Approved for release.

Change control after release

Technical content changes after publication.

Source engineering change

Trigger target impact analysis.

Terminology change

Update termbase and search active documents.

Safety correction

Urgent propagation across locales.

Software release

Revalidate UI paths/screenshots.

Product retirement

Archive manuals without allowing obsolete segments to contaminate current TM.

Technical translation incident response

If a live translation contains a material defect:

contain;
correct;
verify;
identify affected products/locales;
repair TM/termbase/source as needed;
document root cause;
add regression check.

Critical incident example

Target manual says 5 A where source says 0.5 A.

Action:

withdraw/replace affected release according to product policy;
check all locales;
check numeric QA failure;
check TM contamination;
verify corrected artifact.

Terminology incident

Wrong component term appears in 40 manuals.

Fix central termbase and reusable memory, not only PDFs.

Technical translation maturity model

Level 1: bilingual rewriting.

Level 2: term lists and basic review.

Level 3: CAT/TM/termbase plus numeric/tag QA.

Level 4: configuration-aware workflow and SME review.

Level 5: risk-based release, automated validation, incident learning.

Level 6: integrated technical-content architecture linked to product lifecycle and engineering change.

Maturity means that translation remains aligned with the product as the product changes.

The production rule

Telecommunications

Typical content:

protocols;
network architecture;
radio frequency;
identifiers;
QoS;
provisioning.

High-risk elements:

protocol terms, frequency units, identity codes, configuration values.

Software engineering

Typical content:

UI;
APIs;
CLI;
architecture;
deployment;
logs;
configuration.

High-risk elements:

code, commands, paths, keys, exact UI labels, version-specific behavior.

Cybersecurity

Typical content:

vulnerabilities;
authentication;
authorization;
threats;
remediation;
advisories.

High-risk elements:

CVE IDs, versions, severity, conditions, exploitability, mitigation instructions.

Do not translate “authentication” and “authorization” as if interchangeable.

Civil engineering

Technical prose interacts with legal claim language and identifiers. Patent-specific legal translation deserves its own specialist process. This technical system can support the scientific/engineering understanding but should not replace legal-IP expertise.

Specifications and requirements language

Requirements documents use language that can define what a system is obliged, permitted or expected to do.

Shall, must, should, may

Organizations and standards use these words according to specific conventions. Do not assume their force from everyday English alone. Follow the source organization’s requirements style and target equivalent policy.

Requirement versus description

“The system shall log failures” is not the same as “The system logs failures” if the first is a requirement statement and the second describes observed behavior.

Requirement versus recommendation

“Should” can indicate recommendation rather than obligation under many standards conventions.

Permission

“May” may indicate permission or possibility. Determine source convention.

Prohibition

“Shall not,” “must not” or equivalent may define a formal prohibition.

Condition

“The system shall shut down if temperature exceeds 90 °C.” Preserve both trigger and required response.

Exception

“Except during maintenance mode” narrows requirement. Do not omit.

Scope

“All external interfaces” versus “selected external interfaces.” Quantifier controls requirement size.

Acceptance criteria

Pass/fail wording should not become vague.

Controlled technical language

Technical organizations sometimes use controlled-language rules to reduce ambiguity and improve translation.

One term per concept

Use preferred terminology consistently.

One meaning per term where possible

Avoid using “port” to mean both network endpoint and physical connector in same manual unless context/policy supports it.

Short clear instructions

Reduce unnecessary syntactic ambiguity.

Explicit references

Prefer component names over vague “it” when multiple referents exist.

Consistent warning structures

Supports reuse and safety.

Controlled language is not universally suitable

Research papers, expert reports and design rationale may need richer prose. Use controlled authoring where function justifies it.

Translation-oriented technical source writing

Technical translation improves when the source is written for multilingual reuse.

Avoid hidden noun-stack ambiguity

“Cooling water pump control panel test procedure” can have several attachment structures. Rewrite source where possible.

Define acronyms

First use where appropriate.

Use stable terms

Do not alternate component names casually.

Keep conditions near actions

Reduces scope ambiguity.

Use complete sentences for dynamic software messages

Supports localization.

Separate identifiers from prose

Makes protection easier.

Use structured data for values

Dates, units and quantities can then be validated and formatted.

Provide context metadata

Drawings, screenshots, feature, component, user role.

Drawing translation workflow

Step 1: identify drawing revision.

Step 2: inventory translatable notes.

Step 3: protect dimensions, symbols, item numbers and drawing IDs.

Step 4: translate notes with controlled terminology.

Step 5: place target text without covering geometry.

Step 6: verify leader/callout association.

Step 7: perform bilingual visual proof.

Text expansion

Target notes may be longer. Redesign callout boxes without changing diagram relations.

Font and glyphs

Technical drawings may use CAD fonts with limited script support. Verify target script.

Layer management

CAD or illustration systems can store language variants in layers. Keep source/target identity controlled.

Raster drawings

Text embedded in image may require redraw. Avoid OCR-only trust for critical values.

Table translation workflow

Step 1: understand row/column dimensions.

Step 2: identify unit headers.

Step 3: protect values and IDs.

Step 4: translate labels.

Step 5: preserve footnote markers.

Step 6: check alignment.

Step 7: compare representative rows.

Blank versus zero

Do not fill blank cells with zero.

N/A

Not applicable can differ from unavailable or unknown.

Special symbols

Dash can mean “not applicable,” “none” or range depending table. Check legend.

Wrapped headers

Target line breaks can change which unit appears attached to which header. Visual proof.

Safety-warning workflow

Step 1: identify governing product safety system.

Step 2: identify hazard, consequence and avoidance.

Step 3: preserve signal-word class.

Step 4: apply approved terminology.

Step 5: preserve symbol identity.

Step 6: review with safety/product expert where required.

Step 7: verify final label/manual layout.

Do not rewrite for marketing tone

Safety copy is not campaign copy.

Do not remove repetition

Repeated warnings can be required at points of use.

Do not merge warnings casually

Two hazards may require separate locations or actions.

Software documentation workflow

Step 1: know product version.

Step 2: import actual target UI terminology.

Step 3: protect code/identifiers.

Step 4: translate conceptual explanations.

Step 5: test menu paths.

Step 6: verify screenshots.

Step 7: run build/link QA.

Documentation generated from code

Some API docs are generated. Translate only supported fields; regeneration can overwrite manual edits.

Docs-as-code

Markdown/AsciiDoc repositories need version-control integration. Translation branches should not break source code blocks.

Release synchronization

Documentation target should ship with matching software version.

Scientific translation workflow

Step 1: identify field and article/report type.

Step 2: build terminology.

Step 3: protect symbols and statistical notation.

Step 4: translate methods with procedural fidelity.

Step 5: preserve hedging and attribution.

Step 6: verify tables/figures/citations.

Step 7: target-language scientific edit.

Claim ladder

May suggest.

Suggests.

Is associated with.

Predicts.

Causes.

Proves.

These are not interchangeable.

Evidence status

Reported.

Observed.

Estimated.

Modeled.

Assumed.

Preserve source evidential status.

Technical reviewer calibration

Two reviewers can disagree about whether a term, unit format or sentence is acceptable. Calibrate with real examples.

Calibration set

Include:

critical number error;
terminology variation;
source defect;
acceptable syntax variation;
identifier issue;
warning issue;
unit conversion.

Distinguish error from preference

“Use ‘install’ instead of ‘fit’ because the approved termbase specifies it” is evidence.

“I prefer ‘install’” may be preference.

Severity

Critical:

could create severe safety, legal, clinical or technical consequence.

Major:

materially changes function, requirement or concept.

Minor:

target-language defect without material technical change.

Root cause

Do not confuse the output error with cause.

Wrong number could come from:

source,
OCR,
translator,
MT,
reviewer,
DTP.

Technical QA dashboard

Useful operational signals:

critical errors;
number/unit defects;
terminology defects;
identifier defects;
source queries;
source defects;
build failures;
release lag;
change-propagation failures.

A single “translation score” hides what engineering teams need to fix.

Technical translation as a source-quality sensor

Translators often find:

undefined acronyms;
conflicting values;
ambiguous references;
missing steps;
inconsistent component names.

Feed these defects back to source authors. Multilingual review can improve the original technical content.

Change-impact analysis

When source changes, classify:

Editorial change

Spelling/punctuation. Limited target impact.

Terminology change

May affect many documents and TM.

Technical value change

High-priority locale update.

Safety change

Urgent controlled propagation.

Feature change

May affect UI, docs, screenshots, training and support.

Regulatory change

May require specialist/legal review.

Regression testing technical translations

After changes, test known high-risk items.

Critical term.

Key tolerance.

Safety warning.

Menu path.

Figure reference.

Unit display.

Every major incident should add a regression case.

Technical translation debt

Known unresolved problems can accumulate:

old terminology;
unreviewed legacy manuals;
stale screenshots;
obsolete TM;
unverified MT;
hard-coded source text.

Track by risk and product exposure.

Debt interest

One wrong master segment can propagate into hundreds of future translations.

Debt priority

Safety and active products first.

Technical document lifecycle

Create.

Review.

Approve.

Translate.

Revise.

Validate.

Release.

Maintain.

Retire.

Translation should remain linked to that lifecycle.

The engineering principle

Technical translation succeeds when the target changes language without changing the engineering state.

That sentence is the simplest possible summary of this entire node.

The 50-second technical translation router

If you need to decide quickly what kind of technical translation problem you have, start here.

The problem is a word or technical term

Route to terminology.

Ask:

What concept?
What domain?
What definition?
What approved target term?

The problem is a number or unit

Route to hard-detail QA.

Ask:

Same value?
Same sign?
Same unit?
Same range?
Same precision?

The problem is a model/part/version string

Route to identifier protection.

Translate the label, preserve the identity.

The problem is a table/chart

Route to structural data translation.

Check rows, columns, legends, axes, units, footnotes.

The problem is a drawing

Route to technical-product-documentation handling.

Protect geometry, item numbers, dimensions, callouts and symbols.

The problem is a procedure

Route to action logic.

Check:

actor,
action,
object,
condition,
sequence,
result.

The problem is a warning

Route to safety translation.

Check hazard, consequence, avoidance, signal word, symbol.

The problem is software documentation

Route to product-version + UI/API context.

Protect code, commands, paths, keys and target UI labels.

The problem is scientific/statistical meaning

Route to the specialist concept page plus this system for workflow.

The problem is “the source looks wrong”

Raise a technical query.

Do not silently fix product truth.

Technical translation training programme

A strong technical translator develops both language skill and technical operating discipline.

Module 1: source analysis

Identify:

document type;
audience;
product;
version;
risk.

Module 2: terminology

Learn:

concept systems;
definitions;
term authority;
termbases.

Module 3: identifiers

Practice recognizing:

part numbers;
serials;
versions;
codes;
drawing IDs.

Module 4: quantities

Practice:

decimals;
ranges;
tolerances;
units;
scientific notation.

Module 5: requirements logic

Practice:

must;
may;
should;
not;
unless;
at least;
only.

Module 6: procedures

Analyze:

sequence;
condition;
action;
expected result.

Module 7: safety

Practice warning structures and symbol handling.

Module 8: tables/drawings

Translate in context, not text extraction alone.

Module 9: software/code

Protect technical syntax and UI identity.

Module 10: CAT/TM/QA

Use tools without surrendering judgment.

Module 11: subject-matter research

Find authoritative sources.

Module 12: revision and release

Perform layered QA and configuration checks.

Training exercise 1: number integrity

Create a page containing:

0.05;
−5;
2–8;
10 ± 0.2;
1 × 10⁻⁶;
35%.

Translate prose around them. Then compare source-target numbers mechanically.

Training exercise 2: unit integrity

Mix:

mm;
µm;
N·m;
MPa;
kHz;
mL.

Students identify which values would become dangerous if prefixes or units drift.

Training exercise 3: requirement force

Translate:

must;
should;
may;
must not;
only if;
unless.

Then explain the logical force in plain language.

Training exercise 4: identifier spotting

Give a paragraph containing:

model name,
part number,
serial number,
date,
quantity,
revision.

Students classify what can be localized and what must remain exact.

Training exercise 5: table reconstruction

Give a table without formatting.

Students rebuild row/column meaning before translating.

Training exercise 6: drawing context

Provide source labels separately and then with the drawing.

Compare how context resolves terms such as:

cover,
housing,
support,
plate.

Training exercise 7: warning logic

Source:

“Do not open until pressure reaches 0 bar.”

Students list:

prohibition,
condition,
threshold,
unit.

Training exercise 8: software UI

Translate help text with and without actual target UI screenshot.

Observe terminology mismatch.

Training exercise 9: source defect

Give prose value 24 V and table value 12 V.

Students write technical query rather than choosing.

Training exercise 10: TM trap

Old TM says:

“Open Settings > Network.”

Current UI says:

“Preferences > Connectivity.”

Students reject exact-match authority.

Training exercise 11: AI hallucination

Give incomplete source:

“Install the spacer if…”

Ask AI to translate.

Students detect any invented completion.

Training exercise 12: release audit

Students receive:

approved translation;
old screenshot;
new software build;
term update.

They decide whether release is safe.

Technical research method

Technical translators need a hierarchy of evidence.

1. Current source package

Primary content authority for the task.

2. Client/product terminology

Current approved terms.

3. Official standards

When applicable.

4. Manufacturer/product documentation

For names and functions.

5. Authoritative domain references

Professional/academic sources.

6. Comparable target technical documents

For real usage.

7. General dictionaries/search

Candidate generation, not final authority.

Search-result frequency is not terminology authority

A mistranslation can be frequent online. A deprecated term can dominate old manuals. A marketing synonym can outrank the engineering term.

Use search to find evidence, not to replace concept analysis.

Technical target-language style

Technical style should be precise and usable.

Clarity

Readers should know what to do or understand.

Consistency

Stable concepts use stable terms.

Economy

Remove unnecessary complexity without deleting technical conditions.

Explicit reference

Avoid vague pronouns where multiple technical objects exist.

Parallel structure

Useful in steps and tables.

Active versus passive

Choose according to domain/style. Active can make actor/action clear. Passive can be appropriate where process/result matters or actor is intentionally unspecified.

Nominalization

Technical English can overuse noun strings. Rewrite if target becomes ambiguous.

Noun strings

Identify head noun and modifier relationships.

The existing How English Works guide to noun modifiers and noun strings can support this English mechanism without duplicating it here.

Controlled repetition

Repeat technical term when consistency matters. Do not vary for literary style.

Technical translation versus localization

Technical translation moves technical meaning between languages.

Localization can additionally change:

date format;
currency;
locale conventions;
UI behavior;
address;
search;
product-market content.

Do not let localization silently change engineering values. Market adaptation and technical invariants must remain separate.

Technical translation versus transcreation

Marketing headline can be transcreated.

Specification table cannot.

A technical product page can contain both.

Zone the content:

creative marketing;
technical description;
safety;
legal;
UI.

Apply appropriate method to each zone.

Technical translation versus interpreting

A live engineering meeting may need interpreting rather than document translation.

Technical terminology preparation supports both.

But real-time interpreting has different cognitive and quality architecture, owned by the Interpreting System.

Technical translation and quality evaluation

The Translation Quality System provides general evaluation architecture.

Technical profile should weight:

accuracy;
terminology;
numbers/units;
identifiers;
logic;
technical integrity.

Critical technical error

Can cause severe safety/technical consequence.

Major error

Changes function, requirement, compatibility or important concept.

Minor error

Language/style issue without material technical effect.

AI governance for technical translation

If AI is used, define:

approved model/tool;
data privacy;
source types;
prohibited high-risk content;
terminology injection;
human review;
logging;
versioning.

Confidentiality

Technical documents may contain:

trade secrets;
unreleased products;
security architecture;
personal data.

Do not upload to unapproved services.

Prompt injection

User-generated or external technical content can contain instructions that an LLM might follow. Treat source as data.

Model version changes

Regression-test technical benchmark after model update.

Benchmark set

Include:

numbers;
units;
negation;
requirements;
identifiers;
terminology;
tables;
code;
warnings.

Quality estimation

Can route review.

Cannot prove critical correctness.

Security and technical translation

Security documentation can itself be sensitive.

Access control

Limit source files to authorized personnel.

Logs

Do not log confidential source text unnecessarily.

Credentials

API keys/passwords should not be exposed to translation vendors if not needed.

Redaction

Use safe placeholders where translation does not require secret values.

Secure transfer

Use approved systems.

Accessibility in technical documentation

Technical information should remain accessible after translation.

Alt text

Translate meaningful image descriptions.

Table headers

Preserve semantics for screen readers.

PDF reading order

Translated DTP should not break accessibility structure.

Language metadata

Set correct target language.

Plain technical language

Use accessible wording without deleting necessary distinctions.

Desktop publishing and technical translation

Technical DTP can introduce errors after linguistic approval.

Text expansion

Callout boxes and warning labels can overflow.

Table reflow

Rows/columns can shift.

Equation rendering

Superscripts/subscripts can break.

Font coverage

Target script may require another font.

Image labels

Ensure arrows/callouts remain aligned.

Final PDF proof

Mandatory for safety/high-value documents where final rendering matters.

Technical release matrix

Green

Correct revision.

All critical queries closed.

Terms current.

Hard-detail QA passed.

Required review complete.

Final format verified.

Amber

No critical issues.

Known minor issue with owner.

Low-risk release only if policy permits.

Red

Source conflict unresolved.

Wrong/unknown revision.

Critical number/unit/identifier issue.

Safety review incomplete.

Do not release.

100-point technical translation checklist

1. Correct source file?
2. Correct source revision?
3. Correct product/version?
4. Correct target locale?
5. Audience defined?
6. Purpose defined?
7. Domain defined?
8. Risk classified?
9. Termbase current?
10. Reference hierarchy known?
11. Do-not-translate list?
12. Model numbers protected?
13. Part numbers protected?
14. Serial numbers protected?
15. Version strings protected?
16. Drawing IDs protected?
17. Units inventoried?
18. Ranges inventoried?
19. Tolerances inventoried?
20. Scientific notation checked?
21. Signs checked?
22. Percentages checked?
23. Ratios checked?
24. Dates checked?
25. Time values checked?
26. Requirement words checked?
27. Negation checked?
28. Conditions checked?
29. Exceptions checked?
30. Sequence checked?
31. Warnings identified?
32. Signal words controlled?
33. Safety symbols correct?
34. Hazard preserved?
35. Consequence preserved?
36. Avoidance preserved?
37. Tables complete?
38. Table units present?
39. Footnotes aligned?
40. Charts complete?
41. Legends aligned?
42. Axes correct?
43. Drawings correct revision?
44. Callouts aligned?
45. Dimensions unchanged?
46. Datum/symbols intact?
47. Equations intact?
48. Variables mapped?
49. Equation references correct?
50. Code protected?
51. Commands protected?
52. API paths protected?
53. JSON/XML keys protected?
54. Placeholders intact?
55. File paths intact?
56. UI labels match product?
57. Menu paths match target UI?
58. Screenshots current?
59. Links valid?
60. Software version current?
61. Chemical identifiers correct?
62. Device identifiers correct?
63. Sample IDs correct?
64. Statistical terms correct?
65. Hedging preserved?
66. Attribution preserved?
67. Methods sequence preserved?
68. Manufacturing part identity preserved?
69. Tools correct?
70. Lubricants/materials correct?
71. Inspection limits correct?
72. Acceptance criteria correct?
73. Source queries closed?
74. Authorized corrections recorded?
75. Translation complete?
76. Self-review complete?
77. Bilingual revision complete?
78. SME review complete if required?
79. Numeric QA passed?
80. Terminology QA passed?
81. Identifier QA passed?
82. Tag QA passed?
83. Build validation passed?
84. Untranslated-source scan passed?
85. Target grammar reviewed?
86. Controlled style reviewed?
87. Tables visually checked?
88. Figures visually checked?
89. Warnings visually checked?
90. Final PDF/app/build checked?
91. Correct target file selected?
92. Filename/version correct?
93. Approval recorded?
94. Public release status correct?
95. TM updated?
96. Termbase updated?
97. Obsolete segments deprecated?
98. Change propagation verified?
99. Incident path known?
100. Can the team explain why this target is technically safe to release?

The final checklist principle

Case 4: pressure range

Source:

“Supply pressure: 4–6 bar(g).”

Target must preserve:

range;
bar;
gauge-pressure meaning if “g” is defined that way in system.

Do not casually convert to absolute pressure.

Case 5: tolerance stack

Source drawing:

Ø20 H7.

This is technical notation, not ordinary prose. Translation may need a target-language explanation elsewhere but should preserve the controlled tolerance designation in the drawing.

Case 6: surface finish

Drawing uses standardized surface-texture symbol plus value.

Do not replace symbol with a translated adjective such as “smooth.”

Case 7: material specification

Source:

“AISI 316 stainless steel.”

The designation AISI 316 is controlled material identity. The descriptive material phrase may be localized, but the grade should remain.

Case 8: cable instruction

Source:

“Route the cable away from high-current conductors.”

Target should not simplify to “keep cable away from wires.” Technical category matters.

Case 9: electrical isolation

Source:

“Isolate the supply and verify absence of voltage.”

“Switch off” alone may not equal “isolate.” The target needs domain-appropriate safety terminology.

Case 10: fuse rating

Source:

“Use a 2 A time-delay fuse.”

Case 40: log message

Source log text includes machine-readable code E104.

Translate explanation; preserve E104.

Case 41: aviation identifier

IATA/ICAO code appears beside airport name.

Translate/localize airport name according to policy; preserve code.

Case 42: maritime identifier

IMO number and MMSI have different identity roles.

Do not interchange.

Case 43: vehicle identifier

VIN stays exact even if model description is translated.

Case 44: medical-device UDI

UDI-DI and production identifiers have different functions. Preserve machine-readable identity.

Case 45: chemical dangerous-goods number

UN number may identify transport hazard entry; chemical name can have different identifier systems. Do not conflate.

Case 46: patent identifier

Application, publication and priority numbers are distinct. Translate labels, preserve numbers.

Case 47: DOI/ISBN

Publication identifiers remain exact; titles may translate.

Case 48: technical drawing note

Source:

“BREAK SHARP EDGES 0.2–0.5.”

Target must preserve manufacturing instruction and range. Do not translate “break” as fracture.

Case 49: thread direction

“Left-hand thread.”

Target must not become “thread on left side.”

Case 50: surface treatment

“Anodize after machining.”

Sequence matters.

Practice and transfer

The technical system is learned by repeated classification.

For any sentence, identify:

human language;
controlled term;
identifier;
quantity;
unit;
logic;
procedure;
safety;
reference.

Then translate only the elements that are actually linguistic.

The technical audit after translation

Run two different audits.

Audit A: source-target technical integrity

Compare:

values;
units;
identifiers;
terms;
conditions;
sequence.

Audit B: target usability

Read target alone.

Can an engineer, technician, user or scientist follow it naturally?

A target can pass one audit and fail the other.

The technical translation team

Large/high-risk projects can include:

project manager;
technical translator;
reviser;
terminologist;
SME;
localization engineer;
DTP specialist;
QA reviewer;
release owner.

Small projects can combine roles. The responsibilities still exist.

What the client should provide

Correct source.

Revision status.

Termbase/glossary.

Previous approved translation.

Drawings/screenshots.

Product access where feasible.

SME contact.

Unit/conversion policy.

Safety requirements.

Deadline including review.

What the translator should provide

Accurate target.

Queries.

Terminology consistency.

Hard-detail care.

Self-review.

Disclosure of uncertainty.

What the reviser should provide

Independent source-target check.

Error severity.

Evidence-based correction.

What the SME should provide

Technical truth.

Concept clarification.

Validation of critical terms/process.

What the project manager should provide

Correct files.

Version control.

Workflow.

Review scheduling.

Release coordination.

Frequently asked questions about technical translation

What is technical translation?

Technical translation is translation of engineering, scientific, industrial, software, product or other specialist technical content in a way that preserves technical meaning, identity, quantities, procedures and applicable terminology.

What is the difference between technical translation and general translation?

Technical translation usually has more controlled terminology, structured data, identifiers, measurements, diagrams, standards and risk-sensitive procedures.

Does technical translation have to be literal?

No. Syntax and phrasing should be natural in the target. Technical invariants should remain unchanged.

What is the most important part of technical translation?

There is no single part, but concept accuracy plus hard-detail integrity—numbers, units, identifiers, logic and version—is fundamental.

Why is terminology so important?

Technical terms identify concepts inside systems. Inconsistent or incorrect terminology can create false distinctions or collapse real ones.

What is a termbase?

A structured terminology resource containing concepts, preferred terms, definitions and related metadata.

Is a glossary the same as a termbase?

A glossary can be a simple term list. A termbase usually stores richer structured concept information.

Can technical translators use dictionaries?

Yes, as research tools. Domain context, definitions and authoritative usage remain necessary.

Can technical translators use Google search?

Search can find evidence. Frequency alone is not authority.

Should technical translators convert units?

Only when project policy requires it. Conversion must preserve precision and technical meaning.

Should part numbers be translated?

Usually no; translate the label around them. Follow product policy.

Should software commands be translated?

Executable commands generally remain exact. Translate explanations.

Should API names be translated?

Code-level identifiers generally remain exact unless the API itself defines localized forms.

Should warnings be rewritten to sound friendly?

Not if that changes controlled safety meaning or hierarchy. Follow product safety system.

What is the difference between warning and caution?

It depends on the safety system and applicable standard. Do not treat signal words as arbitrary synonyms.

What is technical QA?

Checks designed to detect terminology, numeric, unit, identifier, tag, cross-reference, formatting and other technical defects.

Can automated QA prove a translation is correct?

No. It catches defined patterns. Human technical review remains necessary.

Why use subject-matter experts?

They can validate domain concepts and real system behavior beyond linguistic evidence.

Can an engineer translate technical documents?

An engineer may understand the domain deeply but still need professional target-language and translation competence. Roles can overlap when the person has both.

Can a translator work without engineering degree?

Yes, depending on domain and competence. Technical translation requires sufficient subject understanding, research and review architecture; high-risk projects may require specialist collaboration.

Is technical translation suitable for machine translation?

Many repetitive technical texts can benefit from MT or LLM assistance, especially with controlled terminology. High-risk output requires stronger review.

Why is MT dangerous for technical text?

It can produce fluent output while changing small but critical details such as negation, units, numbers or technical sense.

Should raw MT be used for safety manuals?

Unreviewed raw MT is generally inappropriate for high-consequence safety content. Use risk-based professional review.

What is post-editing?

Human revision of machine-generated translation according to defined quality requirements.

Why does source version matter?

A perfect target of an obsolete source is technically wrong for the current product.

What is configuration control?

Managing the relationship among approved product versions, components and documentation so the correct content describes the correct configuration.

What is a technical source defect?

An error or inconsistency already present in the source, such as conflicting values or incorrect identifiers.

Should a translator correct source defects?

Raise them and follow authorized correction process. Avoid silent engineering changes.

What if the termbase is wrong?

Raise a terminology query. Correct the authoritative resource if approved, then propagate.

What if an old TM match conflicts with new termbase?

Current authoritative terminology should generally win according to project policy.

What is an exact TM match?

A source segment identical to a stored segment. It still requires contextual/version validation.

What is a fuzzy match?

A similar prior source-target segment. Review the differences carefully.

Why are drawings hard to translate?

Meaning is tied to geometry, identifiers, dimensions, symbols and callouts, not just text.

Why are tables hard to translate?

Rows, columns, units and footnotes create relationships that can break during extraction or layout.

Why are formulas hard?

The formula may stay unchanged while variable definitions, symbols and references must remain aligned.

Why are software docs hard?

They combine language with code, UI, versioned behavior and executable identifiers.

Why are scientific papers hard?

They require discipline terminology, methods, statistical meaning, evidence status and claim strength.

What is the best technical translation workflow?

One that is source-controlled, terminology-aware, risk-based, reviewed, technically validated and linked to product change control.

How do you check numbers?

Use automated comparison where possible, then human verification of legitimate locale formatting/conversion.

How do you check units?

Compare source-target unit symbols and verify any authorized conversion.

How do you check identifiers?

Exact-string comparison.

How do you check procedures?

Verify action, object, condition, sequence and expected result.

How do you check warnings?

Verify hazard, consequence, avoidance, signal-word class and symbol/layout.

How do you check cross-references?

Validate that target figure/table/section numbers exist and point correctly after layout.

What is in-context technical review?

Checking the target against the actual product, drawing, UI, table, diagram or final rendered document.

What makes technical translation world-class?

Not vocabulary alone. It is the integration of language, terminology, domain knowledge, hard-detail control, tools, review, configuration and release discipline.

Current standards and professional reference layer

ISO 17100:2015 — Translation services — Requirements for translation services. This remains the published current edition; ISO lists a second edition work item under development.

ISO 704:2022 — Terminology work — Principles and methods. It establishes basic principles and methods for terminology work and explicitly applies across scientific, technological and industrial fields.

ISO 1087:2019 — Terminology work and terminology science — Vocabulary. This current confirmed standard establishes basic terminology-work vocabulary.

ISO 10209:2022 — Technical product documentation — Vocabulary. It defines terms relating to technical drawings, product definition and related documentation.

IEC/IEEE 82079-1:2019 — Preparation of information for use of products — Part 1. This remains the published general standard while Edition 3 is under development.

ISO 20607:2019 — Safety of machinery — Instruction handbook — General drafting principles. The published edition remains current while a replacement is expected.

ISO 3864-1:2011 — Safety colours and safety signs — Part 1. It remains current for design principles for safety signs and markings.

ISO 3864-2:2016 — Product safety labels.

ISO 3864-3:2024 — Graphical symbols for safety signs.

ISO 7010:2019 — Registered safety signs, with a new edition currently under development.

Continue through the Master Art of Translation architecture

Root: Master Art of Translation | The Complete System for Moving Meaning Between Languages.

Source analysis: How to Read a Source Text Before You Translate It.

Equivalence: How Equivalence Works When Languages Do Not Match One-to-One.

Context: The Context Stack.

Terminology: The Terminology System.

Translation Memory: The Translation Memory System.

Machine Translation: The Machine Translation System.

Human Translation: The Human Translation System.

Translation Quality: The Translation Quality System.

Localization: The Localization System.

Vocabulary: Vocabulary Learning Hub.

English mechanisms: How English Works V1.1.

Final synthesis

Technical translation is not successful because every source sentence has a fluent target sentence.

It is successful when the translated technical system remains the same system.

The same product.

The same component.

The same measurement.

The same limit.

The same requirement.

The same warning.

The same procedure.

The same software version.

The same drawing relationship.

The same configuration.

Language can change radically to achieve that stability.

A noun can become a clause.

A passive can become active.

A long sentence can become two.

A source term can become an established target-domain term that shares none of its visible morphology.

But the engineering relationships cannot drift invisibly.

That is why technical translation needs terminology, numbers, diagrams, software context, safety architecture, configuration management and release control in addition to bilingual skill.

The translator’s deepest professional question is not:

“What words should I use?”

It is:

“What technical reality does this source encode, and what must remain invariant so the target user receives the same reality in another language?”

When a translation team can answer that question from source intake through final release, technical translation becomes a controlled engineering communication process rather than a sequence of language substitutions.

Complete technical translation laboratory: a small pump-control document

The following fictional source package is designed to show how several technical layers interact. It is entirely original teaching material. The point is not to teach pump engineering. It is to demonstrate the translation method.

Source package metadata

Document:

PCU-240 Installation and Service Instructions.

Source revision:

Product:

Pump Control Unit PCU-240.

Applicable hardware:

PCU-240-2 and PCU-240-4.

Firmware:

4.2.1 or later supported 4.x release.

Target:

professional publication-ready translation.

Critical resources:

component termbase;
wiring drawing WD-240-C;
torque table T-12;
target UI glossary;
safety-label library.

Original source excerpt

WARNING — ELECTRIC SHOCK HAZARD

Disconnect and isolate the 230 V AC supply before removing the front cover. Verify absence of voltage at terminals L1 and N before touching internal components.

1. Mount the PCU-240 vertically using four M6 fasteners.

2. Tighten the mounting fasteners in a cross pattern to 8 ± 0.5 N·m.

3. Connect the protective conductor to terminal PE before connecting L1 and N.

4. For model PCU-240-4 only, connect the auxiliary pressure sensor to connector J4.

5. Restore power only after the front cover is installed.

At startup, the STATUS indicator flashes twice and then remains green. If the indicator remains red for more than 10 s, disconnect power and see Section 7.3, “Startup faults.”

Operating ambient temperature: −10 to 50 °C.

Maximum relative humidity: 90%, non-condensing.

Do not operate the unit above 2,000 m altitude unless the approved derating procedure has been applied.

First-pass technical inventory

Identifiers:

PCU-240;
PCU-240-2;
PCU-240-4;
L1;
N;
PE;
J4;
Section 7.3.

Quantities:

230 V AC;
four M6 fasteners;
8 ± 0.5 N·m;
two flashes;
10 s;
−10 to 50 °C;
90%;
2,000 m.

Sequence constraints:

isolate before removing cover;
verify absence before touching;
PE before L1/N;
cover before restoring power.

Model constraint:

J4 sensor applies only to PCU-240-4.

Warning:

electric shock.

Expected result:

STATUS flashes twice then green.

Troubleshooting condition:

red for more than 10 s.

What the translator may change freely

Sentence order within a paragraph where technical logic remains.

Article use.

Passive/active voice.

Target punctuation.

Natural target syntax.

What the translator should not change without authority

Product identity.

Terminal labels.

Sequence.

Torque.

Model applicability.

Startup behavior.

Operating limits.

Warning class.

Bad translation pattern 1: stylistic simplification

“Turn off power before opening the unit.”

Problems:

“disconnect and isolate” reduced to “turn off”;
230 V AC omitted;
front cover becomes generic unit;
verification at L1/N omitted.

The sentence is simple. It is technically incomplete.

Bad translation pattern 2: over-expansion

“To ensure complete electrical safety, fully disconnect the unit from all possible power sources and confirm with an approved voltmeter that absolutely no dangerous voltage remains anywhere inside the cabinet.”

Problems:

adds “all possible sources”;
adds specific instrument;
adds “anywhere”;
adds stronger claims not present in source.

A safety-minded translator can still invent.

Bad translation pattern 3: number drift

8 ± 0.5 N·m becomes 8.5 N·m.

Tolerance becomes one value.

Bad translation pattern 4: model scope drift

“Connect auxiliary sensor to J4.”

“For model PCU-240-4 only” disappears.

Other variant may not support that connection.

Bad translation pattern 5: expected result turned into instruction

“Flash the STATUS indicator twice.”

The source describes what the device does, not what the installer should do.

Bad translation pattern 6: “more than” becomes “at least”

Source:

red for more than 10 s.

Target:

red for at least 10 s.

Boundary at exactly 10 seconds changes.

Bad translation pattern 7: altitude condition removed

Target says:

maximum altitude 2,000 m.

Source permits operation above 2,000 m under approved derating procedure.

Target becomes stricter and removes an authorized configuration.

Good translation reasoning

Translate the warning using the product’s approved target safety terminology.

Preserve “disconnect and isolate” as distinct actions if target technical convention distinguishes them.

Preserve terminal labels exactly.

Use the approved target term for protective conductor.

Preserve model-only condition.

Preserve expected startup sequence.

Preserve exact thresholds and ranges.

Then read the target as an installer. Can the procedure be followed naturally?

Second-pass drawing check

Open WD-240-C.

Confirm:

L1/N/PE labels match drawing;
J4 is actually auxiliary sensor connector;
front cover terminology matches parts diagram;
fastener callout corresponds to M6.

This visual evidence can resolve wording that prose alone cannot.

Third-pass UI check

If Section 7.3 tells the user to open a target UI menu, use actual localized labels from firmware 4.2.1. Do not invent them from English.

Fourth-pass release check

Confirm target manual is marked Rev C and correct product variants.

A technically perfect Rev B translation should not be attached to Rev C product.

Change-propagation laboratory

Now imagine engineering issues Revision D with three changes.

Change 1:

mounting torque increases from 8 ± 0.5 N·m to 9 ± 0.5 N·m.

Change 2:

PCU-240-4 auxiliary sensor connector changes from J4 to J5.

Change 3:

startup fault threshold changes from more than 10 s to more than 15 s.

What should happen?

Source diff marks affected sentences.

Translation jobs are created for every active locale.

TM should not supply old exact target without recognizing source change.

Numeric QA should catch values if old target remains.

Drawing WD-240 must also update J4 → J5.

Troubleshooting section 7.3 may contain the same threshold and must be audited.

Training slides or service bulletins referring to J4 should be searched.

What should not happen?

Translator manually changes only the first occurrence.

Old PDF remains live.

TM stores both values without revision metadata and randomly suggests them later.

Termbase should not be used to store changing numeric values as if they were terminology.

Regression test created

After the incident/change, add checks:

PCU-240-4 connector = J5 for Rev D;
mounting torque = 9 ± 0.5 N·m;
startup threshold = >15 s.

Now product change improves translation governance.

Technical source-authoring laboratory

Weak source

“After it is connected, check it and then turn it on if okay.”

Problems:

What is “it”?
What connection?
What check?
What means okay?
What turns on?

Improved source

“After connecting the pressure sensor to J5, verify that the connector latch is fully engaged. Then restore power to the PCU-240.”

Benefits:

explicit component;
explicit condition;
explicit action;
stable term;
better translation.

Weak source noun string

“pump motor bearing temperature alarm reset procedure.”

Possible structures are ambiguous.

Improved source

“Procedure for resetting the bearing-temperature alarm on the pump motor.”

Translation becomes more reliable.

Weak source terminology

Source alternates:

front panel;
front cover;
access cover

for one component.

Improved source

Choose approved concept term.

Weak source unit handling

“Tighten to 10.”

Improved:

“Tighten to 10 N·m.”

Weak source condition

“If needed, replace it.”

Improved:

“Replace the O-ring if cuts, flattening or permanent deformation are visible.”

Technical quality and release scenarios

Scenario 1: low-risk internal engineering note

Possible workflow:

Scenario 9: emergency safety correction

Fast-track:

authoritative source correction;
translate delta;
independent critical check;
replace affected locale asset;
audit all versions.

Scenario 10: new product family

Build terminology and architecture before translation scale.

Technical translation governance

Organizations producing large technical estates can formalize:

source ownership;
term ownership;
translation approval;
SME review;
MT policy;
QA profile;
change control;
incident handling;
retirement.

Source owner

Owns source correctness and revision.

Terminology owner

Owns concept/term policy.

Translation owner

Owns target linguistic process.

Technical owner

Owns product truth.

Release owner

Owns final publication state.

RACI example

Term approval:

Terminologist responsible, engineering accountable, translator consulted.

Safety warning meaning:

Product safety accountable, translator responsible for target wording, legal/regulatory consulted where needed.

Numeric conversion:

Engineering/product policy accountable; translator executes approved rule.

Software UI label:

Product localization terminology owner accountable.

Final PDF release:

Documentation/release owner accountable.

Technical translation data portability

Keep reusable language assets portable where possible.

Translation memory.

Termbase.

Style guide.

QA rules.

Decision logs.

Do not lock institutional knowledge entirely inside one platform.

Document and product retirement

When product retires:

mark documentation obsolete;
preserve historical records if required;
stop old TM from active priority;
retain terminology status;
redirect users to current replacement where applicable.

Do not delete blindly

Service teams may still support installed legacy equipment.

Historical translation

Can remain useful if clearly labeled by product/revision.

Maintenance calendar

Monthly:

critical translation incidents.

Quarterly:

term changes, product updates, stale screenshots.

Annually:

legacy docs, standards status, tool versions, major QA rules.

Cadence depends on product change rate.

Standards status must be verified at publication time

Standards evolve. A technical article that says “current” should verify current status.

As of September 2026:

ISO 17100:2015 remains the published translation-services standard, with Edition 2 under development.

ISO 704:2022 is the published terminology-work principles and methods standard.

ISO 1087:2019 remains published and was confirmed in 2025.

ISO 10209:2022 is published for technical product documentation vocabulary.

IEC/IEEE 82079-1:2019 remains the published instructions-for-use standard while Edition 3 is under development.

ISO 20607:2019 remains published for machinery instruction handbooks while a replacement is expected.

ISO 3864-1:2011 and ISO 3864-2:2016 remain current published safety-sign/label standards.

ISO 3864-3:2024 is the current published edition for graphical symbols used in safety signs.

ISO 7010:2019 remains published while Edition 4 is under development.

This distinction between published and draft status is itself a technical-documentation discipline.

The professional principle

Technical translators do not need to become the engineer who designed every product.

They need enough technical understanding, research skill, terminology discipline and workflow support to recognize when language decisions can change technical meaning and when expert clarification is required.

The strongest technical translator is not the person who never asks a question.

It is the person who knows which questions must not be guessed.

Final operating manual

Before translation:

identify source/revision;
classify risk;
load terms;
inventory protected data.

During translation:

translate concepts;
preserve identifiers;
preserve quantities;
preserve logic;
raise queries.

After translation:

numeric QA;
unit QA;
term QA;
identifier QA;
bilingual revision;
SME review if needed.

Before release:

final format;
correct version;
cross-references;
warnings;
approval.

After release:

monitor corrections;
propagate changes;
maintain TM/termbase;
retire obsolete content.

Closing: translate the document without changing the machine

A useful way to think about technical translation is to imagine the target user standing in front of the same product as the source user.

The screws have not changed.

The voltage has not changed.

The software version has not changed.

The connector has not changed.

The chemical has not changed.

The statistical result has not changed.

The safety hazard has not changed.

Only the language has changed.

The target therefore succeeds when the target user can make the same technically correct decisions from the new language that the source user can make from the original.

That is why technical translation is simultaneously linguistic and engineering-adjacent.

It changes expression while preserving technical state.

It uses terminology without confusing terminology with all of language.

It uses tools without surrendering judgment.

It uses subject experts without surrendering target-language quality.

It uses automation for deterministic checks and human review for meaning.

It stays attached to version, configuration and product lifecycle.

And when something is unclear, it asks before it invents.

That is the Technical Translation System.

Advanced technical edge cases: where good systems are tested

Edge case 1: one source sentence describes two product variants

Source:

“On Model A, connect the sensor to J2; on Model B, connect it to J3.”

A translation memory system may split the sentence and lose variant relationship. Keep both model-condition mappings visible.

Edge case 2: one source value has two display units

Source:

“Torque: 20 N·m (177 lbf·in).”

If the project preserves dual units, verify that the conversion remains correct. Do not re-convert one value independently and create disagreement.

Edge case 3: source contains intentionally rounded user value

Engineering database says 19.8 N·m; manual says 20 N·m.

Translator should use approved manual source, not “correct” it from another data set without authority.

Edge case 4: same symbol has different meaning by field

“V” can mean voltage, volume or velocity depending document.

Symbol itself may remain unchanged while prose definition determines meaning.

Edge case 5: same acronym changes meaning inside one organization

“PM” can mean preventive maintenance in one manual and project manager in another.

Termbase should include domain/context, not one global expansion.

Edge case 6: source-language abbreviation is retained internationally

Target professionals use the source acronym more than a localized expansion.

Keep established professional usage; do not force translated initials.

Edge case 7: source specification contains legal normative reference

Standard number remains exact while standard title may have an official target-language title.

Use official title where appropriate rather than inventing.

Edge case 8: one standard has been superseded

Source intentionally references historical standard because legacy product was certified to it.

Do not silently replace with current standard. Historical applicability may be part of product configuration.

Edge case 9: draft standard in source

Source explicitly references draft status.

Target should preserve draft status, not present it as published authority.

Edge case 10: drawing note uses all capitals

Target script/case convention differs.

Preserve emphasis/function, not necessarily Latin capitalization.

Edge case 11: engineering shorthand

Source note:

“TYP 4 PLCS.”

Translator needs to know drawing convention: typical, four places.

A literal dictionary translation can fail badly.

Edge case 12: reference designator

R15, C22, U3 on a PCB are identifiers.

Do not translate letters.

Edge case 13: localized decimal comma inside CSV

Human-readable target locale uses comma decimal separator, but CSV uses comma delimiter.

Technical export format may require another representation. File format and locale can conflict.

Edge case 14: spreadsheet formula separator

Some spreadsheet locales use semicolons in formulas.

Do not manually localize formulas unless application/export rules require it.

Edge case 15: Excel autoformats part number as date

Identifier 3-12 becomes date.

Protect cell type.

Edge case 16: leading zero lost

Part code 00124 becomes 124.

Identifier integrity failure.

Edge case 17: scientific notation autoformatted

Code “1E10” treated as number.

Determine whether code or quantity.

Edge case 18: Unicode minus versus hyphen

A negative sign may be replaced with hyphen or disappear under font/encoding.

Visual QA plus numeric parsing.

Edge case 19: micro sign versus Greek mu

Different Unicode code points can appear visually similar.

Systems may normalize differently. Follow technical/data convention.

Edge case 20: decimal point in software syntax

User-facing number localizes, but configuration file requires period decimal.

Separate display from machine syntax.

Edge case 21: translated UI changes hotkey

Documentation references Alt+F.

Target UI hotkey may differ. Use actual localized product behavior.

Edge case 22: screenshot contains obsolete serial number

Localization should avoid exposing real/customer data and should use controlled examples.

Edge case 23: diagram text baked into image

OCR extracts labels but loses arrows.

Use original design source when possible.

Edge case 24: PDF reading order wrong

Text extraction interleaves columns.

Translator can produce fluent nonsense from scrambled source. Check visual PDF/source structure.

Edge case 25: scanned manual OCR changes “1” to “l”

Model number corrupts.

OCR is upstream technical risk.

Edge case 26: source contains handwritten annotation

Determine whether annotation is authoritative, in scope or obsolete.

Edge case 27: color carries technical status

“Green line” in chart may identify series. If target publication prints grayscale, language alone cannot preserve distinction.

Edge case 28: red/green status unsuitable for color-blind access

Localization cannot fix product design silently. Raise accessibility issue.

Edge case 29: same unit symbol attached to different physical quantity

“m” can mean metre or variable m. Context and formatting matter.

Edge case 30: “standard conditions” undefined

Translator should not invent temperature/pressure values. Query.

Edge case 31: process term is proprietary

Generic translation may remove trademark/proprietary distinction.

Edge case 32: trademark looks descriptive

Preserve according to brand policy.

Edge case 33: source uses local trade name for material

Target market recognizes standardized material designation instead.

Map concept, not marketing nickname, while preserving product identity if required.

Edge case 34: target region regulates a different label

Localization/regulatory adaptation may require additional approved text.

Translator should not invent regulatory compliance.

Edge case 35: customer asks translator to “improve” safety claim

Escalate. Marketing/style request should not override safety engineering.

Edge case 36: source table contains hidden formula cells

Translation software exports display values only.

Round-trip can break spreadsheet behavior.

Edge case 37: CAD text uses blocks

One translated block updates multiple callouts.

Verify each context.

Edge case 38: one glossary term conflicts with official standard

Determine project authority hierarchy. Client may intentionally use another terminology system.

Edge case 39: old user manual contains unsafe obsolete procedure

Do not use as authoritative reference solely because it is approved history.

Edge case 40: new source is less clear than old source

Prior translation can help detect regression, but current source owner must resolve.

Client and vendor governance for technical translation

Technical translation quality depends on information exchange between the organization that owns the product and the language provider.

Client should define scope

Which files?

Which versions?

Which locales?

Which review level?

Which unit/conversion policy?

Vendor should define capabilities

Language.

Domain.

Tools.

Security.

SME/revision capacity.

Onboarding

Provide sample package.

Termbase.

Style.

TM.

file instructions.

query path.

Pilot

Use representative content.

Include:

table;
drawing;
warning;
procedure;
technical terminology.

Vendor quality review

Measure:

critical errors;
term adherence;
query quality;
technical file handling;
correction responsiveness.

Do not compare unlike projects

A translator handling clear software help should not be compared directly with one handling poor scanned chemical manuals without context.

Corrective-action request

When quality fails, give:

examples;
severity;
root-cause questions;
required remediation.

Security

Technical vendors may receive confidential IP. Contract and tooling should reflect sensitivity.

Procurement questions

Can the provider handle our file formats?

Can it preserve tags/variables?

Does it support our CAT/TM/termbase?

Does it have domain translators?

How is revision performed?

How are SMEs involved?

How are critical errors handled?

How are data and files secured?

Can reusable assets be exported?

Can source changes be synchronized?

Technical translation metrics that actually help

Critical error rate

More meaningful than total typo count for high-risk content.

Number/unit defect rate

Shows hard-detail control.

Terminology defect rate

Can reveal termbase gaps.

Source-query rate

High rate may indicate poor source, not poor translator.

Source-defect rate

Useful feedback to technical writing.

TM leverage

Operational productivity metric, not quality proof.

Post-edit effort

Can help assess MT/TM usefulness, but low edit distance can also reflect weak review.

Release lag

Time between source and target release.

Regression rate

How often corrected error returns.

Build failure rate

Useful for software/resource localization.

Metric caution

Do not reward translators for fewer queries if it encourages guessing.

Do not reward reviewers for more edits if it encourages preference changes.

Do not reward speed while ignoring critical defects.

Metrics should support technical outcomes.

Technical translation knowledge base

A mature program can maintain:

terminology;
approved examples;
source-authoring rules;
QA profiles;
known failure modes;
standards status;
technical decision records.

Known failure mode entry

Issue:

µm sometimes exported as mm after OCR.

Control:

unit comparison + OCR spot check.

Known terminology issue

Source “housing” and “enclosure” inconsistent on legacy product.

Control:

use current component definition and drawing.

Source-author feedback loop

If translators repeatedly ask the same question, change the source system.

Repeated vague pronoun → source-authoring rule.

Repeated term inconsistency → termbase.

Repeated unit omission → template validation.

Repeated screenshot mismatch → automated capture/versioning.

Translation becomes an instrument for improving technical communication globally.

Regression library

Keep examples of previous critical defects.

Negation.

decimal.

range.

part number.

warning.

UI path.

drawing callout.

Run after:

tool change;
MT engine change;
workflow change;
major termbase update.

Translation-platform migration

Before switching platform, inventory:

TMs;
termbases;
QA rules;
segmentation;
file filters;
context;
users;
metadata.

Pilot:

technical manual + software resource + drawing/table sample.

Verify:

tags;
numbers;
matches;
context;
export.

File filters are technical translation infrastructure

A file filter decides what translators see.

Bad filter can:

hide text;
expose code;
split variables;
remove context.

Validate before scale.

XML

Use XPath/extraction rules carefully.

JSON

Translate values, protect keys where appropriate.

CSV

Delimiter/encoding/quoted fields.

Markdown

Protect code and URLs.

HTML

Translate visible text and relevant attributes while preserving markup.

CAD

Specialized workflow.

OCR as upstream risk

Scanned legacy manuals can be technically dangerous.

OCR errors:

O/0;
I/1/l;
5/S;
decimal;
minus;
superscript;
µ/m.

Use visual source checks for critical numeric/identifier content.

Structured authoring

DITA/XML or other structured systems can improve reuse and translation if:

topics are modular;
keys stable;
metadata accurate;
conditions controlled.

Conditional text

One source topic may generate multiple product variants.

Translation must preserve conditional markup.

Conref/reuse

Reused source can produce consistent target.

But one context-specific exception may require separate content.

Single sourcing

One technical content source can generate:

manual;
web help;
PDF;
training.

Translation strategy should preserve source relationships.

Channel differences

PDF may need page references.

Web may need links.

Training may need instructor cues.

Do not hard-code one channel’s wording into shared content if it breaks another.

Technical translation as access to engineering knowledge

Accurate multilingual technical content allows:

operators to work safely;
engineers to collaborate;
technicians to maintain equipment;
researchers to understand methods;
users to configure products;
regulators to inspect evidence.

This is why technical translation should be treated as operational infrastructure rather than cosmetic language work.

Final release verification

Open the delivered artifact.

Do not rely only on CAT status.

Check:

title and revision;
product model;
table of contents;
warnings;
numbers;
figures;
cross-references;
fonts;
links;
page breaks;
language metadata.

For software:

open the real build.

For drawings:

open final PDF/CAD export.

For web:

open live page.

Technical project closeout

Final target stored?

Source/target relationship recorded?

TM promoted?

Termbase updated?

Queries closed?

Obsolete assets archived?

Incidents logged?

Closeout creates future reliability.

Ten final principles

1. Translate concepts, not strings.

2. Preserve identifiers exactly.

3. Treat numbers and units as technical data.

4. Preserve conditions, negation and sequence.

5. Use drawings, tables and product context.

6. Ask when the source conflicts with itself.

7. Use automation for deterministic checks.

8. Use human/SME judgment for meaning.

9. Tie translation to product revision.

10. Propagate corrections to the system, not only the page.

A final technical reading test

Imagine two technically competent users standing before the same equipment.

One reads the source.

One reads the target.

Would they identify the same component?

Would they tighten it to the same torque?

Would they stop at the same warning?

Would they connect the same terminal?

Would they observe the same threshold?

Would they select the same software option?

Would they reach the same technically valid decision?

If the answer is yes, the translation is doing its job.

If the answer is no, fluency is irrelevant until the technical state is repaired.

Final technical release governance

A technical translation can be linguistically complete and still be unready for release. The last stage therefore asks not only whether the target is correct, but whether it is the correct target for the correct product, document revision, locale and delivery channel.

Release question 1: Is this the approved source baseline?

Confirm the source file, revision and product state one last time. A late engineering revision can arrive after linguistic review. If the source baseline changes, the translation status must change with it.

Release question 2: Are all high-risk deltas closed?

Check recent changes involving:

safety;
numbers;
units;
compatibility;
requirements;
identifiers;
software behavior.

These deserve explicit confirmation rather than assumption.

Release question 3: Did the final layout preserve technical relationships?

Review the delivered format, not only the bilingual editor.

Confirm:

warning and symbol stay together;
table headers stay over correct columns;
leader lines still point correctly;
equations render correctly;
cross-references resolve;
target text is not clipped.

Release question 4: Did late edits reopen any earlier checks?

A late “small” edit can change a number, condition or term.

If a late edit changes:

number → rerun numeric QA;
term → rerun terminology/consistency check;
warning → rerun safety review;
UI label → rerun product-context check;
drawing note → rerun visual check.

Quality gates should reopen only where affected, but they should reopen.

Release question 5: Are reusable assets safe?

Before promoting final targets:

remove rejected variants;
mark deprecated terminology;
store approved segments;
keep obsolete product versions separated.

Future translation quality depends on what today’s project feeds into memory.

Post-release maintenance

Technical translation continues after publication because products and standards evolve.

Monitor product changes

New hardware.

Firmware.

software.

component substitutions.

Each can invalidate translation.

Monitor terminology changes

Renamed feature or component should trigger search across active content.

Monitor standards changes

When a standard revision becomes published, determine whether existing documentation must change. Do not automatically update a legacy document whose product remains certified to the older standard.

Monitor user feedback

Technicians and users can reveal confusing target terminology or mismatched procedures. Investigate with source/product evidence.

Monitor incidents

A field incident involving a translated instruction deserves immediate language review if communication may have contributed.

Correction propagation map

When one target error is confirmed, ask where else the same information exists.

Live PDF.

Web help.

Mobile help.

Training slides.

Service bulletin.

Translation memory.

Termbase.

Drawing note.

Screenshot.

Support macro.

A correction is complete only when the defect cannot simply return from another system.

Example: wrong torque

The manual says 8 N·m instead of 9 N·m.

Search:

all locales;
assembly work instructions;
training material;
service content;
TM.

Confirm source engineering value.

Correct each applicable current asset.

Add regression check.

Example: wrong component term

Target calls a relief valve a check valve.

A useful internal release note can read:

Technical Translation System profile applied. Source Rev C confirmed. All critical technical queries closed. Terminology current. Number, unit, identifier and tag QA passed. Bilingual revision completed. Safety-critical sections reviewed by designated SME. Figures, tables and cross-references verified in final output. Correct locale/version package confirmed. Approved for release.

This statement does not claim perfection.

It records why release is justified.

The technical stop rule

Do not release when:

source revision is uncertain;
critical source contradiction is unresolved;
a safety value cannot be verified;
required SME review is incomplete;
target file does not match product version;
technical QA reveals unexplained value/identifier differences.

Stopping a release can be a professional success when the alternative is fluent technical misinformation.

The restart rule

Resume when:

authority resolves the conflict;
target is corrected;
affected checks rerun;
release evidence updated.

Where this node sits in the larger architecture

The Technical Translation System depends on the earlier spine.

Source Analysis establishes what the source actually says.

Equivalence defines what must remain stable across languages.

Context Stack supplies drawings, product state, screenshots and domain evidence.

Terminology System controls concept-to-term relationships.

Translation Memory System provides prior approved reuse.

Machine Translation System provides controlled automated generation where appropriate.

Human Translation System provides accountable professional judgment.

Translation Quality System supplies risk, error severity and release confidence.

Localization System handles target-locale behavior beyond the technical text.

This node combines those systems around engineering and scientific invariants.

The final technical translation doctrine

Do not translate a number as if it were a word.

Do not translate an identifier as if it were a phrase.

Do not translate a warning as if it were marketing copy.

Do not translate a requirement as if it were a suggestion.

Do not translate a drawing label without looking at the drawing.

Do not translate a software instruction without checking the product version.

Do not “correct” engineering facts without engineering authority.

Do not let old translation memory override current product truth.

Do not let fluent AI output hide unsupported technical invention.

Do not stop at language review when the final PDF, build, diagram or table can still break the meaning.

The job is complete when another competent user can act on the target and reach the same technically valid result that the source enables.

That is the standard by which the Technical Translation System should be judged.

Final verification margin: technical truth after language approval

The last technical translation risk often appears after the translator and reviser believe the language work is finished. The target can still change during layout, software integration, document generation, engineering revision or release packaging. Final verification therefore has one simple purpose: confirm that the approved meaning survived the path into the artifact the user will actually receive.

Verify the rendered warning

Open the final PDF, web page, label or application screen.

Check that the signal word, hazard statement, avoidance instruction and symbol remain together.

Check that text expansion has not pushed a condition onto another page or hidden it behind a fold.

Verify the rendered quantities

Search the final artifact for critical values.

Compare:

decimal;
minus sign;
range;
unit;
tolerance;
superscript.

Do not assume a value that was correct inside the CAT tool survived DTP or export.

Verify the final identifiers

Spot-check model numbers, part numbers, versions and drawing IDs against the source baseline. This is especially important when layout or OCR tools have touched the content.

Verify the live software path

If documentation tells users to select a menu or setting, test the actual target-language product. A perfectly translated old UI path is still a failed instruction.

Verify the final table and diagram relationships

Read one representative table row horizontally and vertically.

Check one drawing callout from label to physical component.

Check one chart legend against the displayed series.

These checks verify relationships that a text-only review cannot see.

Verify the release metadata

Document title.

Revision.

Product model.

Locale.

Publication date.

Version.

A target can be technically accurate but operationally unusable if its identity is unclear.

Verify late source changes

Ask whether engineering changed the source after the last translation handoff. If yes, confirm the delta reached this locale.

Do not rely only on memory. Use revision history or source-control evidence.

Why the final user is the ultimate technical context

Imagine the target user installing, operating, maintaining, measuring or troubleshooting the product.

They do not see the translator’s glossary.

They do not see the CAT tool.

They do not see the QA dashboard.

They see the released instructions, drawings, labels and screens.

That is why final in-context verification matters.

A technical translation system is successful only when all the invisible professional work produces a visible target that remains correct in use.

Final closeout rule

Close the project when:

the correct target is released;

the correct revision is traceable;

critical QA is complete;

reusable resources are updated;

known obsolete content is controlled;

and any material correction can be propagated reliably.

At that point the translation is not merely linguistically complete.

It is technically integrated.

One final question

Could a competent target-language user follow this document without accidentally changing the machine, software, scientific method, measured quantity or safety condition described by the source?

If yes, the Technical Translation System has preserved its most important promise.

If no, the work is not finished, regardless of how fluent the target sounds.

Final release traceability

Technical translation should end with a traceable relationship between source, target and product release. This final relationship is what allows a future engineer, translator or auditor to answer three practical questions: which source was translated, which target was released, and which product configuration the target describes.

Keep enough metadata to reconstruct that relationship. A simple record can contain the source document number and revision, target locale, target file version, translation/revision status, terminology version, publication date and release owner. High-risk systems may retain more formal evidence; ordinary technical documentation can use a lighter record. The principle is the same.

Traceability becomes especially valuable months later. A field technician may report that a target instruction differs from the current product. The team can determine whether the translation is stale, whether the source itself changed, whether the wrong locale file was deployed, or whether the target contains a true translation error. Without source-target-release identity, every investigation begins from guesswork.

The same record helps prevent inappropriate reuse. A sentence approved for Product Rev B can remain historically correct without becoming the preferred translation for Rev D. A technical translation memory can therefore preserve useful history while still letting current configuration control decide which evidence has authority.

Finally, traceability protects corrections. When a critical value changes, the team can identify the active target assets that depend on the old source rather than searching an uncontrolled publishing estate manually. That is the difference between fixing one document and repairing the multilingual technical system.

The final discipline is simple: every released technical translation should know where it came from, what it belongs to and how it will be changed when the underlying technical truth changes.

Final audit principle

A final technical translation audit should deliberately compare one representative item from every high-risk class before release: one identifier, one number, one unit, one requirement, one warning, one procedure, one table relationship, one drawing reference and one software or configuration reference. This small cross-section cannot replace the full QA already completed, but it can reveal a last-stage integration problem such as the wrong file version, a broken export or a stale resource.

The purpose of this final audit is not to reopen the entire translation. It is to verify that the different protection systems still agree in the released artifact. The termbase should match the document, the document should match the product, the quantities should match the source, and the revision metadata should match the release package.

When those relationships remain intact, technical translation has achieved more than fluent language. It has preserved a controlled technical state across languages and across the full path from source engineering content to the target user’s final document.

Master Art of Translation | The Technical Translation System — How Specifications, Terminology, Units, Drawings, Standards, Safety and Change Control Work Together

The 50-second technical translation route

What this article owns in the Master Art of Translation architecture

The hidden problem: technical language describes a controlled reality

Begin with the exact source package

Source freeze and change control

Source defect versus translation defect

The technical translation brief

The standards layer: current published authority versus drafts

Technical invariants: what must not drift

Identifiers

Quantities

Units

Logic

Sequence

Reference

Technical terminology is concept-first, not word-first

Concept identification

One term per concept is a policy, not a universal language law

Synonym risk

Deprecated terms

Definitions

Technical translation is a family of document systems

Audience and purpose control technical style

The repeatable technical translation method

Route outward when the narrow technical object already has an owner

Technical terminology governance: one concept can control an entire system

Build terminology from the product architecture

Term authority hierarchy

Terminology conflict

Concept drift across revisions

Abbreviations and acronyms

Do-not-translate terms

Identifiers: translate the label, preserve the identity

Model numbers

Part numbers

Serial numbers

Revision strings

Drawing numbers

Technical identity audit

Numbers, units and tolerances: language wrapped around measurement

Value plus unit is one meaning unit

Decimal separators

Thousands separators

Ranges

Minimum and maximum

Tolerances

Significant figures

Scientific notation

Unit symbols versus unit names

Unit conversion

Temperature

Pressure

Torque

Angles

Frequency

Prefixes

Equations, formulas and mathematical notation

Variable identity

Subscripts and superscripts

Operators

Equation references

Function names

Formula prose

Tables, drawings and diagrams: technical meaning has geometry

Tables

Charts

Technical drawings

Callouts

Leader lines

Drawing views

Exploded diagrams

Schematics

P&IDs and process diagrams

Flowcharts

Procedures: preserve action, order, condition and result

Imperatives

Conditional steps

Sequence

Prerequisites