You asked your agency for the website texts. Or you clicked "export" in a plugin, or a developer sent you something before going on holiday. Either way there is now a file on your desktop ending in .xliff or .xlf, it will not open in Word properly, and someone is waiting for you to send it back translated.
Here is what it is.
The short version#
An XLIFF file is a container for text that is on its way to a translator and needs to find its way home again.
The letters stand for XML Localization Interchange File Format. It is an open standard, maintained by a standards body called OASIS, and it exists for one reason: so that the system your text came from can put the translation back in exactly the right place without a human matching things up by hand.
That last part is the whole point. A Word document with two columns would also hold your sentences. It would not hold the information that says this sentence is the headline of the About page, that one is the label of the checkout button.
What is actually inside#
Open an XLIFF in a text editor and you see something like this:
<trans-unit id="about.headline">
<source>We build furniture that lasts</source>
<target></target>
<note>Headline, About page, max 45 characters</note>
</trans-unit>
Four parts, and only one of them is your sentence:
| Part | What it does |
|---|---|
id | The address. This is how the system finds the slot the text came from. |
source | The original sentence. |
target | The empty slot the translation goes into. |
note | Optional context from whoever made the export. |
Multiply that by every sentence on your site and you have the file. A mid-sized company site is a few thousand of these blocks; the file is large but there is nothing complicated in it.
Two versions are in circulation. XLIFF 1.2 is the older one and still by far the most common — WPML, Xcode, Trados and memoQ all write it. XLIFF 2.0 is the 2014 revision, tidier inside, used by newer tools. As a reader you rarely need to care which one you have.
Why the file looks so hostile#
Three things make an XLIFF harder to read than a document:
Inline tags. A sentence like Read our terms before ordering has a link inside it. In XLIFF that link becomes markup around the words — <g id="1">terms</g> — because the translation needs the link to sit around the translated words, not around the English ones. It looks like clutter. It is the difference between a working link and a broken one.
Placeholders. Text like Welcome back, %@ or You have {count} items has a gap the software fills in later with a name or a number. If a translator quietly drops the %@, the app shows a name-shaped hole or, in the worst case, crashes on that screen.
Every string, in file order. Exports are not sorted by importance. The page title, a cookie notice, an error message nobody sees twice a year — all equal, all in a row. It reads like a phone book because that is what it is.
The one rule: do not open it in Word#
This is where most first attempts die.
Word can display an XLIFF, and it will offer to save it. What it saves is no longer the file that came out of your system — the encoding changes, formatting is added, and sometimes the structure is rewritten enough that the import silently fails or refuses the file without saying why. The same is true for Google Docs and for "convert XLIFF to Word" services that hand you a document and no way back.
Safe ways to open one:
- A plain text editor — Notepad, TextEdit in plain-text mode, VS Code. Read-only, but nothing gets damaged.
- A browser-based viewer like our free XLIFF viewer. It shows the file as a table: original on the left, translation on the right, comments underneath — and it never uploads the file anywhere.
- A CAT tool — Trados, memoQ, OmegaT, Poedit. Built for exactly this, and priced for people who do it every day.
- The system that made it, if it has an editor built in. WPML has one, Xcode has one.
Excel deserves a footnote: it is not dangerous as long as you never save the XLIFF as an Excel file. Going XLIFF → CSV → Excel → CSV → XLIFF works, because the CSV step keeps the IDs in a column. Our viewer does exactly that round trip.
Where your file came from#
Knowing the source tells you where the translation has to go back:
- WPML or Polylang on WordPress — the export covers pages, posts, WooCommerce products, menus. It goes back in through the same plugin.
- Xcode — Product, then Export Localizations, produces one
.xclocfolder per language with the.xliffinside. It goes back in through Import Localizations. - Trados, memoQ, Phrase, Smartcat —
.sdlxliffand.mqxliffare XLIFF with extra vendor attributes. If an agency sent you one, they expect the same file back, not a Word document. - Drupal and TYPO3 — the TMGMT module and l10nmgr write and read XLIFF.
- Angular, Symfony, Laravel — a
messages.xlffrom a development team, usually kept in the code repository.
What happens next#
Three routes, and the right one depends on how much text you have and how often it changes.
Hand it to a translation agency. Correct, slow, and priced per word — commonly €0.10 to €0.20 for a European language pair. Eight thousand words into three languages sits somewhere around €2,400 to €4,800. Worth it for the ten pages that sell the product; hard to justify for a help centre that changes weekly.
Type the translations in yourself. Sensible for a handful of entries, punishing after a few hundred. If you go this way, use a viewer rather than a text editor, so you cannot damage the structure by accident.
Run it through a machine translation service that speaks XLIFF. The file goes in, comes back with the target slots filled, and the IDs, inline tags and placeholders survive. This is what we do: €19 per seat per month plus €10 per million tokens, all 64 target languages included, and text that was already translated once is recognised and not billed again. The step-by-step guide walks the whole route from export to import.
A combination is usually the sane answer: machine translation for the whole file, a human pass over the twenty sentences that carry the money.
The three things worth remembering#
- The IDs matter more than the text. They are how the translation gets home. Never edit them, never sort them.
- Word is not a translation tool for this file. A plain text editor, a viewer or a CAT tool — anything else risks a file that no longer imports.
- You do not need a developer. Export, translate, import. The hard part is the export dialog, and that is checkboxes.
If you want to see what is in your file before deciding anything, drop it into the free viewer. It runs in your browser, nothing is uploaded, and it will tell you how many entries you are actually looking at.