Converting an XLIFF file: to Word, Excel, TMX or another version

“Can you convert this XLIFF to Word?” usually cannot be done the way the person asking imagines. An XLIFF file is not a document in another format. It is the translatable text taken out of a document, and what you can turn it into depends on what it still carries.

What an XLIFF file holds, and what it does not

An XLIFF file holds the text units of a source document, their translations and their statuses. The layout, the images and everything else that is not text usually stay behind. The XLIFF 1.2 specification says where the rest goes: the <file> element’s required original attribute “specifies the name of the original file from which the contents of a <file> element has been extracted”, and the optional <skl> element “contains the skeleton file or the location of the skeleton file”. The skeleton is the part that matters for conversion:

The skeleton file is a template that can be used in recreating the original file, from the <source> content, or the translated file, from the <target> content.

XLIFF 2.0 keeps the idea. Its <skeleton> element is a “Container for non-translatable material pertaining to the parent <file> element”, either inline or by reference.

So a translated document is rebuilt by putting the targets back into the skeleton, and only the tool that wrote the skeleton knows how to read it. Often the skeleton is not in the file at all: it stays in the CAT tool’s project, in the content system that exported the strings, or in the developer’s source tree.

Back to Word, or to the original format

This one goes back to the sender, not to a converter:

• A file from a CAT tool (Trados Studio, memoQ, Phrase and others) becomes a translated document when it is opened in that tool’s project and the target document is generated there. Return the translated XLIFF, SDLXLIFF or MQXLIFF to whoever sent it, in the format they sent.
• A file from a content system or a plugin (WordPress with WPML, Articulate, Figma localisation plugins) is imported back into the system that exported it. See the WPML, Articulate and Figma pages for those round trips.
• A file from a developer (Xcode, Angular and similar) is imported into the project, and the app is built from it. See the Xcode page.

A converter that promises a .docx from a bare XLIFF can only lay the segments out as a table or as running text. That is fine for reading, but it is not the client’s document, and nothing that is edited in it can go back into the file.

If what you actually need is a readable copy for someone without a CAT tool, a spreadsheet does that job better, and a spreadsheet can come back.

To Excel, for review

A spreadsheet is the conversion most people actually need: a client, a reviewer or a subject expert can read it without any translation tool. In xliff.ai, open the file and choose the ▾ beside Export. Two of the formats there are for this:

• Bilingual spreadsheet (.bilingual.xlsx): ID, Source and Target, one row per segment, with inline tags shown as their raw markup. It is for reading, sharing and archiving. Nothing typed into it can be read back into the file.
• Review workbook (.review.xlsx): built to come back. The reviewer writes a suggested fix and picks a decision for each row; importing it applies the decisions by segment ID, and refuses any fix that drops or adds a tag.

XLIFF to Excel has the steps, XLIFF to Excel and back explains what Excel does to translation text on the way, and How to review a translation covers the review itself.

To one table with several languages

When the same source has been translated into several languages, each in its own bilingual file, Merge XLIFF files into one multilingual Excel lines the files up into one table: the source, a column per language and a comment column per language, as an Excel workbook or a CSV. It reads XLIFF, SDLXLIFF, MQXLIFF, PO, Excel and CSV files, in any mix. Like the bilingual spreadsheet, the result is for reading and commenting; it is not read back into the files.

To TMX, for a translation memory

TMX is the exchange format for translation memories, so converting a finished XLIFF file to TMX is how its translations become reusable in another tool. XLIFF to TMX does it from the same ▾ menu, in one of two forms:

• Tags stripped: plain text on both sides. Matches from it carry no formatting.
• Tags kept: paired tags are written as <bpt> and <ept>, everything else as <ph>, with the original markup inside.

Only confirmed segments (translated, reviewed or final) go into the TMX, and a segment whose source or target is empty is left out, because a memory built from drafts passes unfinished work on to every later job. A memory loaded into the editor’s Memory panel can also be downloaded as TMX from there.

Between XLIFF 1.2 and 2.0

Moving a file from XLIFF 1.2 to 2.0 is not a change of version number. The two generations use different elements for units, segments and inline codes, and 1.2’s ten state values meet 2.0’s four. A file’s tags, statuses and tool-specific extensions all have to be mapped, and some have no equivalent: XLIFF 1.2 vs 2.0 covers what changes and what a migration costs.

The practical answer is usually not to convert at all. The tool that exported the file expects it back in the version it wrote, so translate it in that version. xliff.ai opens XLIFF 1.2, 2.0 and 2.1 files as they are and exports each in the version it arrived in; it does not convert between them.

To PO, JSON or a developer format

These usually go the other way round: a developer tool that works with XLIFF exports it from its own string files and imports the translated XLIFF back. Translate the XLIFF and send it back, rather than converting it into the string format yourself. If the strings are already in a PO file, a spreadsheet or a CSV, xliff.ai opens that file directly: see PO files, XLSX translation and CSV translation.

A quick reference