Terminology / Termbase
A structured database of approved term pairs (source to target) that specifies exactly how domain-specific words and phrases must be translated within a product or organization, along with context, usage notes, and forbidden alternatives.
The honest version
A termbase is a decisions log. Every entry records a choice that someone made, argued for, and documented: we call this thing “workspace”, not “workbench”. The value is not in the term itself. It is in the reasoning behind it, the contexts where it applies, and the list of forbidden alternatives.
A termbase without context, domain, and do-not-use columns is a glossary that might as well live in a spreadsheet. The difference between a glossary and a professional termbase is structured metadata: which product version introduced this term, which regulatory standard requires this phrasing, which translation was rejected and why. That structure is what makes a termbase enforceable in automated QA.
Standard termbase formats include TBX (TermBase eXchange) for exchange between systems, and most CAT tools and TMS platforms maintain their own internal terminology databases that can export to TBX or CSV.
Why it matters for translation
Inconsistent terminology is the most common, most expensive, and most preventable quality problem in localization. A single product term consistently misapplied across 30 languages and 200,000 strings is a systematic failure, and it is systematic precisely because no termbase enforced the correct choice at the point of translation.
A well-maintained termbase does three things. First, it constrains translators and LLM prompts at generation time: “translate ‘submit’ as ‘einreichen’, not ‘senden’.” Second, it enables automated QA: a terminology checker flags any segment where a source term appears but its approved translation does not. Third, it accelerates onboarding: a new translator or a new AI prompt can use the termbase as ground truth for the product’s vocabulary without reading three years of revision history.
For regulated industries (pharma, medical devices, legal), the termbase is not a convenience. It is a compliance document. Specific terms must appear in specific approved forms. Deviation is not a style issue; it is a regulatory issue.
Where it fails
Terminologies go stale. This is the failure mode, and it is almost never a technology problem.
Products rename features. Legal requirements change the approved phrasing for disclosures. Companies merge and bring conflicting termbases: two different terms for the same concept, both marked “approved” from different predecessor systems. The termbase that was correct in 2021 is a source of errors in 2026 if no one has maintained it.
The maintenance process is the hard part. Someone must own the termbase. That person must have both domain knowledge and translation knowledge. New terms must be added before they appear in source text. A termbase entry created after a project has shipped is useful for the next project, not this one. Term change requests must be reviewed, approved, and propagated to every affected market simultaneously.
The second failure mode is coverage. A termbase that covers 300 terms in a product with 10,000 distinct technical concepts provides false assurance. The terms it covers are handled correctly; the terms it does not cover are handled by individual translator judgment, which is inconsistent by definition.
Finally: termbase entries can be right and contextually wrong. “Workspace” is the approved translation for your SaaS product’s top-level organizational unit, but in a help article explaining how to share access, “workspace” in the source might refer to a different concept that the termbase entry does not cover. Automated QA cannot distinguish between them. Human review can.