People searching glossary compliance translation, terminology QA, forbidden terms translation, missing term check, CAT tool glossary check, termbase QA, or how to enforce approved terminology while translating are trying to solve a recurring speed problem: terminology has already been decided, yet translators and reviewers still spend time rediscovering, remembering, and correcting it.
A good translation environment can surface approved terms while a source segment is open and can also run automated checks that flag target segments when required terminology is missing or a forbidden term appears. Current TMS documentation still describes both forms of control: approved glossary entries shown in the editor and blocklist or forbidden-term checks that can warn or, under stricter project settings, prevent submission. The mechanism is simple: move terminology control from memory into the workflow.
This article has one dominant reader job: use glossary-compliance checks to catch missing approved terms and forbidden target terms while the translator is still inside the segment. It does not replace terminology extraction, concept management, termbase design, or general QA configuration. The concern here is real-time compliance: once the organization has made a terminology decision, how do we stop paying for the same terminology error repeatedly?
Quick answer
A fast terminology-compliance workflow looks like this:
- connect the correct project glossary or termbase;
- distinguish preferred, allowed, deprecated, and forbidden target terms;
- make approved source terms visible in the editor;
- insert approved target terms from the terminology resource instead of retyping when practical;
- enable missing-term and forbidden-term checks;
- tune matching so inflection and morphology do not create a flood of false alarms;
- review every warning as real, intentional exception, or false positive;
- escalate glossary conflicts instead of inventing local workarounds;
- update the governing terminology resource when an approved decision changes;
- rerun terminology QA before delivery.
The speed principle is:
a term decision should be made once, retrieved many times, and checked automatically.
Why terminology errors are expensive
A single terminology inconsistency can create a repair chain.
Suppose the approved target term for “account recovery” is A.
Translator 1 uses A.
Translator 2 uses B.
Machine translation produces C.
Reviewer normalizes some occurrences to A.
A late client reviewer finds three B variants that survived.
Project manager runs search and replace.
One occurrence of B has another meaning and is replaced incorrectly.
Now final QA finds a new error.
This is not a vocabulary problem anymore.
It is workflow debt.
Glossary compliance reduces that debt by catching divergence earlier.
Terminology recognition versus terminology compliance
These are related but different.
Recognition
The CAT tool notices that the source contains a glossary entry and displays the approved term, definition, notes, or metadata.
Compliance
The system checks whether the target actually follows the required terminology rule.
Recognition helps the translator choose.
Compliance checks whether the choice was applied.
You need both.
A visible glossary card that nobody follows is only a suggestion.
A compliance rule with no usable terminology information can become a frustrating warning machine.
Step 1: define terminology states clearly
Not every term in a terminology resource has the same status.
A mature system may distinguish:
- preferred;
- approved;
- admitted;
- deprecated;
- forbidden;
- do not translate;
- product-specific;
- locale-specific;
- historical.
The exact labels vary.
The principle is to separate:
what may be used from what should be used from what must not be used.
If all entries look equal, the translator still has to guess.
Preferred does not always mean mandatory
A preferred term may be recommended in ordinary prose.
A regulated product term may be mandatory.
A marketing synonym may be allowed only in headlines.
A terminology system should express that difference.
Otherwise the compliance layer may either:
- enforce too aggressively;
- enforce too weakly.
Speed depends on correct rule strength.
Step 2: connect the right glossary
The wrong glossary is worse than no glossary because it creates confident interference.
Before translation, confirm:
- client;
- product;
- domain;
- locale;
- version;
- approval date.
If the project is French for Canada, a French-for-France glossary may contain near-equivalents that look plausible but violate market language.
If the product was renamed last month, last year’s glossary may keep resurrecting the old name.
Terminology compliance starts with resource scope.
Step 3: make source-term recognition visible
When the source contains a known term, the editor should ideally make that fact easy to see.
Possible signals:
- underline;
- highlight;
- terminology pane;
- hover card;
- suggestion list.
The translator should be able to inspect:
- approved target;
- definition;
- part of speech;
- usage note;
- domain;
- source;
- forbidden variants.
This reduces research switching.
Term insertion is more than typing speed
Clicking or shortcut-inserting a glossary term can save a few keystrokes.
The bigger benefit is reducing transcription variation.
Suppose the approved target term is long.
Manual typing may create:
- spelling variation;
- hyphen variation;
- capitalization variation;
- wrong inflection;
- missing word.
Insertion starts from the authoritative form.
The translator can then inflect or adapt if the language requires it and the term policy allows that.
Step 4: understand missing-term checks
A missing-term check asks, conceptually:
The source contains a recognized term. Does the target contain the expected approved equivalent?
If no, the system flags the segment.
This catches cases such as:
- translator forgot the glossary;
- machine translation chose another synonym;
- old TM used a deprecated term;
- translator typed an incomplete form.
The warning appears close to the decision.
That is efficient.
Missing does not always mean wrong
A target can be correct even if the exact approved term string does not appear.
Reasons include:
- inflection;
- case marking;
- plural;
- gender;
- compounding;
- contraction;
- syntactic transformation;
- pronoun substitution;
- term omitted because target grammar expresses it elsewhere.
Therefore terminology QA needs language-aware configuration.
A naive exact-string check can create many false positives.
Step 5: understand forbidden-term checks
A forbidden-term or blocklist check asks:
Does the target contain a term that policy says should not appear?
Common reasons to forbid a term:
- old brand name;
- legally unsafe wording;
- competitor terminology;
- deprecated product label;
- noninclusive historical term;
- wrong locale variant;
- misleading technical synonym.
This is particularly powerful because translators may produce the forbidden form unconsciously.
The system acts as a guardrail.
Worked example 1: product rename
Old approved product:
“Secure Console”
New approved product:
“Control Workspace”
The old term appears in:
- TM;
- old reference PDFs;
- translator memory;
- web search results.
The glossary marks “Secure Console” as forbidden.
Now any surviving use triggers a warning.
This is much faster than relying on every translator to remember the migration.
Step 6: distinguish source-triggered checks from target-only forbidden terms
Some forbidden terms make sense only when a particular source concept appears.
Others should never appear in the target at all.
For example:
- old product name should never appear anywhere;
- one synonym may be forbidden only when translating a specific technical concept.
A strong system supports the right scope.
Overbroad blocklists create false positives.
Underbroad rules let real mistakes escape.
Step 7: tune morphology
Languages inflect.
An approved dictionary form may surface in target text as:
- plural;
- declined noun;
- conjugated verb;
- gendered adjective;
- suffixed compound.
If the compliance engine looks only for exact characters, it may flag correct forms as missing.
Possible solutions include:
- fuzzy term matching;
- stemming;
- morphological variants;
- separate approved forms;
- regex;
- termbase entries for common inflections.
Choose the method the platform supports.
The goal is not zero warnings.
The goal is meaningful warnings.
Worked example 2: false missing-term warning
Approved term:
server
Target language requires a case ending in the sentence.
The actual target form is equivalent to server-X.
Exact search does not recognize it.
The tool flags “approved term missing.”
If this happens hundreds of times, translators learn to ignore terminology warnings.
That is dangerous.
The fix is not “ignore all.”
The fix is better matching configuration.
Step 8: treat false positives as system maintenance
A false positive costs time.
One false positive is small.
The same false positive across 3,000 segments becomes significant.
When a warning is repeatedly wrong:
- identify why;
- adjust term entry or matching;
- add approved variant where legitimate;
- refine regex or exact-match setting;
- document the exception.
This keeps the compliance system trustworthy.
Warning fatigue
If the CAT tool shows twenty warnings per segment, users stop distinguishing important warnings from noise.
This is warning fatigue.
Terminology QA should prioritize:
- high-consequence missing terms;
- forbidden terms;
- recurring brand errors;
- regulated language.
Do not turn every stylistic preference into a blocking terminology error.
Step 9: classify warning severity
Useful severity levels:
Informational
Preferred wording exists, but alternatives may be acceptable.
Warning
Likely terminology issue; translator should review.
Error
Required terminology rule violated.
Blocking error
Segment cannot be completed or submitted without correction or explicit override.
Not every project needs all levels.
The key is proportionality.
Blocking rules need strong governance
A blocking forbidden-term rule is powerful.
It can prevent bad language from moving forward.
It can also stop valid work if the rule is wrong.
Before making a terminology rule blocking, ensure:
- term is unambiguous;
- scope is correct;
- variants are understood;
- override path exists;
- owner is identified.
Hard controls require high-quality data.
Step 10: define the override path
Sometimes the translator is right and the glossary is wrong.
Examples:
- source uses term in a new sense;
- target context requires another form;
- client changed decision but glossary is stale;
- approved term is grammatically impossible here.
The workflow needs a way to:
- comment;
- query;
- request terminology change;
- record intentional exception.
Never train translators to bypass the system silently.
A disagreement is useful data.
The terminology decision loop
Strong workflow:
source term appears → approved term surfaces → translator uses or questions it → compliance check runs → exception is resolved → governing resource updates → future segments benefit.
Weak workflow:
source term appears → translator improvises → reviewer changes it → no resource updates → next translator repeats the mistake.
The first loop learns.
The second loop pays repeatedly.
Worked example 3: medical terminology
Suppose the project requires a specific regulated target term for “adverse event.”
A general synonym may be understandable.
But regulatory reporting expects the approved term.
Glossary compliance flags the synonym.
The translator corrects it immediately.
That is a good use of strict terminology QA because the consequence of variation is high.
Worked example 4: marketing terminology
Source term:
“home”
Brand style prefers one target word, but two alternatives are allowed depending on context.
A hard blocking rule would be excessive.
Better:
- preferred term displayed;
- note explains usage;
- warning only if a truly banned term appears.
Terminology governance should match communication function.
Glossary compliance and machine translation
MT may produce fluent synonyms that violate client terminology.
Real-time terminology QA is valuable after MT because fluency can hide inconsistency.
The translator sees a smooth sentence and may skim it.
A missing-term warning forces attention to the approved lexical decision.
This is one reason terminology checks remain important in AI-assisted translation.
Glossary compliance and translation memory
An old 100% TM match may contain a deprecated term.
If terminology QA runs on reused segments, it can expose the conflict.
This is important.
“Approved memory” and “current terminology” can diverge over time.
Terminology rules may need to outrank historical reuse.
Which resource wins?
A useful priority model:
- current mandatory terminology;
- current product or legal rules;
- current style guide;
- reviewed client TM;
- lower-priority legacy TM;
- MT or AI suggestions.
This is not universal, but it illustrates governance.
A termbase should not merely sit beside other suggestions.
Its authority should be understood.
Glossary compliance and exact matches
Should exact matches be exempt from terminology QA?
Often, no.
A 100% source match can retrieve an old target using the wrong current term.
Run relevant terminology checks across reused content when terminology changed.
Glossary compliance and locked segments
A locked segment may contain a forbidden term after a brand migration.
If QA excludes locked content, the old term may survive.
Understand tool behavior.
For major terminology changes:
- search locked content;
- unlock affected scope;
- update;
- revalidate.
Protection from editing should not mean protection from current policy.
Step 11: keep glossary metadata useful
A target term alone may not be enough.
Helpful metadata:
- definition;
- context;
- part of speech;
- domain;
- locale;
- product;
- approval status;
- forbidden variants;
- usage example;
- source authority.
Good metadata reduces queries.
Bad metadata creates repeated hesitation.
Keep entries concise
A glossary card should help within seconds.
Do not hide the key rule inside a 400-word note.
Put critical information first:
Use X for Y product. Do not use Z. Plural allowed.
Then add detail if necessary.
Terminology is a decision-support resource.
Step 12: separate term extraction from compliance
Term extraction discovers candidates.
Compliance enforces approved decisions.
Workflow:
extract candidates → review → approve → publish to termbase → compliance checks enforce.
Do not automatically turn every extracted phrase into mandatory terminology.
Candidate frequency is not authority.
Step 13: run a terminology migration when policy changes
If a preferred term changes globally:
- update termbase;
- mark old term deprecated or forbidden;
- search current project;
- search current TM if policy requires;
- update recurring templates;
- rerun terminology QA;
- communicate the change.
Otherwise old language continues to re-enter through TM and habit.
Failure mode 1: glossary attached but ignored
Cause:
- terms are hard to see;
- warnings disabled;
- glossary too noisy.
Repair:
- improve visibility;
- reduce irrelevant entries;
- enable compliance.
Failure mode 2: every synonym becomes forbidden
The system overconstrains natural language.
Repair:
- reserve hard rules for genuine terminology requirements.
Failure mode 3: forbidden-term rule is too broad
Substring matching flags innocent words.
Example:
forbidden short string occurs inside another word.
Repair:
- exact matching;
- word boundaries;
- language-aware rules.
Failure mode 4: glossary conflicts with grammar
Approved citation form cannot appear unchanged in every sentence.
Repair:
- permit inflection;
- add variants;
- use morphological matching.
Failure mode 5: stale glossary
New product decision exists only in email.
Repair:
- update the authoritative termbase before or during project start.
Failure mode 6: translators silently override
The glossary remains wrong because nobody records the conflict.
Repair:
- create a query path;
- treat exceptions as feedback.
Failure mode 7: terminology warnings checked only at final QA
Hundreds of violations accumulate.
Repair:
- surface term checks live where practical;
- still run final batch QA.
Failure mode 8: blocklist contains ambiguous common words
The tool flags too much.
Repair:
- scope the entry;
- add source trigger;
- use context note.
A terminology-warning triage
When a warning appears, ask:
Is the term genuinely mandatory?
If yes, correct it.
Is the target a valid inflected form?
If yes, fix the rule or add variant.
Is this a legitimate contextual exception?
Document it.
Is the glossary stale?
Escalate.
Is the warning caused by bad substring matching?
Refine the entry.
This takes seconds once habitual.
Build a high-value blocklist
Do not start with 10,000 forbidden words.
Start with high-cost mistakes:
- former product names;
- legally prohibited terms;
- competitor names accidentally used;
- dangerous false friends;
- wrong regional spellings;
- deprecated technical labels.
A small, high-precision blocklist earns trust.
Then expand.
Translation speed and terminology density
A project with one glossary term every five pages differs from a project with five terms per sentence.
High terminology density increases:
- lookup frequency;
- consistency risk;
- QA value.
Term recognition and insertion become more valuable as density rises.
Terminology compliance for teams
In multi-translator work, glossary enforcement prevents divergence.
Without it:
Translator A chooses A.
Translator B chooses B.
Reviewer normalizes.
With it:
Both see A immediately.
If B is forbidden, the system flags it before handoff.
Team speed improves because consistency is created upstream.
Reviewer speed
Terminology QA also helps reviewers.
Instead of searching manually for every approved term, reviewers can focus on warnings and samples.
This does not eliminate reading.
It reduces mechanical checking.
Client review
Client reviewers often focus heavily on terminology.
A strong compliance layer can reduce predictable client corrections.
Every avoided client correction saves:
- email;
- explanation;
- global search;
- repair;
- reapproval.
Early terminology control has downstream value.
A compliance health metric
Track:
- terminology warnings per 1,000 segments;
- percentage real;
- percentage false positive;
- repeated glossary conflicts;
- forbidden-term escape rate;
- client terminology corrections.
A good system should show:
- fewer real violations;
- fewer false alarms;
- faster resolution.
Do not optimize to zero warnings by disabling rules
Zero warnings can mean:
- excellent translation;
- or no useful checks.
Measure quality, not dashboard cleanliness.
Glossary compliance in inflected languages
For morphologically rich languages, build policy around lemmas and acceptable forms.
Possible approach:
- termbase stores lemma;
- variants store common forms;
- QA uses language-specific fuzzy matching;
- exceptions are recorded.
Do not force ungrammatical citation forms merely to satisfy a naive checker.
Language comes first.
The checker should support language.
Glossary compliance in compounds
Germanic and other languages may form compounds that contain the approved term.
Exact whole-word matching may miss them.
The project needs:
- compound-aware matching;
- approved compound variants;
- regex;
- manual review where needed.
Again, the goal is meaningful signal.
Glossary compliance in CJK languages
Word boundaries may not be marked by spaces in the same way as English.
Term recognition needs appropriate segmentation.
Do not copy English matching assumptions blindly across languages.
Glossary compliance in right-to-left scripts
Display, punctuation, and mixed-script terms can create visual complexity.
Make sure the glossary shows:
- correct script;
- correct direction;
- preserved product tokens;
- appropriate transliteration policy.
Terminology compliance still works, but interface rendering matters.
Abbreviations and full forms
A concept may allow:
- full form first occurrence;
- abbreviation later.
A simplistic compliance rule can wrongly demand the full form every time.
Use usage notes:
First occurrence: full form (ABC). Later: ABC.
Some platforms support more advanced logic; others require reviewer judgment.
Case sensitivity
Brand names may be case-sensitive.
General terminology may not be.
Examples:
iPhone;eSIM;- acronym;
- drug name.
Set case rules intentionally.
Do not make every glossary term case-sensitive by default.
Punctuation inside terms
Terms may include:
- hyphens;
- slashes;
- apostrophes;
- symbols.
Define whether variants are acceptable.
Example:
e-mail versus email.
If brand policy chooses one, block the other where appropriate.
A five-minute glossary preflight
Before a large project:
- search the main product name;
- search five critical domain terms;
- inspect forbidden variants;
- test one inflected form;
- trigger one deliberate violation;
- confirm the warning behaves as expected.
This catches broken terminology setup early.
A practical project routine
Before translation
- attach current termbase;
- confirm locale;
- test recognition;
- test forbidden-term rule.
During translation
- inspect term metadata;
- insert approved terms;
- resolve warnings before leaving important segments;
- query conflicts.
Before delivery
- run batch terminology QA;
- inspect ignored warnings;
- search newly changed terms;
- verify deprecated terms are gone.
A practical governance routine
Every terminology decision should have:
- owner;
- date;
- scope;
- status;
- source evidence.
If nobody owns the termbase, it decays.
Compliance cannot be stronger than the data it enforces.
The deeper principle: move correctness closer to the decision
Traditional correction happens late:
translate → review → find inconsistent term → repair.
Compliance shifts the control earlier:
term appears → correct choice surfaces → violation warns immediately.
The cost of correction generally rises with distance.
A one-second correction in the current segment is cheaper than a fifty-file terminology migration after delivery.
Transfer beyond translation
The same idea appears in:
- code linters;
- spellcheck;
- schema validation;
- controlled vocabularies;
- data validation;
- design systems.
When a decision is standardized, the environment should help enforce it.
Human memory should not be the only control.
A glossary-compliance maturity ladder
Level 1
Glossary exists in a spreadsheet.