Wie man .po in .mo Dateien kompiliert (4 Methoden)

Sie haben einen Nachmittag damit verbracht, eine deutsche Übersetzung zu perfektionieren. Jeder String in Ihrer de_DE.po-Datei liest sich hervorragend, die Platzhalter sind intakt, die Pluralformen sind korrekt. Sie laden sie auf Ihre Website hoch, stellen die Sprache auf Deutsch um, und... nichts. Die Seite ist immer noch auf Englisch. Sie überprüfen den Dateinamen, den Ordner, die Textdomäne. Alles scheint richtig zu sein. Warum zeigt WordPress Ihre Übersetzung dann nicht an?

Neun von zehn Malen ist die Antwort dieselbe: Sie haben die .po bearbeitet, sie aber nie in .mo kompiliert. WordPress liest .po-Dateien zur Laufzeit nicht — es lädt die kompilierte Binärdatei .mo. Wenn Ihre Übersetzungen tatsächlich erscheinen sollen, müssen Sie die .po jedes Mal in .mo kompilieren, wenn Sie den Text ändern. Die .po ist Ihre bearbeitbare Quelle; die .mo ist das, was die Website bereitstellt.

Dieser Leitfaden erklärt, warum dieser Kompilierungsschritt existiert, und zeigt dann vier zuverlässige Wege auf, ihn durchzuführen: WP-CLI, den klassischen msgfmt-Befehl, Poedit und ein Cloud-Tool, das die .mo automatisch für Sie erstellt. Wir behandeln auch die häufigste Falle – das Vergessen des Neukompilierens – und das neuere .l10n.php-Format, das WordPress jetzt aus Geschwindigkeitsgründen bevorzugt.

Warum lädt WordPress .mo und nicht .po?

WordPress lädt .mo-Dateien, weil es kompilierte Binärdateien sind, die für schnelle Suchvorgänge optimiert sind, während .po-Dateien reine Textdateien sind, die für Menschen zum Lesen und Bearbeiten gedacht sind. Das Parsen von Text bei jedem Seitenaufbau wäre langsam; das Lesen einer vorgefertigten binären Hashtabelle ist nahezu augenblicklich.

Eine .po-Datei ist zeilenbasiert und menschenfreundlich. Jeder Eintrag koppelt eine Quell-msgid mit einer übersetzten msgstr, plus Kommentare, die angeben, woher der String stammt. Das ist hervorragend für die Bearbeitung, aber schrecklich für die Leistung — der Server müsste bei jeder Anfrage die gesamte Textdatei neu parsen.

#: includes/cart.php:88
msgid "Your cart is empty"
msgstr "Ihr Warenkorb ist leer"

Eine .mo-Datei verpackt dieselben String-Paare in ein Binärformat mit einer internen Nachschlagetabelle, sodass WordPress direkt zu einer Übersetzung springen kann, ohne den Text zu scannen. Der Kompromiss ist, dass .mo für Menschen unlesbar ist und immer dann neu generiert werden muss, wenn sich die .po ändert. Wenn der Unterschied zwischen .po und .mo noch unklar ist, erklärt unser Beitrag zu .po vs .mo vs .pot Dateien jedes Format und wie sie zusammenhängen.

Vier Wege, .po in .mo zu kompilieren

Es gibt kein einziges „richtiges“ Tool – die beste Wahl hängt davon ab, wie Sie bereits arbeiten. Im Folgenden finden Sie vier zuverlässige Methoden, von einem Ein-Zeilen-Befehl bis zu einem vollautomatischen Cloud-Workflow. Alle vier erzeugen die identische Binärdatei .mo, die WordPress zur Laufzeit lädt.

Methode 1: WP-CLI

Der sauberste moderne Ansatz ist WP-CLI, das einen ganzen Ordner von .po-Dateien mit einem einzigen Befehl kompilieren kann. Wenn Sie WordPress bereits über die Kommandozeile verwalten, passt dies natürlich in Ihren Workflow.

# Compile every .po file in the languages folder to .mo
wp i18n make-mo languages/

# Compile into a specific destination directory
wp i18n make-mo languages/ build/languages/

Der make-mo-Befehl durchsucht das Zielverzeichnis, kompiliert jede gefundene .po und schreibt eine passende .mo daneben (oder in das von Ihnen angegebene Ziel). Es verarbeitet Batches elegant, was es ideal macht, wenn Sie viele Sprachen gleichzeitig pflegen. Es ist das empfohlene Tool für jedes Projekt, das bereits WP-CLI verwendet.

