XLIFF File Translation: How to Translate and Return It Intact
To translate an XLIFF file, open it in a tool that reads the format, translate only the target elements, leave every tag and placeholder untouched, run QA checks, and import the result back into the app it came from. A text editor technically works. A CAT tool or a translator who works in one is safer, because it locks the markup and flags mistakes before they break your build.
This guide explains what is inside the file, how the process runs from export to re-import, where translations most often go wrong, and what to ask for when you hire someone to do it.
TL;DR
XLIFF is an XML container for translatable text. Source and target sit side by side, and markup is wrapped so it survives translation.
Never type over tags, placeholders or IDs. Most failed imports trace back to damaged inline markup.
Machine translation can pre-fill a file, but it can overwrite existing targets and its output is a draft until a human reviews it.
Validate the file and run QA checks for tags, placeholders, numbers and glossary terms before you import it.
For a Hungarian, English, German or French XLIFF, a single specialist translator working in a CAT tool keeps terminology consistent across the whole file.
Table of Contents
What an XLIFF file is
XLIFF stands for XML Localization Interchange File Format. The standards body behind it describes it as a tool-neutral specification for the lossless interchange of localizable data. In practice, that means your software, course platform or content system exports its strings into one file. A translator works on that file in any compatible tool, and the file goes back in with the translations placed where they belong.
The point of the format is separation. Layout, code and formatting stay out of the translator’s way. Microsoft’s globalization guidance describes the same idea: during extraction, non-translatable elements are stored apart, while the translatable text moves into XLIFF. The translator works with text only, without worrying about the original file format.
The specification’s FAQ lists what such a file can carry: the translatable text, but also metadata such as identifiers, length restrictions and translator notes. So a good XLIFF file often tells you more than a plain spreadsheet of strings would. A note might say that a string is a button label, or that it must stay under 20 characters.
Where you will meet XLIFF files
The most common sources are:
Mobile and desktop apps. Development environments export localizable strings as XLIFF for each target language.
E-learning authoring tools. Course platforms export slide text, quiz questions and captions as XLIFF so a translator can work without opening the course. We cover that side in our guide to e-learning translation.
Content and product management systems. Many connect to translation workflows through the format.
Translation agencies and CAT tools. Some tools convert other formats to XLIFF internally, then convert back after translation.
Versions matter. You will see 1.2, 2.0, 2.1 and 2.2 in the wild, plus vendor variants. The 1.2 and 2.x structures differ, and not every tool supports every version, so check which one your exporter produces before you send the file anywhere.
How the file is built
You do not need to be a developer to read one. The core structure is simple:
A file element names the source and target languages.
Inside it, each translatable string lives in a trans-unit (in 1.2) or a unit with segments (in 2.x).
Each unit holds a source element with the original text and a target element for the translation.
DeepL’s help center, for example, explains that source text sits in source elements and translations in target elements within the same trans-unit. After a machine translation pass, the target-language attribute is updated and the original source text stays in the file. That matters for review: the translator or reviewer sees both sides of every string.
Attributes carry the control information. A unit marked translate=“no” should be left alone. A state attribute shows whether a segment is new, translated, reviewed or final. Unit IDs let your application match each translation to the right place, so they must never be edited.
Inline tags: the part that breaks
A string like “Click Save to continue” cannot be stored as plain text, because the bold formatting has to survive. XLIFF handles this with inline elements. memoQ’s documentation explains that bpt, ept, ph and it are masking tags, and that the actual markup is stored inside them. A CAT tool imports these as protected inline tags, so the translator can move them around a sentence but cannot accidentally split or delete them.
This is the biggest practical argument against translating XLIFF in a plain text editor. A single deleted bracket or a placeholder such as {username} typed with a different character can stop the file from importing, or worse, import and display garbage.
The translation workflow, step by step
1. Prepare the export
Export from your application with the target language set. Check the XLIFF version. Note which units are already translated, because you probably do not want those retranslated. Send the translator context if you have it: screenshots, a glossary, notes on tone, character limits, and whether the audience is consumer or professional.
2. Set up the project in a CAT tool
The file is imported into a computer-assisted translation tool. Tools of this type support the format widely. One desktop tool’s product page, for instance, states that it handles XLIFF 1.0, 1.1, 1.2, 2.0, 2.1 and 2.2 as well as vendor variants, with translation memory and machine translation suggestions in the editor. Inline tags appear as protected markers, and a translation memory suggests earlier translations of identical or similar strings.
3. Translate and edit
The translator works segment by segment. The job is not just converting words. Strings in software are short, often without context, and a one-word button label can have three possible translations depending on whether it is a verb or a noun. This is where subject knowledge pays. A medical device interface, an automotive diagnostic tool and a video game menu each use different conventions in Hungarian, and the wrong register is visible immediately to native users.
4. Run QA
Before delivery, run automated checks and a human read-through (details in the QA section below).
5. Export the translated XLIFF
The tool writes the translated targets back into the XLIFF. Settings matter here. According to memoQ’s documentation, the export can check that tags are correctly paired, and the target language written to the file is the project’s target language unless you change it. Confirm the language code matches what your application expects. For Hungarian, that is hu or hu-HU, depending on your system.
6. Import and test in context
The translated file goes back into your application. Microsoft’s guidance says that after translation, skeleton files reassemble the original format with the translated content. Then you preview the result. Look at layout, fonts, directionality, pagination and text wrapping. Hungarian text is often longer than English, with long compound words that can overflow buttons and break narrow columns, so this step catches problems no file check will.
Machine translation and XLIFF
Many teams pre-translate XLIFF files with a machine translation engine, then have a person fix the output. This is a sound approach for large volumes of repetitive or lower-risk content, as long as you know how the engines treat the file.
A few behaviors to plan for, taken from one engine’s help page:
Units flagged translate=“no” are excluded.
Units whose state is anything other than initial or empty are normally ignored.
The engine overwrites existing target elements, so existing approved translations should be removed from the upload, or split into a do-not-retranslate subset.
That last point catches teams out. If you send a half-translated file with approved strings in it, you can lose work that was already reviewed.
Automation platforms offer a second route. Their documentation describes converting files to XLIFF, processing source segments with machine translation or AI, inserting the results into targets, and converting back to the original format. The same documentation notes that format support differs by tool, and that direct XLIFF input to one popular engine is limited to version 2.1 in that workflow. If your exporter produces 1.2, you may need a conversion step.
One more rule: machine output is a draft. One XLIFF editor’s guide notes that machine translation fills empty segments as Draft and confirms nothing. Treat it the same way. Anything customer-facing, legal, medical or safety-related needs a human who knows the subject. That is what post-editing is for. Light post-editing fixes errors and obvious awkwardness. Full post-editing brings the text to the quality of a human translation, which is the right level for published content.
Tool types: what fits your job
You will not find a single best tool, but you can match the type to the situation.
Approach | Best for | Watch out for |
Plain text editor | A few strings, a developer comfortable with XML | No tag protection, no QA, easy to break the file |
Desktop CAT tool | Professional translators, large files, terminology control | Needs a licence and a trained user |
Cloud translation management system | Teams with many languages and continuous releases | Setup effort, per-seat costs, data leaves your environment |
Machine translation engine alone | Quick drafts, internal content | Overwrites targets, no human review, tag handling varies |
Specialist translator in a CAT tool | Customer-facing, regulated or terminology-heavy content | Needs a briefing and context from you |
If your file contains regulated or sensitive content, such as unreleased product text, patient-facing instructions or contracts, think about where the data goes. A cloud tool or an engine that stores uploads is a different risk from a translator working locally under a confidentiality agreement. Our piece on confidential translation services covers what to ask.
Checking quality before you import
An XLIFF can look fine and still fail in production. Build a short release check.
Automated checks
Run QA in the CAT tool before export. A typical set, as one XLIFF editor guide lists it, covers tags, placeholders, numbers, punctuation, consistency and glossary terms. Clear all empty targets and any tag or placeholder mismatches before delivery. Phrase’s documentation identifies tag problems as a common cause of export errors and recommends running QA checks to confirm tags and formatting before exporting.
Schema and importer validation
Validate the translated file against the XLIFF schema, and against your own importer. Hyperlocalise’s tutorial advises that teams validate translated XLIFF against the schema and their importer before importing it. A file can be schema-valid and still rejected by your application because of a quirk in how it reads attributes, so test both.
Human review in context
Automated checks do not know that a word is wrong for the screen it sits on. Read the translation in the running application or a preview build. Use this list:
Do any strings overflow their containers?
Are variables, plurals and dates in the right order for the language?
Do names of features match across the product, documentation and marketing?
Are units, currencies and number formats correct for the target market?
Do special characters render? Hungarian uses long vowels with double acute accents (ő, ű), which some older fonts and encodings mishandle.
Is the tone consistent with the rest of your product?
Keep a record of every fix. Feed the corrections back into the translation memory and glossary, so the next batch starts from a better baseline.
Common XLIFF problems and quick fixes
The import fails with no clear message. Check for broken or missing inline tags, unescaped characters such as an ampersand, and a wrong language code.
Some strings appear in English after import. Look for empty targets, or units skipped because of their state or translate attribute.
Placeholders show as raw code. A placeholder was edited or moved outside its tag. Restore it from the source and rerun the placeholder check.
Text is cut off. Check any length restrictions in the file’s metadata and ask the translator for a shorter variant.
Translators complain about missing context. Add notes in the file, screenshots, or a link to a test build. Short strings without context are the top cause of wrong terminology.
Version mismatch. Convert to the version your importer expects, then revalidate.
Our perspective
We handle XLIFF files as a translator first and a file technician second. That order matters. The format is only a container, and what decides whether your product feels native to Hungarian users is whether the person translating understands what the string does on the screen, in the machine, or in the contract. Working as a single translator on a project has a practical benefit: one person owns the terminology from the first segment to the last. There is no handoff between a first translator and a reviewer who never saw the glossary. For technical, medical, legal, automotive and game content, that consistency is what keeps a 10,000-string file from reading like ten different authors wrote it. We work in up-to-date CAT tools, which keep your tags locked and your translation memory growing, and we run QA checks before every delivery. We also keep realistic deadlines and tell you early if a file needs context or a clarification, because a fast wrong answer costs more than an accurate one a few hours later. For urgent releases, we are often reachable outside regular business hours. If you already pre-translate with a machine engine, we can post-edit the output at the level your content needs, and we treat everything you send as confidential. Bernadett
What to look for in an XLIFF translation service
When you compare providers, ask these questions:
Which XLIFF versions and variants do you accept? The answer should be specific. If they cannot name the version you export, expect trouble.
Which tools do you work in, and how do you protect tags? A professional works in a CAT tool and runs tag and placeholder checks before delivery.
How do you handle terminology? Ask whether they use your glossary and translation memory, and whether they return an updated memory.
Who does the translation, and who reviews it? Know whether one specialist or a chain of subcontractors touches your file.
How is the file stored and shared? Ask about confidentiality terms, storage and deletion. This matters for unreleased products and personal data.
What turnaround is realistic? Ask for a deadline tied to word count, not a vague promise.
Can you post-edit machine output? If you already use a machine engine, ask whether they offer light and full post-editing as separate levels.
Will you test the file back in context? At minimum, they should validate the file. Better, they review a build or screenshots.
Pricing for this work is almost always per word, with rates set by language pair and by whether the text is translated from scratch or post-edited. Repetitions and matches from your translation memory can lower the effective cost, so share earlier files if you have them.
Our XLIFF translation service
We translate XLIFF files between Hungarian and English, and also from and into German and French, for technical, medical, legal, automotive, financial, marketing, software, multimedia and video game content. Published rates start at €0.05 per word for translation into Hungarian and €0.07 per word for translation into English, German or French. Machine translation post-editing starts at €0.04 per word for full post-editing and €0.03 per word for light post-editing. Localization is quoted per project.
Send us your file, the XLIFF version and any glossary or screenshots you have, and we will reply with a realistic timeline. See the rates and request a quote on the Wordsbyme home page.
FAQ
Can I translate an XLIFF file in a text editor?
Yes, because it is plain XML, and you can type each translation into its target element. The risk is that nothing protects the inline tags, placeholders or IDs, so one slip can stop the import. For anything beyond a few strings, use a CAT tool that locks the markup and runs QA checks.
Can machine translation handle an XLIFF file by itself?
Some engines accept XLIFF directly, but support depends on the version and on how the tool treats existing targets. One engine’s help page warns that it overwrites existing target elements. Machine output stays a draft, so have a specialist review anything customers or regulators will read.
What should I send a translator along with the XLIFF file?
Send the file, the XLIFF version, the target locale, and a glossary or earlier translation memory if you have them. Screenshots or a test build help most, since software strings are short and often ambiguous. Note any character limits, even if they are already in the file’s metadata.
How do I know the translated file will import correctly?
Validate it against the XLIFF schema and against your own importer before the real import. Run QA checks for tags, placeholders and empty targets. Then preview the result in the application and check layout, fonts and text wrapping.
Sources
Recommended
Comments