The client called it a "small consistency issue." It was not small. A medical-device maker in Lyon had a single approved French term for one component of an insulin pump: the "cartouche," the cartridge that holds the drug. Not "réservoir." Not "ampoule." Not "recharge." Cartouche, full stop, recorded in their termbase years ago because regulators, trainers, and the helpline all keyed their language to that one word. The localization team ran a 280-segment instructions-for-use update through an MT-first pipeline, the kind where a machine fills every segment before a linguist opens the file. The engine, fluent and confident, "preferred" the more common French word "réservoir." It used it in segment 12. Then, because the translation memory now contained that rendering, the same wrong word leveraged into segments 47, 88, 134, 201, and nineteen others. By the time anyone looked, "réservoir" appeared in twenty-four segments, in a printed quick-start guide, in a training video subtitle file, and in the helpline script. The fix was not retyping one word. It was a recall conversation, a re-print, a re-record, and a very uncomfortable meeting about how a single synonym had quietly replicated itself across an entire product family. This lesson is about exactly how that happens: how machines extract terms, how a translation memory leverages matches, and the precise places an engine drifts off the approved term and turns one wrong choice into a hundred.

The Two Memories a Shop Runs On

Before you can see where the engine drifts, you have to know what it is drifting away from. A localization operation runs on two distinct kinds of institutional memory, and people who do not work in the field constantly confuse them. They are not the same asset, they do not do the same job, and the engine interacts with each one differently.

The first is the termbase, also called a glossary or term database. A termbase is the controlled list of approved terms for a client or a product: the source word, the one blessed target word, and usually a note about what it means, what it must never be confused with, and sometimes what synonyms are explicitly forbidden. The cartouche entry is a termbase entry. A termbase is prescriptive. It does not record what was translated; it records what must be translated, every time, no exceptions. It is the rulebook for the words that matter.

The second is the translation memory (TM), the database of previously translated and approved sentence pairs. Every time a human finalizes a segment, the source sentence and its target sentence are stored together as a unit. The next time the same or a similar source sentence appears, the TM can offer the stored translation back. A TM is descriptive and historical: it records what was translated, sentence by sentence, so the work is never done twice. It is the memory of past sentences, where the termbase is the rulebook for individual words.

The termbase says what a word must become. The translation memory says what a sentence already became. One is a rule; the other is a record. The engine can violate the rule while obeying the record, and that is where the trouble starts.

Here is the relationship that the rest of this lesson turns on: a termbase governs terms (individual words and short phrases), and a TM governs segments (whole sentences or sentence-like units). A single segment can contain several terms. So a TM match can be "correct" at the segment level, a faithful record of a real past translation, and still contain a term that violates the termbase, because the wrong term was baked into that sentence when it was first stored. The two memories can disagree, and when they do, the engine has no instinct about which one wins. You do.

Why the Segment Is the Unit of Everything

A segment is the atomic chunk the whole pipeline operates on, usually a sentence, sometimes a heading, a list item, or a cell, defined by segmentation rules in the CAT tool (the computer-assisted translation environment where linguists work). The TM stores and retrieves at the segment level. The MT engine pre-fills at the segment level. The post-editor accepts or rejects at the segment level. This matters because terminology lives inside segments, not as a separate layer the segment-level machinery naturally respects. When a segment leverages from the TM as a whole unit, every term locked inside it comes along for the ride, approved or not. The unit of memory is the sentence; the unit of liability is often the single word buried in it.

How a Machine Extracts Terms, and Where It Guesses

Before a termbase can enforce anything, somebody has to build it, and increasingly that somebody is partly a machine. 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. Done by hand, it is slow and thorough. Done by a machine, it is fast and naive, and understanding the difference is the first place a linguist adds value the engine cannot.

A term-extraction tool works by spotting patterns. Statistical extractors look for sequences of words that occur more often than chance would predict, on the theory that a repeated multi-word unit is probably a term of art. Linguistic extractors add part-of-speech rules: noun phrases, adjective-plus-noun combinations, the grammatical shapes that terms usually take. Newer LLM-assisted extractors read the text more holistically and propose terms that "look like" domain vocabulary based on everything they have seen. All three produce a list of candidate terms. None of them produce a termbase. The gap between a candidate list and an approved termbase is entirely human judgment, and the gap is enormous.

The Four Ways Machine Extraction Misleads

A machine-generated candidate list is a draft, never a decision, and it misleads in four predictable directions:

• It surfaces frequent non-terms. A statistical extractor flags whatever repeats. In a software manual, "click the button" repeats constantly; it is not a term, it is a phrase. The list fills with high-frequency noise that a human must strip out.
• It misses the rare term that matters most. The single most consequential term in a document, the one regulated word, the one component name, may appear only twice. Frequency-based extraction undervalues exactly the low-frequency, high-stakes term whose mistranslation is catastrophic.
• It cannot see the synonym trap. The machine may extract "cartridge" and "reservoir" as two separate candidates because both appear in the English source, with no idea that the client has decided one is approved and the other is forbidden. The extractor lists; it does not adjudicate. The decision that only one of them is allowed is a human decision the machine cannot make.
• It strips the context that defines the term. The same source word can be two different terms in two different domains, even within one product: a "driver" in software versus a "driver" in hardware. A machine extracting a flat list loses the disambiguation that tells a translator which target word each instance requires.

The discipline here is simple to state and easy to skip under deadline: a machine extracts candidates, a human builds the termbase. Every candidate term is a question, not an answer. Is this actually a term? What does it mean here? What is the one approved target word, and which tempting synonyms are forbidden? Treating the extraction output as a finished glossary is how the synonym trap gets built into the foundation, before a single segment is ever translated.

TM Leverage: The Engine of Speed, and of Propagation

Leverage is the word the industry uses for reusing past translations from the TM, and it is the single biggest source of both productivity and replicated error in the whole pipeline. When a new source segment arrives, the CAT tool searches the TM for a stored source segment that is identical or similar, and offers the corresponding stored target. The degree of similarity determines the kind of match, and the kind of match determines how much you should trust it. There are two that you must be able to tell apart in your sleep.

An exact match, often called a 100% match, means the incoming source segment is character-for-character identical to a source segment already in the TM. The tool drops in the stored target with full confidence, and most of the time you barely look at it, because it was approved before. This is where leverage earns its keep: a document with high internal repetition or a strong overlap with past work can be 40, 60, 80% leveraged, and that leverage is most of the speed advantage in the whole MT-first economy.

A fuzzy match is a partial match: the incoming source is similar but not identical to a stored source, scored as a percentage of similarity, typically anywhere from a 99% match down to a 75% threshold below which the tool usually stops offering it. A 95% fuzzy match might differ by one word; a 78% fuzzy match might share only half its words. The tool offers the stored target and highlights the difference, and the linguist's job is to adapt the stored translation to the changed source. Fuzzy matching is where leverage gets dangerous, because the stored target was correct for the old source, and the changed part is exactly where the old translation may now be wrong.

An exact match reuses a whole approved sentence. A fuzzy match reuses most of one and trusts you to fix the rest. The error hides in the part the percentage tells you not to look at.

The Fuzzy-Match Trap in Detail

Picture a stored TM segment whose source was "Insert the cartridge into the lower port" and whose approved target uses the blessed word cartouche. Now the new source arrives: "Insert the cartridge into the upper port." That is a 90%-plus fuzzy match; only "lower" changed to "upper." The tool offers the stored cartouche translation and highlights the one changed word. The post-editor, working fast, fixes "lower" to "upper" and accepts. Perfect. Leverage worked: the approved term rode along inside the reused sentence, and only the genuinely changed word needed attention. This is leverage at its best, and it is why a clean TM is the most valuable asset a localization operation owns.

Now picture the inverse, which is the real lesson. The stored TM segment was created back when the engine drifted, so its target already contains the wrong word, "réservoir," not cartouche. Every fuzzy match that pulls from that poisoned segment inherits the wrong term, and the highlighted difference draws your eye to "lower versus upper," away from the term sitting quietly in the unchanged part of the sentence. The fuzzy-match interface is, by design, pointing your attention at what changed. The propagated term error lives in what did not change. That is not a bug in your attention. It is the structural reason a single wrong term, once it enters the TM, replicates across every future segment that leverages from it, silently, for as long as the TM is reused.

Where MT and TM Collide, and the Term Drifts

In a real 2026 pipeline, the TM and the MT engine are not separate steps; they are layered. The CAT tool fills each segment with the best thing it has, in a priority order that usually runs: exact TM match first, then high fuzzy match, and only where the TM has nothing does the MT engine (neural MT or an LLM) generate a fresh rendering. This layering is efficient, and it is also exactly where the approved term goes to die, because the term is governed by a different system than the one filling the segment.

Walk the priority order with terminology in mind. When an exact TM match fills a segment, the term inside it is whatever was approved, or drifted, when that segment was first stored. The current termbase has no say; you are reusing a past decision. When a fuzzy match fills a segment, the term rides in the unchanged portion, as we just saw, beneath the highlight. And when the MT engine fills a segment, you are at the mercy of the engine's preferences, and the engine's preferences are the heart of the drift.

Why the Engine "Prefers" the Wrong Word

