XLIFF-bestanden vertalen (Drupal, Symfony, Angular, iOS)
Een Drupal-ontwikkelaar plaatste vorige week een verhaal op Stack Overflow dat jaarlijks duizenden keren voorkomt bij enterprise lokalisatieteams. Haar team exporteerde een 40MB XLIFF-bestand van hun Drupal-site. Ze opende het in een teksteditor, plakte stukken in Google Translate, stelde het bestand opnieuw samen, importeerde het terug in Drupal – en de helft van de pagina's weigerde te renderen omdat vertaalde strings misvormde XML, onjuist geëscapeteerde tekens en kapotte <g>-tags bevatten waar de inline-opmaak was vernietigd.
XLIFF is niet voor niets de enterprise lokalisatiestandaard. Het is XML-gebaseerd, tool-agnostisch en ondersteunt de uitgebreide metadata die serieuze vertaalprojecten nodig hebben: vertaalstatussen, alternatieve vertalingen, notities tussen vertalers en ontwikkelaars, en gestructureerde inline-opmaak. Maar de grote flexibiliteit maakt het ook gemakkelijk te beschadigen, en de tools die .po-bestanden veilig verwerken, falen vaak bij XLIFF.
Deze gids legt uit wat XLIFF uniek maakt, waarom generieke vertaalbenaderingen het kapotmaken, en de juiste manier om XLIFF-bestanden te vertalen voor Drupal, Symfony, Angular en iOS – de vier platforms waar XLIFF in 2026 het meest wordt gebruikt.
Wat is XLIFF (en waarom enterprise teams het gebruiken)
XLIFF staat voor XML Localization Interchange File Format. Het is een OASIS-standaard die specifiek is ontworpen voor het verplaatsen van vertaalinhoud tussen tools – contentmanagementsystemen, vertaalgeheugen databases, CAT-tools en lokalisatieplatforms. In tegenstelling tot Gettext .po-bestanden (die platte sleutel-waarde-paren opslaan) of JSON-lokale bestanden (die willekeurig genest zijn), is XLIFF een gestructureerd XML-document met een gestandaardiseerd schema.
XLIFF 1.2 vs XLIFF 2.0
Er bestaan twee versies in het wild, en deze zijn niet volledig compatibel.
XLIFF 1.2 is de oudere, meer wijdverspreide versie. Het gebruikt <trans-unit>-elementen om vertaalbare inhoud te omwikkelen, met <source>- en <target>-kinderen. Inline-opmaak gebruikt <g>, <x> en gekoppelde tags <bpt> / <ept>. Drupal's Translation Management Tool en veel oudere platforms exporteren nog steeds 1.2.
XLIFF 2.0 is de revisie uit 2014, eenvoudiger en schoner. Het gebruikt <unit> en <segment> met <source> en <target>. Inline-opmaak gebruikt <pc> (paired code) en <ph> (placeholder). Symfony's vertaalcomponent en moderne iOS-exports gebruiken standaard 2.0.
Een vertaaltool die 1.2 verwerkt, verwerkt niet automatisch 2.0. De tag-vocabulaire is anders, en de escaping-regels verschillen enigszins. Controleer altijd welke versie uw platform exporteert voordat u een vertaalpipeline kiest.
De anatomie van een XLIFF-eenheid
Een minimale XLIFF 1.2 trans-unit ziet er zo uit:
<trans-unit id="msg_welcome" datatype="plaintext">
<source>Welcome, <g id="1">%name%</g>!</source>
<target state="needs-translation">Welcome, <g id="1">%name%</g>!</target>
<note>Displayed on the homepage after login</note>
</trans-unit>
De <g id="1"> omwikkelt een placeholder-variabele. Het state-attribuut vertelt het platform dat deze string vertaling nodig heeft. De <note> is een hint voor de ontwikkelaar. Een vertaler die XLIFF begrijpt, zou dit moeten produceren:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Een vertaler die het bestand als platte tekst behandelt, zou een van deze kapotte varianten kunnen produceren:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Elk van deze varianten breekt de import anders. De eerste hernoemt de variabele. De tweede ontsnapt de XML. De derde verwijdert de opmaaktag volledig.
Slechte oplossingen (waarom u XML niet zomaar kunt vertalen)
De meeste teams beginnen met dezelfde drie benaderingen en verliezen enkele dagen voordat ze opgeven.
XLIFF aan een generieke AI voeren
Kopieer het bestand, plak het in Claude of ChatGPT, vraag om vertaling. Het model doet meestal redelijk werk met de tekst, maar behandelt XLIFF-tags inconsistent. Soms behoudt het <g>-tags, soms vertaalt het het id-attribuut, soms verwijdert het ze volledig. Validatie mislukt. Uw import genereert XML-parseerfouten.
Een CAT-tool zonder XLIFF-ondersteuning gebruiken
Tools zoals Poedit zijn gebouwd voor het .po-formaat. Ze kunnen XLIFF openen, maar behandelen het als een generieke tekstcontainer. Inline-tags zijn niet vergrendeld. Placeholders zijn niet beschermd. U krijgt een vertaling die er in de editor prima uitziet, maar bij import faalt de schemavalidatie.
Een eigen script schrijven
Uw team schrijft een Node- of Python-script dat XLIFF parset met xml2js, bronstrings extraheert, Google Translate aanroept en vertalingen terugschrijft. Dit werkt voor 90% van de strings. De overige 10% – strings met geneste opmaak, meervoudsgroepen of speciale tekens – breken op manieren die pas zichtbaar worden nadat u al bent uitgerold.
Dezelfde 'flexibel formaat ontmoet naïeve vertaler'-faalmodus treft i18next JSON- en Gettext .po-bestanden. Onze gids over i18next JSON-bestanden vertalen voor React en Next.js en onze post over hoe .po-bestanden te vertalen zonder codevariabelen te breken behandelen de parallelle problemen voor die formaten.
De juiste manier: Syntax-bewuste XLIFF-verwerking
Een correcte XLIFF-vertaalpijplijn volgt dezelfde principes als onze PO-engine, aangepast voor XML.
Parsen, niet Regex
Behandel XLIFF als een gestructureerd document. Parseer het met een echte XML-parser, bouw een boomstructuur en loop door de <trans-unit>- (of <unit> voor 2.0) elementen. Proberen om bron- en doelinhoud te matchen met regex is de snelle weg naar beschadigde bestanden.
Inline-tags vergrendelen vóór vertaling
Elke <g>, <x>, <bpt>, <ept>, <ph>, <pc> binnen een <source> moet behouden blijven op basis van positie en id-attribuut. Vervang ze door numerieke placeholders voordat u tekst naar het LLM stuurt, en voeg vervolgens de originele tags met hun attributen opnieuw in nadat de vertaling is teruggekomen.
Respecteer de State Machine
XLIFF-eenheden hebben statusattributen: new, needs-translation, translated, reviewed, final, signed-off. Een pijplijn mag alleen eenheden vertalen in de new- of needs-translation-status, en de uitvoerstatus instellen op translated (niet final – een reviewer moet nog verifiëren).
Structuur behouden buiten vertaaleenheden
XLIFF-bestanden bevatten headers, metadata, attributen op bestandsniveau, notities en alternatieve vertalingen (<alt-trans>). Deze moeten ongewijzigd blijven gedurende de round-trip. Het strippen of herordenen ervan verbreekt de round-trip compatibiliteit met het bronplatform.
Valideer vóór levering
Voordat u vertaalde XLIFF retourneert, valideert u deze tegen het schema. XLIFF 1.2 heeft een officiële XSD. XLIFF 2.0 heeft zijn eigen. Een tool die zichzelf niet kan valideren, is een tool die u kapotte bestanden zal leveren.
Platformspecifieke opmerkingen
Elk belangrijk platform dat XLIFF gebruikt, heeft eigenaardigheden die het waard zijn om te kennen.
Drupal
Drupal's Translation Management Tool (TMGMT) exporteert XLIFF 1.2. Contenttypen omvatten nodes (pagina's, artikelen), taxonomietermen en configuratie. TMGMT omwikkelt elk vertaalbaar veld in een afzonderlijke <trans-unit> met een Drupal-specifiek ID-formaat (fieldname:delta:format).
Let op: Drupal slaat tekstformaatinformatie (gefilterde HTML, volledige HTML, platte tekst) op naast de inhoud. Vertaling moet HTML-opmaak behouden wanneer het formaat dit toestaat, en strippen naar platte tekst wanneer het formaat dit niet toestaat. Uw pijplijn heeft per-veld-bewustzijn nodig.
Symfony
Symfony's vertaalcomponent gebruikt standaard XLIFF 2.0 (sinds Symfony 4). Strings staan in translations/messages.xx.xliff. Symfony ondersteunt ICU-berichtformaat binnen XLIFF, wat betekent dat een enkele eenheid structuren zoals {count, plural, one {...} other {...}} kan bevatten.
Let op: ICU meervoudscategorieën binnen XLIFF hebben dubbele bescherming nodig. De XML-tags blijven intact, EN de ICU-sleutelwoorden (plural, one, other, =0) mogen niet worden vertaald. Veel XLIFF-tools behandelen één laag, maar niet beide.
Angular i18n
Angular exporteert XLIFF 1.2 of 2.0 via de opdracht ng extract-i18n. Bestanden bevatten component template strings, met <x>-tags die Angular-expressies en interpolaties zoals {{ count }} vertegenwoordigen.
Let op: Angular gebruikt id-hash-conflicten over identieke bronstrings heen. Een vertaling moet eenheids-ID's precies behouden, anders kan Angular ze niet matchen bij import. Het hernoemen van id-attributen tijdens de verwerking veroorzaakt direct een fout.
iOS (Xcode-export)
Xcode exporteert XLIFF 1.2 voor app-lokalisatie via Product > Export Localizations. Strings komen uit Localizable.strings, Info.plist-ingangen, storyboards en XIBs. iOS-meervoudsregels staan in .stringsdict-bestanden die geëxporteerd worden als aanvullende trans-units.
Let op: iOS storyboard-strings verwijzen naar UI-element-ID's. Deze mogen niet worden gewijzigd. Bovendien vereist Xcode dat het target-language-attribuut exact overeenkomt met het verwachte locale-formaat (es, niet es-ES, in sommige contexten), anders negeert het de import stilzwijgend.
XLIFF vertalen met SimplePoTranslate
SimplePoTranslate ondersteunt XLIFF in de Pro- en Lifetime-abonnementen. De workflow is hetzelfde als voor .po-bestanden.
1. Exporteer uw XLIFF
Exporteer vanuit uw bronplatform één of meerdere .xliff-bestanden. Gebruik voor Drupal de exportactie van TMGMT. Zoek voor Symfony translations/messages.en.xliff. Voer voor Angular ng extract-i18n --format=xlf2 uit. Gebruik voor Xcode de Localization-export.
2. Uploaden naar SimplePoTranslate
Sleep het bestand naar het dashboard. Het platform detecteert automatisch de XLIFF-versie (1.2 of 2.0), parset de structuur en identificeert vertaalbare eenheden. Kies uw doeltaal en toon.
3. Syntax-bewuste vertaling
Inline-tags, ICU-parameters, placeholders en eenheids-ID's worden vergrendeld vóór de vertaling. De onderliggende AI-engine ziet alleen schone tekst met context. Vertaalde tekst wordt opnieuw ingevoegd in de exacte originele structuur, statussen worden bijgewerkt en het bestand wordt gevalideerd tegen het XLIFF-schema vóór levering.
4. Downloaden en importeren
Download de vertaalde XLIFF (plus .po, .json en .php equivalenten als u cross-platform nodig heeft). Importeer in uw bronplatform. Valideer door een paar vertaalde pagina's of weergaven te renderen voordat u uitrolt.
# Angular example
ng extract-i18n --format=xlf2 --output-path=src/locale
# upload src/locale/messages.xlf to SimplePoTranslate
# download messages.es.xlf
# reference in angular.json i18n configuration
ng build --localize
5. Integreren in CI
Zodra u de pijplijn vertrouwt, automatiseert u deze. Exporteer XLIFF bij elke release, dien in via API, download vertaalde bestanden, commit naar de repo, implementeer. Dit is hetzelfde CI-vriendelijke patroon dat veel bureaus gebruiken voor WordPress .po-vertaling – zie onze post over cloud-gebaseerde vertaling zonder kapotte sites voor het architectuurpatroon.
Alles op een rijtje
XLIFF is het juiste hulpmiddel voor serieus lokalisatiewerk – gestructureerd, tool-agnostisch en rijk genoeg om projectmetadata over systemen heen te dragen. Maar de XML-structuur is ook fragiel. Elke tag, attribuut en statuswaarde heeft semantische betekenis, en een vertaler die XLIFF niet begrijpt als formaat, zal uw bestand beschadigen op manieren die pas aan het licht komen wanneer de import mislukt of een gebruiker een kapotte UI rapporteert.
De veilige aanpak is syntax-bewust: parseer de XML, vergrendel de structurele elementen, vertaal alleen tekstoppervlakken met context, valideer tegen het schema vóór levering. Dit geldt of u nu een Drupal-site, een Symfony API, een Angular SPA of een iOS-app levert. Het platform verschilt, maar de XLIFF-discipline niet.
Klaar om XLIFF-bestanden voor Drupal, Symfony, Angular of iOS te vertalen zonder kapotte tags? Probeer SimplePoTranslate gratis – geen creditcard vereist. Upload
.xliff, download veilige vertalingen, importeer in uw platform.