How Translators Use AI to Keep Terminology Consistent

Use AI at three points: extract candidate terms from the source and the client's past translations to build a termbase; apply that termbase in your machine translation engine or CAT tool so drafts start with the right terms; then audit, with an AI model listing every rendering of each key term and a QA tool checking approved and forbidden terms.

The rule that keeps this working: AI proposes, the termbase decides, QA verifies. Engines apply glossaries imperfectly, especially in languages that inflect nouns or build compounds. Large language models like variety and will swap in a synonym "for style" three segments after using the approved term. And no model can know which of two correct-looking renderings your client wants on their packaging. Only the client can decide that, so the client's decision has to be written down where every tool can see it.

Follow me on Instagram@sagnikteaches

Where terminology slips in a real job

• Several people, one client. Two translators on one website each pick a reasonable term for the same concept.
• Machine output that varies. An engine renders the same source term two ways depending on the sentence around it.
• Synonyms for style. LLM-based translation avoids repetition, which is good for prose and bad for terms.
• Old materials. The client's existing brochure uses one term, their new website another, and nobody noticed.
• Mid-project changes. The client changes a term halfway through, and earlier files still carry the old one.

Each of the five steps below closes one or more of these gaps.

Connect on LinkedInSagnik Bhattacharya

Step 1: Extract candidates from the source and past translations

Term extraction used to mean hours with a highlighter. A language model does a good first pass in minutes, provided you tell it what counts as a term. Use a business AI plan or the AI inside your CAT tool, and check the client allows it. For an illustrative specialty coffee roaster sending its whole online range for translation:

Subscribe on YouTube@codingliquids

From the attached source files, extract candidate terms for a
translation termbase. A term is a word or phrase with a specific meaning
in coffee roasting, brewing or this company's products, which should be
translated the same way every time. Exclude everyday words.
For each: the term, how many times it appears, one example sentence,
and a note if the same concept appears under different source wordings.
Then, from the attached previous translations, list how each term was
translated before, with every variant found.

An illustrative extract of the result, with descriptive notes standing in for the target-language terms:

What you'd fix: "flavour" is an everyday word that slipped through, so remove it. The useful finds are the variants. "Cupping notes" appears on every product page with three different past translations, which is exactly the inconsistency a customer browsing the shop would notice. And "dry process" in older files turns out to mean the same as "natural process", which the model spotted only because the prompt asked for different source wordings of one concept.

Step 2: Get the client's decisions into a termbase

Some clients already have a glossary, and it often needs as much work as a fresh extraction. An illustrative before, from a spreadsheet the roaster's previous agency left behind, with target terms shown as placeholders:

washed          [X] / [Y]
natural         see dry
dry process     [Z]
cupping notes   [A]   (marketing prefers B??)
Honey           dont translate?

Every line hides an open question: two targets for "washed", a cross-reference instead of a decision, a note nobody resolved, and a question mark on the do-not-translate call. Ask the model to convert it into entries with a status field, marking anything with two options, a question mark or a cross-reference as "needs decision", and the after gives you the client's question list:

washed process  | approved: none  | options: [X], [Y]        | needs decision
natural process | merge with "dry process" | option: [Z]     | needs decision
cupping notes   | approved: [A]?  | note: marketing prefers [B] | needs decision
honey process   | do not translate? |                          | needs decision

Nothing from an inherited glossary counts as approved until the current client contact says so.

Turn the candidates into questions for the client, not decisions you make for them. Keep the email short and give options with context:

Before we translate the range, could you confirm a few terms? For each,
we've shown the options found in your past materials.

1. "Cupping notes" (heading on every product page): option A or B?
   A is closer to what tasters say; B is plainer for general shoppers.
2. "Honey process": translate it, or keep the source term as a
   recognised coffee term?
3. "Natural" and "dry" process: we'll use one term for both. Which?

A one-letter reply for each is perfect.

Replies aren't always one letter. An illustrative answer to question 3: "Use natural on the website, but our wholesale price list says dry process and our café customers know it, so leave that alone." That's two approved terms for one concept, which is fine if the termbase says where each belongs. Record [Z] as approved for web and retail packaging and the dry-process rendering as approved for wholesale documents, each with a context note, and forbid neither. Don't quietly pick one because it's tidier; the next price-list job would come back "corrected" to a term the client asked you not to use there.

Record each decision in a structured entry. A filled-in example, with the target term shown as a placeholder:

SOURCE TERM: cupping notes
APPROVED TARGET: [option A]
FORBIDDEN VARIANTS: [option B]; [old brochure variant]
DEFINITION: the flavours a professional taster records when assessing
  a coffee; used as the heading above flavour descriptors
CONTEXT: product page heading; always capitalised as a heading
STATUS: approved by client (marketing lead), 7 Oct 2026
SOURCE OF DECISION: email reply, filed in project folder

