A working termbase is not written up front — it grows during the project, out of the terms that actually cause trouble. Why it is hard, where it goes wrong, and what a buyer should ask a vendor for.
- A termbase is not a glossary you write up front
- The part most often thrown away
- The hard ones need an owner, not a vote
- The freeze point: easy to miss, and missing it has a price
- What the buyer should ask for
A termbase is not a glossary you write up front
Teams tend to picture terminology work as a task you finish before translation starts: sit down, list the terms, agree the equivalents, hand it over. In twenty years of running projects, that is not how a usable termbase gets built. The list you write before you have seen the source is a guess.
The real termbase grows while the work is moving, out of the terms that actually cause trouble. What you can do up front is small: the obvious product names, the regulated terms you already have approved, and anything the client feels strongly about. That is a seed, not a termbase.
The part most often thrown away
A termbase draws on several sources, two of which everyone thinks of: the client's own approved material — previous filings, existing labelling, a shipped manual — and the source text itself, which reveals its terms of art and its ambiguous words as a linguist works through it.
The one that gets overlooked is the third: the query log. The translator asks, the client or a domain reviewer answers — and that answer is a terminology decision, whether or not anyone writes it down as one.
Those answers are judgements you paid for. Capturing them into the termbase is most of the work; leaving them in email and chat is most of the drift. Once a project ends and people rotate, nobody remembers why a term was settled that way, and the next project relitigates it.
The hard ones need an owner, not a vote
On any project of size, a handful of terms have no clean answer. Two target words both defensible. A source term the client uses loosely across departments. A regulated phrase where the standard and the marketing team disagree. These do not resolve by consensus.
They resolve because someone with authority decides and records the decision with its reason. And the reason matters more than the decision — six months later, on the next revision, someone will question the choice, usually a new reviewer who was not there. An entry that says only "use X" gets reopened; one that states the basis is left alone.
The freeze point: easy to miss, and missing it has a price
A termbase should stay open through the first pass and the first review, because that is when the real terms surface. But there is a point where it has to stop moving.
The cost of missing that point is concrete: if a term changes after half the document set is translated, you have not improved consistency — you have created two versions of the truth and a rework bill. The later the change, the larger the bill.
Exactly where that point sits depends on the number of deliverables, how far review has progressed, and how the documents cross-reference each other. Judging it is the part of terminology management that most depends on experience, and the part tooling cannot decide for you.
What the buyer should ask for
If you are commissioning the work, do not ask for "a glossary" as a deliverable and assume that covers you. Ask three things. That a termbase is built from your approved material, not invented. That the query answers from your project are captured into it, so the decisions you paid to make are not lost. And that you get the termbase back, in a format you can reuse, at the end.
A vendor who treats terminology as tooling will keep it on their side and rebuild it, quietly, every engagement — and bill you for the rebuild each time. A vendor who treats it as your asset hands it over. That difference is worth more over three years than any per-word rate.