The CAT Tool Compatibility Problem: A Trouble Translators Share

There is a problem in the translation industry that everyone knows about but that is rarely explained to the client: the tools cannot speak to one another properly. A file one translator prepares in memoQ may not open as expected in another translator’s Trados installation, formatting may shift and notes may disappear.

Contents

The CAT tool compatibility problem has been measured in the literature more concretely than people assume. In the case study in the book, the proportion of those who run into it stands at around 90 per cent, and most of them describe it as a regular state of affairs rather than an exception.

This article sets out the technical source of the problem, the fragmented structure of the market, why standards are not enough, the cost that reaches the client and how a delivery format guarantee closes that cost off.

What does the CAT tool compatibility problem look like?

The compatibility problem is not a single fault; it surfaces at several different layers. The most visible is a project file that will not open: a package prepared in one tool contains a version or a structure the other tool does not support.

The second layer is formatting tags. Elements such as bold, italic, a hyperlink or a variable field are carried in the file as tags. Tools name these tags differently and place them in a different order. When a tag is lost during transfer, the formatting in the target document breaks.

The third layer is metadata: segment statuses, translator notes, approval records, quality control settings and termbase links. Most of these have no standard equivalent and drop out in transfer. The text arrives, but the project’s memory does not.

The fourth layer is support for source file formats. One tool can open a particular desktop publishing or subtitle format while another cannot. The translator then has to convert the file by hand, and every step of the conversion carries a fresh risk of loss.

How widespread the problem is: the finding of the case study

In the case study Pietrzak and Kornacki carried out with 141 Polish translators, roughly 90 per cent of participants reported that they experienced tool compatibility problems. About 70 per cent of those say they run into the problem often (2021 data).

That figure shows the problem is not an isolated installation error. Almost all professional translators spend part of their working lives getting files to convert into one another. It is an item of time that produces no translation directly.

The same study also shows that 91 per cent of translators hold their own tool licence (2021 data). Tool choice is therefore mostly the translator’s own decision; it is not imposed by an agency or a client. That freedom is a good thing professionally, but it also feeds the fragmentation of the market.

It should be borne in mind that the study was carried out in the Polish market. Since tool distribution and file formats are global, the direction of the finding can be taken to hold for Türkiye as well; assuming that the figures are identical, however, would not be right.

The fragmented structure of the market

The structural cause of the compatibility problem is that there is no single dominant tool. In the same case study the usage shares of the tools are as follows (2021 data).

Tool	Usage share	What it means for compatibility
SDL Trados	43.3%	The de facto common ground, but not enough on its own
memoQ	29.1%	Can read Trados packages, but there is no full equivalence
Wordfast	10.6%	A lighter structure, limited format support
Other tools	The remaining share	Cloud-based and in-house solutions; transfer is at its most fragile here

What the table says is plain: more than half the market lies outside any single tool. If there are three different parties in a project chain, the odds are high that at least two different tools are in play. Every point of transfer means a risk of loss.

Version differences come on top of this. Package incompatibility can arise even between two different versions of the same tool. On corporate projects, fixing the version matters as much as choosing the tool.

Cost is another reason for the fragmentation. The price of desktop licences is a significant item for a freelance translator, so nobody buys a second tool unless they have to. The market therefore stays divided out of economic necessity rather than technical preference.

Why are standards not enough?

The industry has seen the problem and developed standards. TMX was defined for moving translation memories between tools, and XLIFF for moving the content to be translated together with its segment structure. Both are widely supported.

The problem is that the standards are flexible. A standard defines what may be carried across, but it does not oblige every tool to interpret it in the same way. Tag naming, whitespace handling, line-break management and custom fields vary from tool to tool. The result is a transfer that is technically valid but flawed in practice.

The second problem is that standards do not cover the whole of a project. The termbase, the quality control rules, the link to a style guide and the segmentation rule file are mostly specific to the tool. The memory moves across, but the working arrangement of the project does not.

The fourth problem is the variety of versions. Different versions of the same standard are published over the years, and tools come to support them at different speeds. When the file that is sent does not state which version it was produced against, tracing the source of transfer problems becomes harder.

The third is non-standard shortcuts. Under time pressure, files are sometimes moved by converting them into intermediate formats. The method works, but it largely removes any control over formatting and segment structure.

What is the bill for the client?

The compatibility problem does not appear to the client as a technical fault. It shows up in three different forms: late delivery, a broken page layout and unexpected extra cost. All three begin somewhere in the process that is out of sight.

