TMX XLIFF and Compatibility: Translation File Formats

Whichever software your translation memory sits in today, one day it will move somewhere else. Suppliers change, software ages, teams turn over. When that day comes, what will save you is tool-independent file formats such as TMX XLIFF.

Contents

These formats are something like the shared language of the translation industry. Every tool has its own internal data structure; the common formats translate those structures into one another. They do not work flawlessly, but the alternative is complete lock-in.

In this article we look at which format carries what, what is lost in transfer, and what the buying side should put in its contract.

Why are common formats such as TMX XLIFF needed?

As translation tools multiplied in the 1990s, each one brought its own file structure. If an agency kept its memory in one piece of software, working with a translator who used another became practically impossible.

The problem was not only technical but economic as well. Changing software meant losing the whole of the accumulated memory. That created a powerful lock tying the user to a single provider.

The industry developed common formats to loosen that lock. Most of them are XML-based: text-based structures that a human can also read and that can be carried safely between programs.

Four formats stand out today: TMX for the memory, XLIFF for the working file, TBX for terms and SRX for segmentation rules. Together the four cover every portable component of a translation project.

The shared logic of these formats is to separate the content from its carrier. In a Word document, text and formatting are intertwined; in translation formats the text is held apart and the formatting is held separately as tags. This separation is the basic design choice that makes both transfer and automated checking possible.

TMX: the exchange format for translation memory

TMX (Translation Memory eXchange) was developed in the late 1990s so that translation memories could be transferred between tools. A TMX file is a list of source-target sentence pairs; alongside each pair there may be fields such as the language code, the creation date and user information.

TMX matters greatly for the buying side: it is the format that turns your organisation’s accumulated translation into a concrete file. If you hold your memory as TMX, you take your repetition discount with you when you change supplier.

TMX files can be opened like plain text. That is practical on the one hand – you can check the content by eye – and on the other it calls for care over confidentiality. Every name, address and amount that appears in the memory is readable inside this file.

Two things therefore have to be discussed together for TMX deliveries: handing the file over to you, and when the copies held by the supplier will be destroyed. If the second is not written down, your memory carries on living in two places at once.

XLIFF: the exchange format for translation work

XLIFF (XML Localisation Interchange File Format) solves a different problem from TMX. TMX carries accumulated knowledge; XLIFF carries work in progress. An XLIFF file holds the segments to be translated, their existing translations, the segment statuses and the notes left for the translator.

The practical benefit is this: the source document may be Word, InDesign or a software resource file. XLIFF separates the translatable text of that document from its formatting. The translator deals only with the text, and the structure of the file is left intact.

XLIFF is a standard maintained within OASIS, and different versions are in use. The differences between versions may look small, but they can be a source of trouble in transfers between tools; asking which version is in use is a technical-looking yet thoroughly practical question.

In software and web localisation XLIFF has become all but obligatory. The automated connections between content management systems and translation tools are usually built on this format too.

On the buying side the most visible benefit of XLIFF is that the translation does not damage your file. Because the text travels out and back through a separate channel, the delivered document comes back with the same structure as the source. In heavily formatted catalogues and multilingual web projects this is a detail that brings the typesetting cost down on its own.

TBX and SRX: terms and rules

TBX (TermBase eXchange) is the format used to move termbases, and it is standardised in ISO 30042. It carries fields such as the source term, the approved equivalent, the definition and the status together.

On simple projects a two-column table file does the job as well. But as your term list grows and the number of fields increases, the table falls short; fields such as forbidden equivalents and status information are lost.

SRX (Segmentation Rules eXchange), for its part, carries the rules that define how the text is to be split. It looks like a detail at first glance, but it matters a great deal: when the same document is split by different rules, match rates change and analysis results become impossible to compare.

In a corporate translation relationship it is ideal for all four of these files to be transferable. In practice most organisations ask only for the TMX; the other three are usually never discussed and stay with the supplier.

An incomplete handover, though, also lowers the value of the memory. A memory moved without its term list does not show which equivalent was a deliberate corporate choice; moved without its segmentation rules, it can produce a different split in the new tool and lower the match rate unexpectedly. Asking for the four files together raises the quality of the handover markedly, even though it creates no extra cost.

What is lost in transfer?

Common formats make the move possible, but not lossless. The losses are usually not in the text but in the information around it.

