The glossary is correct. Invisible Word characters are breaking the match.
The term looks identical. The match disappears. A non-breaking hyphen or narrow space can be enough: inspect the characters before changing the glossary.
On this page
The short version
- Similar-looking text can contain different characters. Inspect code points before editing the termbase.
- NFKC folds some spaces, but does not turn every hyphen into ASCII.
- Preserve the original DOCX and test the actual CAT-tool import, match and export.
You can see the term. The match is missing.
The glossary says “co-operate”. The document appears to say “co-operate”. Adding another entry feels like the quickest fix. First, check whether those hyphens are the same character.
In a 15 October discussion, Rocío Cordero reports non-breaking hyphens and narrow no-break spaces affecting terminology matching in Word files imported into memoQ. Several commenters describe similar cleanup work. The thread is a diagnostic lead; it does not establish that AI inserted the characters or that every import behaves the same way.
The distinction can be difficult to see. A non-breaking hyphen is still visible; it is not a zero-width character. Its line-breaking behavior and code point differ from an ordinary keyboard hyphen. Spaces can also look alike while carrying different values.
A tiny DOCX makes the difference inspectable.
Download the synthetic DOCX and the Python reproduction into the same folder. Run python3 docx-character-matching.py with Python 3.10 or later, without optimization flags. It uses only the standard library and verifies the accompanying fixture.
- co-operate
- The separator is U+002D HYPHEN-MINUS.
- co‑operate
- The separator is U+2011 NON-BREAKING HYPHEN.
The script reads the literal text back from the DOCX XML and compares the strings. For ASCII versus non-breaking hyphen, exact comparison, NFC comparison and NFKC comparison all return false. For an ordinary space versus U+202F narrow no-break space, exact and NFC comparisons return false; NFKC comparison returns true.
- Preserve
Keep the original file and a small failing example.
- Inspect
Compare source and term code points, not screenshots.
- Check settings
Inspect the actual term entry and DOCX import configuration.
- Reproduce in the tool
Record tool version, match result and exported appearance.
“Normalize it” is an incomplete instruction.
Unicode normalization distinguishes canonical forms, such as NFC, from compatibility forms, such as NFKC. In the fixture, NFC correctly reconciles composed and decomposed “café”. It leaves the tested hyphen and spacing differences intact.
NFKC maps U+2011 to U+2010 HYPHEN, not U+002D HYPHEN-MINUS. It maps U+202F to an ordinary space. The Unicode character list documents these mappings. A normalization call alone therefore cannot promise the comparison your workflow expects.
Decide what equality means for this task. A comparison-only mapping may recognize two term spellings while preserving intentional source typography. Rewriting the document changes its content and layout behavior. Keep those decisions separate, and do not remove meaningful non-breaking spaces just to make a counter turn green.
Use the CAT tool’s controls deliberately.
memoQ documents term-level matching and case settings. Inspect the entry actually in use. Do not assume a default explains an existing term, or equate the tool’s Exact setting with the script’s plain string equality.
Its DOCX import settings also include controls for font hints and minor formatting changes. They are settings to investigate, not proven fixes for this example. Removing formatting can change the return file. Try the smallest permitted change on a copy.
- Agree the transformation
Name the characters, scope and typography that must survive.
- Import the test copy
Inspect terminology recognition and tag structure.
- Export and compare
Check wording, line breaks and required formatting.
- Record the decision
Keep the original, transformation rule and tool-specific evidence.
Keep a repeatable preflight.
- The failing term has a minimal example with inspected code points.
- The original is preserved and intended typography is documented.
- The actual term and import settings were checked.
- The approved change improves the intended match in the target tool.
- The exported file preserves required content, formatting and line behavior.
Questions we hear
Should we replace every non-breaking space?
No. It may intentionally keep a number and unit together or follow locale conventions. Agree a narrow transformation and verify the export.
Did AI create these characters?
The reported workflow suggests that possibility, but the characters alone cannot identify the authoring tool or prove a cause.
Will this script clean customer DOCX files?
No. It creates or verifies its synthetic fixture and demonstrates comparisons. It is not a general extractor or cleanup tool.
Sources
- Word characters affecting terminology matchingRocío Cordero on LinkedIn, 15 October 2026
- Unicode Normalization FormsUnicode Standard Annex #15
- General Punctuation character names and mappingsUnicode
- Edit term base entrymemoQ documentation
- Microsoft Word DOCX import settingsmemoQ documentation