Building a Termbase From a Live Project — and Knowing When to Freeze It

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 forms while the work is moving, from the terms that actually cause trouble.

What you can and should do up front is small: pull 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. Everything else earns its place by showing up in the text and forcing a decision.

Where the terms come from

Three sources, in this order. First, the client’s own approved material — previous filings, existing labelling, a shipped manual. If the buyer already calls a component one thing on their packaging, that decision is made; we are not going to relitigate it, and we lock it early.

Second, the source text itself. A linguist working through a datasheet flags the terms that repeat, the ones that look like terms of art, and the ones where two plausible target words exist. Those flags are the spine of the termbase. They are the terms that, left undecided, will come back three documents later as an inconsistency.

Third — and this is the one people skip — the questions. Every good project generates a 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. Capturing those answers into the termbase is most of the work. Losing them is most of the drift.

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 the decision gets recorded with a one-line reason.

The reason matters more than it looks. Six months later, on the next revision, someone will question the choice — usually a new reviewer who was not there. If the termbase entry says only "use X", they reopen it. If it says "use X — matches the 2019 CE labelling, per [name]", they move on. The note is what stops the same argument happening every cycle.

When to freeze

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, and missing that point is its own kind of damage. 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 practical rule we use: freeze a term once it has been applied across more than one deliverable and reviewed. After that, changing it is a formal change, not a quiet edit — it means going back and updating everywhere it already appears, on purpose, with the cost understood. Freezing is not rigidity; it is refusing to let a late opinion silently fork the terminology.

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 — because it is your asset, and its value is in the next project, not this one.

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.