Component	Transfer risk	Consequence
Sentence text	Low	Usually carried across without trouble
Formatting tags	High	Bold/italic information lost, tag errors appear
Domain and client information	Medium	Memory filters stop working
Segment status	Medium	The line between approved and draft is erased
Notes and comments	High	Project history is lost
Term fields	Medium	Forbidden equivalents and definitions may drop out

The second row in the table is the one that causes the most trouble. Formatting tags are represented differently from tool to tool; after a transfer the output file may be broken, or extra work may arise at the typesetting stage. Checking the output of a few files visually after a transfer is therefore a good habit.

How widespread is the compatibility problem?

This is not a theoretical matter. In a case study carried out with 141 translators, 90% of participants reported having compatibility problems between tools, and 70% of those said the problem recurred frequently (Pietrzak & Kornacki 2021).

The figures show that common formats have reduced the problem without solving it. The reason is that the standards contain optional fields and each tool interprets those fields differently. Complying with a standard and producing the same result are two different things.

In the same research, the fragmented distribution of tools feeds the problem as well: SDL Trados 43.3%, memoQ 29.1%, Wordfast 10.6% (Table 6.2). In other words, at least two different tools work side by side in a typical supply chain, and a transfer takes place at every handover.

For the buyer the conclusion is clear: transfer is a point of risk, and how many transfers the process involves is a question worth asking. Every transfer carries a small price in both time and quality; reducing the number of links in the chain lowers that price directly.

The compatibility problem has a cost dimension too. In a market where 91% of translators buy their licence out of their own pocket (Pietrzak & Kornacki 2021), acquiring the tool the client wants is a real obstacle for small suppliers. Common formats working as they should is not merely a technical convenience; it is a condition for keeping the market open to small players.

The Türkiye context

Some of the compatibility problems seen in Türkiye stem not from the standards but from character encoding. The Turkish-specific letters – ı, İ, ğ, ş, ç, ö, ü – still get corrupted in files produced with older encodings, and it remains a common sight. Making sure UTF-8 is used in the transfer heads off most of these problems from the start.

The second local factor is where the documents come from. A large share of the official paperwork that comes in for translation in Türkiye is scanned PDF; producing XLIFF from these files is possible only after OCR, and the tag structure stays weak. Asking for the source file lowers both the cost and the transfer risk.

The third is contract practice. Domestic translation contracts usually say nothing about ownership of the translation memory and the term list. If the memory contains personal data, who holds the file also matters under Law No. 6698. Delivery of the TMX and destruction of the copies held by the supplier should be covered together in the same clause. This article is for general information and is not legal advice.

What does this mean for you?

File formats are the most technical-looking heading in translation procurement, yet the one with the most concrete consequences. If the right clauses are in the contract, changing supplier stops being a crisis.

1. Have it written down that the translation memory will be delivered to you in TMX format at the end of the project.
2. Ask separately for the term list in TBX or table format.
3. Require the segmentation rules (SRX) to be transferable.
4. Tie the deadline for destroying the supplier’s copies after delivery to a clause.
5. Have a few files checked on a sampling basis after the transfer.
6. Keep the source files: the editable originals, not the PDFs.

These six items keep your translation assets with you and lay the ground for your future price negotiations. You can see how we apply them on our services page, and you can write to us about moving your existing memory.

Frequently asked questions

What is the difference between TMX and XLIFF?

TMX carries the translation memory: it is an archive of source-target sentence pairs. XLIFF carries translation work in progress: it contains the segments to be translated, their statuses and their notes. One transfers accumulated knowledge, the other ongoing work.

Why should I ask for my memory as TMX?

TMX is a tool-independent format and is read by almost every translation environment. If your memory sits only in one tool’s own format, moving it becomes difficult when you change supplier or software.

Is there data loss during transfer?

Partial loss is common. Sentence text is usually carried across without trouble; formatting tags, domain information and custom metadata are open to loss. A sampling check should therefore be run after the transfer.

How widespread are compatibility problems?

In a case study carried out with 141 translators, 90% of participants reported having compatibility problems between tools, and 70% of those said the problem recurred frequently. Common formats have thus reduced the problem but not removed it.

Sources

• Pietrzak, P. & Kornacki, M. (2021). Using CAT Tools in Freelance Translation. Routledge Focus, Chapter 6, Table 6.2.
• OASIS (2014). XLIFF Version 2.0 Specification. OASIS Standard.
• ISO 30042:2019, Management of terminology resources – TermBase eXchange (TBX).