The candidate list came back in ninety seconds and it looked like a gift. A mid-size language-service provider had landed a new account: a German manufacturer of industrial cooling equipment, forty thousand words of technical documentation to localize into French, Spanish, and Japanese, with more updates promised every quarter. The project manager wanted a termbase before the first segment was translated, because she had learned the hard way what happens without one. So a junior linguist pasted the German source into an LLM, asked it to "extract all the technical terms and give me approved translations," and got back a tidy two-column table of three hundred and forty entries. Source term, target term, clean and formatted, ready to import. It felt like a week of work compressed into a coffee break. The PM looked at it, saw three hundred and forty rows of plausible German and plausible French, and almost imported it straight into the translation-management system as the project's official glossary. She did not, and the reason she did not is the entire subject of this lesson. Because forty of those rows were wrong, and an unverified glossary does not make forty isolated mistakes. It makes forty rules, and every rule then propagates itself, automatically and silently, into every segment the term ever touches.

What a Termbase Actually Is, and Why It Is a Rulebook

Start with the words, because in this corner of localization the words are slippery and people use them loosely. A term is a word or short phrase that carries a fixed, domain-specific meaning: not "the machine," but "the compressor"; not "open it," but "the bleed valve." A term is the vocabulary a field has agreed to be precise about. A glossary, in the loosest sense, is any list pairing terms with their meanings or translations. A termbase (sometimes written term base, also called a term database or, in some tools, a terminology database) is the formal, structured, authoritative version of that glossary: the controlled list of approved terms for a client or a product, where each entry records the source term, the one blessed target term, and usually a definition, a domain, a part of speech, a usage note, and frequently a list of forbidden variants that must never be used.

The distinction that matters is not really format. It is force. A glossary in the casual sense is a suggestion: here are some words and what they tend to mean. A termbase is a rule. It does not describe what people have translated; it prescribes what they must translate, every time, with no exceptions, on pain of failing the file. When the cooling-equipment client's termbase says the German "Kältemittel" must become the French "fluide frigorigène" and never "réfrigérant," that is not advice. It is law for that account. A post-editor who renders it "réfrigérant" has produced a terminology error, scoreable against an evaluation typology, and in a regulated or safety-critical context that single wrong word can be a Critical error that fails the entire delivery.

A glossary is a list of words. A termbase is a list of rules. The moment a term enters the termbase, it stops being a suggestion and starts being a requirement that the whole pipeline is obligated to enforce. That is exactly why you cannot afford to put a wrong one in.

Hold onto that, because it reframes the whole task. Building a termbase is not data entry. It is legislation. Every row you add is a rule you are imposing on every translator, every post-editor, every MT engine, and every future update for as long as the account exists. A wrong row is not a typo. It is a bad law that the entire system will now obey faithfully, which is the worst possible kind of error: one the machinery is designed to enforce and amplify rather than catch.

Term Extraction: The Mining Step

Term extraction is the process of mining a body of source text to find the words and phrases that are likely to be domain terms, the candidates that deserve an approved translation and a termbase entry. It is the first step in building a termbase, and historically it was the slow, expensive, expert one: a terminologist or senior linguist reading the source, marking what counted as a term of art, deciding what was just ordinary language, and assembling the list by judgment. The value was never in finding words. It was in deciding which words mattered and what each one truly meant in this specific domain.

That mining step is exactly what AI now does in ninety seconds, and that is both the opportunity and the trap of this lesson. An extraction tool, whether a statistical extractor, a linguistic one, or an LLM, can produce a candidate list at a speed no human can match. What it cannot do, what no machine can do, is the part that gave the human terminologist their value: turning the candidate list into a verified, approved, defensible termbase. The speed is real and worth having. The danger is mistaking the fast first half of the job for the whole job.

Why an Unverified Auto-Glossary Is Worse Than No Glossary

