.po vs. .mo vs. .pot: WordPress-Übersetzungsdateien erklärt

Sie öffnen den languages-Ordner eines WordPress-Themes und finden drei fast identische Dateien: twentytwentyfour.pot, twentytwentyfour-de_DE.po und twentytwentyfour-de_DE.mo. Gleiches Theme, gleiche Sprache, drei verschiedene Erweiterungen. Welche bearbeiten Sie? Welche lädt WordPress tatsächlich? Und warum verschwinden Ihre Übersetzungen lautlos, wenn Sie die falsche bearbeiten?

Wenn Sie sich jemals gefragt haben, welche Datei in der Debatte .po vs. .mo-Datei wichtig ist, sind Sie nicht allein. Diese drei Dateierweiterungen sind das Rückgrat jeder übersetzten WordPress-Website, doch der Unterschied zwischen ihnen bringt Anfänger und erfahrene Entwickler gleichermaßen ins Stolpern. Bearbeiten Sie die falsche Datei, und Ihre deutschen Besucher sehen immer noch Englisch. Bearbeiten Sie die richtige, überspringen aber einen Schritt, und es ändert sich auch nichts.

Dieser Leitfaden erklärt genau, was .pot-, .po- und .mo-Dateien sind, wie sie im GNU Gettext-Workflow zusammenhängen, wo sie in WordPress zu finden sind und warum Sie eine .mo-Datei niemals in einem Texteditor öffnen sollten. Am Ende wissen Sie, welche Datei Sie anfassen und welche Sie in Ruhe lassen sollten.

Was sind .pot-, .po- und .mo-Dateien?

Kurz gesagt: Eine .pot-Datei ist die leere Vorlage, eine .po-Datei ist Ihre bearbeitbare Übersetzung, und eine .mo-Datei ist die kompilierte Binärdatei, die WordPress zur Laufzeit liest. Sie bilden eine Kette, und jedes Glied hat genau eine Aufgabe.

Diese drei Formate stammen alle von GNU Gettext, dem Lokalisierungssystem, auf das WordPress, Drupal und Tausende von PHP- und C-Projekten angewiesen sind. Gettext trennt die Quellstrings, die ein Entwickler schreibt, von den Übersetzungen, die ein Übersetzer bereitstellt, sodass dieselbe Codebasis Dutzende von Sprachen sprechen kann, ohne eine einzige PHP-Zeile anzufassen.

Stellen Sie es sich wie eine Rezeptkarte vor. Die .pot ist die leere Karte mit Zutatenfeldern, aber ohne Mengenangaben. Die .po ist die für ein bestimmtes Gericht ausgefüllte Karte. Die .mo ist die laminierte, maschinenlesbare Kopie, die die Küche tatsächlich während des Betriebs verwendet. Sie schreiben auf die Papierkarte; Sie kritzeln niemals auf die laminierte.

Die .pot-Datei: Die Master-Vorlage

Eine .pot-Datei (Portable Object Template) enthält jeden übersetzbaren String in einem Theme oder Plugin, wobei die Übersetzungen leer gelassen werden. Sie ist die Masterliste, die Entwickler ausliefern, damit Übersetzer genau wissen, was übersetzt werden muss. Die msgstr-Zeilen sind leer, da noch keine Sprache ausgewählt wurde.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr ""

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr ""

Beachten Sie das leere msgstr "". Eine .pot ist eine Vorlage, keine Übersetzung. Sie kopieren sie einmal pro Sprache und füllen die Lücken aus. Eine .pot wird selten manuell bearbeitet; sie wird aus dem Quellcode neu generiert, wann immer sich Strings ändern.

Die .po-Datei: Ihre von Menschen bearbeitbare Übersetzung

Eine .po-Datei (Portable Object) ist eine Kopie der .pot, deren msgstr-Zeilen für eine Sprache ausgefüllt sind. Dies ist die Datei, die Übersetzer und Entwickler tatsächlich bearbeiten. Sie ist reiner Text, menschenlesbar und versionskontrollfreundlich.

#: includes/checkout.php:42
msgid "Add to Cart"
msgstr "In den Warenkorb"

#: includes/account.php:108
msgid "Your order has been shipped to %s"
msgstr "Ihre Bestellung wurde an %s versandt"