Methode 2: msgfmt

Das ursprüngliche Gettext-Dienstprogramm für diese Aufgabe ist msgfmt, Teil des GNU gettext-Pakets. Es kompiliert eine einzelne .po in eine einzelne .mo und ist auf praktisch jedem Linux- und macOS-System verfügbar.

# Compile one file
msgfmt my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Add statistics about translated, fuzzy, and untranslated strings
msgfmt --statistics my-plugin-de_DE.po -o my-plugin-de_DE.mo

# Install it first if missing
#   macOS:  brew install gettext
#   Debian: sudo apt-get install gettext

Das Flag -o benennt die Ausgabedatei. Das Flag --statistics ist wirklich nützlich – es zeigt Ihnen an, wie viele Strings übersetzt, unscharf oder noch leer sind, sodass Sie eine unvollständige Übersetzung erkennen, bevor Sie sie veröffentlichen. Für die Skripterstellung einer Datei nach der anderen ist msgfmt die zuverlässige, schnörkellose Wahl.

Da msgfmt ein einfaches Befehlszeilentool ist, fügt es sich nahtlos in die Automatisierung ein. Sie können es in eine Shell-Schleife packen, um einen ganzen Ordner zu kompilieren, oder es in eine CI-Pipeline integrieren, sodass jeder Commit, der eine .po berührt, automatisch eine frische .mo erzeugt. Ein gängiges Muster ist for f in languages/*.po; do msgfmt "$f" -o "${f%.po}.mo"; done, das jede Sprache in einem Durchgang kompiliert. Das --check-Flag fügt eine Validierung hinzu, die Format-String-Fehler zwischen msgid und msgstr meldet, bevor sie in Produktion gehen – eine günstige Absicherung gegen fehlerhafte Platzhalter-Bugs, die übersetzte Layouts stillschweigend beschädigen.

Methode 3: Poedit (Kompiliert beim Speichern)

Wenn Sie Übersetzungen in einem grafischen Editor bearbeiten, kompiliert Poedit automatisch für Sie. Jedes Mal, wenn Sie eine .po-Datei speichern, schreibt Poedit die passende .mo direkt daneben – kein separater Befehl, kein zusätzlicher Schritt.

Dies ist ein Grund, warum Poedit bei Übersetzern, die sich auf der Kommandozeile nicht wohlfühlen, beliebt bleibt. Sie öffnen die .po, tippen Ihre Übersetzungen ein, klicken auf Speichern, und beide Dateien werden gemeinsam aktualisiert. Das Verhalten können Sie in den Einstellungen von Poedit überprüfen, wo die automatische .mo-Kompilierung beim Speichern standardmäßig aktiviert ist. Poedit und ähnliche Desktop-Tools werden in Die 5 besten kostenlosen Tools zum Bearbeiten und Übersetzen von PO-Dateien auf Mac und Windows vorgestellt.

Der Haken bei einem Desktop-Editor ist, dass die Kompilierung nur dann erfolgt, wenn ein Mensch die Datei öffnet und speichert. Das ist in Ordnung für ein Einzelpersonenprojekt, skaliert aber nicht auf ein Dutzend Sprachen oder ein Team, das Dateien hin- und herschiebt. Wenn jemand eine .po in einem anderen Tool bearbeitet und sie ins Repository kopiert, ohne Poedit zu öffnen, wird die .mo niemals aktualisiert. Für größere oder kollaborative Projekte beseitigt eine automatisierte Methode – Kommandozeile oder Cloud – diese Abhängigkeit davon, sich an das Speichern zu erinnern.

Methode 4: Ein Cloud-Tool, das die .mo für Sie generiert

Die vierte Option eliminiert den Kompilierungsschritt vollständig: Verwenden Sie einen Cloud-Dienst, der die kompilierte .mo zusammen mit der übersetzten .po zurückgibt. Sie führen nie einen Befehl aus oder speichern eine Datei zweimal – Sie laden hoch, und fertige, korrekt benannte Dateien kommen zurück.

SimplePoTranslate funktioniert genau auf diese Weise. Sie laden eine .po oder .pot hoch, es übersetzt die Strings mit kontextbewusster KI und gibt eine einzelne ZIP-Datei zurück, die die .po und .mo Seite an Seite generiert enthält – bereits kompiliert, bereits benannt, um Ihrer Textdomäne und Ihrem Gebietsschema zu entsprechen. Es gibt keinen separaten Kompilierungsschritt und keine Möglichkeit, einen zu vergessen.

Es kümmert sich auch um die Details, die manuelle Workflows stören. Syntax Locking fixiert Platzhalter wie %s, %1$s und {name} sowie HTML-Tags vor der Übersetzung, sodass Ihre Variablen intakt in der .mo erhalten bleiben. Volle Gettext-Plural-Unterstützung bedeutet, dass auch komplexe Pluralformen korrekt kompilieren – ein Thema, das es sich lohnt, eingehend zu verstehen, was wir in Gettext-Pluralformen verstehen behandeln. Und da es in der Cloud läuft, gibt es kein Plugin zu installieren und keine Build-Tools zu warten.

Die häufigste Falle: Sie haben das Neukompilieren vergessen

Der häufigste Grund, warum Übersetzungen nicht erscheinen, ist die Bearbeitung der .po ohne das Neukompilieren der .mo. WordPress lädt weiterhin die alte Binärdatei, sodass Ihre neue Formulierung nie angezeigt wird – und es gibt keine Fehlermeldung, die Ihnen sagt, warum.

Das mentale Modell, das Sie sich einprägen sollten: Die .po ist Ihr Entwurf, die .mo wird ausgeliefert. Jede Änderung an der .po ist für WordPress unsichtbar, bis Sie die .mo neu generieren. Machen Sie das Neukompilieren nach jeder Bearbeitung zu einem Reflex, oder verwenden Sie ein Tool, das automatisch kompiliert, damit dieser Schritt niemals übersprungen werden kann.

Diese Falle ist besonders tückisch bei der Übergabe von Staging an die Produktion. Ein Entwickler bearbeitet und kompiliert lokal, sieht die funktionierende Übersetzung, stellt dann aber nur die .po bereit und vergisst die .mo – so behält die Produktion stillschweigend den alten Text bei. Immer wenn Sie Übersetzungsdateien zwischen Umgebungen verschieben, verschieben Sie die .po und die frisch kompilierte .mo zusammen, oder kompilieren Sie als Teil Ihres Bereitstellungsschritts, sodass die Binärdatei immer aus der aktuellen Quelle neu erstellt wird.

Wenn Ihre Übersetzungen nach dem Neukompilieren immer noch nicht erscheinen, liegt das Problem normalerweise an einer Namensabweichung, einem falschen Ordner oder einer Caching-Schicht, die die alte Datei enthält. Die vollständige Checkliste finden Sie unter Warum Ihre Übersetzungen in WordPress nicht angezeigt werden.

Ein Hinweis zum neueren .l10n.php-Format

Neuere WordPress-Versionen haben ein drittes Laufzeitformat eingeführt: .l10n.php. Anstelle einer binären .mo werden Übersetzungen als einfaches PHP-Array gespeichert, das der PHP-Opcode-Cache im Speicher halten kann, was Suchvorgänge auf stark frequentierten Websites noch schneller als .mo macht.

<?php
return [
	'domain'  => 'my-plugin',
	'messages' => [ 'Your cart is empty' => 'Ihr Warenkorb ist leer' ],
];

WordPress generiert .l10n.php-Dateien automatisch, wenn die passende .mo verfügbar ist, sodass Sie sie nicht manuell erstellen müssen. Vorerst bleibt das Kompilieren einer korrekten .mo die Grundlage – das Performance-Format wird daraus abgeleitet.

Zusammenfassung

Um .po zuverlässig in .mo zu kompilieren, wählen Sie die Methode, die zu Ihrer Arbeitsweise passt: WP-CLI für Befehlszeilen-Batches, msgfmt für einzelne Dateien mit Statistiken, Poedit für die automatische Kompilierung beim Speichern oder ein Cloud-Tool, das die .mo für Sie erstellt, damit der Schritt niemals übersprungen wird. Alle vier erzeugen dieselbe Binärdatei, die WordPress zur Laufzeit benötigt.

Welchen Weg Sie auch wählen, denken Sie an die goldene Regel: Bearbeiten Sie die .po, dann kompilieren Sie in .mo — jedes Mal. Diese eine Gewohnheit verhindert den frustrierendsten Übersetzungsfehler in WordPress, bei dem alles richtig aussieht, die Website aber hartnäckig auf Englisch bleibt.

Bereit, den manuellen Kompilierungsschritt endgültig zu überspringen? Testen Sie SimplePoTranslate kostenlos — keine Kreditkarte erforderlich. Laden Sie Ihre .po hoch und laden Sie ein sofort einsatzbereites .po + .mo Bundle im kostenlosen Tarif in wenigen Minuten herunter.