It is tempting to think a quick, imperfect glossary is at least better than nothing. In localization, that intuition is dangerously wrong, and understanding why is the spine of this lesson. A wrong entry in a verified, enforced termbase is not a neutral gap. It is an active source of replicated error, and the more disciplined your pipeline is about enforcing the termbase, the more efficiently it will spread the mistake.

Walk the mechanism slowly, because the speed of the damage is the part that surprises people. Suppose the auto-extracted glossary contains a single wrong rule: the German "Ventil" (valve) has been paired with the French "soupape," when this client's approved term is actually "vanne," because in their equipment the part is a different kind of valve and "soupape" means something specific and wrong. Now import that into the TMS as the project termbase. From that instant:

• The MT engine is told to prefer the wrong word. A modern pipeline injects the termbase into the machine-translation step, so the engine is now actively instructed to render every "Ventil" as "soupape." The one place a sharp human eye might have flagged the oddity is now overruled by the glossary itself.
• The post-editor is told the wrong word is correct. When the post-editor checks the segment against the termbase, the termbase confirms "soupape." The verification step that exists to catch errors now actively endorses this one, because the error is in the reference, not the output. The checker is checking against a poisoned standard.
• The QA tooling flags the right word as a violation. An automated terminology check will now mark any segment that correctly uses "vanne" as a terminology error against the approved glossary, inverting the entire purpose of the check. The linguist who knows better gets a warning for being right.
• The translation memory stores the wrong word forever. Every confirmed segment writes "soupape" back into the TM, so the error becomes leveraged institutional memory that propagates into every future update, every related deliverable, and every channel that shares the memory.

Read that list again and notice what it describes. An unverified auto-glossary does not just fail to help. It recruits every quality control in the pipeline to defend the error. The MT injection, the post-editor's termbase lookup, the automated QA, and the TM leverage are all mechanisms built to enforce consistency, and a wrong rule turns each of them into a mechanism for enforcing the wrong thing consistently. With no glossary at all, a thoughtful linguist might at least translate "Ventil" correctly by judgment. With a wrong glossary, the system actively prevents them from doing so and flags them when they try.

No glossary leaves room for human judgment to be right. A wrong glossary overrules human judgment and makes the whole pipeline enforce the error. An unverified auto-extracted termbase is not a head start. It is a set of bad laws the machinery will obey faster and more thoroughly than it would ever obey a good linguist's instinct.

The Error Rate Is Not Trivial

You might hope the wrong rows are rare enough to ignore. They are not. The same property that makes large language models produce fluent, confident, sometimes-wrong translations makes them produce fluent, confident, sometimes-wrong glossary entries. Recall the failure rates that haunt this whole program: studies of LLM output on medical content found error rates around 59% on drug names, 60% on dates and times, and 66% on adverse events, every one delivered in grammatically perfect prose. A glossary entry is exactly the kind of short, high-stakes, name-like artifact those numbers describe. The model will give you a target term that looks right, reads right, and is formatted right, with the same serene confidence whether it is correct or invented. A wrong glossary entry has no tell. It does not look uncertain. That is precisely why it must be verified by something other than how plausible it looks.

The Extraction-Then-Verify Loop

So the discipline this lesson teaches is a loop, and the loop has two halves that must never be collapsed into one. The first half is fast and the machine does most of it. The second half is slow and a human must own all of it. The error that the cooling-equipment PM nearly made, and that thousands of teams make under deadline, is treating the output of the first half as if it were the output of the second. Extraction produces candidates. Verification produces a termbase. They are different artifacts with different levels of authority, and the entire safety of the process depends on never confusing them.

State the loop plainly:

• Extract (fast, machine-led): run the source through an extraction tool or an LLM and get a candidate list quickly. Cast a wide net. It is fine, even good, for this list to over-include, because the next step is a filter.
• Verify (slow, human-led): take every candidate and subject it to a fixed set of checks before it is allowed to become a rule. A candidate that passes all checks becomes a termbase entry. A candidate that fails any check is fixed, demoted, or thrown out. Nothing skips this step. Nothing is approved because it "looks fine."

