Terminology Management for Technical Content

Why terminology management decides how a translation is judged

When an engineer at your Mexican distributor opens a translated service manual, they do not evaluate syntax. They look for the names of the things they handle every day. If a component is called one thing on page 12 and something else on page 340, or carries a word their technicians have never said out loud, the verdict forms in about ninety seconds and it is rarely revised afterward.

That reaction is not fussiness. Inconsistent naming has operational consequences. A spare part ordered under two designations ends up twice in the ERP. A safety function described with a word that does not appear on the machine's own labeling forces the operator to guess which control is meant. A datasheet that names a measurement one way while the test report names it another gives a certification body a reason to open a question. Style problems irritate; naming problems cost hours and money.

Terminology is also the part of quality a buyer can verify without speaking the language. Ask for the term list, hand it to a bilingual engineer in the target market, and within an hour you know whether the supplier understands your product. That is why term decisions sit early in the way we run quality control, well before anyone proofreads a sentence.

What a termbase is

A termbase is a concept-oriented database. That phrase carries the whole idea: the unit of storage is a thing in the world, not a word. One entry equals one concept, and inside that entry sit the designations used for it in each language, along with everything a translator needs to use them correctly.

The difference shows as soon as a concept has several names. A component known to engineering as a retaining collar, to the field as a lock ring, and to the parts catalog by its number alone is one concept with three English designations, one approved and two recorded as variants. In a two-column list, the same situation produces three unrelated rows and no way to tell which one wins. Concept orientation handles the reverse case just as cleanly: one English word naming two different objects becomes two entries, kept apart by their definitions.

These are the fields that earn their place in a technical termbase. Anything beyond them tends to be filled in once and never looked at again.

Field	What goes in it	Why it matters
Definition	One or two sentences describing the concept, in the source language	Lets a translator tell two similar entries apart without seeing the machine
Context sentence	A real sentence taken from your documentation	Shows grammatical behavior: countable or not, noun or verb, part of a fixed phrase
Approved designation	The single term to use, per language and per regional variant	Removes the daily coin flip between two defensible synonyms
Forbidden variants	Terms explicitly rejected, each with a one-line reason	The most useful field in the record, and the one most often left empty
Status	Approved, pending validation, or rejected	Tells the translator whether to apply the entry or raise a query
Source of authority	Who decided: a standard, a nameplate, an internal spec, a named reviewer	Ends the argument when somebody challenges the term two years later
Subject field and product line	Where the entry applies and where it does not	Stops a hydraulics term from being imposed on the electrical manual
Image or figure reference	A callout number or a cropped drawing	Settles ambiguity faster than any definition, especially on small parts

Building the first list: extraction and triage

Term extraction starts from your own content, never from a generic dictionary. The tool passes over the source corpus and proposes candidates by frequency and by pattern, favoring multi-word noun phrases, which is where technical terminology mostly lives. A 40,000-word manual typically yields eight hundred to a thousand raw candidates. Nobody validates a thousand terms, so the list gets cut before it ever reaches you.

Triage is done by a linguist who knows the domain, and it removes three categories. Ordinary language that happens to be frequent goes out. Strings that are simply do-not-translate items, model codes and trade names, move to a separate DNT list instead of becoming term entries. Near-duplicates get merged into one concept with variants recorded. What survives on that manual is usually 150 to 250 entries, and those are the ones that carry real risk if somebody guesses at them.

If you already have material, say so at kickoff. An approved parts nomenclature, a style guide, an old spreadsheet, previously translated documents your market team liked, a labeled assembly drawing: all of it shortens the work and, more importantly, keeps new documentation aligned with what your customers already have on the shelf.

The validation loop with your reviewer

Extraction is the easy half. Value appears when somebody on your side, in the target market, signs off on the target terms. Here is how that loop runs on our projects, and what makes it succeed or stall.

1. Name one arbitrator per language. Usually an application engineer, a service manager or a technical trainer at the local subsidiary or distributor. One person with authority beats a committee of five, every time. When sales and engineering disagree, engineering decides anything that appears inside a procedure, and sales may decide catalog headings.
2. Send a short, sortable list. Source term, proposed target, definition, context sentence, and one column for the reviewer to type into. Nothing else. Two hundred entries reviewed at working speed takes a technical reader roughly two to three hours.
3. Set a deadline and a default. Silence is a decision too. Entries not challenged by the deadline are marked approved, and we state that in writing when the list goes out. Without the rule, programs wait weeks on a file nobody owns.
4. Record the reasoning, not only the verdict. When a reviewer rejects a term, we ask for a sentence explaining why. That sentence lands in the forbidden variants field and prevents the same debate on the next product line.
5. Lock entries before the bulk translation starts. Approved terms are pushed into the translation environment, where they appear automatically as the linguist works and are checked mechanically before delivery. A term list living in an email attachment does nothing.
6. Treat late changes as amendments. A term that changes after translation has begun is logged, applied across the files in progress, and flagged against anything already delivered so the next revision stays coherent.

