Så översätter du XLIFF-filer (Drupal, Symfony, Angular, iOS)
En Drupal-utvecklare postade på Stack Overflow förra veckan med en berättelse som utspelar sig tusentals gånger om året bland lokaliseringsgrupper i företag. Hennes team exporterade en 40 MB XLIFF-fil från sin Drupal-webbplats. Hon öppnade den i en textredigerare, klistrade in delar i Google Translate, satte ihop filen igen, importerade tillbaka den till Drupal – och hälften av sidorna vägrade att visas eftersom översatta strängar innehöll felaktig XML, felaktigt escapade tecken och trasiga <g>-taggar där inline-formateringen hade förstörts.
XLIFF är företagens lokaliseringsstandard av en anledning. Det är XML-baserat, verktygsoberoende och stöder den rika metadata som seriösa översättningsprojekt behöver: översättningsstatusar, alternativa översättningar, anteckningar mellan översättare och utvecklare, och strukturerad inline-markering. Men dess stora flexibilitet gör den lätt att korrumpera, och de verktyg som säkert hanterar .po-filer fungerar ofta inte med XLIFF.
Denna guide beskriver vad som gör XLIFF unikt, varför generiska översättningsmetoder förstör det, och det rätta sättet att översätta XLIFF-filer för Drupal, Symfony, Angular och iOS – de fyra plattformar där XLIFF används mest frekvent under 2026.
Vad är XLIFF (och varför företagsteam använder det)
XLIFF står för XML Localization Interchange File Format. Det är en OASIS-standard designad specifikt för att flytta översättningsinnehåll mellan verktyg – innehållshanteringssystem, översättningsminnesdatabaser, CAT-verktyg och lokaliseringsplattformar. Till skillnad från Gettext .po-filer (som lagrar platta nyckel-värde-par) eller JSON-lokaliseringsfiler (som är godtyckligt nästlade), är XLIFF ett strukturerat XML-dokument med ett standardiserat schema.
XLIFF 1.2 vs XLIFF 2.0
Två versioner finns i omlopp, och de är inte helt kompatibla.
XLIFF 1.2 är den äldre, mer utbredda versionen. Den använder <trans-unit>-element för att omsluta översättbart innehåll, med <source>- och <target>-barn. Inline-formatering använder <g>, <x> och <bpt> / <ept>-parade taggar. Drupals översättningshanteringsverktyg och många äldre plattformar exporterar fortfarande 1.2.
XLIFF 2.0 är revisionen från 2014, enklare och renare. Den använder <unit> och <segment> med <source> och <target>. Inline-markering använder <pc> (parerad kod) och <ph> (platshållare). Symfonys översättningskomponent och moderna iOS-exporter använder 2.0 som standard.
Ett översättningsverktyg som hanterar 1.2 hanterar inte automatiskt 2.0. Taggvokabulärerna är olika, och escaping-reglerna skiljer sig något. Kontrollera alltid vilken version din plattform exporterar innan du väljer en översättningspipeline.
Anatomien av en XLIFF-enhet
En minimal XLIFF 1.2 trans-unit ser ut så här:
<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>
<g id="1"> omsluter en platshållarvariabel. Attributet state talar om för plattformen att denna sträng behöver översättas. <note> är en utvecklarhint. En översättare som förstår XLIFF bör producera:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
En översättare som behandlar filen som vanlig text kan producera någon av dessa trasiga varianter:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Var och en av dessa bryter importen på olika sätt. Den första döper om variabeln. Den andra escapar XML:en. Den tredje tar bort formateringstaggen helt.
Dåliga lösningar (Varför du inte bara kan översätta XML)
De flesta team börjar med samma tre metoder och bränner flera dagar innan de ger upp.
Mata in XLIFF till en generisk AI
Kopiera filen, klistra in i Claude eller ChatGPT, be om översättning. Modellen gör oftast ett rimligt jobb med texten men behandlar XLIFF-taggar inkonsekvent. Ibland bevarar den <g>-taggar, ibland översätter den id-attributet, ibland tar den bort dem helt. Valideringen misslyckas. Din import kastar XML-tolkningsfel.
Använda ett CAT-verktyg utan XLIFF-stöd
Verktyg som Poedit är byggda för .po-format. De kan öppna XLIFF men behandlar det som en generisk textbehållare. Inline-taggar är inte låsta. Platshållare är inte skyddade. Du får en översättning som ser bra ut i redigeraren men misslyckas med schemavalidering vid import.
Skriva ett anpassat skript
Ditt team skriver ett Node- eller Python-skript som tolkar XLIFF med xml2js, extraherar källsträngar, anropar Google Translate och skriver tillbaka målsträngar. Det fungerar för 90 % av strängarna. De andra 10 % – strängar med nästlad formatering, pluralgrupper eller specialtecken – går sönder på sätt som bara visar sig efter att du redan har lanserat.
Samma ”flexibla format möter naiv översättare”-fel påverkar i18next JSON och Gettext .po-filer. Vår guide om att översätta i18next JSON-filer för React och Next.js och vårt inlägg om hur man översätter .po-filer utan att bryta kodvariabler täcker de parallella problemen för dessa format.
Det rätta sättet: Syntaxmedveten XLIFF-bearbetning
En korrekt XLIFF-översättningspipeline följer samma principer som vår PO-motor, anpassad för XML.
Parsa, inte Regex
Behandla XLIFF som ett strukturerat dokument. Parsa det med en riktig XML-parser, bygg ett träd och gå igenom <trans-unit>- (eller <unit> för 2.0) elementen. Att försöka regex-matcha käll- och målinnehåll är den snabbaste vägen till korrumperade filer.
Lås inline-taggar före översättning
Varje <g>, <x>, <bpt>, <ept>, <ph>, <pc> inuti en <source> måste bevaras av position och id-attribut. Ersätt dem med numeriska platshållare innan du skickar text till LLM, och återinfoga sedan de ursprungliga taggarna med deras attribut efter att översättningen har returnerats.
Respektera tillståndsmaskinen
XLIFF-enheter har tillstånd attribut: new, needs-translation, translated, reviewed, final, signed-off. En pipeline bör bara översätta enheter i new eller needs-translation tillstånd, och sätta utdatans tillstånd till translated (inte final – en granskare bör fortfarande verifiera).
Bevara struktur bortom översättningsenheter
XLIFF-filer innehåller rubriker, metadata, filnivåattribut, anteckningar och alternativa översättningar (<alt-trans>). Dessa måste förbli oförändrade under hela rundresan. Att ta bort eller omordna dem bryter rundresekompatibiliteten med källplattformen.
Validera före leverans
Innan du returnerar översatt XLIFF, validera mot schemat. XLIFF 1.2 har en officiell XSD. XLIFF 2.0 har sin egen. Ett verktyg som inte kan självvalidera är ett verktyg som kommer att leverera trasiga filer till dig.
Plattforms-specifika anteckningar
Varje stor plattform som använder XLIFF har egenheter som är värda att känna till.
Drupal
Drupals Translation Management Tool (TMGMT) exporterar XLIFF 1.2. Innehållstyper inkluderar noder (sidor, artiklar), taxonomitermer och konfiguration. TMGMT omsluter varje översättbart fält i en separat <trans-unit> med ett Drupal-specifikt ID-format (fieldname:delta:format).
Fallgrop: Drupal lagrar textformatinformation (filtrerad HTML, full HTML, vanlig text) tillsammans med innehåll. Översättning måste bevara HTML-markering när formatet tillåter det, och strippa till vanlig text när formatet inte gör det. Din pipeline behöver fältmedvetenhet.
Symfony
Symfonys översättningskomponent använder XLIFF 2.0 som standard (sedan Symfony 4). Strängar finns i translations/messages.xx.xliff. Symfony stöder ICU-meddelandeformat inuti XLIFF, vilket innebär att en enda enhet kan innehålla {count, plural, one {...} other {...}}-strukturer.
Fallgrop: ICU plural-kategorier inuti XLIFF behöver dubbelt skydd. XML-taggarna förblir intakta, OCH ICU-nyckelorden (plural, one, other, =0) får inte översättas. Många XLIFF-verktyg hanterar ett lager men inte båda.
Angular i18n
Angular exporterar XLIFF 1.2 eller 2.0 via kommandot ng extract-i18n. Filer innehåller komponentmallsträngar, med <x>-taggar som representerar Angular-uttryck och interpolationer som {{ count }}.
Fallgrop: Angular använder id-hashkollisioner över identiska källsträngar. En översättning måste bibehålla enhets-ID:n exakt annars kan Angular inte matcha dem vid import. Att döpa om id-attribut under bearbetningen är ett omedelbart fel.
iOS (Xcode Export)
Xcode exporterar XLIFF 1.2 för applokalisering via Product > Export Localizations. Strängar kommer från Localizable.strings, Info.plist-poster, storyboards och XIBs. iOS pluralregler finns i .stringsdict-filer som exporteras som ytterligare trans-units.
Fallgrop: iOS storyboard-strängar refererar till UI-element-ID:n. Dessa får inte ändras. Dessutom kräver Xcode att attributet target-language exakt matchar dess förväntade lokalformat (es, inte es-ES, i vissa sammanhang) annars ignorerar det tyst importen.
Översätta XLIFF med SimplePoTranslate
SimplePoTranslate stöder XLIFF på Pro- och Lifetime-planer. Arbetsflödet är detsamma som för .po-filer.
1. Exportera din XLIFF
Från din källplattform, exportera en eller flera .xliff-filer. För Drupal, använd TMGMT:s exportåtgärd. För Symfony, hitta translations/messages.en.xliff. För Angular, kör ng extract-i18n --format=xlf2. För Xcode, använd lokaliserings exporten.
2. Ladda upp till SimplePoTranslate
Dra filen till instrumentpanelen. Plattformen upptäcker automatiskt XLIFF-versionen (1.2 eller 2.0), tolkar strukturen och identifierar översättningsbara enheter. Välj ditt målspråk och tonfall.
3. Syntaxmedveten översättning
Inline-taggar, ICU-parametrar, platshållare och enhets-ID:n låses före översättning. Den underliggande AI-motorn ser bara ren text med kontext. Översatt text återinsätts i exakt samma ursprungliga struktur, statusar uppdateras, och filen valideras mot XLIFF-schemat före leverans.
4. Ladda ner och importera
Ladda ner den översatta XLIFF (plus .po, .json och .php motsvarigheter om du behöver korsplattform). Importera till din källplattform. Validera genom att rendera några översatta sidor eller vyer innan du rullar ut.
# 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. Integrera i CI
När du litar på pipelinen, automatisera den. Exportera XLIFF vid varje release, skicka via API, ladda ner översatta filer, committa till repo, deploya. Detta är samma CI-vänliga mönster som många byråer använder för WordPress .po-översättning – se vårt inlägg om molnbaserad översättning utan trasiga webbplatser för det arkitektoniska mönstret.
Sammanfattning
XLIFF är det rätta verktyget för seriöst lokaliseringsarbete – strukturerat, verktygsoberoende och tillräckligt rikt för att bära projektmetadata över system. Men dess XML-struktur är också skör. Varje tagg, attribut och statusvärde har semantisk vikt, och en översättare som inte förstår XLIFF som ett format kommer att korrumpera din fil på sätt som kanske inte visar sig förrän importen misslyckas eller en användare rapporterar ett trasigt UI.
Den säkra metoden är syntaxmedveten: parsa XML, lås de strukturella elementen, översätt endast textytor med kontext, validera mot schema före leverans. Detta gäller oavsett om du lanserar en Drupal-webbplats, en Symfony API, en Angular SPA eller en iOS-app. Plattformen skiljer sig åt, men XLIFF-disciplinen gör det inte.
Redo att översätta XLIFF-filer för Drupal, Symfony, Angular eller iOS utan trasiga taggar? Prova SimplePoTranslate gratis – inget kreditkort krävs. Ladda upp
.xliff, ladda ner säkra översättningar, importera till din plattform.