The mental model that keeps the loop honest is the courtroom one. The extraction tool is a witness who has named some suspects. A witness naming a suspect is not a conviction. Every candidate term is presumed unproven until it has been examined and the evidence checked. The terminologist is not the witness and not the stenographer; the terminologist is the judge who decides what is admitted into the record as law. Treating the witness's list as the verdict is how the innocent get convicted, which here means how the wrong word becomes the enforced rule.

Extraction names candidates. Verification convicts or acquits them. A candidate is a question, never an answer, and the unforgivable shortcut is letting a candidate become a rule without ever standing trial.

Why the Loop Is Non-Negotiable, Especially Under Deadline

The loop is easiest to skip at the exact moment it matters most. When the deadline is tight and the candidate list is long and the rows all look reasonable, the pressure to import-and-go is enormous, and the cost of verifying feels like pure overhead because nothing has gone wrong yet. This is the trap. Verification is cheap now and the error is catastrophic later, and the asymmetry runs entirely against your intuition in the moment. Checking three hundred and forty candidates is a few hours of careful work today. Discovering after delivery that forty of them were wrong, and that the wrong words have leveraged across three languages, six deliverables, and a quarter of updates, is a reprint, a re-record, a re-translation, a client-confidence crisis, and possibly a regulatory finding. The few hours are not overhead. They are the cheapest insurance in the building, and they only feel expensive because the disaster they prevent has not happened yet.

The Five Verification Checks Every Candidate Must Pass

Verification is not a vibe. It is a fixed set of named checks you run on every candidate, the same way every time, so that "I verified it" means something specific and defensible rather than "it looked okay to me." Five checks carry almost all the weight. Run them in order, and treat any failure as disqualifying until resolved.

Check One: Is It Actually a Term?

The first and most common failure is that the candidate is not a term at all. Extraction tools, especially statistical ones, surface whatever repeats, and plenty of frequent things are not terms. "Click the button," "please note," "as shown in the figure," "the following" are high-frequency phrases, not domain terms, and they bloat a candidate list with noise. An LLM, asked to extract terms, will sometimes hand back generic vocabulary dressed up as terminology because it is pattern-matching on "things that appear in technical documents." The check is a question: does this word carry a fixed, domain-specific meaning that requires one controlled translation, or is it ordinary language that any competent translator would render correctly without a rule? If it is ordinary language, it does not belong in the termbase. A termbase clogged with non-terms is not just untidy; it dilutes the authority of the entries that matter and makes the genuine high-stakes terms harder to find and enforce.

Check Two: The Domain Check

This is the most important check and the one the machine is least able to do for you. The same source word can be a completely different term in a different domain, and the correct target depends entirely on which domain you are actually in. A "driver" is software in one context and a hardware component in another and a person operating a vehicle in a third. A "Ventil" is one kind of valve in a heating system and a structurally different kind in a brass instrument. The candidate list is flat; it strips the context that tells you which meaning is in play. The domain check forces you back to the source document to confirm what the term means here, in this client's product, in this specific technical field, not what it means in general. This is where an extracted glossary most often goes subtly and expensively wrong: not a random hallucination, but a real translation of the term in the wrong domain, which reads perfectly and is precisely incorrect. Verifying the domain is verifying that the target term is right for this content and not merely right for some content.

Check Three: Source-and-Target Pairing

A termbase entry is a pair, and both halves can be wrong independently. The source side can be malformed: the extractor may have grabbed a fragment ("cooling fluid temperat") or fused two terms or split one across a line break. The target side can be a wrong translation, a near-synonym that violates the client's choice, an over-literal calque, or, with an LLM, an outright fabrication that sounds like a real technical term but is not one any native specialist would use. The pairing check verifies three things at once: that the source term is correctly and completely captured, that the target term is an accurate translation of that source term, and that the pairing is the one this client approves. A target term can be a perfectly good translation in the abstract and still be wrong for this account because the client mandated a different approved variant. Checking the pairing means checking the relationship, not just inspecting each side alone.