The most common outcome is a broken layout. The translation is correct, but tables shift, bullet points change, heading styles disappear and the page count grows. Delivering a catalogue bound for print, or a contract bound for signature, in that state is unacceptable.

The second outcome is that the correction rounds drag on. The client sends the file back to have the layout put right, the fix is made through a fresh transfer and new losses appear. The loop closes after a few rounds, but the delivery date has slipped long since.

The third outcome is more insidious: the file becomes unusable in the next project. If the memory has been saved incomplete or corrupted, the expected gain from repetition does not materialise in the update project and the cost forecast fails to hold.

Making up for it through process: the delivery format guarantee

The way to turn this into a problem that does not concern the client is to give an undertaking on the delivery format. A good agency tells you in writing not which tool it uses but in which format and in which layout it will deliver to you.

In practice this means that whatever format the file you send is in, the translation comes back in the same format and with the same page layout. A Word document is delivered as Word, a presentation as a presentation, a subtitle file with its time codes preserved. Every loss that arises during conversion is closed off before delivery.

The step that secures this is the format comparison. The source and target documents are opened side by side, and heading levels, table structure, bullet points, hyperlinks and page breaks are checked. This check is a separate step from the translation check and can be carried out by different people.

For work bound for print or publication one more step is added: the desktop publishing check. The aim here is not the accuracy of the text but whether text that has grown longer in the target language still fits its boxes. You can see which delivery formats our service packages cover on the translation services page.

The Türkiye context

The first factor that aggravates the compatibility problem in the Türkiye market is character encoding. Documents coming out of older corporate archives have at times been stored in old encodings specific to Turkish. When those files are brought into modern tools, Turkish letters are corrupted; the corruption arises when the file is opened rather than during translation, and if it goes unnoticed it is written into the memory in corrupted form as well.

The second factor is the requirements attached to official documents. In translations that will go for notarisation, to a consulate or to a public authority, the layout of the document, the placement of the stamp and signature areas and the page structure all matter. A loss of layout here is not an aesthetic problem but a reason for the application to be refused.

The third factor is the limited stock of ready-made resources for Turkish. Because Turkish is counted a low-resource language, the Turkish-specific segmentation rules, abbreviation lists and quality control definitions in the tools are often incomplete. These definitions have to be set up by hand at the start of a project; when they are not, incompatibility problems multiply.

What does this mean for you?

From your side the subject has a single practical consequence: which tool is used is not your problem, the delivery format is. The questions you ask should be chosen accordingly.

1. Send your file in its original editable format; a source file always gives a better result than a scanned copy.
2. Ask for the quote to state in writing that the delivery format and the page layout will be preserved.
3. For work bound for print, ask separately whether the desktop publishing check is within scope.
4. For official applications, share the layout requirements set by the authority before you take delivery of the document.
5. On long-term collaborations, have it written into the contract that your memory file can be handed over to you in a standard format.

Whatever your file format, you can send us your documents through the quote page to settle the delivery terms, and share any special layout requirements through our contact page.

Frequently asked questions

How widespread is the CAT tool compatibility problem?

In the case study carried out with 141 Polish translators, around 90 per cent of participants stated that they experienced compatibility problems, and around 70 per cent of those said they ran into the problem often.

Do the TMX and XLIFF standards not solve the problem?

In part they do. Both formats carry the text and the segment structure, but formatting tags, notes, status information and quality control settings are interpreted differently from tool to tool. Loss during transfer usually happens in those layers.

Will working with an agency that uses a different tool create a problem for me?

It should not create one for you. What is decisive is not which tool the agency uses but which format it undertakes to deliver in. If the delivery format and the preservation of layout are written into the quote, the choice of tool stops being your problem.

Which format should I send my file in?

If possible, send the original editable form of the document. Word, Excel, PowerPoint, InDesign and subtitle files can be processed directly. If you are sending a scanned PDF, allow for a preparation stage and for the time it will add.

Sources

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation: Insights from a Case Study. London: Routledge Focus, Table 6.2 and pp. 71–95.
• OASIS (2014). XLIFF Version 2.0 Specification. OASIS Standard.
• LISA (2005). TMX 1.4b Specification. Localization Industry Standards Association.
• O’Brien, S., Ehrensberger-Dow, M., Connolly, M. & Hasler, M. (2017). Irritating CAT tool features that matter to translators. HERMES, 56, pp. 145–162.