A vendor claiming CAT-tool compliance usually means they can open a file in Trados or memoQ. That is not the same as compliance. Real CAT-tool compliance means a file survives the full round-trip, export, translation, re-import, with every tag intact and every segment matching the source structure exactly, and that claim needs testing, not just a yes on a vendor questionnaire.
Foliage Solutions builds every file to that standard because the alternative shows up later, as degraded translation memory match rates on a project that should have reused significant prior work.
This distinction matters more than it sounds. Standardized exchange formats exist specifically to make CAT-tool compatibility straightforward, and even they do not guarantee it in practice.
Why standard formats do not automatically mean compatibility
XLIFF and TMX exist precisely to solve the interoperability problem: XLIFF carries active translation work between tools, TMX carries accumulated translation memory. Both are open, XML-based standards, and most CAT tools support both.
Support for a standard is not the same as consistent behavior across tools. Documented interoperability testing between CAT tools has found real gaps even when every tool involved claims standard compliance: one comparison found that TMX files exported from two different platforms produced no context matches against each other when imported into a third tool, despite both files being nominally standard-compliant. Segmentation rules, tokenisation settings, and tag-handling conventions differ enough between tools that standard-format support alone does not guarantee a clean result.
This is the gap between a vendor saying “we support Trados and memoQ” and a vendor who has actually tested what happens when a file moves between them.
Some of this gap comes down to how each tool interprets segmentation and tokenisation rules, decisions that are technically within the standard but not fully prescribed by it. A period followed by a capital letter might mark a new sentence in one tool’s default settings and stay part of the same segment in another’s. Multiply that kind of small interpretive difference across a full document, and two tools that both claim TMX support can still produce translation memories that barely match each other.
What compliance actually requires
Four things separate genuine CAT-tool compliance from a compatibility claim nobody has verified.
Tag structure preservation. Every formatting tag needs to survive export, translation, and re-import without corruption or duplication. A single orphaned tag can break segmentation for the rest of the file, and the error often does not surface until re-import, well after the translator has finished.
Segmentation fidelity. The file needs to segment the same way on export as the source document structure implies, so that translation memory matches align correctly. A file that segments differently than intended silently reduces match rates without any visible error.
Round-trip testing, not just export testing. Confirming a file exports cleanly into XLIFF is not the same as confirming it re-imports cleanly after translation. The full round-trip, not just half of it, is what actually predicts whether a project will go smoothly.
Named tool testing, not general claims. “Compatible with major CAT tools” is not a testable claim. “Tested against Trados, memoQ, Phrase, Smartling, XTM, and Wordfast specifically” is. If a vendor cannot name which tools they have actually tested against, they are making a general claim, not demonstrating compliance.
These four requirements are not independent of each other. A file can pass tag structure preservation and still fail segmentation fidelity, because tags can survive intact while the boundaries around them shift. Genuine compliance means all four hold at once, on the same file, verified together rather than checked off one at a time against different sample documents.
What happens when compliance is assumed instead of tested
The failure pattern is consistent. A DTP vendor prepares a file, exports it, and hands it off, confident the file is CAT-tool ready because it opened without an error message. The translator works through it normally. Nothing looks wrong during translation.
The problem surfaces on re-import, or worse, on the next project using the same translation memory. Fuzzy matches that should have been near-exact come back partial or missing entirely, because formatting codes leaked into segments during the original round-trip and the TM stored the pollution as if it were language. By the time anyone traces the drop in match rates back to its source, the original project is long finished and the damage is already stored in the TM permanently.
This is why compliance needs to be tested at the point of file preparation, not discovered months later in a completely different project.
A mid-size LSP we worked with had this happen with a prior vendor before switching to Foliage. A batch of InDesign files went through DTP preparation and translation without issue on the surface. Three projects later, using the same client’s translation memory, fuzzy matches that historically ran above 90 percent started coming back closer to 60. Nobody connected it to the original batch until someone finally opened the TM directly and found formatting codes embedded inside what should have been clean text segments. The fix required rebuilding the affected TM entries manually, a cost that never appeared on the original project’s invoice because the damage was invisible at the time of delivery.
How to verify a vendor’s compliance claim before committing a project
Ask which specific CAT tools the vendor has tested against, by name, not as a general category. Ask whether they test the full round-trip, export and re-import, or only confirm the file opens correctly on export. Ask what happens when a tag error is found during their own QA process, and whether that QA step exists as a defined part of their workflow or is left to the translator to catch.
Then test it directly. Send a representative file with real complexity, not the simplest document available, and check what comes back after the full round-trip through your own CAT tool. A vendor whose compliance claim is accurate will show clean segmentation and intact tags. A vendor whose claim was general will show exactly where the gap is, usually in the first file you send.
Pay particular attention to fuzzy match rates on the return trip, not just whether the file opens. A file that opens without error but returns fuzzy matches lower than expected against a known translation memory is showing you the exact failure this article describes: technically valid, not actually compliant. That distinction rarely shows up as an error message. It shows up as a number quietly lower than it should be.
Why this matters more for ongoing TM health than for a single project
This is worth stating plainly: a compliance claim is not a permanent fact about a vendor. It is a fact about a specific file, a specific tool version, and a specific point in time. Treating it as anything more durable than that is where the gap between claimed and actual compliance quietly reopens.
A single project with a compliance gap is a bad outcome. The bigger cost is what it does to a translation memory that a client expects to compound in value over years of work together. Every project run against a compromised TM inherits the contamination from the first one, and the effect is cumulative: fuzzy match rates that should improve project over project instead plateau or decline, and nobody notices the root cause because it happened long before the symptom appeared.
This is the argument for treating compliance testing as a standing requirement rather than a one-time vendor check. A vendor who was compliant on the file they demonstrated during evaluation is not automatically compliant on every file type and every CAT tool version going forward. Software updates change how tools handle tags and segmentation. A compliance claim that was accurate a year ago deserves periodic re-verification, not permanent trust based on one early test.
What this looks like in practice at Foliage
Every file we prepare is built and tested against the specific CAT tools our clients actually use: Trados, memoQ, Phrase, Smartling, XTM, and Wordfast, not a generic claim of broad compatibility. Testing covers the full round-trip, not just export, because that is the only test that actually predicts what happens to translation memory on re-import.
When we say a file is CAT-tool compliant, that claim is backed by testing against the named tool a specific client uses, not a general assumption that standard-format support is sufficient on its own.
We also re-verify periodically rather than treating an early test as permanent. When a client updates their CAT tool version, or when we onboard a new format for an existing client, that is a trigger for a fresh round-trip test, not an assumption that last year’s result still holds.
The underlying question we ask before signing off on any file is simple to state and harder to skip under deadline pressure: if this file goes through the full round-trip today, does the translation memory that comes out the other side stay exactly as clean as it went in.
Talk to Foliage Solutions about testing CAT-tool compliance against the specific tools your team actually runs.
Leave a Reply