Check Four: The Definition

An entry with no definition is an entry you cannot really verify and that no one downstream can use to resolve ambiguity. The definition is what makes a termbase entry self-explaining: it states what the term means in this domain, which fixes the domain check in place, distinguishes the term from its near-neighbors, and gives the post-editor in another country a way to confirm they are looking at the same concept. Writing or verifying the definition is not bureaucratic decoration. It is the step that forces you to articulate what the term actually is, and articulating it is frequently how you catch that the target translation is subtly wrong. If you cannot write a one-sentence definition that makes the source and the target obviously refer to the same concept, that difficulty is a signal: something in the pairing is off. A good definition also future-proofs the entry, so the next linguist inherits the meaning and not just the word.

Check Five: Client Approval

The final check is the one that converts a verified candidate into an actual rule, and it is the one no amount of linguistic skill can substitute for. Terminology is, at bottom, a client's prerogative. The client decides that "Kältemittel" is "fluide frigorigène" and not "réfrigérant," and that decision can rest on regulatory filings, existing published materials, a corporate style guide, a legal constraint, or simple long-standing preference that the helpline and the trainers are all keyed to. You can verify that a candidate is a real term, in the right domain, correctly paired, and well defined, and the client can still tell you their approved word is a different one. So the high-stakes, ambiguous, or business-critical entries go to the client for sign-off before they become enforced rules, with the candidates organized so the client can approve a clean list quickly rather than wade through three hundred unfiltered rows. Client approval is not a rubber stamp at the end. It is the act that gives the termbase its authority, and skipping it means you have written rules the client never agreed to and may not accept when the consequences arrive.

Is it a term? Is it right for this domain? Is the source-and-target pairing accurate and approved? Is it defined? Has the client signed off on what matters? Five checks. A candidate that has not passed them is not a termbase entry. It is a suspect still awaiting trial, and you do not enforce a suspect.

A Worked Build From a Real Document

Abstract checks are easy to nod along to and hard to actually run, so build a small termbase the slow way, from a fragment of the cooling-equipment manual, and watch the loop catch real errors. Here is the German source passage the junior linguist fed to the LLM, translating into French:

"Das Kältemittel zirkuliert durch den Verdichter und das Ventil. Vor der Wartung muss das System drucklos gemacht werden. Der Kondensator darf nicht blockiert werden, da dies zu Überhitzung führt."

The LLM's extraction came back with six candidates, formatted and confident: Kältemittel to "réfrigérant," Verdichter to "compresseur," Ventil to "soupape," Wartung to "entretien," Kondensator to "condensateur," and Überhitzung to "surchauffe." A tidy six-row table that the system would happily import. Now run the loop, candidate by candidate, and notice that the formatting tells you nothing about which rows are sound.

Candidate by Candidate

