User Rating 0.0 ★★★★★

Total Usage 0 times

Category Document Converters

XLIFF Content Supports XLIFF 1.2 with TYPO3 Flow namespace

Extract

JSON Structure

Key From

Indent

JSON Output

Converted JSON will appear here...

Is this tool helpful?

Your feedback helps us improve.

★ ★ ★ ★ ★

About

XLIFF (XML Localisation Interchange File Format) is the OASIS standard for exchanging localization data between tools. TYPO3 Flow stores translations as XLIFF 1.2 files under Resources/Private/Translations/, namespaced with urn:oasis:names:tc:xliff:document:1.2. When building Angular frontends with Pascal Precht's angular-translate, these XML files must be converted to flat JSON key-value maps. Manual conversion is error-prone: missed trans-unit elements, broken namespace resolution, or malformed keys from resname attributes silently corrupt your i18n pipeline. This tool parses XLIFF 1.2 documents using the native DOMParser, extracts translation units with proper namespace handling, and outputs JSON structures directly consumable by $translateProvider.useStaticFilesLoader(). It handles both source-only and source-target extraction modes. Note: this tool assumes well-formed XLIFF 1.2. XLIFF 2.0 uses a different schema and is not supported.

Formulas

The conversion follows a deterministic extraction pipeline from XML DOM to JSON object:

parse(xliff) → DOMParser.parseFromString(xliff, text/xml)

For each <trans-unit> element, the JSON key is resolved as:

key = resname ? resname : id

When nested output is selected, dot-separated keys are split into object hierarchies:

key = "a.b.c" → {a: {b: {c: value}}}

The value extraction depends on mode:

value =

{

target.textContent if target mode and target existssource.textContent otherwise (fallback)

Where resname is the preferred key attribute from <trans-unit>, id is the fallback identifier, source is the source language element content, and target is the target language element content. Total units extracted: N = count(trans-unit) across all <file> elements in the document.

Reference Data

XLIFF Element	Attribute	JSON Mapping	Description
<file>	source-language	Top-level locale key	ISO 639-1 language code of source
<file>	target-language	Top-level locale key	ISO 639-1 language code of target
<file>	original	Metadata (ignored in output)	Original file reference path
<trans-unit>	id	JSON key (fallback)	Unique identifier for translation unit
<trans-unit>	resname	JSON key (preferred)	Resource name, often dot-notated
<source>	-	JSON value (source mode)	Source language text content
<target>	-	JSON value (target mode)	Target language text content
<note>	-	Ignored	Translator comments, not exported
<group>	restype	Key prefix (if nested)	Logical grouping of translation units
<body>	-	Container	Wraps all trans-unit elements
<header>	-	Ignored	File-level metadata, skeletons
Namespace	urn:oasis:names:tc:xliff:document:1.2	-	XLIFF 1.2 XML namespace URI
TYPO3 Convention	id format	Dot-separated key	e.g. controller.action.label
angular-translate	JSON format	Flat key-value	{"KEY": "value"}
angular-translate	Nested format	Nested object	{"KEY": {"SUB": "value"}}
File extension	.xlf	.json	Standard file extensions
Encoding	UTF-8	UTF-8	Both formats use UTF-8

Frequently Asked Questions

TYPO3 Flow XLIFF files declare the namespace urn:oasis:names:tc:xliff:document:1.2. The converter uses DOMParser's getElementsByTagNameNS() with this exact URI to locate , , and elements. If no namespace is found, it falls back to non-namespaced getElementsByTagName() to handle files that omit the namespace declaration. Files using XLIFF 2.0 (namespace urn:oasis:names:tc:xliff:document:2.0) use a different element structure and are not supported.

The converter prioritizes the resname attribute as the JSON key because TYPO3 Flow conventions use resname for semantic dot-notated identifiers (e.g., controller.action.label). When resname is absent, the converter falls back to the id attribute. If neither exists, the unit is skipped and a warning is logged in the output summary. In angular-translate, the key is what you reference in your templates via {{ "KEY" | translate }}, so consistent naming is critical.

It depends on your localization workflow. Source mode extracts the original language strings - useful when building the base locale JSON file (e.g., en.json). Target mode extracts translated strings - use this when generating locale files for other languages (e.g., de.json, fr.json). If target mode is selected but a specific trans-unit lacks a element, the converter falls back to to prevent empty values in your JSON output.

Flat JSON produces a single-level key-value map: {"header.title": "Welcome"}. Nested JSON splits dot-separated keys into object hierarchies: {"header": {"title": "Welcome"}}. angular-translate supports both via $translateProvider configuration. Flat is simpler and avoids key collision issues. Nested gives cleaner namespace organization but requires that no key is simultaneously a value and a parent (e.g., you cannot have both "header" = "text" and "header.title" = "text").

Yes. You can upload multiple .xlf files using the file picker or drop them into the drop zone. Each file is parsed independently and produces its own JSON output. The converter preserves the source-language and target-language attributes from each file's element so you can identify which locale each output belongs to. For bulk TYPO3 Flow projects with dozens of packages, this is significantly faster than configuring a Grunt task pipeline.

The converter uses textContent to extract element values, which strips all XML markup and returns plain text. If your XLIFF source or target elements contain CDATA sections, the enclosed text is extracted normally. However, inline XLIFF markup like , , (placeholder and paired tags) will have their text content merged into the output string without tag semantics. For angular-translate, this is typically acceptable since interpolation uses {{ variable }} syntax rather than XML inline elements.