An MT engine, whether a narrow neural MT system trained only to translate or a general LLM translating as a side effect of predicting plausible text, chooses target words by probability. It learned from vast quantities of general text what target word usually corresponds to a given source word in a given context. In ordinary French, "reservoir" is a far more common word than "cartouche" for a container that holds a liquid. The engine, optimizing for the most probable fluent rendering, reaches for the common word. It is not being careless. It is being exactly what it is: a probability machine with no knowledge that this one client, for this one regulated device, has decided the common word is forbidden and the rarer word is law.

This is the deep reason terminology and machine translation are structurally in tension. A termbase encodes an arbitrary, prescriptive, low-frequency choice: "use this word, not the obvious one." An MT engine is built to produce the statistically obvious word. The approved term is, very often, the less probable word precisely because the client chose it to be distinctive, unambiguous, or legally precise. So the engine's default behavior and the termbase's requirement point in opposite directions, and unless the engine is explicitly forced to honor the termbase, through a feature variously called terminology injection, constrained decoding, or a glossary-aware setting, it will drift toward the common synonym every single time it generates that segment fresh. The drift is not random. It is gravitational. The engine falls toward the probable word the way water falls downhill, and the approved term is uphill.

An approved term is a rule that says "do not use the obvious word." An MT engine is a machine built to produce the obvious word. Without enforcement, the engine wins, and it wins quietly.

And Then the Error Feeds Itself

Here is the mechanism that turned one wrong word into twenty-four in the Lyon story. The engine generates "réservoir" in segment 12. A post-editor, moving fast on a per-word rate that did not budget for deep scrutiny, reads a fluent, grammatical French sentence and accepts it. The CAT tool, on confirmation, writes that approved segment, wrong term and all, back into the translation memory. Now the poisoned segment is a stored asset. The next time a similar sentence appears, that poisoned segment surfaces as an exact or fuzzy match, the wrong term riding inside it, and it leverages forward. The error has stopped being an engine output and become institutional memory. It will now propagate not because the engine keeps choosing it, but because the TM keeps offering it, and every future leverage launders the mistake one more time. A single un-caught term drift does not stay a single error. It compounds, because the system is designed to reuse, and it will faithfully reuse the mistake.

How One Wrong Term Becomes a Hundred Segments

It is worth slowing all the way down on the replication, because the speed of it is the part that surprises even experienced linguists. Terminology errors do not scale linearly with effort; they scale with reuse, and reuse is the entire point of the machinery. Three multipliers turn one drift into a flood.

• The leverage multiplier. Once the wrong term is in a stored segment, every exact and fuzzy match drawn from that segment carries it. One poisoned segment in a high-repetition document can surface dozens of times. The more "efficient" your TM leverage, the more efficiently it propagates a buried error.
• The cross-asset multiplier. The same TM and termbase usually feed more than one deliverable: the manual, the quick-start guide, the UI strings, the help center, the training video subtitles, the helpline script. A term that drifts in one project leverages into all of them, because they share the memory. The error crosses formats and channels without anyone re-introducing it.
• The frequency multiplier. The terms most worth getting right, the component name, the safety-critical noun, the regulated word, are often the ones that recur most, precisely because they are central to the product. The more important the term, the more segments it touches, and the wider one wrong choice spreads.

Stack those three and the arithmetic is brutal. A term that drifts once, in one segment, in one project, can end up wrong in a hundred segments across six deliverables in three channels, every instance reading perfectly, every instance traceable back to a single fluent guess the engine made and a single tired keystroke a human did not catch. This is why terminology is not a tidiness concern. In an MT-first, TM-leveraged pipeline, a term error is the most efficiently replicated mistake in the building.

The Cost Is Rarely the Retype

When the error is finally caught, the cost is almost never the labor of changing a word. A global find-and-replace across the TM can fix the database in minutes. The cost is everything the wrong term already touched downstream: the printed guide that has to be reprinted, the video that has to be re-recorded and re-subtitled, the helpline staff who have to be retrained off the old word, the regulatory file that now has an inconsistency a reviewer can flag, and the client's confidence, which does not come back with a find-and-replace. The term drift is cheap to make, cheap to fix in the database, and expensive in every place it already escaped to. That asymmetry, trivial to commit and costly to contain, is exactly why catching it at the segment, before it enters the TM, is worth so much more than catching it later.

The Terminologist as the Engine's Referee

All of this explains why a role that sounded like clerical housekeeping a decade ago, the terminologist, the person who owns the termbase, is becoming one of the most leveraged jobs in an MT-first shop. In a pipeline where the engine gravitationally drifts toward the common synonym and the TM faithfully replicates whatever it is fed, somebody has to be the referee who decides what the approved word is and forces the whole system to honor it. That somebody is not the engine. The engine cannot referee itself; it has no concept of "approved," only "probable."

