Post 9 in our series on localization skills for modern technical communicators
Your translation vendor sends you a quality report. The same product feature appears under six different labels across your documentation. The translators resolved the inconsistency independently, producing six different translations. The cost is more than the retranslation bill: it’s the next release, and all the ones after that, where the same problem compounds unless something upstream changes.
You already know what needs to happen. What you may not yet know is how to build a termbase that actually works: one that writers consult, translators trust, and your governance structure keeps current after the launch enthusiasm fades.
That’s what this post covers: design decisions that determine whether a termbase earns trust or loses it, the tooling landscape from enterprise to starting-out, how TBX connects your terminology to the broader translation workflow, and the governance habits that turn a one-time build into a living system.
Here’s my poem for this one, on the subject of building something that lasts (I had to go a little deep):
The fields are defined; the concepts are named.
— CJ Walker
The tool is connected; the workflow is framed.
A termbase isn’t built in a day or a week:
it’s tended, not finished, by those who would seek.
Designing a termbase that works
Before you open a tool, you need a design. The most common mistake in termbase development isn’t a bad tool choice or a poorly formatted TBX export. It’s starting with too much scope and too little structure, which produces a database that grows quickly, loses coherence, and eventually stops being trusted by the people who rely on it.
The design stage answers three questions: what goes in, how it’s structured, and what counts as a complete record.
Scope: start smaller than you think you should
The instinct when building a termbase is to capture everything. Resist it. A termbase that attempts to govern 2,000 terms from day one will have 2,000 records of uneven quality, inconsistent definitions, and disputed forbidden terms.
A termbase that starts with 50 carefully chosen, fully governed records from the highest-traffic product area will earn the trust of the writers and translators who use it, and that trust is what makes it expandable.
Choose your starting scope by asking: where does terminology inconsistency cause the most visible pain? That’s usually the product area with the highest translation volume, the most active support ticket stream, or the most recent localization quality complaint. Start there, prove the value, and build outward.
Fields: which ones to include
A full terminology record can hold a lot of fields: concept identifier, definition, context sentence, subject field, administrative metadata, multilingual equivalents, and more. Not every organization needs all of them from day one. A working minimum for a new termbase is: concept identifier, preferred term, forbidden terms, definition, and context sentence. That’s enough to enforce consistency in authoring and give translators the guidance they need.
- Add multilingual equivalents as soon as you have a localization program.
- Add subject field tags when your termbase covers more than one product area.
- Add administrative metadata (who approved the record and when) when more than one person is contributing to the termbase and governance becomes a team responsibility.
The principle is straightforward: include every field you’ll actually use and maintain. A field that’s populated for twenty percent of records and empty for the rest creates the impression of incompleteness without delivering any governance value.
The concept-first discipline in practice
The concept-first principle is straightforward: start with the underlying idea, then assign the preferred label. In practice, this means resisting the temptation to build your termbase around your existing word choices. Instead, ask: what is this thing? What does it do? How is it distinct from related concepts? Then decide what to call it.
This discipline catches a category of problem that purely label-driven termbases miss: the case where two different concepts share a label in the source content, or where one concept has accumulated so many labels that none of them feels authoritative. Getting to the concept first forces the clarity that makes the label decision defensible.
Tooling: choosing the right fit
The terminology management tool market covers a wide range, from enterprise platforms with deep CAT tool integration to lightweight options that work well for smaller teams or early-stage programs. The right choice depends on your translation volume, your existing toolchain, and whether your termbase needs to function across a team or primarily as a personal governance resource.
Enterprise options
MultiTerm, part of the SDL Trados ecosystem, is the most widely deployed enterprise terminology management tool. It integrates directly with Trados Studio and with most major TMS platforms. If your organization already runs Trados for translation, MultiTerm is the natural choice: the integration is tight, TBX export is straightforward, and translators working in Studio see term suggestions automatically as they work.
memoQ’s term base module follows the same logic within the memoQ ecosystem. If your translators work in memoQ, the termbase that surfaces in memoQ is the termbase they’ll actually use.
Phrase (formerly Memsource) includes terminology management as part of its TMS platform. For organizations that have centralized their translation workflow in Phrase, the integrated term management avoids the complexity of connecting a separate tool to an existing pipeline.
Mid-market and independent options
TermWeb and LogiTerm are independent terminology management platforms that integrate with multiple CAT tools via TBX, rather than being tied to a single ecosystem. They’re worth considering if your organization works with multiple translation providers or if your translators use different tools across projects.
Acrolinx sits at the intersection of content quality and terminology enforcement, checking source content against terminology rules before it reaches translation. If your primary pain point is writers using forbidden terms in source content rather than translator consistency, Acrolinx addresses the problem earlier in the pipeline, which is almost always less costly.
Starting out
If you’re building a termbase for the first time and don’t yet have organizational buy-in for a dedicated tool, start with a well-structured spreadsheet or a free trial of an enterprise tool like MultiTerm or memoQ. A spreadsheet won’t integrate with CAT tools, but it will force you to think in records and develop your definition-writing skills. A free trial gives you real tool experience without organizational commitment, and the TBX file you export can follow you into whatever platform your organization eventually adopts.
TBX: the format that connects your termbase to the world
TBX (TermBase eXchange) is the open XML standard for sharing terminology data between systems. Understanding it at a working level matters more than it might seem, because TBX is what makes your termbase portable, tool-independent, and genuinely interoperable with the broader translation workflow.
When you export your termbase to TBX and load it into a CAT tool or TMS, the translator sees your preferred terms, your forbidden terms, and your definitions surfaced automatically as they work. That surface is only as good as the TBX export underlying it.
A TBX file is structured around the same concept-first logic your termbase design follows.
Each concept gets a “termEntry” element.
Within that, each language gets a “langSet.”
Within each language set, each term variant (preferred, admitted, forbidden) gets its own element with the appropriate administrative status.
Definitions, context sentences, and subject field tags attach at the right level in the hierarchy.
You won’t write TBX by hand, and you don’t need to. But knowing the structure helps you understand why certain termbase fields matter for tool integration, and why a definition that lives only in a notes field may not surface correctly in a translator’s CAT environment. When evaluating a terminology management tool, always test its TBX export against the CAT tool or TMS your translators use. Compatibility isn’t universal, and a trial import before you commit can save significant pain later.
Integrating your termbase into the translation workflow
A termbase that isn’t connected to the translation workflow is a reference document, not a governance system. The integration step is where the termbase moves from something people consult to something that actively shapes what gets translated and how.
The integration has two layers: the authoring layer and the translation layer.
At the authoring layer, the termbase enforces terminology decisions before content reaches translation. This can be as simple as a style checker that flags forbidden terms in the source content, or as sophisticated as a full content quality platform like Acrolinx that validates against terminology rules in real time. The earlier a forbidden term is caught, the less costly and less disruptive the fix.
At the translation layer, the termbase surfaces approved equivalents to translators as they work. In a CAT tool, this typically appears as a term match panel alongside the translation memory segment: the translator sees that the source contains a term in the termbase and is offered the approved target-language equivalent.
Whether translators are required to accept the suggestion or free to override it is a governance decision your organization needs to make explicitly, but the suggestions must surface for the governance to function.
The TMS sits above both layers, managing the flow of content and terminology data between them. In a well-integrated pipeline, the termbase is loaded into the TMS, distributed to translators’ CAT tools as part of project setup, and updated centrally so everyone is always working from the current approved version.
From static database to living system: ongoing governance
The most dangerous moment in a termbase’s life isn’t the launch – it’s the six months later, when the initial energy has dissipated, the review backlog has grown, and nobody has formally taken responsibility for keeping the records current.
A living termbase requires three governance commitments:
- A named steward
One person who is accountable for the overall health of the termbase, approves new records, and is the first point of contact when terminology disputes arise. Without a named steward, the termbase is everyone’s responsibility and nobody’s job. - A review cadence
Terminology records go stale. Products evolve, features get renamed, and forbidden terms get resurrected by new team members who weren’t part of the original governance process. A quarterly review of the highest-traffic records, plus a release-cycle review triggered by significant product updates, keeps the termbase aligned with the product it serves. - A term request process
Writers, translators, and subject matter experts will encounter concepts not yet in the termbase, and they need a clear, lightweight channel for proposing new records. If the process for requesting a new term is unclear or burdensome, people will work around the termbase rather than contributing to it, and the database will diverge from the content it’s supposed to govern.
Career opportunities
Technical communicators who develop genuine termbase skills, not just familiarity with the concept but practical experience designing, populating, and integrating a termbase, are entering a part of the localization industry where skilled practitioners are genuinely scarce relative to organizational demand.
Terminology specialist is the practitioner role this post speaks to most directly: the person who builds and maintains the termbase, governs the workflow, manages the tool integrations, and develops the terminology records that make translation consistent. This role exists in language service providers, in-house localization teams, and larger technical communication departments.
Localization engineer with terminology focus is the technical variant: a role at the intersection of termbase management and tool integration, responsible for the TBX pipeline, the CAT tool configuration, and the TMS setup that makes terminology governance visible to translators in their working environment.
Terminology and content quality lead is the senior individual contributor role that combines termbase ownership with source content quality: enforcing terminology standards in the authoring environment, running terminology audits, and reporting on compliance as a localization readiness metric.
Each of these roles builds directly on the conceptual foundation and practical skills this post covers, but the skills themselves are only part of the picture. Making the organizational and strategic case that creates the conditions for these roles to exist and be properly resourced is a discipline in its own right, and one I’ll take up in a future post.
Your 10-week learning path
This path is designed for a technical communicator who has completed the conceptual groundwork and is ready to develop hands-on termbase skills.
Weeks 1 and 2: Design your termbase
If you’ve been developing terminology records as you’ve worked through this mini-series, now is the time to build them into a proper termbase structure. If you’re starting fresh, pick five to ten terms from a single product area and draft them fully before scaling up.
Either way, define your scope explicitly: one product area, one document type, or one set of concepts that causes consistent inconsistency. Add subject field tags. Add forbidden terms for every preferred term that has a known synonym in active use. Write definitions that would survive being read by a translator who has never seen your product.
Weeks 3 and 4: Choose and explore a tool
Select one terminology management tool to work with. If you have an existing CAT tool in your workflow, choose the term module that integrates with it. If you’re starting fresh, use a free trial of MultiTerm or memoQ.
Load your termbase records and spend time with the interface: add records, edit them, mark terms as preferred or forbidden, and explore the TBX export.
Weeks 5 and 6: Export TBX and test integration
Export your termbase in TBX format and import it into a CAT tool or translation project. If you don’t have a live translation workflow to test against, use the CAT tool’s demo or trial environment.
Observe how term matches surface during translation and whether your definitions and forbidden term flags are displaying correctly.
Weeks 7 and 8: Audit an existing content asset
Take a document you maintain and run a terminology audit against your termbase.
Identify every instance of a forbidden term, every concept that appears with more than one label, and every concept that belongs in the termbase but doesn’t yet have a record. This builds the analytical habit that makes terminology ownership sustainable rather than one-off.
Weeks 9 and 10: Draft a governance framework
Write a one-page governance document for your termbase: named steward, review cadence, term request process, and escalation path for disputes. Keep it short enough to actually be followed.
This is your proof of concept for the (coming) governance layer.
Your next career move
The practical skills in this post, designing, building, integrating, and governing a termbase, are what convert a conceptual understanding of terminology management into a demonstrable professional competency. They’re also what make the business case credible: you can only quantify the return on a terminology program if you understand what the program actually involves.
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.
