What Causes Fuzzy Matches to Fail in Translation Memory Systems

You know the segment is in the TM. You translated something nearly identical last quarter. Concordance can find pieces of it. And yet the CAT tool returns no fuzzy match—or a score so low it never appears in the results list.

This is one of the most common TM support tickets in LSP and in-house localization teams. The usual assumption is that the TM is broken or empty. More often, the unit is there and the matcher is doing exactly what it was built to do: compare surface strings, then hide anything that falls below a threshold.

What causes fuzzy matches to fail in translation memory systems is almost never a corrupt database. It is a diagnostic: the unit is there, and the matcher hid it. Check configuration first (wrong TM, segmentation, named penalties, threshold), then decide whether the miss is a limit of string-based memory.

What a Fuzzy Match Actually Measures

A fuzzy match is a previously stored source segment that is similar to, but not identical with, the segment you are translating. Tools score that similarity as a percentage. An exact match is 100%. A context match (the same segment and the same surrounding segments, or the same context ID) is typically reported as 101% or 102%. Everything from 1% to 99% is fuzzy.

Vendors do not publish a single shared formula. In practice, most CAT tools estimate similarity from edit distance—how many insertions, deletions, and substitutions it takes to turn one string into the other—plus tool-specific rules for tags, numbers, punctuation, and penalties. memoQ's own documentation is explicit that the comparison uses letters and words, not their meaning.

That last point is the one that surprises people. A synonym, a pronoun swap, an active/passive rewrite, or a clause reorder can drop the score below the retrieval threshold even when a human would call the segments interchangeable. Research on Trados, memoQ, and other tools has shown the same pattern: surface matchers struggle with paraphrase, word-order change, and inflectional variants, and short segments are penalized hardest.

If two sentences mean the same thing but share few of the same words, the TM is not “failing.” It never promised semantic retrieval.

Why an Expected Match Never Appears

When a translator says “the fuzzy match failed,” they usually mean one of three things:

  • The tool returned no hit at all
  • A hit appeared, but the score was too low to be useful (or to be shown)
  • Concordance found the text, but segment lookup did not

Those are different failures. Walk them in this order.

1. The TM is not the one being searched

Before blaming the algorithm, confirm the obvious:

  • Wrong TM attached. The unit lives in a client TM, a master TM, or an archived TM that is not enabled for this project.
  • Language-pair mismatch. A TM stored as EN-US → FR-FR will not serve EN-GB → FR-CA unless the tool is configured to look across variants.
  • Project, client, or domain filters. Many TMs store metadata and then filter lookup to “this client only” or “this subject only.” A valid unit can be invisible because the filter is stricter than the linguist expects.
  • Read-only or disabled lookup. The TM is listed, but lookup (not just update) is turned off.

If concordance against the same TM finds the string, the unit exists and the problem is scoring, segmentation, or the minimum match value—not a missing database.

2. Segmentation does not match how the unit was stored

Fuzzy matching compares segments, not documents. If the current file is split differently from the file that populated the TM, the stored unit and the live unit are no longer the same object.

  • A two-sentence source was stored as one segment; the new file splits on both periods
  • A list item, title, or table cell was segmented with different rules after a filter or import change
  • An alignment import created units that do not match the CAT tool's current sentence-break rules

Concordance still works here, because it searches inside units. Segment lookup fails because nothing in the TM is “close enough” to the newly cut sentence. Open the TM editor, find the stored source, and compare its boundaries with the current segment before you change thresholds.

3. Tags, punctuation, numbers, and spaces ate the score

This is the most common operational cause. The words look the same to a human; the matcher sees extra tokens.

In memoQ, a “high fuzzy” hit (95–99%) is specifically the band where the text is the same but numbers, punctuation, tags, or spaces differ. Other tools apply explicit penalties for formatting differences, multiple translations of the same source, or poorly aligned imported units. Either way, a handful of inline codes can push a near-exact segment under a 75% or 70% threshold so it never appears.

Check for:

  • Inline tags in different positions, counts, or types (bold, link, placeholder, XML)
  • Tag strictness set high enough that a formatting difference blocks an otherwise exact match
  • Punctuation and quotes — straight vs. curly quotes, dash types, trailing periods, extra spaces
  • Numbers and dates written differently (1,000 vs 1000, 3 April vs April 3)
  • Placeholders and variables whose names changed even though the surrounding sentence did not

