xliff1.8 KB

XLIFF 2.0 — Translation state (en to es)

The XLIFF 2.0 half of a version twin covering how each version records translation progress. XLIFF 1.2 has approved="yes|no" plus a ten-value target state; XLIFF 2.0 removed approved and cut the vocabulary to four ordered values (initial, translated, reviewed, final) with everything else pushed into a namespaced subState.

Internationalization Localization catalogs

Preview — first 49 linesxliff

<?xml version="1.0" encoding="UTF-8"?>
<!-- XLIFF 2.0 replaced the 1.2 state vocabulary with exactly four ordered values — initial,
     translated, reviewed, final — and moved everything else into subState, which is namespaced
     and free-form. approved="yes|no" is gone. The mapping is therefore lossy in both directions:
     1.2 "needs-review-translation" and "needs-adaptation" both collapse to 2.0 "translated", and
     going back the other way requires a policy decision the file itself cannot record. -->
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="es">
  <file id="f1" original="app.strings">
    <unit id="s1">
      <segment state="initial">
        <source>Files</source>
        <target></target>
      </segment>
    </unit>
    <unit id="s2">
      <segment state="initial">
        <source>Move to trash</source>
        <target>Move to trash</target>
      </segment>
    </unit>
    <unit id="s3">
      <notes><note category="pipeline">Machine translated, awaiting human review.</note></notes>
      <segment state="translated" subState="novus:machine-translated">
        <source>Rename</source>
        <target>Renombrar</target>
      </segment>
    </unit>
    <unit id="s4">
      <segment state="translated">
        <source>Duplicate</source>
        <target>Duplicar</target>
      </segment>
    </unit>
    <unit id="s5">
      <segment state="reviewed">
        <source>Properties</source>
        <target>Propiedades</target>
      </segment>
    </unit>
    <unit id="s6" translate="no">
      <notes><note>Brand name — translate="no" means leave it alone.</note></notes>
      <segment state="final">
        <source>Novus</source>
        <target>Novus</target>
      </segment>
    </unit>
  </file>
</xliff>

Specifications

Source Language: en
Target Language: es
Aspect: how each version records translation progress
Twin Of: the same content in the other XLIFF version
Version: 2.0 (OASIS)
Namespace: urn:oasis:names:tc:xliff:document:2.0
Seed: 20260807
Wave: p7
Line Endings: LF

Testing contract

Expected to pass

Scenario: Map every unit's state from one version to the other.
Expected result: The mapping is lossy in both directions: 1.2 'needs-review-translation' collapses to 2.0 'translated' + subState, and going back requires a policy the file cannot record.

What is a .xliff file?

XLIFF (XML Localization Interchange File Format) is an OASIS-standard XML format for exchanging translatable content between tools. It wraps source and target text in trans-units (1.2) or units and segments (2.0), with metadata, states, and notes. It is the lingua franca between authoring tools and translation-management systems.

How to use this file

Use an example .xliff file to test XLIFF parsers and validators, CAT tools and translation-management systems, and converters between XLIFF 1.2 and 2.0 or to other catalog formats.

How to use this file for testing

“XLIFF 2.0 — Translation state (en to es)” is a deterministic Novus Examples fixture for Internationalization, Localization catalogs. Parallel text and accented, multi-script content — for testing translation pipelines, Unicode handling, and localization tooling.

Documented properties for this file: seed 20260807 · LF. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.

Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.

Translation-catalog fixtures carry the same message set across formats, each with its native placeholder syntax. Test your i18n loader, catalog converter, or translation-memory tool, and use the RTL and CJK variants to check bidirectional text and Unicode handling.

Load the catalog with your i18n framework and verify placeholder interpolation and plural handling; the RTL and CJK variants exercise bidirectional text and font fallback.

Code examples

from translate.storage.xliff import xlifffile  # pip install translate-toolkit

store = xlifffile.parsefile("states-2.0.xliff")
for unit in store.units[:5]:
    print(unit.source, "->", unit.target)