• Kältemittel to "réfrigérant" (FAIL on pairing and client approval). Is it a term? Yes, refrigerant is a genuine domain term. Right domain? Yes, refrigeration. But the pairing fails: this client's approved French term is "fluide frigorigène," the term used in the relevant European regulatory texts, and "réfrigérant" is on their forbidden-variant list precisely because it is the common-sounding word that an engine reaches for. The machine produced the probable word, not the approved one. This entry goes to the client, is confirmed as "fluide frigorigène," and "réfrigérant" is recorded as a forbidden variant so the QA tooling will flag it.
• Verdichter to "compresseur" (PASS, with a definition added). Is it a term? Yes. Right domain? Yes, this is the compressor in a refrigeration cycle. Pairing accurate? Yes, "compresseur" is correct. The only gap is the missing definition, so add one: "the component that compresses the refrigerant vapor in the cooling cycle." Now it is self-explaining and the entry is approved.
• Ventil to "soupape" (FAIL on the domain check). This is the dangerous one, the row that reads perfectly and is precisely wrong. Is it a term? Yes. But the domain check, run against the actual source, reveals that in this equipment the "Ventil" is a shut-off valve in a fluid line, which in French technical usage is a "vanne," whereas "soupape" denotes a different kind of valve (a pressure-relief or spring-loaded valve) and means the wrong component. "Soupape" is a real, fluent, plausible translation of "Ventil" in some domains and the wrong term in this one. Without the domain check, this row imports clean and ships an incorrect, safety-relevant term across every segment. Corrected to "vanne," defined, and flagged for client confirmation.
• Wartung to "entretien" (FAIL on the term check, then reconsidered). Is it a term, or ordinary language? "Wartung" means maintenance, and whether it belongs in the termbase depends on the client. If they distinguish "entretien" (routine upkeep) from "maintenance" (technical servicing) in their documentation, it is a controlled term and the right variant must be confirmed. If they use the word generically, it is ordinary language any translator handles without a rule, and forcing it into the termbase only adds noise. The check sends it to the client question list rather than silently enforcing one of two defensible words.
• Kondensator to "condensateur" (FAIL, the textbook domain trap). Is it a term? Yes. Pairing accurate in the abstract? "Condensateur" is a correct French translation of "Kondensator." But the domain check matters enormously here, because "Kondensator" is also the German for an electrical capacitor, and "condensateur" in French carries both the refrigeration "condenser" meaning and the electrical "capacitor" meaning. In this cooling-equipment context the intended concept is the heat-exchanger condenser, so the entry is correct but the definition must pin the domain explicitly ("the heat-exchanger component that condenses refrigerant vapor to liquid"), or a future post-editor working a related electrical document could leverage the entry into the wrong concept. Passes, but only because the definition nails the domain down.
• Überhitzung to "surchauffe" (PASS, with a usage note). Is it a term? In refrigeration, "surchauffe" (superheat) is a precise technical quantity, not merely "overheating," and the source here uses it in the general "overheating" sense. The check catches that the same target word covers a precise technical term and a general meaning, so the entry passes but carries a usage note distinguishing the two senses, preventing a later mistranslation in a thermodynamics context.

Tally the loop. Of six confident, well-formatted machine candidates, exactly one (Verdichter) was clean as delivered. One was a silent, safety-relevant domain error that read perfectly (Ventil). One was a client-approval and forbidden-variant problem (Kältemittel). Two needed the definition to pin down the domain so they would not leverage into the wrong concept later (Kondensator, Überhitzung). One was a is-it-even-a-term question that belonged to the client, not the machine (Wartung). The extraction did real work: it found the candidates in seconds. But the verified termbase, the one that is safe to enforce, was produced entirely by the second half of the loop, the half no machine performed.

Six plausible rows, one of them clean. That ratio is not a story about a bad model. It is the normal yield of extraction, and it is exactly why the candidate list is the start of the work and never the end of it.

What the Finished Entry Looks Like

The difference between the imported row and the verified entry is visible in the shape of the record. The machine gave you "Ventil | soupape," two columns. The verified entry for that same term carries the source term "Ventil," the corrected and client-confirmable target "vanne," a domain ("refrigeration equipment, fluid lines"), a part of speech, a one-sentence definition ("a shut-off valve controlling fluid flow in a line"), a forbidden variant ("soupape, which denotes a pressure-relief valve and must not be used for this component"), and a status flag (client-confirmation pending). That richer record is not bureaucracy. Every field is a verification check made permanent, so the next linguist, the QA tool, and the MT injection all inherit not just a word but the reasoning that makes the word a defensible rule. The two-column table was a guess. The structured entry is a decision you can stand behind in an audit.

Who Owns the Loop, and the Role It Creates