If the words match and only the markup differs, this is a settings problem, not a missing translation. Review tag-permissive matching (memoQ's tag strictness is the documented control) and format penalties in the TM or project settings.

4. A named penalty subtracted points from an otherwise exact hit

Vendor docs treat this as a separate mechanism from edit distance. The matcher found the unit. Then it subtracted percentage points for a condition on the hit, and the result fell under the threshold—or landed as a high fuzzy that translators ignore.

RWS documents these Trados penalties:

  • Missing formatting / different formatting. An inline tag is present on one side and absent on the other, or the tag type changed (b vs i).
  • Multiple translations. More than one exact TM match exists for the source. The tool penalizes the hit rather than choosing a master. That is a conflict, not a missing unit.
  • Auto-localization. Dates, times, numbers, or measurements kept the source-language pattern instead of the target pattern (1,000 vs 1.000).
  • Text replacement. An acronym, variable, or alphanumeric string differs (EU vs UE).
  • Alignment. The unit came from alignment, not a confirmed translation.
  • Character-width. Full-width vs half-width characters in CJK or similar scripts.

memoQ applies the same idea with different names. Project TM settings can subtract points for a specific user, a specific TM, a workflow role, or a soft filter on a descriptive field. A strict filter hides the unit entirely. Tag strictness defaults to medium (same tag type and position; names and attributes may differ). Strict demands identical tag properties for a 100%. Permissive only requires the same number of tags.

If the Lookups panel shows a hit with a penalty icon or a 95–99% on identical words, read the penalty name before you lower the threshold. The unit is not missing. The system is marking it.

5. The minimum match value is hiding a usable hit

Every major CAT tool lets you set a fuzzy threshold. Below that number, matches are not offered. The documented defaults are not the same: Trados Studio's minimum match value defaults to 70% (inclusive; configurable 30–100%). memoQ's default TM settings return nothing under 60%, and treat 95% and above as a good match—the band where the text is the same and only tags, punctuation, spaces, or numbers differ. Projects often raise those floors to 80% or 85% to keep junk out of the results list.

That is reasonable for long, repetitive sentences. It is a problem for:

  • Short segments (under about six words), where changing one token destroys the percentage
  • Morphology-heavy languages, where a single inflectional affix can be treated as a whole-word miss
  • Word-order differences that look small to a linguist and large to an edit-distance scorer

If concordance finds the unit and segment lookup does not, lower the threshold on a copy of the project and see whether a 60–70% hit appears. Do not leave a low threshold on in production if it floods translators with noise—use it as a diagnostic, then decide whether the real fix is segmentation, tags, or accepting that this pair is a paraphrase, not a fuzzy.

6. The matcher cannot see meaning, only strings

When the current sentence is a rewrite of a stored sentence, lookup will fail even with a generous threshold. Published tests on Trados, memoQ, and OmegaT show retrieval collapsing after synonym substitution, pronoun replacement, active/passive voice changes, and clause reordering. Inflectional prefixes and suffixes are often treated as different words. Combined transformations push scores under the cutoff even when the translation could have been reused with a small edit.

This is also why “almost the same” marketing copy, UI strings with a new product name, or Scripture verses with a minor wording revision often produce no hit. The TM stored what was said, not what was meant.

7. Tokenization and script rules

Matchers split text into tokens before they score it. If the tool treats a word delimiter as an ordinary character, a whole sentence can collapse into one token and fuzzy leverage disappears. Community reports on Tibetan in Trados (the tsheg mark read as a character instead of a space) are a clear example of this class of failure; similar issues show up whenever a language's word boundaries do not match the tool's default tokenizer.

If fuzzy matching is systematically dead for one script or language and healthy for another in the same TM, suspect tokenization, not translator error. Re-indexing the TM after a delimiter fix is often required before scores recover.

A Diagnostic Sequence That Fits a Real Ticket

Use this order. It goes from cheapest checks to structural ones.

  1. Confirm lookup. Is the expected TM enabled for search, in the right language pair, without a client/domain filter that excludes the unit?
  2. Run concordance on the distinctive phrase. If concordance is empty, the unit is not in this TM (or was stored under a different language or encoding). Stop and find the right resource.
  3. Open the stored source next to the live segment. Are the sentence boundaries the same? If not, fix segmentation or retrieve via concordance and join/split manually.
  4. Diff tags, numbers, punctuation, and spaces. If only markup differs, relax tag strictness or format penalties and test again.
  5. Read the penalty on the hit. Formatting, multiple translations, auto-localization, text replacement, alignment, user/TM/role, or a soft filter can drop a 100% under the floor.
  6. Temporarily lower the minimum match value. Studio default is 70%; memoQ default is 60%. If a hit appears just under the project floor, decide whether the threshold is too aggressive for this text type or the segment is simply too short for percentage matching to be meaningful.
  7. Read the two sources as a linguist. If they are paraphrases, synonyms, or reorderings, the miss is expected. Do not keep lowering the threshold hoping the algorithm will become semantic.

What “Failure” Usually Is Not

A few explanations come up in tickets and are usually wrong:

  • “The TM is corrupt.” Rare. Missing lookup plus a working concordance almost always means scoring or filters.
  • “Fuzzy matching is random.” Scores differ across tools because the formulas differ, but they are stable for a given tool, TM, and settings.
  • “A 70% match is always usable.” On a twenty-word sentence, 70% can be one or two word changes. On a four-word string, 70% can be a different sentence. Length changes what the percentage means.
  • “Raising the threshold improves quality.” It only hides weaker hits. It does not make the remaining matches more accurate.

Fixes That Help — and Fixes That Do Not

Help:

  • Attach the TM that actually contains the work; remove filters you did not intend
  • Align segmentation rules with the TM's original import
  • Use concordance when segment lookup fails, then decide whether to store a better-cut unit
  • Relax tag matching when the text is identical and only codes differ
  • Clear or reduce a named penalty that is marking a confirmed unit as if it were aligned or multiply translated
  • Keep a lower threshold for short-segment or morphologically rich jobs; keep a higher one for long, repetitive technical text. Do not treat Studio's 70% and memoQ's 60% as interchangeable.
  • Re-index a TM after tokenization or delimiter changes

Do not help, or help only once:

  • Importing the same TM a second time “to refresh matches” (creates duplicates and conflicting entries). If matches collapsed after a tool move or TMX import, that is a migration problem, not a reason to re-import.
  • Dropping the threshold to 40% and asking translators to sort the noise
  • Treating every miss as a data-quality problem when the new source is a rewrite

If misses cluster around inconsistent stored translations, that is a quality problem—audit the TM rather than chasing scores. See How to Audit Translation Memory Quality.

The Limit You Cannot Configure Away

Fuzzy matching answers one question: have I seen a string this close before? It cannot answer whether the stored translation is appropriate for this audience, this register, or this surrounding paragraph. That is why a high fuzzy can still be the wrong suggestion, and why a semantically perfect precedent can score too low to appear.

This is the same structural limit we described in Your Translation Memory Is Faithfully Preserving Your Mistakes: the database stores outputs, not the reasons those outputs were chosen.

That is why we built Aquilla around living memory instead of string lookup. Suggestions come from the project's own work, the surrounding context, and the team's documented translation philosophy—not from an edit-distance score against a segment pair. For teams that spend more time explaining why a “known” TM unit did not come back than they spend translating, that difference matters.

You can still run a conventional TM. This page exists because that workflow is real, and the misses have mechanical causes. Just do not expect a surface matcher to retrieve meaning.

Summary: Fuzzy-Match Failure Checklist

  • ☐ Confirm the expected TM is attached, writable/searchable, and unfiltered
  • ☐ Confirm the language pair (including locale variants) matches the stored units
  • ☐ Concordance-search a distinctive phrase; if empty, you are in the wrong TM
  • ☐ Compare stored vs. live segmentation
  • ☐ Diff tags, placeholders, numbers, punctuation, and whitespace
  • ☐ Check tag strictness / format penalties
  • ☐ Read named penalties (formatting, multiple translations, auto-localization, alignment, filters)
  • ☐ Temporarily lower the minimum match value (Studio default 70%, memoQ default 60%) to see if a hit is being hidden
  • ☐ Treat short segments and inflection-heavy languages as percentage-hostile
  • ☐ If the new source is a paraphrase, stop tuning—the matcher cannot see synonyms
  • ☐ If stored translations themselves conflict or look wrong, audit the TM rather than the scorer

FAQ

What causes fuzzy matches to fail in translation memory systems?

The usual ticket is one of these: the expected TM is not being searched; the live file is segmented differently from the stored unit; tags, numbers, or punctuation ate the score; a named penalty subtracted points from an otherwise exact hit; the minimum match value is hiding a usable score; or the new source is a paraphrase the string matcher cannot see. Tokenization failures are rarer and language-specific. Start at the top of that list. Do not open with “the TM is corrupt.”

Why does concordance find the unit when segment lookup does not?

Concordance searches inside units. Segment lookup compares whole segments and then hides anything below the threshold. If concordance hits and lookup is empty, the unit exists. Check segmentation, tags, named penalties, and the floor before you attach another TM.

Why did a 100% become a 98% or disappear?

The words are often identical. Trados subtracts documented points for missing or different formatting, multiple translations, auto-localization, text replacement, alignment origin, and character-width. memoQ reports 95–99% as high fuzzy when only numbers, punctuation, tags, or spaces differ, and can subtract more for a user, TM, role, or soft filter. Those points can push a near-exact hit under Studio's 70% or memoQ's 60% so it never appears.

Is this the same as matches breaking after a TM migration?

No. After a tool upgrade, CAT switch, or TMX import, look at index, locale codes, and tag encoding first. That is the migration diagnostic. This page is the stable-TM ticket: a known unit that still does not come back as a fuzzy.

Related Resources