Termbase, or the spreadsheet someone emailed you

Most companies begin with an Excel glossary, and that is a sensible way to start. It stops being enough at a predictable moment, usually the third language or the second product line.

Question	Excel glossary	Termbase
Structure	Rows pairing a source word with a target word	Entries built around a concept, with any number of languages and variants
During translation	Consulted by hand, when the translator thinks to	Surfaces in the editor on the exact segment where the term occurs
Before delivery	No automated verification possible	A check flags every segment that ignores an approved designation
Rejected wording	Rarely written down anywhere	Stored with its reason, inside the same entry
Adding a language	Another column, wider and less readable each time	Another designation inside the entry that already exists
Traceability	Whoever saved the file last	Date, author and authority recorded per entry

A spreadsheet is not thrown away when you move up. It gets imported, deduplicated and enriched, which is normally the first task on a new terminology program and takes a day or two for a few hundred rows.

Five terms that cause real trouble

Examples argue better than principles. Each of these has produced a genuine query on technical projects.

• Valve, into French. Three candidates, three different objects. A vanne isolates flow in a pipeline, a soupape is a pressure or engine valve, a robinet is a manually operated tap. English covers all three with one word. Without a validated entry the translator picks by instinct, and an instinct that goes wrong on a P&ID legend propagates into every operating procedure referencing it.
• Anlage, from German. Depending on context it is a plant, a system, an installation, a unit, or an attachment to a letter. Automation documentation uses it constantly, sometimes in two senses within one chapter. This is where a query goes to a specialist rather than to guesswork: Anke Hoffmann, our German technical translator, keeps one entry per sense with a plant hierarchy diagram attached to each.
• Cheville, in French mechanical text. It can be an anchor set into concrete, a dowel pin, or a peg, and each maps to a different English target and a different part family. Reverse the direction and the trap reappears: an English source saying "anchor" gives no clue whether the concrete fixing or the tie-down point is meant.
• Torque, into Spanish. Regional practice diverges. Mexican industrial usage accepts torque and par de apriete for tightening torque, while Iberian technical writing prefers par and treats torque as an anglicism. The physical quantity is identical; the wrong pick tells the reader the manual was written for somebody else. Variant-level entries settle it once instead of once per document.
• Screw and bolt, across most languages. English separates them by whether the fastener mates with a nut or with a tapped hole. Several languages blur that line, and a parts list translated without the distinction produces ordering errors that surface only at assembly. This is exactly the kind of entry that belongs in a translated datasheet before it belongs anywhere else.

Maintenance: keeping terminology management alive

Terminology programs almost never fail at launch. They fail in year two, when the person who built the list moves on and nobody inherits the role. Four habits prevent that.

• A named owner on your side. One person who receives new candidates and either arbitrates or routes them onward. The role costs a few hours per quarter.
• A quarterly pass instead of a rolling free-for-all. Candidates raised on recent projects are batched and reviewed together, which is faster for the reviewer and produces more consistent decisions than answering queries one by one.
• Deprecate rather than delete. When a term is superseded, mark the old one forbidden and record the date it changed. Documents in the field still carry it, and support staff need to know what it maps to now.
• Feed it from live projects. Every query raised during translation ends as either an entry or a documented rejection. Queries that vanish into an email thread are the leak that eventually empties the system.

The termbase is your property, exportable in TBX or CSV whenever you ask for it. It is a different asset from the sentence-level database described in our explainer on translation memory: one governs wording already approved in full sentences, the other governs individual terms inside sentences nobody has written yet. Running both together is what our terminology management service is built around, and either one alone leaves a gap the other would have covered.

What skipping it costs

The bill for absent terminology arrives late, which is why the discipline is undersold. A pattern we see repeatedly: a manufacturer translates a 200-page manual into three languages with no validated term list, saving the two or three days the validation loop would have taken. The distributor in one market rejects the file. Their engineer marks up forty pages, most of the corrections being the same dozen components renamed. Those changes have to be applied across three deliverables, reflowed in the layout, and pushed back into the stored translations so they hold on the next revision. The rework consumes more engineering attention than the original review would have, and it happens under deadline pressure rather than at the calm start of a project.

Then come the effects nobody attributes to translation at all. Support tickets from technicians describing a part by a name that appears nowhere in the manual. Warranty claims documented with inconsistent component names, which slows failure analysis. Training material that contradicts the labeling on the machine itself. None of that shows up on a translation invoice, and all of it traces back to a decision that two hours of review were not worth scheduling.