Notice what the worked build actually required. It did not require typing German into a table; the machine did that in seconds. It required knowing that "soupape" and "vanne" are different valves, that "fluide frigorigène" is the regulatory term while "réfrigérant" is the colloquial one, that "Kondensator" straddles refrigeration and electrical meanings, and that the client, not the linguist, owns the final call on a contested term. That is domain knowledge, judgment, and a relationship with the client's intent, and it is precisely the cluster of skills the machine cannot supply. The extraction step commoditized the part of terminology work that used to be slow. It made the verification step, the judgment, more valuable, not less, because now the judgment is the entire scarce ingredient and the speed is free.

This is the shape of the AI-era terminology role in general, and it is good news for the linguist who understands it. The job is no longer "find the terms," because the machine finds candidates faster than any human. The job is "decide which candidates become rules, and make those rules defensible," which is harder, higher-value work that an engine structurally cannot do because it has no concept of "approved," only "probable." The terminologist who masters the extraction-then-verify loop is not competing with the extraction tool. They are doing the half of the job that the tool created demand for by automating away the other half. The person who runs the loop owns something the pipeline cannot manufacture: the difference between a confident guess and a verified rule.

The machine made the candidate list free, which made the verified termbase the entire job. Extraction is a button. Verification is a profession. The linguist who owns the second half owns the part the engine made more valuable by automating the first.

Key Takeaways

• A term is a domain-specific word with a fixed meaning; a glossary is any list pairing terms with translations; a termbase is the formal, structured, authoritative glossary where each entry is an enforced rule, not a suggestion. Term extraction is the process of mining source text for candidate terms. Building a termbase is legislation, not data entry: every row becomes a rule the whole pipeline must obey.
• An unverified auto-extracted glossary is worse than no glossary, because a wrong rule recruits every quality control to defend the error: the MT engine is instructed to produce the wrong word, the post-editor's termbase lookup confirms it, automated QA flags the correct word as a violation, and the TM stores the mistake as permanent leveraged memory. No glossary leaves room for human judgment to be right; a wrong one overrules it.
• LLM glossary entries fail at meaningful rates with no visible tell, the same way LLM medical output showed roughly 59% errors on drug names, 60% on dates and times, and 66% on adverse events, all in confident, fluent form. A wrong entry looks exactly as plausible as a right one, so plausibility is never verification.
• The discipline is a two-half loop that must never be collapsed: extract fast (machine-led, wide net, candidates only), then verify slow (human-led, every candidate, no exceptions). Extraction produces candidates; verification produces a termbase. A candidate is a question, never an answer, and is presumed unproven until it stands trial.
• Five verification checks carry the weight: (1) is it actually a term or just frequent ordinary language; (2) the domain check, confirming the term means what it means here and not in some other field; (3) source-and-target pairing, verifying both halves and that the pairing is the client-approved one; (4) the definition, which makes the entry self-explaining and often exposes a subtly wrong pairing; (5) client approval, the act that converts a verified candidate into an authoritative rule.
• The domain check catches the most dangerous error: a real, fluent, plausible translation of the term in the wrong domain, which reads perfectly and is precisely incorrect (for example "soupape" for a shut-off "Ventil" that should be "vanne"). This is not a random hallucination but a right-sounding wrong rule, exactly the kind verification exists to stop.
• In the worked build, only one of six confident, well-formatted machine candidates was clean as delivered. That ratio is the normal yield of extraction, not a sign of a bad model, which is why the candidate list is the start of the work and never the end of it. A verified entry carries source, target, domain, part of speech, definition, forbidden variants, and approval status: every field a verification check made permanent and audit-defensible.
• Extraction commoditized finding terms and made verification the entire scarce ingredient. The AI-era terminology role is not "find the terms" but "decide which candidates become rules and make those rules defensible," judgment the engine cannot supply because it has no concept of approved, only probable. The linguist who owns the verify half owns the part the machine made more valuable, not less.