Guide · For business
Translating XML files: what gets translated and what stays untouched
XML separates content from structure. Only the text is translated; tags, keys and placeholders stay as they are. This guide to translating XML files shows which fields are included, how to prepare the file and what to check after the import.
In short
- The text content is translated. Tags, attribute names, IDs, keys and paths stay as they are.
- Before exporting, decide which elements and attributes are to be translated, such as
title,altorlabel. - Placeholders such as
{0},{count}or%sare never translated, but their position in the sentence may change. - The file should be well-formed and encoded in UTF-8, ideally with a schema or sample output.
- A test run with a small file saves hours on the big export.
What gets translated in an XML file
In XML, the content sits between the tags; the structure around it is technical. So only the text content and some of the attributes are translated. Tags, attribute names, IDs, keys, file paths and codes stay unchanged, or the target system won’t be able to find the content again.
The difficulty rarely lies in the language. It lies in drawing the line: which fields are visible text, and which are control information? You define this once, and from then on the import filter in the translation system applies it to every new file.
Five steps from file to import
It takes five steps to get from the file to the import. The most important is the second: once it is clear which fields get translated, the rest runs largely automatically.
- Check the fileWell-formed, UTF-8, schema available
- Define the fieldsWhich elements and attributes are text
- Set up the filterWe configure the import in the translation system
- TranslateWith translation memory and a glossary
- ImportTest run, then the full import
1. Check the file and its encoding
Open the file in an editor or parser and check that it is well-formed. The encoding should be UTF-8 without a BOM. Include the schema, DTD or a sample output so that the structure is unambiguous.
2. Define the translatable fields
Mark which elements contain text and which attributes are to be translated as well, such as title, alt or placeholder. The opposite list matters just as much: IDs, keys, codes, paths and technical values.
3. Set up the import filter
Based on this, we set up the filter in the translation system. It hides everything that is not translated and protects tags and placeholders from being changed. The filter then applies to every future export in the same format.
4. Translate with translation memory and a glossary
The translation uses translation memory and a glossary so that recurring text stays the same. For interface text, specify length limits so that nothing gets cut off.
5. Import and test
You receive a file with the same structure and the same keys. Import a small selection first and check special characters and placeholders, then import the rest.
The XML checklist as a PDF
The checklist from this page on a single sheet, to pass on to your developers or agency. Currently available in German only.
Checklist before you export
Sort out these points once, and every future export runs without follow-up questions.
Preparing XML for translation
What to check after the import
Most problems don’t show up in the file but only in the target system. These six points uncover them.
| Check | What to look for |
|---|---|
| Well-formedness | The file parses and validates without errors |
| Special characters | Umlauts, accents and quotation marks display correctly |
| Placeholders | All variables are present, none translated, none duplicated |
| Text length | Translated text fits into fields, buttons and labels |
| Language tag | xml:lang or the equivalent attribute is set to the target language |
| Spot check in the system | Look at a selection in the target system, not just in the file |
Common mistakes
Almost every mistake has the same cause: nobody clarified beforehand what is text and what is technical.
| Avoid | Better | Why |
|---|---|---|
| Translating tags or attribute names | Translate only text content and the attributes you have specified | The target system no longer recognises changed tags. |
| Translating or deleting placeholders | Keep placeholders exactly as they are | If a placeholder is missing, the system shows a gap or breaks. |
| Exporting the file in ISO-8859-1 | Use UTF-8 without a BOM | Umlauts and special characters arrive corrupted. |
| Running the whole file through a machine translation tool | Work with a filter that separates text from technical content | Without a filter, keys and codes get changed too. |
| Exporting everything without a test run | Start with a sample file | Otherwise a format error multiplies across thousands of entries. |
Frequently asked questions
Is XLIFF better than XML?
XLIFF is an XML format developed specifically for translation: source and target text sit side by side, with room for status and comments. If your system can export XLIFF, use XLIFF. If not, generic XML with a suitable filter works just as reliably.
Can you work with our own XML schema?
Yes. We set up a filter once that defines which elements and attributes are translated. After that, every future export in the same format can be processed without any preparation.
What happens to HTML in CDATA sections?
It is treated as formatted text: the content is translated and the markup is preserved. What matters is that you identify these sections in advance so the filter handles them correctly.
How do you keep terminology consistent across many files?
With translation memory and a glossary. Recurring text is translated identically, and product names and technical terms follow your specifications, in later exports too.
Can this be automated?
Yes. With the API or tolingo connect, exports can be handed over and translated files imported back automatically. That pays off as soon as exports come up regularly.