Wie man einen WPML-Export übersetzt (XLIFF-Dateien in einem ZIP)

Wenn Sie gerade Übersetzungsaufträge aus WPML exportiert haben und vor einer ZIP-Datei sitzen und nicht wissen, was zu tun ist, ist dies der richtige Leitfaden. Sie müssen die Datei nicht entpacken und Sie müssen keine einzige XLIFF-Datei öffnen.

Was Sie hier eigentlich haben

Der Export von WPML ist ein ZIP-Archiv mit einem Ordner namens posts/ und einer .xliff-Datei pro Beitrag. Mehr nicht.

Die folgenden Zahlen stammen aus einem echten Export von 44 Beiträgen, gemessen statt geschätzt, sodass Sie diese mit Ihren eigenen vergleichen können.

Zwei Dinge an diesem Archiv überraschen die meisten Nutzer.

Jede Datei definiert ihr eigenes Sprachpaar. Das <file>-Element am Anfang jeder XLIFF-Datei gibt an, aus welcher Sprache sie stammt und in welche sie übersetzt werden soll:

<file original="103-3aeb85935a8505760aa368dc691898a7"
      source-language="fr"
      target-language="en"
      datatype="plaintext">

Ein einziger Export kann also vier verschiedene Zielsprachen gleichzeitig enthalten, wie im Beispiel: Französisch ins Englische, Deutsche, Spanische und Italienische. Das Archiv ist nicht ein einzelner Übersetzungsauftrag, sondern vier, die miteinander verschachtelt sind.

WPML nennt Ihnen die Größe des Auftrags. Jede Datei enthält ihre eigene Wortzahl in einem benutzerdefinierten Attribut:

tool:wpml-words-to-translate-count="843"

Addieren Sie diese, und Sie wissen genau, womit Sie es zu tun haben, bevor Sie sich verpflichten. Im Beispiel: 34.829 Wörter.

Was in einer Datei steckt

Eine XLIFF-Datei ist XML. Jedes übersetzbare Textstück ist eine <trans-unit> mit einem <source> und einem <target>. Der Inhalt ist in CDATA eingeschlossen, damit HTML innerhalb eines Beitrags das umgebende XML nicht beschädigt.

Hier ist eine vollständige Einheit. Diese Einheit wurde bereits über den Translation-Memory-Speicher verarbeitet, was man an den state-Attributen erkennt:

<trans-unit resname="title" restype="string" datatype="html" id="title">
  <source><![CDATA[Bien ventiler son logement en hiver]]></source>
  <target state="needs-review-translation" state-qualifier="tm-suggestion">
    <![CDATA[Ventilating your home in winter]]>
  </target>
  <tool:extradata unit="Title" type="text" group="Main Content" group_id="Main_Content-0"/>
</trans-unit>

Einheiten in diesem Zustand waren in diesem Export die Ausnahme: 18 von 228. Die anderen 210 besitzen gar kein state-Attribut, und ihr Zieltext entspricht wortwörtlich dem Quelltext.

Und hier ist das Detail, das entscheidet, wie Sie den gesamten Auftrag angehen.

WPML schreibt den Quelltext als Ausgangspunkt in das Ziel. Eine XLIFF-Datei, in der jedes <target> ausgefüllt ist, ist also keine übersetzte Datei. Im echten Export enthielten 217 der 228 Einheiten immer noch den Quelltext wortwörtlich. Nur 18 enthielten einen tatsächlichen Vorschlag aus dem Translation Memory, markiert mit state="needs-review-translation".

Wenn Sie die Datei nur überfliegen, werden Sie zu dem Schluss kommen, dass sie bereits fertig ist. Das ist sie nicht.

Die Einheiten, die Sie finden werden

WPML exportiert nicht nur den Beitragsinhalt. Im Beispiel-Export setzten sich die 228 Einheiten wie folgt zusammen:

Jede Einheit enthält zudem ein <tool:extradata>-Tag, das benennt, worum es sich handelt und zu welcher Gruppe sie gehört. So können Sie eine Kategorie ohne Raten von einem Titel unterscheiden.

Beachten Sie die Felder des SEO-Plugins. Ihre Meta-Titel und Beschreibungen befinden sich in diesem Archiv. Das ist eine gute Nachricht, bringt aber eine Entscheidung mit sich: Eine wörtlich übersetzte Meta-Beschreibung ist selten diejenige, die in der Zielsprache den Klick generiert.

Beachten Sie auch URL. Ihre Slugs sind übersetzbar, und im Beispiel-Export wurden sie bewusst in der Quellsprache belassen. Das ist eine bewusste Entscheidung mit Auswirkungen auf Ihre bestehenden Links, die nur Sie treffen können.

Die Shortcodes sind bereits deklariert

Das ist die beste Funktion von WPML, die fast niemand bemerkt. Der Header jeder Datei enthält eine Phase, in der jeder auf Ihrer Website registrierte Shortcode aufgelistet ist:

<phase phase-name="shortcodes" process-name="Shortcodes identification">
  <note>wp_caption,caption,gallery,playlist,audio,video,embed,
  wpml_language_switcher,product_brand,...</note>
</phase>

Ihre benutzerdefinierten Shortcodes stehen dort neben den WordPress-Shortcodes. Es ist eine maschinenlesbare Liste von Elementen, die den gesamten Prozess unverändert überstehen müssen.

Warum die offensichtlichen Wege schmerzen

Sie einzeln zu öffnen bedeutet, die Zielzeilen innerhalb von XML zu suchen, HTML-Tags und Shortcodes zu berücksichtigen, zu speichern und dies weitere 43 Mal zu wiederholen. Und das für jede der drei anderen Sprachen.

Sie an einen Übersetzer oder eine Agentur zu senden bedeutet, dass die sprachliche Arbeit zwar stimmt, die Arbeit mit den Dateien jedoch nicht. Sie zahlen einen Experten-Stundensatz dafür, dass jemand vorsichtig mit XML umgeht, und Sie zahlen ihn beim nächsten Content-Update erneut. Die Koordination ist der Kostenfaktor, nicht der Wortpreis.

Den Text in einen Chat-Assistenten zu kopieren funktioniert für einen Beitrag. Beim zehnten haben Sie den Überblick verloren, welche Dateien fertig sind, die Terminologie ist inkonsistent und nichts überträgt Ihre Entscheidungen von einer Datei zur nächsten.

Der gesamte Prozess in fünf Schritten

Alles vor dem vierten Schritt ist kostenlos. Das ist wichtiger, als es klingt: Ein Plan, der Ihr Archiv falsch interpretiert hat, kostet nichts in der Korrektur. Es gibt also keinen Grund zu raten.

Zwei Wege für den mittleren Teil

Die Schritte zwei bis vier können im Browser oder vollständig über das Terminal erfolgen. Die Wahl entscheidet nur darüber, wer die Eingaben tätigt, nicht über das Ergebnis.

Wählen Sie die Methode, die zu Ihrem Workflow passt. Wenn Sie dies gerade mit einem offenen Terminal lesen, bietet Option B weniger Schritte. Falls nicht, ist Option A keineswegs eine schlechtere Alternative.

Weg 1: Die ZIP-Datei wie sie ist senden

AI Glot akzeptiert sowohl XLIFF als auch ZIP, sodass ein WPML-Export ungeöffnet hochgeladen werden kann. Laden Sie das Archiv hoch und beschreiben Sie den Auftrag in einem Satz.

Die Anweisung ist ein Freitext, und hier werden die Eigenheiten des Exports zum Vorteil statt zum Ärgern:

Translate every trans-unit into the target language declared in each file.
Only translate units where the target still holds the same text as the source.
Leave the URL units exactly as they are.
Keep every shortcode, HTML tag and CDATA wrapper untouched.

Lesen Sie die zweite Zeile noch einmal, denn sie ist entscheidend. “Übersetze nur Einheiten, bei denen das Ziel noch denselben Text wie die Quelle enthält” ist genau die beschriebene 217-von-228-Situation. Das bedeutet, dass Sie nicht für die 18 Einheiten bezahlen, die Ihr Translation Memory bereits erledigt hat.

Sie erhalten einen Plan, bevor Kosten anfallen: die gefundenen Sprachen, der Umfang, die Wortzahl und die Kosten. Wenn der Plan etwas falsch interpretiert hat, korrigieren Sie dies in einem Satz, und er plant neu. Dann laden Sie eine ZIP-Datei mit derselben Struktur herunter, die bereit für den Import ist.

Weg 2: Ihren KI-Agenten arbeiten lassen

Wenn Sie mit Claude, ChatGPT, Cursor oder einem anderen Coding-Agenten arbeiten, müssen Sie den Browser überhaupt nicht öffnen. Unser Command-Line-Tool meldet sich über OAuth an und nimmt eine Datei direkt entgegen, sodass ein Agent den gesamten Auftrag ausführen kann.

Einmal installieren und anmelden:

npm install -g @ai-glot/cli
aiglot auth login

Dadurch öffnet sich ein Browser, um die Maschine zu autorisieren. Auf einem Server ohne Browser verwenden Sie aiglot auth login --device für den Device-Code-Flow oder aiglot auth login --key <key> in der CI.

Geben Sie Ihrem Agenten dann den Pfad zur Datei und lassen Sie ihn arbeiten. So etwas wie dies ist ausreichend:

My WPML export is at ~/Downloads/my-site-export.zip. It is a ZIP of XLIFF
files, one per WordPress post, and each file declares its own target
language.

Use the aiglot CLI to translate it. Run `aiglot batches create --help` and
`aiglot batches approve --help` first so you use the real flags. Create the
batch from the ZIP with an instruction that translates only the units whose
target still equals the source, and leaves the URL units alone. Show me the
plan and the cost before you approve anything. Use the lite quality tier.
Then poll until it is done and download the result next to the original.