Forbidden variants matter as much as the approved term, because they're what QA tools check against. If you need to move the termbase between tools, or hand it to an agency, export it as TBX (TermBase eXchange, the ISO 30042:2019 format), which keeps the structure intact. The same approach for a business's own product names, rather than a translator's, is covered in building a product glossary AI must use in every draft.

Step 3: Put the termbase where the drafts are made

A termbase that sits in a folder doesn't change the draft. Connect it to whatever produces your first version:

• Machine translation glossaries. DeepL's glossary limits depend on the plan: the Team plan allows five glossaries of up to 1,000 entries per language pair, and the Business plan unlimited glossaries.
• CAT tool AI. Trados Studio 2026's AI Assistant can be directed to use your termbase, and memoQ AGT builds its output using your translation memories, termbases and LiveDocs.
• A chat assistant, for short texts. Paste the relevant entries into the prompt with a strict instruction.

For the chat-assistant route, the prompt needs to rule out the style-driven swaps:

Translate the text below. Use the glossary terms EXACTLY every time the
source term appears, including in headings, adjusting only grammatical
endings where the target language requires it. Never replace a glossary
term with a synonym, even to avoid repetition. After the translation,
list every glossary term you used and the segment it's in.
GLOSSARY: [source = approved target; forbidden: ...]

The list at the end is useful, but treat it as a claim. On an illustrative 80-word newsletter blurb, the model's closing list read "cupping notes = [A] (heading); filter roast = [approved term] (line 2); natural process = [Z] (line 3)". The heading actually carried a synonym for [A]: the model reported the term it had been told to use, not the one it wrote. Searching the output for each approved target takes under a minute on a short text and catches it.

An illustrative before and after shows what goes wrong without that line. The source says "Both cupping notes panels are on the back of the bag." With the glossary applied as a plain find-and-replace, the draft contains the approved term, but in its singular base form, so the heading term no longer agrees with "both" and the plural verb. A reader sees a small grammatical slip on every bag. With the prompt allowing grammatical endings, the approved term appears in its correct plural form and the audit in step 4 still recognises it as the approved term.

The instruction about grammatical endings matters. Glossaries in engines tend to insert the base form, which then sits wrongly in a sentence that needs a plural or a case ending. Expect to fix those by hand, and check them in step 4.

Take care with terms that are also everyday words. In the roaster's brewing guides, "bloom" means the first small pour that lets freshly roasted coffee release gas; on the farm-origin pages, the same word describes the coffee trees flowering before harvest. Engine glossaries generally apply an entry wherever the source word appears, so adding "bloom" would force the brewing term into the flowering sentence. Leave terms like this out of the engine glossary, keep them in the termbase with a definition and a context note for each sense, and check every occurrence in step 4. In an illustrative run with no glossary entry, the engine rendered the brewing sense correctly in six of nine segments and used the flower word in the other three, which is exactly the pattern the audit is there to find.

Whichever route you use, the drafts still get post-edited; the routine for that is in a translator's post-editing workflow.

Step 4: Audit every rendering after translating

Two checks, done in this order, catch nearly everything.

The AI audit. Give a language model the source, the target and the term list, and ask for a map rather than corrections:

For each glossary term, list every segment where the source term (or
its variants) appears and quote how it was translated. Flag any segment
where the approved target term is missing, a forbidden variant appears,
or a different word is used. Do not correct anything.

An illustrative result on the roaster's product pages: "cupping notes" appears in 112 segments; 109 use the approved term, two use the forbidden option B (both in pages translated before the client's decision arrived), and one uses a third phrase the model introduced in a heading. "Honey process" is left untranslated, as agreed, in all nine cases. That's three fixes you might have missed reading page by page.

Check the audit's coverage before trusting its "all consistent" lines. Compare the model's count for each key term with your CAT tool's concordance or filter count. In an illustrative check on the brewing guides, the model reported 26 occurrences of "filter roast", all consistent; the CAT tool found 31. The five it missed were all in the last guide of the upload, which the model had skipped, a common result when too much text goes in at once. Rerun the audit on that file alone, and on large jobs audit file by file rather than in one go.

The QA tool check. Then run your CAT tool's terminology check. In Trados Studio, the Terminology Verifier can flag target terms marked as forbidden in the termbase, which requires a picklist field in the termbase for marking them. In ApSIC Xbench, the Key Term Mismatch check flags segments that deviate from glossaries you've designated as key terms. These tools are deterministic, so they don't miss an exact match, but they also don't understand inflection or rephrasing, which is where the AI audit helps. Using both is the point.

Do-not-translate lists are terminology too

Some of the most visible consistency errors are words that should never have been translated at all. A delicatessen's own-label range is a good illustration: product line names, a house blend of spices with a trademark-style name, the shop's loyalty scheme and its "click and collect" service name. An engine will translate a product line whose name is an ordinary everyday phrase literally in one place and leave it alone in another, and a customer searching the translated site then can't find the product the newsletter mentioned.

