XLIFF-Dateien übersetzen (Drupal, Symfony, Angular, iOS)
Ein Drupal-Entwickler postete letzte Woche auf Stack Overflow eine Geschichte, die sich jährlich Tausende Male in Lokalisierungsteams in Unternehmen abspielt. Ihr Team exportierte eine 40 MB große XLIFF-Datei von ihrer Drupal-Website. Sie öffnete sie in einem Texteditor, kopierte Teile in Google Translate, setzte die Datei wieder zusammen, importierte sie zurück in Drupal – und die Hälfte der Seiten weigerte sich zu rendern, weil übersetzte Zeichenketten fehlerhaftes XML, falsch platzierte Escape-Zeichen und kaputte <g>-Tags enthielten, bei denen die Inline-Formatierung zerstört worden war.
XLIFF ist aus gutem Grund der Standard für die Unternehmenslokalisierung. Es ist XML-basiert, tool-agnostisch und unterstützt die umfassenden Metadaten, die ernsthafte Übersetzungsprojekte benötigen: Übersetzungszustände, alternative Übersetzungen, Notizen zwischen Übersetzern und Entwicklern sowie strukturiertes Inline-Markup. Doch gerade seine Flexibilität macht es leicht, es zu beschädigen, und die Tools, die .po-Dateien sicher handhaben, versagen oft bei XLIFF.
Dieser Leitfaden erklärt, was XLIFF auszeichnet, warum generische Übersetzungsansätze es beschädigen und wie man XLIFF-Dateien für Drupal, Symfony, Angular und iOS richtig übersetzt – die vier Plattformen, auf denen XLIFF im Jahr 2026 am häufigsten verwendet wird.
Was ist XLIFF (und warum es Unternehmensteams nutzen)
XLIFF steht für XML Localization Interchange File Format. Es ist ein OASIS-Standard, der speziell dafür entwickelt wurde, Übersetzungsinhalte zwischen Tools zu verschieben – Content-Management-Systeme, Translation-Memory-Datenbanken, CAT-Tools und Lokalisierungsplattformen. Im Gegensatz zu Gettext .po-Dateien (die flache Schlüssel-Wert-Paare speichern) oder JSON-Lokalisierungsdateien (die beliebig verschachtelt sind) ist XLIFF ein strukturiertes XML-Dokument mit einem standardisierten Schema.
XLIFF 1.2 vs XLIFF 2.0
Zwei Versionen existieren und sind nicht vollständig kompatibel.
XLIFF 1.2 ist die ältere, weiter verbreitete Version. Sie verwendet <trans-unit>-Elemente, um übersetzbaren Inhalt zu umschließen, mit <source>- und <target>-Kindern. Inline-Formatierungen verwenden <g>, <x> und gepaarte <bpt> / <ept>-Tags. Drupal's Translation Management Tool und viele ältere Plattformen exportieren immer noch 1.2.
XLIFF 2.0 ist die Revision von 2014, einfacher und sauberer. Sie verwendet <unit> und <segment> mit <source> und <target>. Inline-Markup verwendet <pc> (paired code) und <ph> (placeholder). Symfonys Übersetzerkomponente und moderne iOS-Exporte verwenden standardmäßig 2.0.
Ein Übersetzungstool, das 1.2 verarbeitet, verarbeitet nicht automatisch 2.0. Die Tag-Vokabulare sind unterschiedlich und die Escaping-Regeln unterscheiden sich geringfügig. Überprüfen Sie immer, welche Version Ihre Plattform exportiert, bevor Sie eine Übersetzungs-Pipeline auswählen.
Die Anatomie einer XLIFF-Einheit
Eine minimale XLIFF 1.2 trans-unit sieht so aus:
<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>
Das <g id="1"> umschließt eine Platzhaltervariable. Das state-Attribut teilt der Plattform mit, dass diese Zeichenkette übersetzt werden muss. Die <note> ist ein Entwicklerhinweis. Ein Übersetzer, der XLIFF versteht, sollte Folgendes erstellen:
<target state="translated">¡Bienvenido, <g id="1">%name%</g>!</target>
Ein Übersetzer, der die Datei als reinen Text behandelt, könnte eine dieser fehlerhaften Varianten erstellen:
<target>¡Bienvenido, <g id="1">%nombre%</g>!</target>
<target>¡Bienvenido, <g id="1">%name%</g>!</target>
<target>¡Bienvenido, %name%!</target>
Jede davon beschädigt den Import unterschiedlich. Die erste benennt die Variable um. Die zweite maskiert das XML. Die dritte entfernt das Formatierungs-Tag vollständig.
Schlechte Lösungen (Warum man XML nicht einfach übersetzen kann)
Die meisten Teams beginnen mit denselben drei Ansätzen und verbrennen mehrere Tage, bevor sie aufgeben.
XLIFF einer generischen KI zuführen
Kopieren Sie die Datei, fügen Sie sie in Claude oder ChatGPT ein, und bitten Sie um Übersetzung. Das Modell erledigt die Textübersetzung in der Regel gut, behandelt XLIFF-Tags jedoch inkonsistent. Manchmal bewahrt es <g>-Tags, manchmal übersetzt es das id-Attribut, manchmal entfernt es sie vollständig. Die Validierung schlägt fehl. Ihr Import wirft XML-Parsing-Fehler.
Verwendung eines CAT-Tools ohne XLIFF-Unterstützung
Tools wie Poedit sind für das .po-Format entwickelt worden. Sie können XLIFF öffnen, behandeln es aber als generischen Textcontainer. Inline-Tags sind nicht gesperrt. Platzhalter sind nicht geschützt. Sie erhalten eine Übersetzung, die im Editor gut aussieht, aber bei der Schema-Validierung beim Import fehlschlägt.
Ein benutzerdefiniertes Skript schreiben
Ihr Team schreibt ein Node- oder Python-Skript, das XLIFF mit xml2js parst, Quellzeichenketten extrahiert, Google Translate aufruft und die Ziele zurückschreibt. Es funktioniert für 90% der Zeichenketten. Die anderen 10% – Zeichenketten mit verschachtelten Formatierungen, Pluralgruppen oder Sonderzeichen – brechen auf Weisen, die erst sichtbar werden, nachdem Sie bereits ausgeliefert haben.
Derselbe Fehler "flexibles Format trifft auf naiven Übersetzer" betrifft i18next JSON- und Gettext .po-Dateien. Unser Leitfaden zum Übersetzen von i18next JSON-Dateien für React und Next.js und unser Beitrag wie man .po-Dateien übersetzt, ohne Code-Variablen zu beschädigen behandeln die parallelen Probleme für diese Formate.
Der richtige Weg: Syntax-bewusste XLIFF-Verarbeitung
Eine ordnungsgemäße XLIFF-Übersetzungspipeline folgt denselben Prinzipien wie unsere PO-Engine, angepasst für XML.
Parsen, nicht Regex
Behandeln Sie XLIFF als strukturiertes Dokument. Parsen Sie es mit einem echten XML-Parser, erstellen Sie einen Baum und durchlaufen Sie die <trans-unit>- (oder <unit> für 2.0) Elemente. Der Versuch, Quell- und Zielinhalte per Regex abzugleichen, ist der schnellste Weg zu beschädigten Dateien.
Inline-Tags vor der Übersetzung sperren
Jedes <g>, <x>, <bpt>, <ept>, <ph>, <pc> innerhalb eines <source> muss durch Position und id-Attribut erhalten bleiben. Ersetzen Sie sie durch numerische Platzhalter, bevor Sie den Text an das LLM senden, und fügen Sie dann die ursprünglichen Tags mit ihren Attributen nach der Rückgabe der Übersetzung wieder ein.
Die Statusmaschine respektieren
XLIFF-Einheiten haben Statusattribute: new, needs-translation, translated, reviewed, final, signed-off. Eine Pipeline sollte nur Einheiten im Status new oder needs-translation übersetzen und den Ausgabestatus auf translated setzen (nicht final – ein Prüfer sollte dies noch verifizieren).
Struktur über Übersetzungseinheiten hinaus bewahren
XLIFF-Dateien enthalten Header, Metadaten, dateiebene Attribute, Notizen und alternative Übersetzungen (<alt-trans>). Diese müssen den Roundtrip unverändert überstehen. Das Entfernen oder Neuanordnen dieser Elemente unterbricht die Roundtrip-Kompatibilität mit der Quellplattform.
Vor der Auslieferung validieren
Bevor übersetztes XLIFF zurückgegeben wird, muss es gegen das Schema validiert werden. XLIFF 1.2 hat ein offizielles XSD. XLIFF 2.0 hat ein eigenes. Ein Tool, das sich nicht selbst validieren kann, ist ein Tool, das Ihnen fehlerhafte Dateien liefern wird.
Plattformspezifische Hinweise
Jede wichtige Plattform, die XLIFF verwendet, hat Besonderheiten, die es wert sind, bekannt zu sein.
Drupal
Drupal's Translation Management Tool (TMGMT) exportiert XLIFF 1.2. Inhaltstypen umfassen Nodes (Seiten, Artikel), Taxonomie-Begriffe und Konfiguration. TMGMT umschließt jedes übersetzbare Feld in einer separaten <trans-unit> mit einem Drupal-spezifischen ID-Format (fieldname:delta:format).
Fallstrick: Drupal speichert Textformatinformationen (gefiltertes HTML, vollständiges HTML, reiner Text) neben dem Inhalt. Die Übersetzung muss HTML-Markup beibehalten, wenn das Format es erlaubt, und auf reinen Text reduzieren, wenn das Format es nicht erlaubt. Ihre Pipeline benötigt feldbezogenes Wissen.
Symfony
Symfonys Übersetzungskomponente verwendet standardmäßig XLIFF 2.0 (seit Symfony 4). Zeichenketten befinden sich in translations/messages.xx.xliff. Symfony unterstützt das ICU-Nachrichtenformat innerhalb von XLIFF, was bedeutet, dass eine einzelne Einheit {count, plural, one {...} other {...}}-Strukturen enthalten kann.
Fallstrick: ICU-Pluralkategorien innerhalb von XLIFF benötigen doppelten Schutz. Die XML-Tags bleiben intakt, UND die ICU-Schlüsselwörter (plural, one, other, =0) dürfen nicht übersetzt werden. Viele XLIFF-Tools verarbeiten eine Ebene, aber nicht beide.
Angular i18n
Angular exportiert XLIFF 1.2 oder 2.0 über den Befehl ng extract-i18n. Dateien enthalten Komponenten-Template-Zeichenketten, wobei <x>-Tags Angular-Ausdrücke und Interpolationen wie {{ count }} darstellen.
Fallstrick: Angular verwendet id-Hash-Kollisionen bei identischen Quellzeichenketten. Eine Übersetzung muss die Einheits-IDs exakt beibehalten, da Angular sie sonst beim Import nicht zuordnen kann. Das Umbenennen von id-Attributen während der Verarbeitung führt sofort zu einem Fehler.
iOS (Xcode-Export)
Xcode exportiert XLIFF 1.2 für die App-Lokalisierung über Product > Export Localizations. Zeichenketten stammen aus Localizable.strings, Info.plist-Einträgen, Storyboards und XIBs. iOS-Pluralregeln befinden sich in .stringsdict-Dateien, die als zusätzliche trans-units exportiert werden.
Fallstrick: iOS Storyboard-Strings referenzieren UI-Element-IDs. Diese dürfen nicht geändert werden. Außerdem erfordert Xcode, dass das target-language-Attribut exakt seinem erwarteten Gebietsformat (es, nicht es-ES, in einigen Kontexten) entspricht, sonst ignoriert es den Import stillschweigend.
XLIFF mit SimplePoTranslate übersetzen
SimplePoTranslate unterstützt XLIFF in den Pro- und Lifetime-Plänen. Der Workflow ist derselbe wie bei .po-Dateien.
1. Ihr XLIFF exportieren
Exportieren Sie von Ihrer Quellplattform eine oder mehrere .xliff-Dateien. Für Drupal verwenden Sie die Exportfunktion von TMGMT. Für Symfony suchen Sie translations/messages.en.xliff. Für Angular führen Sie ng extract-i18n --format=xlf2 aus. Für Xcode verwenden Sie den Lokalisierungsexport.
2. Zu SimplePoTranslate hochladen
Ziehen Sie die Datei in das Dashboard. Die Plattform erkennt automatisch die XLIFF-Version (1.2 oder 2.0), parst die Struktur und identifiziert übersetzbare Einheiten. Wählen Sie Ihre Zielsprache und den Ton.
3. Syntax-bewusste Übersetzung
Inline-Tags, ICU-Parameter, Platzhalter und Einheiten-IDs werden vor der Übersetzung gesperrt. Die zugrunde liegende KI-Engine sieht nur sauberen Text mit Kontext. Übersetzter Text wird in die exakte Originalstruktur wieder eingefügt, Status werden aktualisiert und die Datei wird vor der Auslieferung gegen das XLIFF-Schema validiert.
4. Herunterladen und Importieren
Laden Sie das übersetzte XLIFF herunter (plus .po, .json und .php-Äquivalente, falls Sie plattformübergreifende Unterstützung benötigen). Importieren Sie es in Ihre Quellplattform. Validieren Sie, indem Sie einige übersetzte Seiten oder Ansichten rendern, bevor Sie es veröffentlichen.
# 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. In CI integrieren
Sobald Sie der Pipeline vertrauen, automatisieren Sie sie. Exportieren Sie XLIFF bei jeder Veröffentlichung, senden Sie es per API, laden Sie übersetzte Dateien herunter, committen Sie es ins Repo, stellen Sie es bereit. Dies ist dasselbe CI-freundliche Muster, das viele Agenturen für die WordPress .po-Übersetzung verwenden – siehe unseren Beitrag über Cloud-basierte Übersetzung ohne defekte Websites für das Architekturmuster.
Alles zusammenfügen
XLIFF ist das richtige Werkzeug für ernsthafte Lokalisierungsarbeiten – strukturiert, tool-agnostisch und reichhaltig genug, um Projektmetadaten über Systeme hinweg zu transportieren. Aber seine XML-Struktur ist auch anfällig. Jedes Tag, Attribut und jeder Statuswert hat semantisches Gewicht, und ein Übersetzer, der XLIFF nicht als Format versteht, wird Ihre Datei auf Weisen beschädigen, die möglicherweise erst beim Fehlschlagen des Imports oder wenn ein Benutzer eine fehlerhafte Benutzeroberfläche meldet, zutage treten.
Der sichere Ansatz ist syntax-bewusst: Parsen Sie das XML, sperren Sie die Strukturelemente, übersetzen Sie nur Textoberflächen mit Kontext, validieren Sie gegen das Schema vor der Auslieferung. Dies gilt unabhängig davon, ob Sie eine Drupal-Website, eine Symfony-API, eine Angular-SPA oder eine iOS-App ausliefern. Die Plattform unterscheidet sich, aber die XLIFF-Disziplin nicht.
Bereit, XLIFF-Dateien für Drupal, Symfony, Angular oder iOS ohne kaputte Tags zu übersetzen? Testen Sie SimplePoTranslate kostenlos – keine Kreditkarte erforderlich. Laden Sie
.xliffhoch, laden Sie sichere Übersetzungen herunter, importieren Sie sie in Ihre Plattform.