Eine Datei rein, fünf Formate raus: So machen Sie Ihre WordPress-Übersetzungen zukunftssicher

Sie haben drei Wochen damit verbracht, Ihr WordPress-Theme ins Spanische zu übersetzen. Die .po-Datei ist perfekt – jeder String überprüft, jede Variable intakt, jede Pluralform korrekt. Dann entscheidet sich Ihr Kunde für die Migration von einem klassischen PHP-Theme zu einem Headless-Setup mit React im Frontend.

Plötzlich ist Ihre .po-Datei nutzlos. Die React-App benötigt .json. Die Legacy-PHP-Widgets benötigen immer noch .mo. Der Freelancer, der die mobile App betreut, möchte .xliff. Und niemand hat Zeit, 4.000 Strings in drei verschiedene Formate neu zu übersetzen.

Dies ist kein Sonderfall. Es ist die Realität der modernen WordPress-Entwicklung, bei der Themes sowohl mit PHP- als auch mit JavaScript-Komponenten ausgeliefert werden, Plugins eine Mischung aus Gettext und i18next verwenden und Kunden ihre Meinung über die Architektur häufiger ändern als ihre Passwörter.

Warum Übersetzungsdateiformate wichtiger sind als je zuvor

Vor fünf Jahren war die WordPress-Übersetzung einfach. Sie hatten eine .po-Datei (lesbare Quelle) und eine .mo-Datei (kompilierte Binärdatei). Das war's. Jedes Theme, jedes Plugin, jedes Übersetzungstool sprach die gleiche Sprache.

Heute verwendet das WordPress-Ökosystem mindestens fünf Übersetzungsdateiformate in der Produktion:

Die fünf Formate, die Sie kennen müssen

.po (Portable Object) – Das menschenlesbare Quellformat, das von GNU Gettext verwendet wird. Enthält Originalzeichenketten (msgid) und ihre Übersetzungen (msgstr). Dies bearbeiten Übersetzer.

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) – Die kompilierte Binärversion einer .po-Datei. WordPress liest .mo-Dateien zur Laufzeit mit load_textdomain(). Schneller als das Parsen von .po zur Laufzeit, aber nicht von Menschen editierbar.

.json (JavaScript Object Notation) – Wird von wp_set_script_translations() für JavaScript-basierte Übersetzungen in Gutenberg-Blöcken, React-Komponenten und modernen Themes verwendet. WordPress erwartet eine bestimmte JSON-Struktur mit locale_data-Schlüsseln.

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) – Ein zunehmend beliebtes Format für Themes und Plugins, die das Laden von Übersetzungen im Laravel-Stil verwenden. Einige moderne WordPress-Themes umgehen Gettext vollständig und laden Übersetzungen aus PHP-Arrays, um die Leistung zu verbessern.

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) – Der Industriestandard für den Übersetzungsaustausch zwischen verschiedenen Tools und Plattformen. Wird von CAT-Tools (Computer-Assisted Translation) wie memoQ, Trados und Memsource verwendet. Unerlässlich bei der Zusammenarbeit mit professionellen menschlichen Übersetzern.

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

Das Problem: Format-Lock-in

Die meisten Übersetzungstools erzeugen ein Ausgabeformat. Poedit liefert Ihnen .po und .mo. WPML speichert Übersetzungen in der Datenbank (gar nicht in Dateien). Weglot speichert Übersetzungen auf seinen Servern in einem proprietären Format. Selbst TMS-Plattformen wie Crowdin und Lokalise erfordern, dass Sie Exportformate für jedes Projekt manuell konfigurieren.

Dies erzeugt einen Format-Lock-in – Ihre Übersetzungen sind in dem Format gefangen, das Ihr aktuelles Tool erzeugt. Wenn sich Ihre Anforderungen ändern, haben Sie zwei Möglichkeiten:

1. Alles im neuen Format neu übersetzen (teuer, zeitaufwändig und Sie verlieren alle manuellen Korrekturen)
2. Benutzerdefinierte Konvertierungsskripte schreiben (fehleranfällig, besonders bei komplexen Pluralformen und Variablen)

Keine der beiden Optionen ist gut. Beide verschwenden Zeit und Geld. Beide bergen Risiken.

Reale Szenarien, in denen Format-Lock-in schadet

Szenario 1: Theme-Modernisierung. Das Theme Ihres Kunden wird mit Gutenberg-Blöcken neu aufgebaut. Die alten PHP-Vorlagen verwendeten .mo-Dateien. Die neuen Blöcke benötigen .json für wp_set_script_translations(). Ihre 3.000 übersetzten Strings müssen während des Übergangs in beiden Formaten vorhanden sein.

Szenario 2: Agentur-Workflow. Sie verwalten 20 Kunden-Websites. Einige verwenden klassische Themes (.mo). Einige verwenden Headless-Setups (.json). Eines verwendet ein benutzerdefiniertes Framework, das PHP-Arrays liest. Sie benötigen die gleichen Übersetzungen in verschiedenen Formaten für verschiedene Kunden.

Szenario 3: Professionelle Überprüfung. Ihre KI-Übersetzungen sind zu 95 % korrekt, aber Sie möchten, dass ein Muttersprachler die restlichen 5 % überprüft. Professionelle Übersetzer verwenden CAT-Tools, die .xliff importieren. Sie müssen Ihre Übersetzungen nach .xliff exportieren, sie zur Überprüfung senden und die Korrekturen zurückführen.

Szenario 4: Plattformmigration. Ihr Kunde migriert von WordPress zu einer benutzerdefinierten Node.js-Anwendung. Die neue App verwendet i18next und benötigt .json-Dateien. Ihre 5.000 übersetzten Strings im .po-Format müssen konvertiert werden – ohne eine einzige Variable oder Pluralform zu verlieren.

Die Lösung: Einmal übersetzen, jedes Format erhalten

SimplePoTranslate verfolgt einen anderen Ansatz. Wenn Sie eine .po-, .pot-, .json- oder .xliff-Datei hochladen und eine Übersetzung ausführen, erhalten Sie eine ZIP-Datei mit allen fünf Formaten zurück:

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

Dies ist keine „Premium-Funktion“, die hinter einer Enterprise-Stufe gesperrt ist. Jeder kostenpflichtige Plan – Pro (19 $/Monat) und Lifetime (399 $ einmalig) – enthält alle fünf Ausgabeformate in jedem Übersetzungsauftrag.

Warum das für die Zukunftssicherheit wichtig ist

Wenn Sie von Anfang an alle fünf Formate haben, müssen Sie nie neu übersetzen. Ihre Übersetzungen sind ein Asset, das sich an jede technische Anforderung anpasst:

• Kunde migriert von klassisch zu Gutenberg? Stellen Sie die .json-Datei bereit.
• Neuer Entwickler bevorzugt PHP-Arrays? Händigen Sie ihm die .php-Datei aus.
• Professioneller Übersetzer möchte überprüfen? Senden Sie die .xliff-Datei.
• Umzug auf ein anderes CMS? Die .json- und .xliff-Dateien sind plattformunabhängig.

Sie übersetzen einmal. Die Formate sind fertig, wenn Sie sie brauchen.

Wie jedes Format in WordPress funktioniert

Zu wissen, welche Datei wohin gehört, ist für eine saubere Bereitstellung unerlässlich.

Bereitstellen von .mo-Dateien (klassische PHP-Themes und Plugins)

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

WordPress lädt diese automatisch, wenn die Seitensprache übereinstimmt. Kein Plugin erforderlich. Kein Datenbank-Overhead. Dies ist der Ansatz, der die beste Leistung liefert.

Bereitstellen von .json-Dateien (Gutenberg-Blöcke und JS-Komponenten)

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