Die msgid ist der ursprüngliche englische Quellstring und darf sich niemals ändern. Die msgstr ist Ihre Übersetzung. Das %s ist ein Platzhalter, der unberührt in der Übersetzung erhalten bleiben muss – das Weglassen oder Umordnen ist die häufigste Ursache für fehlerhafte Layouts, was wir ausführlich in Wie man PO-Dateien übersetzt, ohne Code-Variablen zu beschädigen behandeln.

Die .mo-Datei: Die kompilierte Binärdatei

Eine .mo-Datei (Machine Object) ist die kompilierte Binärversion Ihrer .po. WordPress kann .po-Dateien zur Laufzeit nicht effizient lesen, daher lädt es stattdessen die vorkompilierte .mo. Das Öffnen einer .mo in einem Texteditor zeigt unlesbare Bytes – sie ist für Maschinen, nicht für Menschen gedacht.

Wenn WordPress load_textdomain() oder load_theme_textdomain() aufruft, sucht es nach einer .mo-Datei, analysiert deren binäre Hash-Tabelle und tauscht jedes msgid zur Laufzeit gegen das passende msgstr aus. Dieses Binärformat macht Suchvorgänge selbst auf Websites mit Tausenden von Strings schnell.

Wie hängen die drei Dateien im Gettext-Workflow zusammen?

Sie bilden eine unidirektionale Pipeline: Quellcode wird zu einer .pot, die .pot wird zu einer sprachspezifischen .po, und jede .po kompiliert zu einer .mo. Übersetzungen fließen immer bergab.

Hier ist der vollständige Lebenszyklus der Reihe nach:

1. Ein Entwickler umschließt benutzeroberflächennahe Strings in Gettext-Funktionen wie __() und _e() innerhalb des PHP-Quellcodes.
2. Ein Scan-Tool liest den Quellcode und generiert die .pot-Vorlage, die jeden umschlossenen String enthält.
3. Ein Übersetzer kopiert die .pot in eine sprachspezifische .po (zum Beispiel de_DE.po) und füllt jedes msgstr aus.
4. Die fertige .po wird zu einer binären .mo kompiliert.
5. WordPress lädt die .mo zur Laufzeit und zeigt die übersetzte Website an.

Wenn der Entwickler später neue Strings hinzufügt, wird die .pot neu generiert, die neuen Einträge werden in jede bestehende .po zusammengeführt (wobei alte Übersetzungen erhalten bleiben), der Übersetzer füllt die Lücken, und die .po wird zu .mo rekompiliert. Der Zyklus wiederholt sich über die gesamte Lebensdauer des Projekts.

Die entscheidende Erkenntnis: Sie bearbeiten die .po und kompilieren sie dann zu .mo. Sie bearbeiten niemals die .mo direkt und übersetzen niemals innerhalb der .pot. Wenn Sie das umfassendere End-to-End-Bild wünschen, führt Sie der ultimative Leitfaden zur WordPress-Lokalisierung mit Beispielen durch die gesamte Pipeline.

Namenskonventionen und der Speicherort der Dateien

WordPress ist streng in Bezug auf Dateinamen. Wenn die Benennung falsch ist, wird Ihre perfekt übersetzte .mo einfach ignoriert, weil WordPress eine genaue Übereinstimmung basierend auf der Textdomain und dem Locale sucht.

Das Namensschema für Theme- und Plugin-Übersetzungen lautet:

# Pattern: textdomain-locale.po / .mo
twentytwentyfour-de_DE.po      # German (Germany) translation
twentytwentyfour-de_DE.mo      # compiled binary WordPress loads
twentytwentyfour-fr_FR.po      # French (France)
twentytwentyfour.pot           # template, no locale suffix

Die textdomain stimmt mit dem String überein, der als zweites Argument an Gettext-Funktionen wie __( 'Add to Cart', 'twentytwentyfour' ) übergeben wird. Das locale ist ein WordPress-Locale-Code wie de_DE, fr_FR oder pt_BR. Die .pot-Vorlage trägt keinen Locale-Suffix, da sie sprachneutral ist.

Der Speicherort ist genauso wichtig wie die Benennung. WordPress sucht in einigen vorhersehbaren Pfaden:

• Theme-Übersetzungen befinden sich im languages/-Ordner des Themes selbst: wp-content/themes/your-theme/languages/.
• Plugin-Übersetzungen befinden sich in wp-content/plugins/your-plugin/languages/.
• Übersetzungen von translate.wordpress.org und Benutzer-Overrides landen in den globalen Verzeichnissen wp-content/languages/themes/ und wp-content/languages/plugins/, die Vorrang haben und Updates überdauern.

