December 15, 2000
Terminology management is not a translation tool problem. It is part of the infrastructure of globalisation, and it is the cheapest thing to get right and the most expensive thing to retrofit.
The way to kill a termbase project is to gather every word from the product manual on day one, exhaust yourself halfway through, and abandon it. The effective order is by the cost of getting it wrong: product names, safety terms, feature names and regulatory expressions are the categories where a mistranslation causes real damage, so do those first. Ordinary descriptive vocabulary can wait, or be skipped entirely.
The first termbase does not need to be large; a few hundred entries are enough. What matters is that they are actually used — in the translation process, in the review checklist, in the product documentation. A two-hundred-entry termbase that everyone follows is worth far more than a two-thousand-entry one nobody reads.
Ranking follows business impact, not word frequency. A rare term whose mistranslation causes a safety incident outranks a common noun that appears ten times a day.
The most common problem after a termbase exists is that it sits on a shared drive, translators do not know about it or know and do not consult it. That makes it a document, not a tool. The effective approach is to wire it into the CAT tool and the MTPE process so that the translator sees approved terminology in the working interface.
Once it is in the process, terminology checking can be automated. Most CAT tools and QA tools support term-consistency checks and can flag where a translation uses a non-standard rendering. That single step moves terminology compliance from good intentions to checked process.
One further layer is often overlooked: onboarding. For a translator's first contact with a project, the termbase is the best possible briefing — it tells them what the product is called, how features are named, which words must not be improvised. Walking the termbase before the first assignment saves more than correcting afterwards.
A termbase is not an asset you finish building; it needs maintenance, and maintenance requires an owner. Somebody — one person or a small group — decides when a term changes, who approves it, and how the change is communicated to everyone affected. Without that arrangement, the termbase decays: translators drift back to guessing and the contents age quietly.
The usual structure is a terminology owner plus a review panel drawn from product, marketing and translation. Any new term or change follows a fixed route: submit, review, approve, enter into the base, notify. The route need not be elaborate, but it must exist and must be recorded.
Version history for terminology changes matters for the same reason. Terms are not static — products evolve and markets move, and last year's standard rendering may no longer be right this year — but changes must be traceable. The problem is organisational -- the team changing the product and the team managing documents are often not the same people. Some mechanism is needed for a change to propagate automatically; watching for it manually does not hold.
Schedule a quarterly review of the most-used terms and retire entries that no longer apply. Names of discontinued models, renamed features, formulations made obsolete by a regulatory change — all of these should come out of the base. Leaving them in costs more than the convenience saved, because a translator will assume they are still valid.
Review has a hidden second benefit: it is the moment when gaps in the terminology system surface. Entries that nobody uses may mean the corresponding feature is not being translated, or that translators do not know the term exists. Those signals only come out of looking at the data periodically.
Terminology management comes down to infrastructure, not tooling. Get the foundation right and every additional language is a matter of quantity; skip it and every additional language re-accumulates the drift. FangService treats terminology management as a front-end step on multilingual projects — bring the product material and start with the first batch of terms.
One client discovered during an overseas certification that the same component had three names across three generations of product manual: heat sink early on, cooling module later, thermal management unit in the latest version. The certification body concluded these might be three different parts and asked for clarification, which cost a month of back and forth. Had the early glossary simply been maintained, that clarification would never have been needed. What terminology management saves is rarely translation spend; it is rework, clarification and certification delay.
The realistic approach to maintaining a glossary has three steps. First, collect only what is mandatory — product definitions, parameter names, certification terms and brand names. Second, capture the two failure modes: one term with several translations, and one translation with several source terms, because those generate the complaints and the rework. Third, assign an owner and a review rhythm, so a product generation change triggers a terminology review. FangService builds bilingual term bases with each entry annotated for forbidden translations and applicable context, ties the glossary to the project version, and configures the translation pipeline to skip untranslatable items such as model numbers and brand names so they are never rewritten by machine translation.
Terminology management easily gets described as a systems project and therefore never starts. In practice three actions in the first three months are enough to see results: force product definitions and parameter names into line by product line; build a forbidden-translations list marking the renderings that have already caused complaints or rework; and add a terminology pre-check to the translation pipeline so high-frequency terms are screened before dispatch.
None of the three needs major investment, and they immediately reduce two classes of problem: clarification and rework caused by one product carrying several names, and renderings already known to be wrong appearing again. A glossary that starts from thirty terms is perfectly adequate, provided it reflects the actual product rather than a generic list copied from elsewhere.
FangService builds client term bases from the product itself: high-frequency and mandatory terms first, annotated with context and forbidden renderings, bound to the project version, and executed as a pre-check in the translation pipeline. Terminology management only earns the right to be called a system once it starts paying off.
Tell us your project scenario and requirements, and we will match the right solution and provide a quote within 24 hours.
Get a Free Quote