Zwei Dinge machen diesen Prompt erfolgreich, und beides lohnt sich zu kopieren.

Er weist den Agenten an, zuerst die Hilfe zu lesen. Ein Agent, der Flag-Namen rät, wird beim ersten Aufruf scheitern und sich dann eine Begründung ausdenken. aiglot help --json gibt jeden Befehl, jedes Flag und jeden Exit-Code auf einmal aus, falls eine Struktur bevorzugt wird.

Er setzt einen Stopp vor die Kosten. aiglot batches approve ist der einzige Befehl, der Credits kostet. Alles davor ist kostenlos. Den Plan also zuerst anfordern kostet nichts und verhindert teure Missverständnisse.

Als Referenz: Dies ist die Sequenz, die der Agent letztendlich ausführen wird:

# 1. Create the batch. Free. Returns a plan and an id.
aiglot batches create ~/Downloads/my-site-export.zip \
  --instruction "Translate every trans-unit into the target language declared in each file. Only translate units whose target still holds the same text as the source. Leave URL units unchanged. Keep shortcodes, HTML and CDATA intact." \
  --json

# 2. Approve. This is the only step that spends credits.
aiglot batches approve <batch-id> --quality lite

# 3. Poll until it finishes.
aiglot batches get <batch-id> --json

# 4. Download the translated archive.
aiglot batches download <batch-id> --output ~/Downloads/my-site-export.translated.zip

Es gibt auch einen MCP-Server (aiglot mcp), falls Ihr Agent Tools gegenüber einer Shell bevorzugt. Die CLI ist der bessere Startpunkt: Sie funktioniert in einem Skript, sie funktioniert in der CI, und Sie können genau sehen, was ausgeführt wurde.

Einbindung Ihres Glossars

Wenn Ihre Seite Begriffe hat, die konsistent bleiben müssen, wie ein Produktname oder eine hausinterne Übersetzung einer wiederkehrenden Phrase, pflegen Sie diese einmal in einem Workspace-Glossar ein. Sie werden dann auf jede Datei im Archiv und auch auf den nächsten Export angewendet.

Das ist der Teil, den ein maschineller Übersetzer schlecht beherrscht. Sein Glossar ersetzt einen Begriff einfach überall dort, wo er vorkommt. Ein Glossar wird hier als Lemma behandelt. Es wird also in den Satz inflektiert und konjugiert, anstatt eine feste Zeichenfolge mitten in den Text zu setzen.

Import zurück in WPML

Das übersetzte Archiv kommt mit der gleichen Struktur zurück: derselbe posts/-Ordner, dieselben Dateinamen, dieselben Einheiten in derselben Reihenfolge, nur dass die Zieltexte nun ausgefüllt sind. Der Bildschirm für Übersetzungsjobs in WPML nimmt es genau so wieder auf, wie es Ihnen ausgegeben wurde.

Zwei Empfehlungen basierend auf der Dateistruktur. Importieren Sie zuerst eine Datei und prüfen Sie den Beitrag in WordPress, bevor Sie das gesamte Archiv übernehmen. Eine Page-Builder-Zeichenfolge an der falschen Stelle ist gerendert viel einfacher zu erkennen als in XML. Und entscheiden Sie sich vor dem Import für die Slugs, nicht danach: Eine veröffentlichte URL zu ändern, bedeutet eine Weiterleitung, die Sie dauerhaft pflegen müssen.

Der realistische Anwendungsbereich

Nutzen Sie dies für die Masse. Vierundvierzig Beiträge in vier Sprachen sind genau die Aufgabe, die in Handarbeit mühsam und in einem Durchgang unauffällig ist. Setzen Sie die menschliche Prüfung dort ein, wo sie ihren Wert beweist: bei Ihren meistbesuchten Seiten und überall dort, wo die Formulierung selbst das Produkt ist. Viele Teams nutzen AI Glot für den ersten Durchgang und lassen einen Reviewer über die Ergebnisse gehen. Das ist eine gute Nutzung eines Experten und eine schlechte Nutzung eines Nachmittags in XML.

Für eine Homepage sollten Sie einen Übersetzer beauftragen. Für das Archiv mit 44 Beiträgen, das Sie heute Morgen exportiert haben, sollten Sie nicht Ihre ganze Woche opfern.

Die hier beschriebene Exportstruktur wurde anhand eines realen WPML-Exports von 44 Beiträgen über vier Sprachpaare ermittelt. Ihr Export kann abweichen, wenn Ihre Seite einen anderen Page-Builder oder ein anderes SEO-Plugin verwendet, und die Unit-IDs werden Ihre eigenen Plugins widerspiegeln. Der posts/-Ordner, das XLIFF 1.2-Format, das Sprachpaar pro Datei und die kopierten Quelltexte in den Zielfeldern waren die Teile, die in allen 44 Dateien konsistent waren.