Legen Sie eine korrekt benannte de_DE.mo in den richtigen Ordner, und deutsche Besucher sehen Deutsch. Legen Sie sie einen Ordner zu tief ab oder buchstabieren Sie die Textdomain falsch, und WordPress fällt stillschweigend auf Englisch zurück, ohne Fehlermeldung. Wenn Ihre Übersetzungen nicht angezeigt werden, ist eine fehlerhafte Benennung oder ein falscher Pfad der übliche Übeltäter, und der Leitfaden zur Fehlerbehebung bei fehlenden Übersetzungen behandelt jede häufige Ursache.

Warum Sie eine .mo-Datei niemals direkt bearbeiten sollten

Da eine .mo eine kompilierte Binärdatei ist, gibt es keine sichere Möglichkeit, sie manuell zu bearbeiten – und jede Änderung, die Sie erzwingen, wird überschrieben, wenn die .po das nächste Mal rekompiliert wird. Die .po ist die Quelle der Wahrheit; die .mo ist ein wegwerfbares Build-Artefakt.

Diese eine Regel erklärt einen Großteil der Support-Tickets mit der Meldung „Meine Übersetzung hat sich geändert, aber die Website wurde nicht aktualisiert“. Jemand ändert einen String, speichert die .po und vergisst, die .mo neu zu kompilieren. WordPress lädt weiterhin die alte Binärdatei, sodass die neue Formulierung nie erscheint. Die Lösung ist immer: .po bearbeiten, zu .mo rekompilieren, neu laden.

Es gibt einen zweiten Grund, warum die Regel wichtig ist: .mo-Dateien sind in der Versionskontrolle nicht diff-freundlich. Da sie binär sind, erzeugt eine geringfügige Textänderung einen undurchsichtigen Block in Ihrer Git-Historie, den kein Reviewer lesen kann. Die .po als nachverfolgte Quelle der Wahrheit zu behalten und die .mo als generiertes Artefakt zu behandeln, hält Ihr Repository überprüfbar und Ihre Übersetzungen auditierbar.

Dies manuell über Dutzende von Sprachen hinweg zu tun, ist mühsam und fehleranfällig. Hier spart ein Cloud-Workflow wirklich Zeit. Tools wie SimplePoTranslate übersetzen Ihre .po-Strings und geben ein einziges ZIP-Archiv zurück, das das passende .po und .mo zusammen enthält – bereits kompiliert, korrekt benannt, bereit zum Ablegen in wp-content/languages/. Es gibt nichts manuell zu kompilieren und keine Chance auf eine veraltete .mo.

Es wendet auch Syntax Locking an, das jeden Platzhalter wie %s, %1$s und {name} sowie HTML-Tags vor der Übersetzung einfriert. Ihre Variablen bleiben intakt, sodass Sie niemals eine .mo ausliefern, die ein Layout beschädigt. Und da es vollständig in der Cloud läuft, gibt es kein zusätzliches Plugin, das Ihre Website verlangsamt – Sie laden eine Datei hoch und laden fertige, kompilierte Übersetzungen herunter.

Alles zusammenfassend

Sobald der Unterschied zwischen der .po vs. .mo-Datei klar wird, hört das gesamte WordPress-Übersetzungssystem auf, mysteriös zu wirken. Die .pot ist die Vorlage des Entwicklers, die .po ist die bearbeitbare Arbeitskopie des Übersetzers, und die .mo ist die kompilierte Binärdatei, die WordPress tatsächlich den Besuchern bereitstellt. Übersetzungen fließen in eine Richtung – Vorlage zu .po zu .mo – und Sie bearbeiten immer nur die mittlere davon manuell.

Merken Sie sich die drei Regeln, die neunzig Prozent der Übersetzungsschwierigkeiten vermeiden: Übersetzen Sie niemals innerhalb einer .pot, kompilieren Sie die .mo immer neu, nachdem Sie eine .po bearbeitet haben, und stimmen Sie die textdomain-locale-Benennung genau ab. Befolgen Sie diese, und Ihre übersetzten Strings werden jedes Mal angezeigt.

Bereit, nicht länger mit dem manuellen Kompilieren und Benennen von Übersetzungsdateien zu kämpfen? Testen Sie SimplePoTranslate kostenlos – keine Kreditkarte erforderlich. Laden Sie Ihre .po oder .pot hoch und erhalten Sie im kostenlosen Tarif innerhalb weniger Minuten ein gebrauchsfertiges .po + .mo-Paket zurück.