Eine Übersetzerin korrigiert einen deutschen Text im PO-Editor und lädt die Datei hoch, doch WordPress zeigt weiterhin den alten Satz. Geändert wurde nur der bearbeitbare Katalog; im tatsächlich geladenen Sprachordner liegt weiterhin die frühere MO-Datei.
Sie erfahren, wie PO- und MO-Dateien zusammenhängen, wie Sie den richtigen Katalog für Locale und Textdomain kompilieren und wie Sie das Ergebnis in WordPress zuverlässig prüfen.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS Language Compiler
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Eine PO-Datei ist ein lesbarer gettext-Katalog mit Ausgangstexten, Übersetzungen, Kontextangaben, Kopfzeilen und Pluralregeln. Die MO-Datei ist der daraus erzeugte Binärkatalog, den WordPress zur Laufzeit lädt. Kompilieren bedeutet, eine syntaktisch gültige PO-Datei in die passende MO-Datei umzuwandeln.
Dieser Schritt ergänzt keine fehlenden Strings und korrigiert weder eine falsche Textdomain noch eine unpassende Locale. Auch der Ablageort bleibt entscheidend: Eine fehlerfreie MO-Datei wirkt nur, wenn WordPress genau diesen Katalog lädt.
Ein realistisches WordPress-Beispiel
Für ein Plugin wird de_DE.pogeändert. Die Übersetzerin prüft Textdomain, Zeichencodierung und Pluralformen, erzeugt daraus de_DE.mound legt beide Dateien im tatsächlich verwendeten Sprachordner ab. Anschließend ruft sie je einen geänderten Singular- und Pluraltext im Frontend auf. Erst diese WordPress-Anfrage belegt, dass nicht nur die Datei erzeugt, sondern auch der richtige Katalog geladen wurde.
Warum es wichtig ist und wann es eingesetzt wird
WordPress wertet im laufenden Betrieb üblicherweise den kompilierten MO-Katalog aus. Deshalb reicht ein neuer Zeitstempel der PO-Datei nicht aus. Ohne erneute Kompilierung bleibt die sichtbare Übersetzung unverändert, obwohl die Quelle korrekt bearbeitet wurde.
Eine neue MO-Datei ist nach freigegebenen Übersetzungsänderungen, reparierten Katalogfehlern oder einem reproduzierbaren Sprachdatei-Build erforderlich. Wenn dagegen die Ausgangstexte gar nicht im Katalog vorkommen oder das Plugin eine andere Textdomain verwendet, muss zunächst die Quelle beziehungsweise die Internationalisierung des Codes korrigiert werden.
Der einfache Weg für Einsteiger
- Sichern Sie die vorhandenen PO- und MO-Dateien und notieren Sie ihren Ablageort.
- Prüfen Sie Locale, Textdomain, Dateinamen, Zeichencodierung und Pluralformen der PO-Datei.
- Kompilieren Sie genau diese Quelle mit einem unterstützten gettext- oder WP-CLI-Werkzeug.
- Übertragen Sie die MO-Datei in den von WordPress tatsächlich verwendeten Sprachordner.
- Testen Sie einen bekannten Singular- und Pluraltext in einer frischen Frontend- oder Admin-Anfrage.
Der technische Weg
Führen Sie den Build in einem sauberen Arbeitsverzeichnis aus und halten Sie Compiler-Version, Befehl sowie Hashes von Ein- und Ausgabe fest. Ein zweiter Build aus derselben Quelle sollte eine identische MO-Datei erzeugen. Warnungen oder Parsefehler ordnen Sie der konkreten Nachricht beziehungsweise Zeile zu, statt eine unvollständige Ausgabe zu veröffentlichen.
Prüfen Sie außerdem die WordPress-Ladereihenfolge. Plugin-, Theme- und globale Sprachverzeichnisse können unterschiedliche Kataloge derselben Textdomain enthalten. Ein Sprachpaket, Plugin-Update, Container-Neubau oder Deployment kann eine manuell abgelegte Datei beim nächsten Release überschreiben.
Für einen kontrollierten Funktionstest ändern Sie einen unkritischen Text, kompilieren erneut und vergleichen sowohl den MO-Hash als auch die sichtbare Ausgabe. Danach stellen Sie den freigegebenen Katalog wieder her.
Risiken, häufige Fehler, Backup und Rollback
Bearbeiten Sie keine MO-Datei binär und behandeln Sie sie nicht als einzige Quelle. Häufige Fehler sind falsche Dateinamen, eine abweichende Locale, beschädigte Pluralregeln, ein ungeeigneter Ladepfad und eine Datei, die beim nächsten Update überschrieben wird.
Brechen Sie bei Parsefehlern, leerer Ausgabe, beschädigten Zeichen oder unerwarteten Änderungen in anderen Übersetzungen ab. Für den Rollback stellen Sie das zuvor gesicherte PO/MO-Paar am selben Ort und mit den bisherigen Rechten wieder her. Cache-Bereinigung ist erst danach sinnvoll, wenn die korrekte Datei nachweislich geladen wird.
Wie AIOWS unterstützt:
AIOWS Language Compiler
AIOWS Language Compiler bietet eine zentrale Oberfläche, um unterstützte WordPress-Sprachdateien zu prüfen und aus einer PO-Quelle die zugehörige MO-Datei zu erzeugen. Locale, Textdomain, Quelle und Ziel sollten vor dem Kompilieren eindeutig feststehen.
Wählen Sie nur den freigegebenen Katalog aus und beachten Sie gemeldete Syntaxfehler. Nach dem Lauf kontrollieren Sie, ob die erwartete MO-Datei am vorgesehenen Ort vorhanden ist. Ein konkreter Text im Frontend oder in der Administration bestätigt anschließend, dass WordPress tatsächlich diesen Katalog verwendet.
Das Modul kann keine fehlenden Übersetzungen ergänzen, eine falsche Textdomain im Plugin korrigieren oder einen ungeeigneten Speicherort gegen spätere Updates absichern. Bewahren Sie deshalb die vorherige PO- und MO-Datei bis zur Abnahme auf. Scheitert der Laufzeittest, stellen Sie dieses Paar wieder her und klären anschließend Quelle, Pfad und Release-Prozess.
Passende AIOWS-Artikel
- WordPress-Plugin-Übersetzungen werden nicht angezeigt
- WordPress-Sprachdateien scannen und verwalten
- Cache für mehrsprachige WordPress-Websites konfigurieren
Fazit und empfohlener Weg
Behandeln Sie PO als gepflegte Quelle und MO als reproduzierbares Laufzeitartefakt. Domain, Locale, Pfad, Syntax und Überschreibungsregel stehen vor der Kompilierung fest; danach werden bekannte Singular- und Pluraltexte in WordPress geprüft. Das vorherige Paar bleibt erhalten, bis der neue Katalog die Laufzeitprüfung bestanden hat und auch nach dem nächsten regulären Deployment korrekt geladen wird.
