Convert an XLIFF file to TMX
The TMX is written in your browser from the file you drop below: TMX 1.4b, one
<tu> per confirmed segment, in document
order. Segments still in an unconfirmed state, and pairs where either side has no text,
are left out on purpose.
The output is deterministic — no dates, no machine ids, no random identifiers — so exporting the same file twice gives you two identical files, and a diff after a review pass shows only what actually changed.
The file opens in the editor. Exports → TMX, tags stripped (.tmx) or Exports → TMX, tags kept (.tmx) writes the memory.
When you need this
A client sends back a finished bilingual file and no memory. A translator worked outside your environment and the leverage from that job is sitting in one .sdlxliff. You are migrating between tools and want the linguistic asset out before the licence lapses. The translations exist; they are just not in a form a TM engine reads.
For a corpus of bilingual files, export each one and merge them in your TM tool, which deduplicates better than any converter.
Steps
- Open the bilingual file. Drop the XLIFF, SDLXLIFF or MQXLIFF file on the zone above. It is parsed in this browser tab; no copy of it is sent anywhere.
- Decide what belongs in the memory. Only segments in translated, reviewed or final state are exported. Use the state chips in the filter bar to see what is confirmed, and confirm anything else you want included with Ctrl+Enter.
- Check the language pair. The top bar shows the source and target language read from the file. Those two codes become srclang and the xml:lang of each tuv, so fix them in the file before exporting if they are wrong.
- Choose a tag mode. Choose Exports then TMX, tags stripped (.tmx) for plain text, or Exports then TMX, tags kept (.tmx) to map inline tags to bpt, ept and ph elements carrying their original markup.
- Import into your TM tool. Import the .tmx into the translation memory, and compare the unit count against the confirmed count from the editor before relying on it.
What to check afterwards
Open the .tmx in a text editor before you import it. The header should carry a real
srclang, and every <tuv> a real xml:lang. Then check the unit count: it
is lower than the segment count, because unconfirmed segments and empty pairs are skipped,
but it should match the confirmed figure in the top bar minus any blank targets.
The file carries no creationdate and no user
id, so nothing about your machine ends up in the memory. Tools that show a creation
date will show the import date instead.
The gotcha
If a file does not declare its languages, the export falls back to the BCP-47
undetermined code und. TM tools treat it as a
real language, so the memory imports cleanly and then matches nothing, ever — a quiet
failure that surfaces weeks later as "the TM is empty". Check the
language pair in the top bar before you export, and fix the file's own
source-language and target-language attributes if they are missing.
Tag mode is the other judgement call. Stripping gives cleaner text and higher fuzzy scores but tells the memory nothing about formatting. Keeping tags preserves it, and imports markup from one file filter into a memory that will be leveraged against files from another — which surfaces later as tag mismatches on otherwise perfect matches. Strip for a mixed corpus; keep for a memory that serves one content type.