How to open and edit an XLIFF file without a CAT tool

Someone sent you an .xlf file and you do not own the tool that made it. The good news is that an XLIFF file is plain text you can open anywhere. The bad news is that “open” and “edit safely” are different things, and the gap between them is where files get broken. This guide covers both.

What an XLIFF file is

XLIFF is an XML vocabulary standardised by OASIS. Its job is to carry translatable text from one step of the localisation process to the next, so that different tools can work on the same file. A content system exports one, a translator fills in the targets, and the content system reads it back.

There are two generations in circulation, and you can tell them apart from the first element:

The two generations are not interchangeable. The 2.0 standard says a conforming 2.0 tool does not have to read XLIFF 1.2 at all, so “it opens XLIFF” never tells you which one. The 1.2 vs 2.0 guide covers the differences.

On the extension: the XLIFF 1.2 specification names .xlf and recommends no other. .xliff is common, but it is a habit, not the standard. The 2.x specifications define no extension at all.

A minimal 1.2 file looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
  <file original="ui.json" source-language="en" target-language="de" datatype="plaintext">
    <body>
      <trans-unit id="save">
        <source>Save <g id="1">all</g> changes</source>
        <target state="translated">Alle <g id="1">Änderungen</g> speichern</target>
      </trans-unit>
    </body>
  </file>
</xliff>

An XML declaration, an <xliff> root, one or more <file> sections, and inside them the units: a source, a target, and a state that records where the translation stands.

Opening one to read it

Any text editor or browser will show you the XML. Two things decide whether what you see is what is in the file:

• The encoding. The first line, the XML declaration, sets the file’s character encoding, and the declared encoding and the encoding the file is actually saved in must match. Without a declaration, an XLIFF file must be UTF-8 or UTF-16, and a UTF-16 file must begin with a byte-order mark. An editor that silently re-saves in a different encoding produces a file whose first line is now wrong.
• Escaping. Formatting from the original document is often stored escaped. Inside a <ph> or <bpt> element you see <b> rather than <b>, and it has to stay that way.

Reading is safe. The trouble starts when you type.

What breaks when you edit it by hand

Inline tags. Formatting and placeholders inside a segment are stored as inline elements such as <g>, <x/>, <bpt>, <ept> and <ph>. The target uses the same inline codes as the source, so deleting or mistyping one in a text editor can break the file when it is converted back into a document. In the example above, losing <g id="1"> from the target loses the bold. The inline tags guide shows every element and what it stands for.

Half an escape. Deleting one character from an escaped </b> gives a file that still parses and renders a document where the bold never ends. Nothing warns you.

Statuses. In XLIFF 1.2 the state attribute on <target> records the status of a translation, and there is also an approved attribute on each <trans-unit> that marks it as final. A text editor will not update either when you change the text, so a target you rewrote still claims whatever status it had. XLIFF 2.0 has only four state values on <segment> (initial, translated, reviewed, final), and if you change one by hand the specification requires you to update or remove its subState attribute too. The segment states guide maps these across tools.

Vendor files. SDLXLIFF and MQXLIFF are XLIFF 1.2 with extra namespaces, and the status that matters lives in the vendor attributes, not in state. Editing the 1.2 attribute changes nothing the vendor tool reads. See the SDLXLIFF and MQXLIFF references.

A file that looks different but is fine. XLIFF 2.0 allows CDATA sections, and a tool may rewrite them as ordinary escaped text when it saves. A diff full of changed CDATA after a round trip is not necessarily damage.

A text editor is fine for reading a file and for a one-word fix in a unit with no tags. For anything more, use something that knows the format.

Editing it in a browser instead

xliff.ai opens XLIFF 1.2, 2.0 and 2.1, SDLXLIFF, MQXLIFF, gettext PO, Excel and CSV in the browser, with no account and no upload: the file is read and written on your own computer. What it does differently from a text editor:

• Tags are chips. Each inline tag shows as one block you cannot split by typing. Deleting one half of a pair either removes both halves or is refused, and a target that is missing a tag the source has is flagged.
• Statuses follow your work. Ctrl+Enter confirms a segment and writes the matching status for the format you opened: state in XLIFF, conf in SDLXLIFF, mq:status in MQXLIFF. Statuses the editor does not recognise are kept exactly as they arrived.
• Only what you change is written. Export splices your edited targets into the original bytes. The encoding, byte-order mark, line endings, attribute order and every vendor extension outside your edits come back as they were.
• Errors are caught before delivery. Fifteen QA checks look for missing tags and placeholders, numbers, punctuation and terminology.

Two limits worth knowing. Files in the old XLIFF 1.1 namespace do not open, and a file that declares Latin-1 or Windows-1252 but contains non-ASCII characters is refused rather than guessed at. And exports have been tested byte for byte but not yet inside Trados Studio or memoQ themselves, so keep your original and open the export in the tool that will consume it before you deliver.

A short checklist

1. Check the root namespace to know whether you have 1.2 or 2.x.
2. Read the encoding declaration, and keep the file in that encoding.
3. Never type over a tag or an escaped <…> sequence; copy them.
4. If you change a target by hand, decide what its status should now say.
5. For anything beyond a one-word fix, edit in a tool that treats tags as atomic, and keep the original until the export has been opened downstream.