Sådan oversætter du XLIFF-filer (Drupal, Symfony, Angular, iOS)
En Drupal-udvikler postede på Stack Overflow i sidste uge med en historie, der udspiller sig tusindvis af gange om året i virksomheders lokaliseringsteams. Hendes team eksporterede en 40 MB XLIFF-fil fra deres Drupal-site. Hun åbnede den i en teksteditor, klistrede bidder ind i Google Translate, samlede filen igen, importerede den tilbage til Drupal – og halvdelen af siderne nægtede at gengive, fordi oversatte strenge indeholdt fejlformuleret XML, escapede tegn de forkerte steder og ødelagte <g>-tags, hvor inline-formateringen var blevet destrueret.
XLIFF er virksomhedernes lokaliseringsstandard af en grund. Den er XML-baseret, værktøjsuafhængig og understøtter den rige metadata, som seriøse oversættelsesprojekter har brug for: oversættelsesstatusser, alternative oversættelser, noter mellem oversættere og udviklere og struktureret inline-markup. Men dens store fleksibilitet gør den let at beskadige, og de værktøjer, der sikkert håndterer .po-filer, bryder ofte sammen med XLIFF.
Denne guide gennemgår, hvad der gør XLIFF unik, hvorfor generiske oversættelsesmetoder ødelægger den, og den rigtige måde at oversætte XLIFF-filer på til Drupal, Symfony, Angular og iOS – de fire platforme, hvor XLIFF oftest bruges i 2026.
Hvad er XLIFF (og hvorfor bruger virksomhedsteams det)
XLIFF står for XML Localization Interchange File Format. Det er en OASIS-standard designet specifikt til at flytte oversættelsesindhold mellem værktøjer – indholdsstyringssystemer, oversættelseshukommelsesdatabaser, CAT-værktøjer og lokaliseringsplatforme. I modsætning til Gettext .po-filer (som gemmer flade nøgle-værdi-par) eller JSON-lokalefiler (som indlejrer vilkårligt), er XLIFF et struktureret XML-dokument med et standardiseret skema.
XLIFF 1.2 vs XLIFF 2.0
To versioner eksisterer, og de er ikke fuldt kompatible.
XLIFF 1.2 er den ældre, mere udbredte version. Den bruger <trans-unit>-elementer til at omslutte oversætteligt indhold, med <source>- og <target>-børn. Inline-formatering bruger <g>, <x> og <bpt> / <ept> parrede tags. Drupals Translation Management Tool og mange ældre platforme eksporterer stadig 1.2.
XLIFF 2.0 er revisionen fra 2014, som er enklere og renere. Den bruger <unit> og <segment> med <source> og <target>. Inline-markup bruger <pc> (paired code) og <ph> (placeholder). Symfony's oversætterkomponent og moderne iOS-eksport er som standard 2.0.
Et oversættelsesværktøj, der håndterer 1.2, håndterer ikke automatisk 2.0. Tag-ordforrådene er forskellige, og escaping-reglerne afviger lidt. Kontroller altid, hvilken version din platform eksporterer, før du vælger en oversættelsespipeline.
Anatomien af en XLIFF-enhed
En minimal XLIFF 1.2 trans-unit ser således ud:
<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"> omslutter en pladsholder-variabel. state-attributten fortæller platformen, at denne streng skal oversættes. <note> er et udviklertip. En oversætter, der forstår XLIFF, bør producere:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
En oversætter, der behandler filen som almindelig tekst, kan producere en af disse ødelagte varianter:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Hver af disse bryder importen forskelligt. Den første omdøber variablen. Den anden escaper XML'en. Den tredje fjerner formateringstagget helt.
Dårlige løsninger (Hvorfor du ikke bare kan oversætte XML)
De fleste teams starter med de samme tre tilgange og spilder flere dage, før de giver op.
Indlæsning af XLIFF til en generisk AI
Kopiér filen, indsæt den i Claude eller ChatGPT, bed om oversættelse. Modellen gør som regel et rimeligt stykke arbejde med teksten, men behandler XLIFF-tags inkonsekvent. Nogle gange bevarer den <g>-tags, andre gange oversætter den id-attributten, og nogle gange fjerner den dem helt. Validering mislykkes. Din import kaster XML-parsing-fejl.
Brug af et CAT-værktøj uden XLIFF-understøttelse
Værktøjer som Poedit er bygget til .po-format. De kan åbne XLIFF, men behandler det som en generisk tekstbeholder. Inline-tags er ikke låst. Pladsholdere er ikke beskyttet. Du får en oversættelse, der ser fin ud i editoren, men som mislykkes ved skemavalidering ved import.
Skrivning af et tilpasset script
Dit team skriver et Node- eller Python-script, der parser XLIFF med xml2js, udtrækker kildestrenge, kalder Google Translate og skriver målene tilbage. Det virker for 90% af strengene. De resterende 10% – strenge med indlejret formatering, pluralgrupper eller specialtegn – går i stykker på måder, der først viser sig, efter at du allerede har lanceret.
Den samme fejltype, hvor "fleksibelt format møder naiv oversætter", påvirker i18next JSON- og Gettext .po-filer. Vores guide om oversættelse af i18next JSON-filer til React og Next.js og vores indlæg om hvordan man oversætter .po-filer uden at ødelægge kodevariabler dækker de parallelle problemer for disse formater.
Den rigtige måde: Syntaks-bevidst XLIFF-behandling
En ordentlig XLIFF-oversættelsespipeline følger de samme principper som vores PO-motor, tilpasset til XML.
Pars, ikke Regex
Behandl XLIFF som et struktureret dokument. Pars det med en rigtig XML-parser, byg et træ, og gennemgå <trans-unit> (eller <unit> for 2.0)-elementerne. Forsøg på at regex-matche kilde- og målindhold er den hurtige vej til beskadigede filer.
Lås inline-tags før oversættelse
Hvert <g>, <x>, <bpt>, <ept>, <ph>, <pc> inde i en <source> skal bevares ud fra position og id-attribut. Erstat dem med numeriske pladsholdere, før teksten sendes til LLM'en, og genindsæt derefter de originale tags med deres attributter, efter oversættelsen er returneret.
Respekter tilstandsmaskinen
XLIFF-enheder har statusattributter: new, needs-translation, translated, reviewed, final, signed-off. En pipeline bør kun oversætte enheder i new- eller needs-translation-tilstand og sætte outputtilstanden til translated (ikke final – en korrekturlæser bør stadig verificere).
Bevar struktur ud over oversættelsesenheder
XLIFF-filer indeholder headere, metadata, filniveauattributter, noter og alternative oversættelser (<alt-trans>). Disse skal overleve uændret gennem round-trip. At fjerne eller omarrangere dem ødelægger round-trip-kompatibiliteten med kildeplatformen.
Valider før levering
Før du returnerer oversat XLIFF, skal du validere mod skemaet. XLIFF 1.2 har en officiel XSD. XLIFF 2.0 har sin egen. Et værktøj, der ikke kan selv-validere, er et værktøj, der vil levere dig ødelagte filer.
Platforms-specifikke bemærkninger
Hver større platform, der bruger XLIFF, har særheder, der er værd at kende.
Drupal
Drupals Translation Management Tool (TMGMT) eksporterer XLIFF 1.2. Indholdstyper inkluderer noder (sider, artikler), taksonomitermer og konfiguration. TMGMT omslutter hvert oversætteligt felt i en separat <trans-unit> med et Drupal-specifikt ID-format (fieldname:delta:format).
Fælde: Drupal gemmer tekstformatinformation (filtreret HTML, fuld HTML, almindelig tekst) sammen med indhold. Oversættelse skal bevare HTML-markup, når formatet tillader det, og fjerne det til almindelig tekst, når formatet ikke gør. Din pipeline skal have felt-specifik bevidsthed.
Symfony
Symfonys oversættelseskomponent bruger XLIFF 2.0 som standard (siden Symfony 4). Strenge ligger i translations/messages.xx.xliff. Symfony understøtter ICU-meddelelsesformat inde i XLIFF, hvilket betyder, at en enkelt enhed kan indeholde {count, plural, one {...} other {...}}-strukturer.
Fælde: ICU plural kategorier inde i XLIFF kræver dobbelt beskyttelse. XML-tags forbliver intakte, OG ICU-nøgleordene (plural, one, other, =0) må ikke oversættes. Mange XLIFF-værktøjer håndterer ét lag, men ikke begge.
Angular i18n
Angular eksporterer XLIFF 1.2 eller 2.0 via ng extract-i18n-kommandoen. Filer indeholder komponenttemplatesstrenge, med <x>-tags, der repræsenterer Angular-udtryk og -interpolationer som {{ count }}.
Fælde: Angular bruger id-hashkollisioner på tværs af identiske kildestrenge. En oversættelse skal opretholde enheds-ID'er nøjagtigt, ellers kan Angular ikke matche dem ved import. Omdøbning af id-attributter under behandling er en øjeblikkelig fejl.
iOS (Xcode Eksport)
Xcode eksporterer XLIFF 1.2 til app-lokalisering via Product > Export Localizations. Strenge kommer fra Localizable.strings, Info.plist-poster, storyboards og XIB'er. iOS pluralregler findes i .stringsdict-filer, der eksporteres som yderligere trans-units.
Fælde: iOS storyboard-strenge refererer til UI-element-ID'er. Disse må ikke ændres. Desuden kræver Xcode, at target-language-attributten nøjagtigt matcher dets forventede lokaleformat (es, ikke es-ES, i visse sammenhænge), ellers ignorerer den importen lydløst.
Oversættelse af XLIFF med SimplePoTranslate
SimplePoTranslate understøtter XLIFF på Pro- og Lifetime-abonnementer. Arbejdsprocessen er den samme som for .po-filer.
1. Eksportér din XLIFF
Fra din kildeplatform skal du eksportere en eller flere .xliff-filer. For Drupal skal du bruge TMGMT's eksportfunktion. For Symfony skal du finde translations/messages.en.xliff. For Angular skal du køre ng extract-i18n --format=xlf2. For Xcode skal du bruge lokaliserings-eksporten.
2. Upload til SimplePoTranslate
Træk filen ind i dashboardet. Platformen registrerer automatisk XLIFF-versionen (1.2 eller 2.0), parser strukturen og identificerer oversættelsesenheder. Vælg dit målsprog og din tone.
3. Syntaks-bevidst oversættelse
Inline-tags, ICU-parametre, pladsholdere og enheds-ID'er låses før oversættelse. Den underliggende AI-motor ser kun ren tekst med kontekst. Oversat tekst genindsættes i den nøjagtige originale struktur, statusser opdateres, og filen valideres mod XLIFF-skemaet før levering.
4. Download og importér
Download den oversatte XLIFF (plus .po, .json og .php ækvivalenter, hvis du har brug for cross-platform). Importér til din kildeplatform. Valider ved at gengive et par oversatte sider eller visninger, før du ruller ud.
# 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. Integrer i CI
Når du stoler på pipelinen, automatiser den. Eksporter XLIFF ved hver udgivelse, send via API, download oversatte filer, commit til repo, deploy. Dette er det samme CI-venlige mønster, som mange bureauer bruger til WordPress .po-oversættelse – se vores indlæg om cloud-baseret oversættelse uden ødelagte sites for det arkitektoniske mønster.
Sammenfatning
XLIFF er det rigtige værktøj til seriøst lokaliseringsarbejde – struktureret, værktøjsuafhængigt og rigt nok til at bære projektmetadata på tværs af systemer. Men dets XML-struktur er også skrøbelig. Hvert tag, hver attribut og hver statusværdi har semantisk vægt, og en oversætter, der ikke forstår XLIFF som format, vil beskadige din fil på måder, der måske først viser sig, når importen mislykkes, eller en bruger rapporterer et ødelagt brugerinterface.
Den sikre tilgang er syntaks-bevidst: Pars XML'en, lås de strukturelle elementer, oversæt kun tekstflader med kontekst, valider mod skemaet før levering. Dette gælder, uanset om du udgiver et Drupal-site, en Symfony API, en Angular SPA eller en iOS-app. Platformen er forskellig, men XLIFF-disciplinen er den samme.
Klar til at oversætte XLIFF-filer til Drupal, Symfony, Angular eller iOS uden ødelagte tags? Prøv SimplePoTranslate gratis – intet kreditkort påkrævet. Upload
.xliff, download sikre oversættelser, importér til din platform.