Der Dateiname enthält das Script-Handle und einen MD5-Hash. WordPress gleicht diese ab, wenn Sie wp_set_script_translations() in Ihrem Plugin oder Theme aufrufen. Wenn Sie Gutenberg-Blöcke erstellen, ist dies die Datei, die Ihre übersetzten Blockbezeichnungen und -beschreibungen korrekt anzeigt.

Verwenden von .xliff-Dateien (professioneller Überprüfungsworkflow)

.xliff-Dateien werden nicht in WordPress bereitgestellt. Sie werden als Austauschformat verwendet, wenn Sie Übersetzungen an einen professionellen Prüfer senden oder in ein CAT-Tool importieren müssen. Der Workflow sieht wie folgt aus:

1. .po in SimplePoTranslate hochladen und .xliff in der ZIP-Datei erhalten
2. .xliff an Ihren Übersetzer oder Gutachter senden
3. Korrigiertes .xliff zurückerhalten
4. Korrigiertes .xliff in SimplePoTranslate hochladen und aktualisiertes .mo und .json erhalten

Dieser Roundtrip-Workflow bewahrt jede Variable und Pluralform, da SimplePoTranslate's Syntax Locking sie in jeder Phase schützt.

Der Vendor-Lock-in-Test

Hier ist ein einfacher Test, um festzustellen, ob Ihr aktueller Übersetzungs-Workflow ein Lock-in-Problem hat:

1. Können Sie Ihre Übersetzungen jetzt als Standard-.po-Dateien exportieren?
2. Wenn Sie Ihr Abonnement für das Übersetzungstool heute kündigen, behalten Sie dann jeden übersetzten String?
3. Können Sie Ihre Übersetzungen in ein völlig anderes Tool oder eine andere Plattform importieren, ohne neu zu übersetzen?

Wenn die Antwort auf eine dieser Fragen „Nein“ lautet, sind Sie gefangen. Dienste wie Weglot und GTranslate scheitern an allen drei Fragen – kündigen Sie das Abonnement und Ihre Übersetzungen verschwinden. WPML speichert Übersetzungen in der Datenbank, was den Export zwar möglich, aber mühsam macht. Selbst Desktop-Tools wie Poedit bestehen den Test auf dem Papier, beschränken Sie aber auf .po und .mo.

Mit SimplePoTranslate lautet die Antwort auf alle drei Fragen „Ja“. Sie laden Standarddateien in fünf Formaten herunter. Sie gehören Ihnen. Löschen Sie Ihr Konto morgen und jede Übersetzung, die Sie jemals gemacht haben, funktioniert noch.

Aufbau einer formatunabhängigen Übersetzungsbibliothek

Für Agenturen und Entwickler, die mehrere Projekte verwalten, ist der intelligenteste Ansatz der Aufbau einer Übersetzungsbibliothek – ein Git-Repository oder ein freigegebener Ordner, in dem Sie übersetzte Dateien für jedes Kundenprojekt speichern.

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

Wenn ein Kunde ein neues Format benötigt, haben Sie es bereits. Wenn ein Kunde die Plattform wechselt, werden Ihre Übersetzungen ohne Aufwand migriert. Wenn ein neuer Entwickler dem Team beitritt, kann er genau sehen, was übersetzt wurde und in welchen Formaten.

Das ist es, was „zukunftssicher“ wirklich bedeutet – nicht vorherzusagen, welche Technologie Ihre Kunden im nächsten Jahr verwenden werden, sondern sicherzustellen, dass Ihre Übersetzungen mit allem funktionieren, was sie wählen.

Sind Sie bereit, sich keine Sorgen mehr über Dateiformate zu machen? Testen Sie SimplePoTranslate kostenlos – laden Sie eine Datei hoch und erhalten Sie fünf Formate zurück. Keine Konvertierungsskripte, keine Neuübersetzung, kein Lock-in.