People searching termbase matching rules, CAT tool term matching, exact term match, prefix term matching, fuzzy terminology matching, term case sensitivity, or how to recognize inflected terminology in CAT tools are solving a subtle productivity problem: a glossary entry is useful only if the editor recognizes the term when it appears in real source text.
A fast translation workflow tunes termbase matching rules so legitimate grammatical variants are found without turning every similar-looking word into a terminology hit. Current terminology systems may offer behaviors described as exact, prefix, fuzzy, or custom matching, plus different levels of case sensitivity. These settings determine whether an entry such as “project” also matches “projects,” whether a German singular can recognize a plural, whether a compound triggers a term hit, or whether an acronym must match uppercase exactly.
This article owns one narrow reader job: configure or choose term matching behavior that gives useful terminology recognition with manageable false positives. It is different from deciding which term is approved, ranking multiple termbases, or checking glossary compliance. Here the terminology already exists. The problem is whether the CAT tool recognizes the right surface forms.
Quick answer
Use the narrowest matching rule that still finds the forms you need.
A practical hierarchy:
Exact — fixed forms, codes, acronyms, tightly controlled names. Prefix — simple suffix variation such as plural/endings. Fuzzy — larger morphological or orthographic variation, used cautiously. Custom — deliberate wildcard/stem rules when you know the pattern.
Then configure case sensitivity.
Test the entry against:
- one form that should match;
- one form that should not.
A matching rule is good when recall improves without creating distracting false hits.
Why terminology recognition fails
A termbase can contain the right term and still fail to help.
Source entry:
project
Source text:
projects
If matching is exact, the editor may not highlight it.
The translator assumes the glossary has no entry.
They invent a new target.
Consistency drifts.
The terminology resource was correct.
Recognition was too strict.
The opposite failure: too many hits
Termbase contains:
cat
A permissive prefix rule matches:
catalog
Now the editor highlights a source word that has nothing to do with the animal.
False hits create:
- distraction;
- wrong suggestions;
- QA noise.
Recognition became too broad.
Term matching is therefore a precision–recall tradeoff.
Exact matching
Exact matching is appropriate when the source form should be recognized only as stored.
Good candidates:
- product codes;
- acronyms;
- model names;
- fixed legal abbreviations;
- terms where suffix variants have different meanings.
Exact matching reduces false positives.
It can miss valid inflections.
Use when identity matters more than flexibility.
Worked example 1: acronym
Entry:
API
You want to recognize:
API
but not:
capital
A case-sensitive exact rule is sensible.
Loose fuzzy matching would be dangerous.
The term is short and identity-specific.
Worked example 2: product code
Entry:
XR-15
Do not let the termbase match:
- XR-150;
- XR-15B;
- XR-51.
Exact recognition prevents product confusion.
This is a high-consequence case.
Prefix matching
Prefix matching is useful when the core term remains stable and grammatical material is appended.
Example:
project
should recognize:
projects.
A moderate prefix rule can allow the suffix without matching a much longer unrelated word.
This works well in some languages and poorly in others.
Test.
Worked example 3: plural
Entry:
sensor
Source:
sensors
Prefix recognition finds it.
Now the translator sees the approved target.
No duplicate plural entry is required.
The termbase remains cleaner.
Worked example 4: false prefix
Entry:
man
Source:
management
A permissive prefix rule may produce a false hit.
Short stems are risky.
Exact matching may be safer.
Term length affects matching strategy.
Fuzzy matching
Fuzzy term matching can recognize forms with changes inside the word, not only at the end.
This can help in languages with:
- vowel changes;
- inflection;
- compounds;
- orthographic variation.
It can also produce many false positives.
Use it when morphology justifies the noise.
Worked example 5: German plural
Entry:
Mutter
Source:
Mütter
A simple prefix rule may fail because the stem changes.
Fuzzy matching can recognize the relationship.
This is useful.
Worked example 6: similar but unrelated word
Entry and source are 80% visually similar.
They represent different concepts.
Fuzzy matching highlights them anyway.
The translator must not infer semantic equivalence from string similarity.
Matching is retrieval.
Meaning still requires judgment.
Custom matching
Custom matching is valuable when you understand the morphology or recurring pattern well enough to define it.
A custom stem/wildcard can recognize intended forms while excluding unrelated extensions.
This can outperform broad fuzzy matching.
But it requires testing.
A bad wildcard can create even more false hits.
Case sensitivity
Case is sometimes semantic.
Examples:
- “Will” as a name versus “will” as modal verb;
- “US” versus “us”;
- product names;
- gene/protein symbols;
- XML;
- acronyms.
Use strict case sensitivity where case carries identity.
Use permissive behavior for ordinary nouns where sentence-initial capitalization should still match.
Worked example 7: brand capitalization
Entry:
iCloud
Source:
iCloud
A case-sensitive rule can prevent hits on incorrect variants.
However, if source authors sometimes write “ICLOUD” in headings, strict matching may miss valid occurrences.
Project source quality affects the choice.
Worked example 8: ordinary noun at sentence start
Entry:
controller
Source sentence begins:
Controller status is shown below.
If case sensitivity is too strict, the term may not match because of initial capitalization.
Permissive case behavior is more useful.
Matching source and target terms separately
Some terminology systems allow matching settings per language or per term variant.
This is valuable.
The source language may need fuzzy recognition.
The target language may need stricter QA.
Do not assume one matching behavior fits both sides.
Source-side recall versus target-side QA
Source-side goal:
find the concept when it appears.
Target-side goal:
verify the approved form is used correctly.
A fuzzy source rule can improve recall.
A fuzzy target rule can create false compliance because an almost-correct target is accepted.
Be deliberate.
Matching multiword terms
Entry:
board of directors
Source may contain:
boards of directors.
Rigid exact matching can miss the plural.
Fuzzy or custom matching can help.
But multiword fuzzy matching can also match phrases with meaningful changes.
Test examples.
Matching compounds
Germanic languages often build compounds.
A component term may appear inside a longer word.
Broad matching can surface useful terminology.
It can also highlight unrelated compounds.
Decide whether the component’s meaning remains stable inside compounds.
Matching prefixes
Some languages encode grammatical or derivational meaning before the stem.
Prefix-based algorithms that only tolerate suffixes may be inadequate.
Fuzzy/custom rules can help.
This is why matching settings must fit language structure.
Matching suffixes
Plural, case, tense, and derivation may add suffixes.
Moderate prefix matching often works well when the stem remains stable.
It can fail when the stem changes.
Matching internal changes
Umlaut, vowel alternation, consonant mutation, and irregular inflection require more flexible recognition.
Use fuzzy matching selectively.
Do not broaden every termbase entry globally because a few terms need it.
Matching misspellings
Some fuzzy term matchers can recognize typos.
This can be helpful for dirty source.
It can also hide source-quality problems.
If a term matches only because the source is misspelled, consider fixing or querying the source.
Terminology recognition should not become silent source normalization.
Failure mode 1: exact everywhere
The termbase has high precision and poor recall.
Translators keep missing valid inflections.
They add duplicate surface forms.
The glossary bloats.
Use more appropriate matching for variable terms.
Failure mode 2: fuzzy everywhere
Everything looks like a term.
The translation results pane becomes noisy.
Terminology QA produces false positives.
Translators stop trusting the resource.
Use flexibility selectively.
Failure mode 3: ignoring case
Acronyms collide with ordinary words.
Brand capitalization becomes invisible.
Turn on case sensitivity where identity depends on it.
Failure mode 4: overusing wildcards
Custom rule matches unintended derivatives and compounds.
Test negative examples.
A rule needs both:
- should match;
- should not match.
Failure mode 5: one default for every language
A matching default designed for English may work poorly for Polish, German, Arabic, Finnish, Hungarian, or another morphological system.
Configure per language where the tool supports it.
Build a positive/negative test set
For each tricky term, write:
Should match
- base form;
- plural;
- expected inflection.
Should not match
- unrelated similar word;
- wrong compound;
- wrong capitalization;
- deprecated variant.
Adjust rule until the set behaves correctly.
This is faster than discovering false hits during live translation.
Worked example 9: short stem
Entry:
net
You want:
nets
You do not want:
network.
A generic prefix rule may be too broad.
Use exact plus explicit plural variant, or a custom rule if supported.
Short entries deserve caution.
Worked example 10: long technical term
Entry:
immunohistochemistry
Source variants are limited.
Exact may be enough.
Fuzzy matching adds little and risks weird false hits.
Long stable terms often need less flexibility.
Worked example 11: hyphenated variant
Entry:
risk based
Source:
risk-based
Does the matcher normalize hyphens?
Test.
If not, add an approved variant or custom rule.
Do not assume punctuation normalization.
Worked example 12: spacing variation
Entry:
e commerce
Source:
e-commerce / ecommerce.
These may be style variants or different source quality.
Matching can recognize them.
Terminology/style rules should decide which target form is preferred.
New-term defaults
If most terms in a language behave similarly, configure sensible defaults for new entries.
This makes quick-add faster.
But review exceptions:
- acronyms;
- product codes;
- short ambiguous terms.
Default saves clicks.
Exceptions preserve precision.
Matching settings and quick-add
Quick-added terms often inherit defaults.
If defaults are wrong, every new entry repeats the mistake.
Audit a sample of new entries.
This is why working-term-base design matters.
Matching settings and term extraction
Extracted terms may arrive as lemmas or surface forms.
Choose matching according to how they will appear in source.
Do not assume imported terminology already has ideal recognition settings.
Matching settings and termbase priority
A high-priority termbase with overly broad fuzzy matching can dominate the results pane.
Priority and matching interact.
A resource can be authoritative and still noisy.
Tune both.
Matching settings and glossary compliance
Terminology QA uses recognition logic.
If matching is too permissive, QA can produce false positives.
If too strict, QA can miss violations.
Term matching is therefore a quality setting as well as a lookup setting.
Matching settings and forbidden terms
A forbidden term should be recognized reliably.
If inflected variants escape the matching rule, the QA may miss them.
Use matching that covers real forbidden forms without flagging unrelated words.
This can be more important than preferred-term recognition.
Matching settings and case-sensitive forbidden forms
Suppose one uppercase acronym is forbidden but lowercase ordinary word is fine.
Case sensitivity can prevent unnecessary warnings.
Precision matters.
Termbase noise audit
Sample 100 highlighted terms.
Classify:
- correct useful hit;
- correct but low-value;
- wrong sense;
- false string match.
If false-hit share is high:
- tighten matching;
- shorten/lengthen source entry appropriately;
- change case settings;
- separate domains.
Termbase miss audit
Take known source terms that should be recognized.
Are they highlighted?
If not:
- exact rule too strict;
- entry form wrong;
- morphology differs;
- punctuation/spacing variation;
- language mismatch.
Improve recall deliberately.
Precision versus recall
This is the core tradeoff.
High precision
Few false hits.
May miss variants.
High recall
Finds many variants.
May create noise.
The ideal setting depends on:
- term consequence;
- term length;
- language morphology;
- project scale.
No universal best.
High-risk terminology
For medical, legal, safety, and regulatory terms, prefer predictable recognition.
You may store explicit variants instead of extremely broad fuzzy rules.
False positives can mislead.
False negatives can hide compliance failures.
Test carefully.
Low-risk productivity terminology
For internal documents, slightly broader matching may be acceptable if it saves lookup.
Risk changes the balance.
Team consistency
If team members use different termbase copies with different matching settings, they see different suggestions.
Centralized resources improve consistency.
Term recognition behavior is part of shared workflow.
Resource versioning
When matching rules are changed substantially, note the change.
If terminology hit rate suddenly changes, the team needs to know why.
This is especially important for shared QA.
A five-minute matching calibration
Pick ten important terms.
For each:
- find two valid variants;
- find one plausible false variant;
- run current matching;
- note misses/false hits;
- adjust only where necessary.
This is a practical calibration sample.
When to add variants instead of loosening matching
If only one irregular form exists, add it explicitly.
Do not switch the whole term to fuzzy matching just to catch one exception.
Specific variants can preserve precision.
When to loosen matching instead of adding dozens of variants
If the language regularly produces many predictable forms, a more flexible rule is more maintainable.
Use linguistic structure.
Matching and compound-heavy languages
A term can appear inside long compounds.
Decide whether retrieving the component is genuinely useful.
If yes, fuzzy/custom matching can create large productivity gains.
If no, exact matching keeps the result pane quiet.
Matching and agglutinative languages
Many suffix sequences can attach to one root.
A naive exact glossary becomes nearly invisible.
Language-aware or custom matching can be essential.
Do not solve by storing every surface form manually if the tool can model the variation.
Matching and analytics
If termbase hit rates are unexpectedly low, matching configuration may be the cause.
Terminology coverage metrics should be interpreted with recognition rules in mind.
A term can exist in the database and still be operationally invisible.
Matching and onboarding
New translators trust highlighting.
If matching is noisy, they learn to ignore the termbase.
If matching is precise, they learn to rely on it.
Configuration affects human behavior.
A term-matching worksheet
For tricky entry:
Source term: Meaning: Expected variants: False friends/similar strings: Case behavior: Chosen matching: exact/prefix/fuzzy/custom. Positive tests: Negative tests: Target QA behavior:
This is enough for high-impact entries.
The deeper principle: make the termbase recognize language, not letter accidents
A terminology database creates value only when its entries meet real text.
Matching settings are the bridge.
Too strict and the termbase stays silent.
Too loose and it becomes noise.
The goal is not maximum highlighting.
The goal is:
highlight the forms that represent the concept often enough that translators and QA can trust the signal.
That is why term matching is a productivity setting.
Advanced practice: calibrate matching by term length
Term length strongly affects false-hit risk.
A short entry:
gas
can appear inside many longer strings.
A long entry:
differential pressure transmitter
is much more distinctive.
Therefore a sensible matching policy may be:
- short terms → exact or carefully custom;
- medium terms → prefix where morphology supports it;
- long technical phrases → more permissive matching may be safe.
Do not apply the same fuzzy tolerance to every string length.
Matching and token boundaries
Different systems define word boundaries differently.
A term may fail because:
- hyphen treated as separator;
- slash treated as part of token;
- apostrophe splits token;
- punctuation remains attached.
Test real source examples.
Matching settings cannot compensate for misunderstood tokenization.
Worked example 13: slash variant
Entry:
input/output
Source:
input / output
Will it match?
Tool behavior varies.
If spacing and punctuation variants recur, store explicit variants or custom rules.
Do not assume normalization.
Worked example 14: apostrophe
Entry:
user account
Source language variant uses possessive/apostrophe forms.
Exact matching may miss.
Prefix may not help multiword structure.
Add variant or choose matching that handles it.
Worked example 15: compound with inserted modifier
Entry:
data protection policy
Source:
corporate data protection policy
If matcher only finds entries at expression start, the embedded phrase may not hit.
Understand tool limitations.
A termbase can be correct and still not recognize embedded use.
Project search or concordance can fill the gap.
Match start rules
Some terminology systems require the entry to begin at the start of the matched expression.
That means a term may not be found inside a larger phrase in all modes.
This matters especially for compounds.
Do not misdiagnose it as missing terminology.
Matching target terms for QA
Suppose preferred target is:
service account
Translator writes:
service accounts
If target-side matching is exact, glossary QA may incorrectly report missing approved term.
If prefix/fuzzy is too broad, QA may accept:
servicing account
Tune target matching separately.
Case sensitivity modes
Some systems offer more than simple yes/no.
A permissive mode may require uppercase letters in the term to match while allowing lowercase letters to vary.
This can be useful for:
- acronyms inside ordinary terms;
- mixed-case brand names.
Learn what the mode actually does.
Worked example 16: acronym inside phrase
Entry:
XML parser
You want:
- XML parser;
- XML parsers.
You do not want:
- xml parser if brand/style requires uppercase.
Configure case + suffix behavior accordingly.
Worked example 17: sentence-initial brand
Brand:
orbitX
At sentence start, source writer incorrectly uses:
OrbitX
Should term matching accept it?
If brand case is mandatory, strict matching reveals source inconsistency.
If source normalization is desired, permissive may be okay.
Resource policy determines behavior.
Matching and diacritics
Some tools may treat accented and unaccented forms as distinct or fuzzy variants.
For names and technical terms, this matters.
Do not let fuzzy matching silently accept missing diacritics if orthography is significant.
Test.
Matching and Unicode normalization
Visually identical text can contain different Unicode compositions.
If a term inexplicably fails to match, normalization may be involved.
This is rare but important in multilingual systems.
Use Unicode-safe pipelines.
Matching and stemming
Terminology matching is not always linguistic stemming.
A “stem” in custom rules may simply mean a literal character sequence.
Do not assume the tool understands morphology like a linguist.
Test the actual pattern.
Custom wildcard discipline
When using * or equivalent wildcard:
- make the fixed stem long enough;
- test unrelated extensions;
- avoid very short roots.
Broad wildcards can explode false positives.
Pipes or stem markers
Some CAT systems let you mark the boundary between fixed and variable parts.
This can be powerful for predictable inflection.
Document the pattern for team maintainers.
Custom rules are code-like configuration.
Matching defaults by language
Set default matching for new terms per language where supported.
Example:
- English: moderate prefix;
- German: fuzzy/custom for compounds where useful;
- product codes: exact via entry overrides.
Defaults reduce repetitive setup.
Overrides handle exceptions.
Matching defaults by termbase
A brand termbase may default to exact/case-sensitive.
A general technical TB may default to prefix.
Resource purpose can determine defaults.
Matching and term variants
If one concept has source variants:
- “login”;
- “log-in”;
- “sign-in”;
do not rely on fuzzy matching to equate them if they are true lexical variants.
Store variants explicitly under one concept.
Matching rules handle morphology.
Variants handle synonymy.
Matching and synonyms
String similarity is not semantic synonymy.
“car” and “automobile” require explicit concept variants.
Fuzzy matching cannot know they are related.
Terminology modeling remains necessary.
Matching and homographs
Same source string can represent multiple concepts.
Matching rules cannot disambiguate.
Use:
- domain;
- definition;
- context;
- separate entries.
Recognition only says the string appears.
Matching and abbreviations
Store:
- full term;
- abbreviation;
as variants if both should trigger.
Do not expect fuzzy matching to connect them.
Matching and acronym plurals
Acronym plural may be:
- APIs;
- API’s in bad source;
- API.
Decide which forms should match.
Explicit variants can be safer than broad fuzzy.
Matching and hyphenation policy
If source authors vary:
- pre-processing;
- preprocessing;
a custom or variant-based solution may reduce misses.
Also consider source style cleanup.
Terminology matching should not compensate forever for poor authoring.
Matching and source normalization
Some pipelines normalize:
- case;
- punctuation;
- whitespace.
Know whether matching occurs before or after normalization.
This explains surprising hits.
Matching and forbidden variants
Forbidden target term:
insuree
Approved:
insured person.
If forbidden form has inflections, ensure QA can recognize them.
A too-strict forbidden rule creates false negatives.
Matching and compound false positives
Entry:
port
Source:
portable.
A permissive prefix may match incorrectly.
Short terms need negative testing.
This is one of the strongest reasons to avoid blanket prefix/fuzzy settings.
A false-hit cost model
A false term hit costs:
- visual attention;
- possible wrong insertion;
- QA warning;
- reduced trust.
Multiply by hundreds of segments.
Matching precision has a real productivity value.
A miss cost model
A missed term costs:
- repeated lookup;
- inconsistent translation;
- reviewer correction;
- QA miss.
Balance both.
Tune by consequence
For high-risk terms, a missed hit may be more expensive than occasional noise.
For common low-risk words, false hits may be the bigger cost.
Matching settings should reflect consequence.
Build a matching regression set
Keep a small list of tricky terms and expected behavior.
After changing defaults or importing a TB, rerun.
This prevents configuration drift.
Regression set example
Term: API Should match: API, APIs if policy allows. Should not: capital.
Term: project Should: projects. Should not: projection if concept unrelated.
Term: DataSync Should: exact case only.
This set can test configuration quickly.
Matching after terminology import
CSV/TBX imports may carry matching metadata—or may not.
After import:
- inspect defaults;
- test high-value entries;
- verify case behavior.
Do not assume imported terms behave like manually created ones.
Matching after merge
When duplicate entries are merged, check which matching rule survives.
A permissive setting from one duplicate may unexpectedly broaden the final entry.
Resource cleanup can change recognition.
Matching and cloud/desktop differences
If translators work across desktop and web editors, confirm termbase matching behavior is consistent enough for the project.
The interface may differ even when resource logic is shared.
Document any important limitations.
Matching and terminology review
Reviewers should know whether a missed term was:
- absent from TB;
- present but unmatched;
- ignored because of context.
This distinction guides the fix.
Do not automatically add duplicates when the real problem is matching configuration.
A diagnostic sequence for “the termbase missed it”
When an expected term is not highlighted:
- confirm term exists;
- confirm language;
- confirm TB attached;
- inspect source spelling;
- inspect matching rule;
- inspect case;
- inspect punctuation/spacing;
- add variant or change rule.
This is faster than randomly editing entries.
A diagnostic sequence for “the termbase is noisy”
When too many irrelevant hits appear:
- identify which TB produced them;
- inspect short entries;
- inspect fuzzy rules;
- inspect prefix rules;
- inspect domain scope;
- tighten specific entries before changing global defaults.
Fix narrowly.
Matching and resource priority
If noisy low-priority TB produces many hits, lower priority may reduce visual dominance.
But false hits still exist.
Fix matching too.
Ranking and recognition solve different layers.
Matching and performance
Very large termbases with extremely permissive matching can increase lookup load.
Modern systems handle large resources well, but unnecessary broad matching still creates human noise.
Optimize for people first.
Matching and terminology analytics
Hit counts can help find terms that never match.
If an important entry has zero hits in a large corpus, check:
- source form;
- matching;
- variants.
The term may be operationally dead.
Language-specific expertise matters
Do not copy English matching policy into every language.
Ask translators:
- where inflection occurs;
- how compounds form;
- what case means;
- how capitalization works.
Termbase matching is partly linguistic engineering.
A practical team standard
For each language, document:
- default matching;
- default case sensitivity;
- exceptions for acronyms;
- exceptions for short terms;
- custom rule conventions.
This reduces inconsistent entry behavior.
The mature result
In a well-tuned termbase:
- most important terms highlight;
- irrelevant strings rarely do;
- QA warnings are believable;
- translators trust suggestions.
That trust is the real productivity output.
Advanced practice: matching rules for preferred and forbidden pairs
A terminology entry can contain both:
- preferred term;
- forbidden variant.
These two forms do not always need identical matching.
Example:
Preferred:
authorization
Forbidden legacy form:
authorisation
If the target locale is US English, exact matching may be enough to flag the forbidden British spelling.
In an inflected language, the forbidden form may need flexible matching so all grammatical variants are caught.
Term-level rules should follow the behavior you need.
Matching and grammatical gender
A target term may have gendered variants.
If the preferred concept can appear in masculine and feminine forms, store valid variants rather than forcing fuzzy matching to guess.
Terminology matching works best when lexical variation is modeled explicitly where meaning or social reference changes.
Matching and number
Singular/plural is often grammatical.
Prefix matching can help.
But some languages change the stem.
Use:
- explicit variant;
- fuzzy;
- custom pattern;
depending on regularity.
Do not store two separate concepts for one inflection.
Matching and verbs
Verb forms can vary dramatically.
A termbase entry may store infinitive/lemma.
Will the matcher find:
- past tense;
- participle;
- imperative?
Test before relying on termbase lookup for verbal terminology.
In some language pairs, explicit variants or fuzzy settings are necessary.
Matching and derivation
Source entry:
authenticate
Text:
authentication.
Are these the same terminology concept?
Related, yes.
Same lexical term, not necessarily.
Do not use fuzzy matching merely to connect every derivational family.
A noun and verb may have different approved targets.
Terminology structure should represent the relationship intentionally.
Matching and semantic drift in compounds
Entry:
security
Source:
security deposit.
The compound may have a specialized meaning unrelated to generic “security.”
If the termbase highlights the component aggressively, the suggestion can mislead.
Short broad terms deserve narrow matching or domain-specific entries.
Matching and phrase boundaries
Entry:
quality assurance
Source:
quality assurance process.
Prefix matching can be useful.
But if entry is:
assurance
and source phrase is “quality assurance,” highlighting the subterm may add little value.
Decide which conceptual level matters.
Matching and stop words
Articles/prepositions inside multiword terms can vary by language.
Some tools may ignore or normalize them; others do not.
If a term keeps missing because of small function-word variation, consider variants rather than very broad fuzzy matching.
Matching and punctuation-heavy terms
Examples:
- C-reactive protein;
- end-to-end;
- 5-year plan.
Test hyphens and numerals.
Punctuation can be meaningful.
Exact matching may be appropriate.
Matching and Unicode casefolding
Turkish dotted/dotless I and other language-specific case behavior can make simple case-insensitive assumptions dangerous.
Use language-aware tool settings.
This is another reason per-language defaults matter.
Matching and German compounds
A source term may appear as a component inside a compound.
Fuzzy matching can surface it.
Ask whether the target translator benefits from seeing the component term.
If yes, use it.
If the hit is semantically misleading in compounds, tighten.
Matching and Slavic inflection
Case endings can change several words in a multiword expression.
Fuzzy/custom matching may improve recall.
But QA can become noisy.
Build a language-specific test set.
Matching and Arabic
Root-pattern morphology and attached clitics may not behave well with simple prefix rules.
Exact or explicit variants may sometimes be safer unless the tool has language-aware matching.
Do not assume “prefix” means linguistic prefix.
Matching and Finnish/Hungarian
Agglutinative morphology can create many suffix sequences.
Storing every form is impractical.
A flexible matcher can be valuable.
But false positives need monitoring.
Language expertise should guide configuration.
Matching and Chinese/Japanese
Word segmentation differs from space-delimited languages.
Term recognition may depend on internal tokenization.
Test actual source corpus.
Do not infer behavior from English examples.
Matching and capitalization in German nouns
German common nouns are capitalized.
Case-sensitive matching rules designed for English can behave differently.
Again, language-specific defaults.
Matching and acronym expansion
Store both:
World Health Organization WHO
if both should trigger.
Do not expect fuzzy string rules to connect them.
Matching is not abbreviation resolution.
Matching and spelling reform
Historical source may contain old orthography.
Do you want the current termbase to match it?
Maybe in archival projects.
Maybe not in current content.
Add legacy variants deliberately rather than globally broadening fuzzy rules.
Matching and OCR errors
Fuzzy matching can recognize misspelled OCR output.
This can be convenient.
But if the source is systematically corrupted, fix OCR.
Termbase should not become a substitute for source cleanup.
Matching and speech transcripts
Transcripts may contain inconsistent capitalization and punctuation.
Permissive case can help.
However, misrecognized words are not terminology variants.
Do not let fuzzy matching legitimize transcription errors.
Matching and terminology density
In a very terminology-heavy technical text, even a small false-hit rate creates huge noise.
Favor precision.
In a sparse general text, broader matching may be tolerable.
Density changes the cost equation.
Matching and project scale
A false hit repeated 10 times is minor.
Repeated 100,000 times is expensive.
Large projects justify more calibration up front.
Matching and reviewer experience
Experienced domain reviewers may tolerate broad hits and use them as clues.
New translators may mistake every highlight for an instruction.
Configure for the team, not an abstract expert.
Matching and UI constraints
If the results pane can show only a few term hits, false matches can push useful terms out of view.
Precision becomes especially important.
Matching rules affect interface competition.
Matching and termbase priority interaction test
Use one known source sentence containing:
- a high-priority exact term;
- a low-priority fuzzy term.
Check which appears first.
If fuzzy noise dominates despite lower priority, tighten it.
Matching and batch QA
Before final terminology QA, consider whether live matching settings were permissive enough to catch variants.
A dedicated QA configuration may use different logic if the tool allows it.
The goal is coverage without overwhelming live translation.
Matching and incremental improvement
Do not attempt to perfect every entry at project start.
Fix the terms that:
- recur;
- cause false hits;
- are missed;
- are high risk.
Termbase quality improves where it matters.
A weekly matching-maintenance loop
For active terminology projects:
- review five false hits;
- review five missed hits;
- adjust specific entries;
- update defaults only if pattern is broad;
- rerun regression set.
Small regular tuning beats occasional massive cleanup.
A “do not broaden” rule
If one irregular form is the only problem, add the variant.
Do not change the default matcher for thousands of terms.
Broad settings should solve broad patterns.
Specific exceptions should remain specific.
A “do not duplicate” rule
If an inflected form fails to match, first inspect matching.
Do not immediately create a duplicate concept entry.
Duplicating surface forms can make terminology maintenance harder.
Matching and future reuse
A well-tuned termbase becomes more valuable over time because later projects recognize terminology reliably.
Poor matching silently destroys reuse even when the database itself is rich.
Recognition is part of asset quality.
Summary
Termbase matching rules help people translate quickly by controlling which surface forms trigger terminology suggestions and QA.
The reliable approach is:
use exact for fixed forms → prefix for simple endings → fuzzy for larger variation with caution → custom rules for known patterns → configure case sensitivity → test positive and negative examples
Do not use one setting for every term or every language.
Balance recall and precision.
A trustworthy termbase is one that appears when it should and stays quiet when it should not.
Frequently asked questions
What is termbase matching?
It is the rule a CAT tool uses to decide whether a source or target word/phrase corresponds to a terminology entry.
What is exact matching?
It recognizes only the stored form, subject to the tool’s case/punctuation behavior.
What is prefix matching?
It recognizes forms that begin with the stored term and add permitted endings or suffixes according to the tool’s algorithm.
What is fuzzy terminology matching?
It recognizes terms with broader string variation, which can help with inflection but may produce false positives.
What is custom matching?
It uses explicit wildcard or stem rules to recognize known variant patterns.
Why does case sensitivity matter?
Case can distinguish acronyms, proper names, brands, and ordinary words.
Should I use fuzzy matching for every term?
No. It can flood the editor and QA with false hits. Use it when the language or term actually needs broader recognition.
How do matching rules affect QA?
Terminology QA depends on recognizing source and target terms. Rules that are too broad or too narrow can create false positives or misses.
When should I add an explicit variant?
When only a small number of irregular forms need recognition and broad matching would create noise.
How do I know if matching is configured well?
Sample hits and misses. A good configuration recognizes expected variants and avoids unrelated strings.
Internal-link opportunities
- How People Translate Quickly | Quick-Add Terminology — for creating new entries that inherit matching settings.
- How People Translate Quickly | Termbase Priority — for ranking multiple terminology resources after recognition.
- How People Translate Quickly | Glossary Compliance — for QA based on terminology recognition.
- How People Translate Quickly | Term Extraction — for building candidate terminology sets.
- Master Art of Translation | The Terminology System — for broader concept governance.