The terminologist's job, in the AI era, is not to type glossaries. It is to stand at the exact points where the term can drift and hold the line:

• At extraction: turning a machine's flat candidate list into a real termbase, resolving the synonym traps, catching the rare high-stakes term the frequency count buried, and disambiguating the source word that means two different things.
• At enforcement: getting the approved term into the engine's process, through glossary-aware MT settings, constrained decoding, or prompt-level instruction, so the engine is forced toward the approved word instead of the probable one, rather than relying on a post-editor to catch every drift by eye.
• At the TM boundary: guarding what gets written back into the translation memory, because the TM is where a term error stops being a one-time mistake and becomes permanent institutional memory. The terminologist is the immune system that keeps the poisoned segment out of the asset everyone reuses.
• At audit: running the consistency check that finds where the approved term and the actual usage have diverged across all the segments and all the deliverables, before a client or a regulator finds it for them.

The engine knows what word is probable. The terminologist knows what word is approved. In an MT-first pipeline, the second kind of knowledge is the one that keeps a product safe, consistent, and out of court, and only a human holds it.

Why This Is a Marvel, Not a Chore

Step back and see the whole machine for what it is, because it genuinely is a marvel. A modern pipeline can take forty thousand words, leverage half of them from sentences a human approved years ago, generate fluent first drafts for the rest in seconds, and inject a client's approved vocabulary into the output automatically. That is an enormous amount of correct, fast, reusable work, and it is real. The termbase and the TM are not bureaucratic overhead; they are the institutional memory that lets a team translate a product once and reap that work across every future update, every channel, every language. Leverage is one of the most elegant ideas in the whole discipline: never solve the same sentence twice.

The marvel and the danger are the same mechanism. The exact property that makes leverage so powerful, that the system faithfully reuses past decisions at scale, is the property that makes a single wrong decision replicate at scale. The machine is not the enemy of good terminology; it is the most powerful amplifier good terminology has ever had, and the most powerful amplifier a bad term has ever had, and it cannot tell the difference. The human who tells it the difference, who decides what is approved and forces the amplifier to carry the right word, is not fighting the machine. They are the one part of the system that gives the amplifier something worth amplifying. That is the terminologist's role, and in an MT-first 2026, it is not a chore. It is the referee's whistle that decides whether the whole beautiful machine produces consistency or replicates a recall.

Key Takeaways

• A shop runs on two distinct memories. The termbase (also called a glossary) is the prescriptive rulebook for individual approved terms; the translation memory (TM) is the historical record of approved sentence pairs. The termbase governs words, the TM governs segments, and a TM match can be a faithful record of a sentence while still containing a term that violates the termbase.
• Term extraction, the mining of source text for candidate terms, is fast and naive when a machine does it. It surfaces frequent non-terms, misses the rare high-stakes term, cannot resolve synonym traps, and strips disambiguating context. A machine extracts candidates; only a human builds the termbase.
• Leverage means reusing stored TM translations. An exact match (100%) reuses a whole approved sentence; a fuzzy match (a scored partial match, typically 75% to 99%) reuses most of one and highlights only what changed, which steers your attention away from the unchanged part where a propagated term error hides.
• In a layered pipeline the segment is filled by exact TM match, then fuzzy match, then MT generation. Each path can carry a wrong term: the TM reuses a past drift, the fuzzy match buries it under the highlight, and the engine generates a fresh one.
• An MT engine "prefers" the common synonym because it chooses the statistically probable word, while an approved term is an arbitrary, prescriptive, often low-frequency choice. The engine's default and the termbase's rule point in opposite directions, so without explicit enforcement the engine drifts toward the wrong word every time, gravitationally and quietly.
• A single drift feeds itself: an accepted wrong term is written back into the TM, becomes institutional memory, and then leverages forward through every future exact and fuzzy match, laundering the mistake with each reuse.
• One wrong term becomes a hundred segments through three multipliers: leverage (every match from a poisoned segment carries it), cross-asset reuse (the shared TM feeds manuals, UI, subtitles, scripts), and frequency (the most important terms recur most). The error is trivial to commit, cheap to fix in the database, and expensive in every downstream deliverable it already reached.
• The terminologist is the engine's referee, holding the line at four points: extraction (building a real termbase from candidates), enforcement (forcing the approved term into the engine's output), the TM boundary (keeping poisoned segments out of the reused asset), and audit (finding divergence before a client or regulator does). The engine knows what is probable; only the human knows what is approved.