Post 8 in our series on localization skills for modern technical communicators
Does your organization have terminology management, or does it have a glossary?
The answer matters more than it might seem. A glossary is a document. It lives somewhere: a shared drive, a wiki page, a PDF attached to the style guide. It lists words with definitions. People consult it when they remember it exists. It grows by accumulation. It’s maintained by whoever has time, which usually means it’s not maintained at all. And the worst is when there are multiple glossaries floating around from lack of any governance.
Terminology management is something different. It’s a governed system: a structured database of concepts, their approved labels, their forbidden variants, their definitions, and their relationships to each other. It connects to the tools your translators use, informs the systems your content passes through, and ensures that the right word is used in the right way, consistently, across every document, every language, and every version of your product.
This post is about closing that gap. Here’s my poem:
A termbase is governed, it works, and it must.
— CJ Walker
The difference is discipline, structure, and care:
the technical communicator’s craft, made to share.
What terminology management actually is
The formal definition is straightforward: terminology management is the systematic practice of identifying, defining, and governing the terms used in a specific domain or organization. The operative word is “systematic.” It’s not ad hoc. It’s not managed by one person who happens to care about words. It’s a process with defined roles, tools, formats, and governance, embedded in the content production workflow.
At its center is the termbase: a structured database of terminology records. Each record documents a single concept along with its preferred term, any permitted synonyms, any forbidden variants, a precise definition, use notes, and, in a multilingual context, the approved equivalent in every target language.
A concept is the underlying idea, independent of any particular word for it. The word is the label. “Start,” “initiate,” and “launch” might all be labels for the same concept in your product context. Terminology management decides which label is authoritative, which are acceptable, and which are forbidden, and records those decisions in a form that both human writers and translation systems can act on.
The anatomy of a terminology record
Understanding what a terminology record contains is the practical starting point for understanding what a termbase does. A well-formed terminology record typically contains the following fields.
Concept identifier
A unique ID for the concept, independent of any label. The concept has its own identity even if the preferred label changes.
Preferred term
The approved label for this concept in this language. There should be exactly one per language. This is what everyone, writers, translators, editors, and systems, should use.
Admitted term
A synonym or variant that is acceptable but not preferred. A translator may use it where register or context demands, but the preferred term takes precedence in technical writing.
Forbidden term
A label that must not be used. If “initiate” is the preferred term and “kick off” is forbidden, that rule needs to be machine-enforceable, not buried in a style guide note.
Definition
A precise, context-specific definition of the concept as it applies in your domain. Not a dictionary definition: a definition that tells a translator or a new team member exactly what this concept means in this product, in this context.
Context sentence
An example of the preferred term used correctly in a sentence, drawn from real content where possible.
Subject field
The domain or product area the term belongs to. Essential for managing a large termbase across multiple product lines.
Source and date
Who approved this record and when. Governance requires provenance.
Cross-references
Links to related concepts, broader concepts, or narrower concepts. This is where the termbase begins to behave like a knowledge structure rather than a list.
In a multilingual termbase, each of these fields has a language-specific version for every target language in the organization’s portfolio. The concept identifier is language-neutral: it links all the language-specific records for the same underlying idea.
Why it matters for localization: the cost of getting it wrong
The quality of your source content determines the quality, speed, and cost of everything downstream. Terminology management is where that principle is most directly tested.
Consider what happens without it.
A technical communicator writes “press the Start button” in one procedure and “click Initiate” in another. Both refer to the same action on the same UI element. The translation memory stores two different translation units. Translators in eight languages make independent decisions about which word to use for each variant. Six months later, the product has eight sets of documentation where the same button has a different name in every language. Support tickets arrive from users who can’t find the button their documentation describes.
Now consider what happens with a functioning termbase.
The preferred term for the button label is defined as “Start” in English, with “Initiate” marked as forbidden. That rule is enforced in the authoring environment, so the second version of the procedure is flagged before it leaves the technical communicator’s desk. Translators in all eight languages work from a single approved equivalent, provided in the termbase and surfaced automatically in their CAT tool. The translation memory stores one translation unit per concept, not two. The localization is consistent, the cost is lower, and the user finds the button.
The difference between these two scenarios isn’t the intelligence of the writers or translators. It’s the presence or absence of a governed system.
The technical communicator as terminology owner
This is the career-framing argument at the heart of this post, and it’s one that the localization industry has been making for years while the technical communication profession has sometimes been slow to hear it: the technical communicator is the natural owner of terminology.
Not the marketing team, who tend to favor the evocative over the precise. Not the engineering team, who tend to use shorthand that makes sense internally but fails users. Not the localization team, who receive terminology decisions made upstream and have to work with whatever arrives.
The technical communicator sits at the point where product knowledge meets user language. That’s exactly where terminology decisions need to be made: by someone who understands both what the product does and how the user needs to talk about it. The technical communicator who steps into the role of terminology owner isn’t taking on extra work at the margins. You’re formalizing something you already do instinctively, and making it systematic, visible, and defensible.
The terminology owner role typically involves:
- Defining and maintaining the termbase, including adding new concepts, retiring obsolete ones, and reviewing admitted and forbidden designations
- Coordinating with subject matter experts to ensure definitions are technically accurate
- Coordinating with the localization team to ensure multilingual equivalents are current and approved
- Enforcing terminology standards in the review process, flagging forbidden terms before content goes to translation
- Auditing terminology consistency across the content base, particularly on update cycles
This is a governance role as much as a writing role, and it carries direct, measurable impact on localization cost and quality.
The standards layer: ISO 30042 and TBX
Terminology management is a discipline with formal standards, and knowing they exist, even at a high level, positions you as someone who understands the field professionally.
ISO 30042
ISO 30042 is the international standard for terminology management systems. It defines the data model and data categories that a termbase should support: the concept-level structure, the term-level fields, the language-specific records, and the administrative metadata. When a tool claims to be ISO 30042 compliant, it means the termbase it manages follows this structure.
TBX (TermBase eXchange)
TBX is the open XML standard for exporting and importing terminology data between systems. It allows a termbase created in one tool to be shared with translators working in a different CAT tool, integrated into a translation management system, or archived independently of any particular platform. TBX is to termbases what XLIFF is to translation files: the lingua franca that lets different tools talk to each other.
You don’t need to write TBX by hand. Most terminology management tools export it automatically. But knowing what TBX is matters for two reasons. First, it tells you that terminology data is portable: your termbase isn’t locked into any single tool. Second, it gives you the vocabulary to have an informed conversation with a localization engineer or TMS administrator about how your terminology integrates into the broader pipeline.
Real-world scenario
A mid-size software company had been localizing its product documentation into six languages for three years. Translation costs were rising with each release despite the word count staying roughly constant. A localization audit revealed the cause: TM leverage was falling because the same concepts were being expressed with different labels across different sections of the documentation, written by different technical communicators over successive releases.
The audit identified 47 concept areas where two or more labels were in active use for the same concept. In some cases, three or four variants existed across the content base. Each variant was being stored as a separate translation unit in the TM. Each generated its own translation cost. And in four of the six target languages, translators had made different choices for different variants, meaning the inconsistency in the source was being compounded in every translated version.
The fix wasn’t a rewrite. It was a termbase. A senior technical communicator led a three-month project to define approved terms for the 47 concept areas, document forbidden variants, and create translation-equivalent records in all six languages in consultation with the localization team. The termbase was integrated into the CAT tool workflow so translators were offered approved equivalents automatically.
On the next release cycle, TM leverage increased substantially and translation costs dropped accordingly. The technical communicator who led the project presented the results to the product leadership team as a measurable return on a modest investment. Six months later, she was appointed to a newly created Terminology and Localization Quality role.
Common pitfalls and how to avoid them
| Pitfall | What goes wrong | How to avoid it |
|---|---|---|
| Confusing a glossary with a termbase | The organization believes it has terminology management when it has a list of definitions with no governance, no forbidden terms, and no multilingual records | Audit what you actually have: does it have concept identifiers? Forbidden terms? Multilingual equivalents? If not, you have a glossary |
| Defining terms rather than concepts | The termbase records words, not the underlying ideas, leading to duplicate records for the same concept with different labels | Start with the concept, assign the preferred label second. Ask: what is the thing we are talking about, before asking: what do we call it |
| No forbidden terms | Writers and translators use whatever label feels natural because there is no explicit prohibition | Every preferred term should have at least one forbidden term if synonyms exist in active use. Prohibition needs to be explicit to be enforceable |
| Definitions that don’t travel | Definitions written for a native English speaker that collapse on translation because they rely on connotation, metaphor, or cultural reference | Write definitions in plain, context-specific language. Test them by asking: would a translator who has never seen this product know exactly what this concept means |
| No governance process | The termbase grows in an uncontrolled way, accumulates inconsistencies, and gradually loses the trust of the people who should be using it | Define who can propose new records, who approves them, and how often the termbase is reviewed. Assign a named steward |
| Termbase disconnected from the workflow | The termbase exists but writers and translators never see it because it’s not integrated into the CAT tool | Ensure the termbase is exported in TBX format and loaded into the TMS or CAT tool so suggestions surface automatically during translation |
Career opportunities
Technical communicators who move into terminology management are stepping into a role with direct, measurable impact on localization cost, and finance teams respond to that argument when it’s framed in their terms.
Terminology owner
The foundational role. Often informal at first: a technical communicator who takes ownership of the termbase alongside their core writing responsibilities. In organizations with active localization programs, this role increasingly carries formal recognition and may be written into the job description.
Terminology manager
A dedicated role in larger organizations or language service providers. Responsible for the full lifecycle of the termbase: design, population, governance, multilingual coordination, and tool integration. Sits at the intersection of technical writing, localization, and information architecture.
Localization quality lead
A broader role that includes terminology governance alongside TM management, style guide enforcement, and translation quality review. Requires the full picture of the localization pipeline that this strand has been building post by post.
Content governance specialist
Organizations with large content operations increasingly need specialists who govern not just terminology but the full content infrastructure: style, structure, vocabulary, and metadata. Terminology management is a strong entry point into this broader governance domain.
A light learning path
Terminology management is a skill that rewards early, practical engagement. You don’t need an enterprise termbase to start developing it. You need a document you own, a handful of concepts that cause confusion, and the discipline to think about them differently.
Weeks 1 to 2: audit one document for terminology consistency
Choose a document you maintain and identify every instance where the same concept appears with more than one label. List the variants. Decide which one should be preferred and why. Note which should be forbidden. This is terminology analysis in its most direct form, and it will immediately sharpen how you read and write.
Weeks 3 to 4: write five terminology records
Take the five most problematic concept areas from your audit and write a full terminology record for each: concept identifier, preferred term, admitted terms if any, forbidden terms, definition, and a context sentence. Use the field structure described in this post. A structured spreadsheet is perfectly fine for a pilot.
Month 2: explore a terminology management tool
MultiTerm (part of SDL Trados), memoQ’s term module, and Phrase Term Manager are the most widely used tools in the industry. Most offer trial access or free tiers. Load your five records and explore how the tool structures and displays terminology data. Look at the TBX export to see what the data looks like in the interchange format.
Month 3 onward: keep reading the Firehead blog!
Termbase design, tooling, and workflow, including how to integrate a termbase into a CAT tool and TMS pipeline, are up next. And then the business case and organizational rollout: the strategic layer that determines whether a terminology initiative takes hold or quietly stalls.
Your next career move
Terminology management is one of the most undervalued competencies in technical communication, and one of the most directly impactful on the localization pipeline. The organizations that do it well spend less on translation, produce more consistent content, and release faster. The technical communicators who lead that work aren’t support staff for the localization process. They’re architects of it.
Terminology management is the layer that governs the vocabulary that every other layer depends on.
Browse our full course catalogue at the Firehead Training Academy to find the courses most relevant to your current stage.
Subscribe to Ignite!, our newsletter, for industry news, skills learnings, and new course announcements.
Firehead. Visionaries of potential.
