Attention
TYPO3 v11 has reached end-of-life as of October 31th 2024 and is no longer being maintained. Use the version switcher on the top left of this page to select documentation for a supported version of TYPO3.
Need more time before upgrading? You can purchase Extended Long Term Support (ELTS) for TYPO3 v11 here: TYPO3 ELTS.
XLIFF Format
The XML Localization Interchange File Format (or XLIFF) is an OASIS-blessed standard format for translations.
In a nutshell, an XLIFF document contains one or more <file>
elements.
Each file element usually corresponds to a source (file or database table) and
contains the source of the localizable data. Once translated, the corresponding
localized data is added for one, and only one, locale.
Localizable data is stored in <trans-
elements. <trans-
contains a <source>
element to store the source text and a
(non-mandatory) <target>
element to store the translated text.
The default language is always English, even if you have changed your TYPO3
backend to another language. It is mandatory to set source-
.
Note
Having several <file>
elements in the same XLIFF document is not
supported by the TYPO3 Core.
Basics
Here is a sample XLIFF file:
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" datatype="plaintext" original="EXT:my_ext/Resources/Private/Language/Modules/<file-name>.xlf" date="2020-10-18T18:20:51Z" product-name="my_ext">
<header/>
<body>
<trans-unit id="headerComment" resname="headerComment">
<source>The default Header Comment.</source>
</trans-unit>
<trans-unit id="generator" resname="generator">
<source>The "Generator" Meta Tag.</source>
</trans-unit>
</body>
</file>
</xliff>
The following attributes should be populated properly in order to get the best support in external translation tools:
original
(in<file>
tag)- This property contains the path to the xlf file.
resname
(in<trans-
tag)unit> - Its content is shown to translators. It should be a copy of the
id
property.
The translated file is very similar. If the original file was named
locallang.
, the translated file for German (code "de") will be named
de.
.
Note
The original file must always be in English, so it is not allowed to create
a file with the prefix "en", for example en.
.
In the file itself, a target-
attribute is added to the
<file>
tag to indicate the translation language ("de" in our example).
TYPO3 does not consider the target-
attribute for its own processing
of translations, but the filename prefix instead. The attribute might be useful
though for human translators or tools.
Then, for each <source>
tag there is a sibling <target>
tag
that contains the translated string.
This is how the translation of our sample file might look like:
<?xml version="1.0" encoding="UTF-8"?>
<xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
<file source-language="en" target-language="de" datatype="plaintext" original="EXT:my_ext/Resources/Private/Language/Modules/<file-name>.xlf" date="2020-10-18T18:20:51Z" product-name="my_ext">
<header/>
<body>
<trans-unit id="headerComment" resname="headerComment" approved="yes">
<source>The default Header Comment.</source>
<target>Der Standard-Header-Kommentar.</target>
</trans-unit>
<trans-unit id="generator" resname="generator" approved="yes">
<source>The "Generator" Meta Tag.</source>
<target>Der "Generator"-Meta-Tag.</target>
</trans-unit>
</body>
</file>
</xliff>
Only one language can be stored per file, and each translation into another language is placed in an additional file.
Note
The optional approved
attribute in a <trans-
tag
indicates whether the translation has been approved by a reviewer.
Crowdin supports this attribute.
Currently, only approved translations are exported and available via the
TYPO3 translation server.
File locations and naming
In the TYPO3 Core, XLIFF files are located in the various system extensions
as needed and are expected to be located in Resources/
.
In Extbase, the main file (locallang.
) is loaded
automatically and is available in the controller and Fluid views without any
further work. Other files must be explicitly referenced with the syntax
LLL:
.
As mentioned above, the translation files follow the same naming conventions, but are prepended with the language code and a dot. They are stored alongside the default language files.
ID naming
It is recommended to apply the following rules for defining identifiers (the
id
attribute).
Separate by dots
Use dots to separate logical parts of the identifier.
Good example:
CType.menuAbstract
Bad examples:
CTypeMenuAbstract
CType-menuAbstract
Namespace
Group identifiers together with a useful namespace.
Good example:
CType.menuAbstract
This groups all available content types for content elements by using
the same prefix CType.
.
Bad example:
menuAbstract
Namespaces should be defined by context.
menuAbstract.CType
could also be a reasonable namespace
if the context is about menuAbstract
.
lowerCamelCase
Generally, lowerCamelCase should be used:
Good example:
frontendUsers.firstName
Note
For some specific cases where the referenced identifier is in a format
other than lowerCamelCase, that format can be used:
For example, database table or column names often are written in snake_case,
and the XLIFF key then might be something like fe_users.first_name
.