XLIFF: the interchange format that keeps translation work portable

XLIFF (XML Localization Interchange File Format) is an OASIS standard designed to solve a specific problem: translation happens in one tool, but the text has to go back into a completely different system afterward. Without a shared interchange format, every pairing of source format and translation tool needs its own converter, and every conversion is a chance to lose data.

XLIFF is that shared format. It does not replace your source files — you still keep your PO files, your JSON resource files, your game's own text format — but it gives translators and translation tools one consistent structure to work in regardless of what the source was.

Structure: file, unit, segment

An XLIFF document is nested XML: one or more file elements, each containing units, each unit containing one or more segments. A unit is roughly "one translatable message"; a segment is a sentence-level or clause-level piece within it, which matters for tools that translate below the message level.

Each segment carries a source element (the original text, never modified) and a target element (the translation). Keeping source and target as separate, paired elements — rather than overwriting the original — is what makes round-tripping possible: the tool that converts your files into XLIFF and back can always verify it put the right translation next to the right original.

<xliff version="2.0" srcLang="en" trgLang="ja">
  <file id="dialogue">
    <unit id="tutorial.press_button">
      <segment>
        <source>Press %s to open your inventory.</source>
        <target>%s を押してインベントリを開く。</target>
      </segment>
    </unit>
  </file>
</xliff>

State attributes: tracking where a segment is in the workflow

Translation is not a single step — a segment moves from untranslated, to translated, to reviewed, and sometimes to a state that flags it needs another look. XLIFF's state attribute on the target element encodes exactly this, values such as initial, translated, reviewed, and final.

This is what lets a project pass through multiple tools and people without losing track of progress: a translation memory system, a reviewer's tool, and the final import step can all read the same state value and agree on what still needs work.

Inline markup

Source text often contains formatting or embedded markup — bold tags, a hyperlink, an inline icon reference — that has to survive translation without a translator needing to understand or accidentally break the underlying syntax. XLIFF represents this with dedicated inline elements rather than leaving raw markup inside the translatable text.

• ph — a placeholder for non-textual content (an image tag, a line break) that a translator can move but not edit
• pc / sc / ec — paired or standalone codes representing markup spans, such as a bold run, so the translator sees where formatting starts and ends without seeing raw tags
• mrk — marks a sub-span of text for annotation, such as a term that must not be translated

Notes

A note element attaches context to a unit or segment — the kind of information a translator needs but that is not part of the text itself: where the string appears in the UI, a character limit, or a warning that a placeholder must not be reordered. Notes travel with the unit through every tool in the pipeline, which is the point: context that only exists in a spreadsheet comment or a chat message gets lost the moment the file changes hands.

Why agencies and CAT tools converge on it

Translation agencies and computer-assisted translation (CAT) tools work across many clients with many different native formats. Standardizing on XLIFF as the interchange layer means a single tool can support any source format, as long as something converts to and from XLIFF, and a translator's environment stays the same regardless of what the client's underlying files look like.

What this protects, ultimately, is round-tripping: the guarantee that text extracted into XLIFF, translated, and merged back produces a file structurally identical to the original except for the translated content. That guarantee is what lets teams move translation work between tools and vendors without re-engineering their pipeline each time.