XLIFF
XLIFF 1.2 and XLIFF 2.0 bilingual interchange files, for translation tools, agencies and platforms that export XLIFF.
| Format | Identifier | Extensions |
|---|---|---|
| XLIFF 1.2 | xliff_12 | .xlf, .xliff (exports use .xlf) |
| XLIFF 2.0 | xliff_20 | .xlf, .xliff (exports use .xlf) |
XLIFF is bilingual: each unit carries the source text and its translation. transglot reads the translation for the locale you import and writes both sides on export, so a translator or tool receiving the file sees the source next to each string. When transglot guesses the format of an .xlf file, the version on <xliff> (or the namespace) picks 1.2 or 2.0.
XLIFF 1.2
<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file original="transglot" source-language="en" target-language="fr" datatype="plaintext">
<body>
<trans-unit id="home.title" resname="home.title">
<source>Welcome back</source>
<target state="translated">Bon retour</target>
<note>Home screen title</note>
</trans-unit>
</body>
</file>
</xliff>Import
- The key is the
resnameattribute, oridwhen there is noresname. A unit with neither is an error, and so is a key that appears twice. - The value is the
<target>text. A unit with no<target>, or an empty one, is skipped with a warning, except when you import the file's source language: then<source>is the value. <note>elements become the key's description (several notes are joined with newlines).- Units inside
<group>elements are read. Other elements, such as<alt-trans>and<context-group>, are ignored. target-languageis checked against the locale you import; a mismatch is accepted with a warning.- The
stateattribute is not imported: an import never marks a translation as reviewed.
XLIFF 2.0
<?xml version="1.0" encoding="utf-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" version="2.0" srcLang="en" trgLang="fr">
<file id="f1">
<unit id="home.title">
<segment>
<source>Welcome back</source>
<target>Bon retour</target>
</segment>
</unit>
</file>
</xliff>Import
- The XLIFF 2.0 namespace is required. A 1.2 document is rejected rather than read as 2.0.
- The key is the
<unit>id. A unit without one is an error, and so is a key that appears twice. - A unit with several
<segment>elements is read as one string, the segments joined in order. - The value is the
<target>text; a unit with no<target>is read from its<source>. - Only units that are direct children of
<file>are read. Units inside<group>elements are not imported. <notes>,<ignorable>and elements from other namespaces (such as the metadata, matches or glossary modules) are ignored. XLIFF 2.0 files do not carry descriptions into transglot.
Inline markup
transglot stores plain text. A unit whose <source> or <target> contains inline elements (<g>, <x/>, <ph>, <bpt> in 1.2; <ph>, <pc>, <sc>, <ec>, <mrk> in 2.0) is skipped with a warning naming it, rather than imported with its placeholders silently removed. Text placeholders such as %1$s and {name} are ordinary text and are kept. CDATA and XML entities decode like any text.
Plurals
Neither version has a plural construct. Plural keys are left out of an XLIFF export, and an ICU plural message inside a unit is an ordinary string.
Export
- One unit per key, in byte order, with
<source>from the project's source locale and<target>from the exported locale. 1.2 writesidandresname(both the key),state="translated", and a<note>with the key's description. 2.0 writes one<segment>per unit. - Language attributes are BCP 47 (
pt-BR). - When a key has no source text,
<source>is empty rather than filled with the translation, so the file never labels translated text as source. - Carriage returns are written as
, and control characters XML cannot represent are replaced with U+FFFD, so the file is always well-formed. - Unlike files for apps, XLIFF exports keep translations that are not valid ICU, because a reviewer needs to see them.
Security
A DOCTYPE with its own declarations is rejected, external DTDs are never fetched, and entities are never expanded from them.