Keep these in the termbase as entries whose approved target equals the source, marked "do not translate", and lock them as non-translatable in the CAT tool where you can. Ask the language model in step 1 to list capitalised phrases, product names and anything that looks like a brand, then confirm the list with the client. The same list protects prices, units and codes, which is covered in the pre-flight stage of post-editing.

Step 5: Handle term changes without breaking earlier files

Clients change their minds, and the dangerous moment is midway through a project. A realistic slip: halfway through the roaster's range, the client decides "filter roast" should use the plainer of the two options. The translator updates the termbase and carries on. Three weeks later, the client points out that the first 40 product pages still use the old term. Nothing was wrong with the tools; the change simply wasn't applied backwards.

Build a change routine instead:

1. Record the change in the termbase entry with the date, and move the old target to forbidden variants.
2. Search all delivered and in-progress files for the old term, including the translation memory.
3. Update the memory so future matches carry the new term.
4. Tell the client which delivered files changed, and send updated versions.

Moving the old term to "forbidden" is what makes step 4's QA catch any stragglers on the next run. The client notice in the last step can be short. Illustrative:

Following your change to "filter roast" on 14 Oct, we've updated the
40 product pages delivered before that date (list attached) and the
translation memory. The updated files are in today's delivery folder;
please replace the earlier versions on your site.

The attached list matters more than the wording. Without it, the client's web team has to guess which pages to re-upload, and a few old pages stay live with the retired term, which the next site-wide audit then reports as your inconsistency. Ask the client to confirm when the replacements are published, and note the date in the termbase entry.

The roaster's full range, start to finish

Putting numbers on the illustrative job: 120 product pages plus brewing guides, about 18,000 source words, one language pair.

• Extraction and review: 1.5 hours. The model proposed 85 candidates; after removing everyday words and merging duplicates, 52 terms remained.
• Client decisions: two emails, one day's wait. The client decided 14 terms with past variants; the other 38 were confirmed as proposed.
• Termbase entries and glossary set-up: 1 hour. Termbase in the CAT tool, glossary in the engine, TBX export for the client's records.
• Translation and post-editing: as normal, with fewer term lookups than usual because decisions had been made up front.
• Audit and QA: 1 hour. The AI audit flagged 17 segments; 14 were real inconsistencies, three were acceptable grammatical variants. The Xbench check found two more.

About three and a half hours of terminology work on an 18,000-word job, most of it before translation started. The payoff shows up later: the client's next product launch reuses the termbase, and the terms on the website, the packaging and the newsletter finally match. Agencies running several linguists on one client need this even more; the agency-level set-up is in building an AI-assisted workflow for a small translation agency, and the final customer-facing check in checking AI translations before customers see them.

Terminology questions from translators

Can AI decide which translation of a term is correct?

It can suggest options and explain the differences, but it can't know which one your client prefers, which one their competitors use, or which one their packaging already carries. Those are client decisions. Present the AI's options with context, get a decision in writing, and record it in the termbase with the date and who approved it.

Is a spreadsheet good enough as a termbase?

For a single translator with one client, a well-kept spreadsheet with columns for source term, approved target, forbidden variants, definition, context and status works. It becomes a problem when several linguists or tools need it. At that point, import it into your CAT tool's termbase, or export it as TBX so it can move between tools without losing structure.

How often should a client's termbase be reviewed?

Review it whenever the client launches a new product line or rebrands, and at least once a year otherwise. Look for terms marked 'proposed' that were never approved, forbidden variants that keep appearing in QA, and entries without a context note. A short annual review with the client keeps the termbase trusted rather than ignored.

Further reads

• Is It Safe to Put Client Documents Into AI Translation Tools? — Check the tools you use are safe for client text.
• Does Your Translation Business Need an AI Usage Policy? — Write down how you use AI on client work.
• Is Machine Translation Good Enough for Client-Facing Documents? — Know when MT output is fit for customers.
• How to Write a House Style Guide Your Team and AI Both Follow — Pair the termbase with a style guide people follow.
• AI Hallucinations Explained for Business Owners: Causes and Fixes — Why models confidently invent plausible terms.
• How to Offer Multilingual Customer Support With AI Translation — Where client termbases end up being reused next.
• AI Translation vs Human Translators: What Documents Really Cost — What a 2,000-word document costs by AI, by AI plus a bilingual reviewer, and by a human translator, with a tour operator's year costed three ways.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: DeepL Pro plan page (glossary limits by plan); RWS Trados Studio 2026 documentation (AI Assistant with termbase; Terminology Verifier forbidden terms); memoQ AGT documentation; ApSIC Xbench documentation (Key Term Mismatch check); ISO 30042:2019 (TermBase eXchange) catalogue entry.