{"id":2253,"date":"2026-06-27T11:25:37","date_gmt":"2026-06-27T08:25:37","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2253"},"modified":"2026-10-18T05:20:22","modified_gmt":"2026-10-18T02:20:22","slug":"wordpress-po-dateien-in-mo-dateien-kompilieren","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-po-dateien-in-mo-dateien-kompilieren\/","title":{"rendered":"WordPress-PO-Dateien in MO-Dateien kompilieren"},"content":{"rendered":"

Sie haben eine \u00dcbersetzung korrigiert, die PO-Datei zur MO-Datei kompiliert, hochgeladen, und Ihre Website zeigt noch den alten Text. Ab WordPress 6.5 ist die wahrscheinlichste Ursache, dass WordPress Ihre MO-Datei gar nicht liest. Daneben liegt eine PHP-\u00dcbersetzungsdatei mit demselben Namen, und die hat Vorrang.<\/p>\n

Auf deutschsprachigen Websites kommt eine zweite Ursache hinzu, die es im Englischen nicht gibt: WordPress kennt f\u00fcnf deutsche Sprachvarianten. L\u00e4uft Ihre Website auf \u201eDeutsch (Sie)\u201c, sucht WordPress eine andere Datei als die, die Sie vermutlich kompiliert haben.<\/p>\n

Diese Anleitung kompiliert WordPress-PO-Dateien mit drei Werkzeugen und zeigt Ihnen die Gr\u00fcnde, warum eine korrekte MO-Datei am Bildschirm trotzdem nichts \u00e4ndert.<\/p>\n

Inhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Welche Datei WordPress tats\u00e4chlich liest<\/a><\/li>\n
  2. Du oder Sie: das Gebietsschema im Dateinamen<\/a><\/li>\n
  3. Kompilieren mit msgfmt oder Poedit<\/a><\/li>\n
  4. Kompilieren mit WP-CLI, samt PHP-Datei<\/a><\/li>\n
  5. Wohin die Datei geh\u00f6rt, und was sie \u00fcberschreibt<\/a><\/li>\n
  6. Als \u201efuzzy\u201c markierte Eintr\u00e4ge erreichen die Website nie<\/a><\/li>\n
  7. Texte aus JavaScript brauchen eine JSON-Datei<\/a><\/li>\n
  8. \u00dcberpr\u00fcfung<\/a><\/li>\n
  9. AIOWS Language Compiler<\/a><\/li>\n
  10. H\u00e4ufige Fragen<\/a><\/li>\n
  11. Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Welche Datei WordPress tats\u00e4chlich liest<\/h2>\n

    Drei Dateitypen tragen denselben Namen und erf\u00fcllen drei verschiedene Aufgaben:<\/p>\n

    \n\n\n\n\n\n\n\n
    Datei<\/th>\nWer sie liest<\/th>\nWas sie ist<\/th>\n<\/tr>\n<\/thead>\n
    mein-plugin-de_DE.po<\/code><\/td>\nSie, und Editoren wie Poedit<\/td>\nDie Textquelle. WordPress liest sie nie.<\/td>\n<\/tr>\n
    mein-plugin-de_DE.mo<\/code><\/td>\nWordPress<\/td>\nDer kompilierte Bin\u00e4rkatalog.<\/td>\n<\/tr>\n
    mein-plugin-de_DE.l10n.php<\/code><\/td>\nWordPress ab 6.5<\/td>\nDerselbe Katalog als PHP-Array, schneller geladen.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    Liegen beide kompilierten Dateien vor, l\u00e4dt WordPress ab 6.5 die .l10n.php<\/code> und ignoriert Ihre .mo<\/code>. Sprachpakete, die Sie von WordPress.org bekommen, enthalten inzwischen beide. Kompilieren Sie also nur die MO-Datei und liegt daneben schon eine PHP-Datei gleichen Namens, bleibt Ihre \u00c4nderung unsichtbar.<\/p>\n

    Sie haben zwei Auswege. Erzeugen Sie die PHP-Datei mit, wie im Abschnitt zu WP-CLI gezeigt. Oder l\u00f6schen Sie die veraltete .l10n.php<\/code>; dann greift WordPress auf Ihre MO-Datei zur\u00fcck. Stimmt die Datei und \u00e4ndert sich trotzdem nichts, hilft Ihnen Plugin-\u00dcbersetzungen werden nicht angezeigt<\/a> bei den Ursachen au\u00dferhalb der Datei.<\/p>\n

    Die Testseite f\u00fcr diesen Artikel zeigte es Schritt f\u00fcr Schritt. Eine .mo<\/code> und ihre .l10n.php<\/code> entstanden aus derselben PO-Datei, und Ihre Seite zeigte diesen Text. Nachdem ein Text ge\u00e4ndert und nur die .mo<\/code> neu erzeugt war, blieb der alte Text stehen. Erst als wp i18n make-php<\/code> die PHP-Datei neu schrieb, zeigte das n\u00e4chste Neuladen den neuen.<\/p>\n

    Du oder Sie: das Gebietsschema im Dateinamen<\/h2>\n

    WordPress bietet Ihnen f\u00fcnf deutsche Sprachvarianten an, jede mit eigenem K\u00fcrzel:<\/p>\n

    \n\n\n\n\n\n\n\n\n\n
    Sprache in den Einstellungen<\/th>\nGebietsschema<\/th>\nDateiname<\/th>\n<\/tr>\n<\/thead>\n
    Deutsch<\/td>\nde_DE<\/code><\/td>\nmein-plugin-de_DE.mo<\/code><\/td>\n<\/tr>\n
    Deutsch (Sie)<\/td>\nde_DE_formal<\/code><\/td>\nmein-plugin-de_DE_formal.mo<\/code><\/td>\n<\/tr>\n
    Deutsch (\u00d6sterreich)<\/td>\nde_AT<\/code><\/td>\nmein-plugin-de_AT.mo<\/code><\/td>\n<\/tr>\n
    Deutsch (Schweiz)<\/td>\nde_CH<\/code><\/td>\nmein-plugin-de_CH.mo<\/code><\/td>\n<\/tr>\n
    Deutsch (Schweiz, Du)<\/td>\nde_CH_informal<\/code><\/td>\nmein-plugin-de_CH_informal.mo<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

    WordPress sucht die Datei mit genau dem K\u00fcrzel Ihrer Website, und steht Ihre Website auf \u201eDeutsch (Sie)\u201c, sucht es de_DE_formal<\/code>. Eine sauber kompilierte de_DE<\/code>-Datei liegt dann daneben und wird nicht geladen.<\/p>\n

    Pr\u00fcfen Sie Ihr K\u00fcrzel unter Einstellungen<\/strong> \u203a Allgemein<\/strong> \u203a Website-Sprache<\/strong>, und benennen Sie Ihre PO- und MO-Datei danach. Pflegen Sie Ihre \u00dcbersetzung in der Sie-Form, geh\u00f6rt sie in die de_DE_formal<\/code>-Datei, nicht in die de_DE<\/code>-Datei.<\/p>\n

    Auf der Testseite blieb ein Plugin mit \u201eDeutsch (Sie)\u201c im Profil und nur einer de_DE<\/code>-Datei vollst\u00e4ndig englisch; mit einer de_DE_formal<\/code>-Datei daneben war es deutsch.<\/p>\n

    Kompilieren mit msgfmt oder Poedit<\/h2>\n

    msgfmt<\/code> ist der Compiler von GNU gettext. Sie finden ihn auf den meisten Linux-Servern und in Git f\u00fcr Windows:<\/p>\n

    msgfmt --check --statistics -o mein-plugin-de_DE_formal.mo mein-plugin-de_DE_formal.po<\/code><\/pre>\n
    --check<\/code> pr\u00fcft Ihren Dateikopf und Ihre Platzhalter wie %s<\/code> und %d<\/code> gegen den Originaltext. --statistics<\/code> nennt Ihnen, wie viele Eintr\u00e4ge \u00fcbersetzt, unscharf und un\u00fcbersetzt sind. Lesen Sie diese Zeile, bevor Sie hochladen.<\/p>\n
    In Poedit schreibt das Speichern Ihrer PO-Datei standardm\u00e4\u00dfig die MO-Datei daneben. In Poedit 3.10 unter Windows und Linux finden Sie die Einstellung unter Datei<\/strong> \u203a Einstellungen \u2026<\/strong> \u203a Allgemein<\/strong>, in der Gruppe \u201eBearbeiten\u201c: \u201eMO-Datei beim Speichern automatisch erstellen\u201c. Auf dem Mac liegt sie in den Einstellungen im Poedit-Men\u00fc.<\/p>\n
    Keines der beiden Werkzeuge schreibt Ihnen die .l10n.php<\/code>.<\/p>\n
    Kompilieren mit WP-CLI, samt PHP-Datei<\/h2>\n
    Die i18n-Befehle von WP-CLI erzeugen beide Formate:<\/p>\n
    wp i18n make-mo  wp-content\/languages\/plugins\/mein-plugin-de_DE_formal.po\nwp i18n make-php wp-content\/languages\/plugins\/mein-plugin-de_DE_formal.po<\/code><\/pre>\n
    Jeder Befehl schreibt seine Datei neben Ihre Quelle, wenn Sie kein Ziel angeben. F\u00fchren Sie nach jeder \u00c4nderung beide aus, dann kann Ihnen die veraltete PHP-Datei nicht passieren. Entfernen Sie aber vorher Ihre \u201efuzzy\u201c-Markierungen: Beide Befehle \u00fcbernehmen unscharfe Eintr\u00e4ge, wie der Abschnitt dazu zeigt. make-php<\/code> kam mit WP-CLI 2.10.0, make-mo<\/code> mit 2.5.0. Fehlt Ihnen einer der Befehle, pr\u00fcfen Sie wp cli version<\/code>.<\/p>\n
    Auf der Testseite antwortete WP-CLI 2.12.0 auf jeden der beiden Befehle mit einer Zeile: Success: Created 1 file.<\/code><\/p>\n
    Wohin die Datei geh\u00f6rt, und was sie \u00fcberschreibt<\/h2>\n
    Den Namen w\u00e4hlen Sie nicht selbst: Textdomain des Plugins, Bindestrich, Gebietsschema, Endung. Die Textdomain finden Sie in der Hauptdatei des Plugins, in der Zeile Text Domain:<\/code>.<\/p>\n
    WordPress sucht zuerst in wp-content\/languages\/plugins\/<\/code> (Themes: wp-content\/languages\/themes\/<\/code>), dann im eigenen languages<\/code>-Ordner des Plugins. Eine Datei im ersten Ordner gewinnt.<\/p>\n
    In genau diesen Ordner schreiben auch Ihre automatischen \u00dcbersetzungsaktualisierungen. Liefert WordPress.org ein neueres Sprachpaket f\u00fcr das Plugin, wird Ihre gleichnamige Datei ersetzt; Ihre \u00c4nderungen sind weg, und nichts sagt es Ihnen.<\/p>\n
    Pflegen Sie eine eigene \u00dcbersetzung, bewahren Sie Ihre PO-Datei au\u00dferhalb von wp-content\/languages\/<\/code> auf, dann k\u00f6nnen Sie nach einem Update neu kompilieren. Was in dem Ordner bereits liegt, zeigt Ihnen WordPress-Sprachdateien scannen und verwalten<\/a>.<\/p>\n
    Als \u201efuzzy\u201c markierte Eintr\u00e4ge erreichen die Website nie<\/h2>\n
    Ein unscharfer Eintrag ist einer, den Ihr Editor geraten hat oder dessen Originaltext sich ge\u00e4ndert hat. Er tr\u00e4gt in Ihrer PO-Datei den Kommentar #, fuzzy<\/code>. Poedit kennzeichnet ihn als \u201eBen\u00f6tigt \u00dcberarbeitung\u201c.<\/p>\n
    msgfmt<\/code> l\u00e4sst unscharfe Eintr\u00e4ge weg, wenn Sie nicht --use-fuzzy<\/code> angeben, und Ihre vollst\u00e4ndig \u00fcbersetzte Datei kann so f\u00fcr jeden unscharfen Eintrag weiter Englisch zeigen. --statistics<\/code> nennt Ihnen deren Zahl.<\/p>\n
    Entfernen Sie die Markierung, nachdem Sie die \u00dcbersetzung gepr\u00fcft haben, und kompilieren Sie neu. Kompilieren Sie nicht mit --use-fuzzy<\/code>, um die Zahl zu versch\u00f6nern. Ein unscharfer Eintrag ist unscharf, weil ihn noch niemand best\u00e4tigt hat.<\/p>\n
    WP-CLI h\u00e4lt sich nicht an diese Regel. Auf der Testseite schrieben wp i18n make-mo<\/code> und wp i18n make-php<\/code> aus WP-CLI 2.12.0 den unscharfen Eintrag als normale \u00dcbersetzung in ihre Dateien, und Ihr Bildschirm zeigte den unbest\u00e4tigten Text. Kompilieren Sie mit WP-CLI, leeren oder best\u00e4tigen Sie vorher jeden unscharfen Eintrag.<\/p>\n
    Die Pluralzeile im Dateikopf lautet f\u00fcr alle deutschen Varianten nplurals=2; plural=(n != 1);<\/code>. Kopieren Sie den Kopf aus einer bestehenden deutschen \u00dcbersetzung, wenn Sie eine PO-Datei von Hand anlegen.<\/p>\n
    Texte aus JavaScript brauchen eine JSON-Datei<\/h2>\n
    Die Texte, die Sie im Block-Editor sehen und in Plugins, die ihre Oberfl\u00e4che in JavaScript aufbauen, liest WordPress nicht aus Ihrer MO-Datei. Sie kommen aus JSON-Dateien mit Namen wie mein-plugin-de_DE_formal-.json<\/code>, eine je Skript.<\/p>\n
    Ist der PHP-Teil \u00fcbersetzt und eine Schaltfl\u00e4che im Editor nicht, sehen Sie genau das. wp i18n make-json<\/code> baut Ihnen diese Dateien aus derselben PO-Datei.<\/p>\n
    \u00dcberpr\u00fcfung<\/h2>\n
    \n\n\n\n\n\n\n\n\n
    Pr\u00fcfung<\/th>\nErwartet<\/th>\n<\/tr>\n<\/thead>\n
    msgfmt --check --statistics<\/code> auf Ihrer PO-Datei<\/td>\nKeine Fehler. Unscharfe und un\u00fcbersetzte Eintr\u00e4ge in der erwarteten Zahl.<\/td>\n<\/tr>\n
    Einstellungen \u203a Allgemein \u203a Sprache der Website<\/td>\nDas K\u00fcrzel im Dateinamen passt zur Sprache der Website, also de_DE_formal<\/code> bei \u201eDeutsch (Sie)\u201c.<\/td>\n<\/tr>\n
    Ordner auflisten: .mo<\/code> und, falls vorhanden, .l10n.php<\/code><\/td>\nBeide j\u00fcnger als Ihre \u00c4nderung. Ist die PHP-Datei \u00e4lter als die MO-Datei, sitzen Sie in der Falle von oben.<\/td>\n<\/tr>\n
    Einen Eintrag als unscharf markieren, kompilieren, Bildschirm neu laden<\/td>\nMuss weiter den englischen Originaltext zeigen.<\/strong> Zeigt er Ihre Vermutung, hat Ihr Compiler unscharfe Eintr\u00e4ge \u00fcbernommen.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    Die letzte Zeile beweist Ihnen, dass Ihr Compiler die Markierung respektiert. Eine Pr\u00fcfung, deren Zeilen alle bestehen, zeigt nur, dass Ihr Normalfall funktioniert. Diese zeigt, dass eine unbest\u00e4tigte \u00dcbersetzung Ihre Besucher nicht aus Versehen erreicht.<\/p>\n
    F\u00fchren Sie sie mit dem Werkzeug aus, das Sie wirklich nutzen. msgfmt<\/code> besteht sie, und der AIOWS Language Compiler mit beiden seiner Compiler ebenso. Ein Compiler, der die Markierung ignoriert, f\u00e4llt durch. Auf der Testseite bestand msgfmt<\/code> 1.0; WP-CLI 2.12.0 fiel mit make-mo<\/code> und mit make-php<\/code> durch.<\/p>\n
    \n
    Wie AIOWS unterst\u00fctzt:<\/p>\n
    AIOWS Language Compiler<\/h2>\n
    Der Language Compiler, in der deutschen Oberfl\u00e4che \u201eSprach-Compiler\u201c, ist der Compiler f\u00fcr die eigenen \u00dcbersetzungen von AIOWS. Er ist kein allgemeiner PO-Editor f\u00fcr Ihre anderen Plugins, und die Grenzen unten sagen genau, wo die Linie verl\u00e4uft.<\/p>\n
    Er kompiliert dort, wo AIOWS liest.<\/strong> Er macht aus den PO-Dateien im languages<\/code>-Ordner Ihres AIOWS-Plugins MO-Dateien, einzeln oder alle mit \u201eAlle Gebietsschemata kompilieren\u201c. L\u00e4sst Ihr Server PHP msgfmt<\/code> ausf\u00fchren, nutzt er msgfmt<\/code>, sonst seinen eigenen Compiler. Beide lassen Ihre unscharfen Eintr\u00e4ge weg, wie msgfmt<\/code> es tut. Eine unbest\u00e4tigte \u00dcbersetzung erreicht Ihre Bildschirme also nie. AIOWS bringt f\u00fcr die eigene Textdomain keine .l10n.php<\/code> mit, die PHP-Datei-Falle von oben betrifft diese Dateien also nicht. WordPress liest die MO-Datei, die das Modul f\u00fcr Sie schreibt.<\/p>\n
    Er zeigt Ihnen vorher, was fehlt.<\/strong> Der Reiter \u201eScannen\u201c vergleicht den Code des Plugins mit seinen PO-Dateien. Er meldet, wie viel der AIOWS-Oberfl\u00e4che \u00fcbersetzt ist, und listet leere und doppelte Eintr\u00e4ge. Ein leerer Eintrag kompiliert ohne Fehler und zeigt trotzdem Englisch. Lesen Sie diese Liste also zuerst.<\/p>\n
    Er nimmt Ihre bearbeitete Datei an.<\/strong> \u201eHochladen \/ Verwalten\u201c \u00fcbernimmt eine PO- oder MO-Datei, die Sie anderswo bearbeitet haben, etwa in Poedit, und legt sie dorthin, wo AIOWS sie l\u00e4dt. Eine gleichnamige Datei wird ersetzt. Jede Datei dort k\u00f6nnen Sie auf demselben Bildschirm herunterladen. Nehmen Sie also vorher eine Kopie.<\/p>\n
    Der praktische Nutzen: Sie korrigieren eine Bezeichnung in der deutschen AIOWS-Oberfl\u00e4che direkt im Backend, ohne SFTP und ohne lokale gettext-Installation.<\/p>\n
    \"Der
    Eine Protokollzeile je Schritt und Datei.<\/figcaption><\/figure>\n
    Seine Grenzen, offen gesagt. Er kompiliert nur die Dateien im eigenen languages<\/code>-Ordner von AIOWS. F\u00fcr die PO-Datei eines anderen Plugins oder eines Themes nutzen Sie msgfmt<\/code>, Poedit oder WP-CLI wie oben. Er schreibt nur MO-Dateien, keine .l10n.php<\/code> und kein JSON. Er ersetzt die alte MO-Datei, ohne eine Kopie zu behalten; laden Sie die alte also vorher herunter, wenn Sie sie vielleicht zur\u00fcckbrauchen.<\/p>\n
    AIOWS Language Compiler ansehen<\/a>AIOWS-Pl\u00e4ne vergleichen<\/a><\/p>\n<\/section>\n
    H\u00e4ufige Fragen<\/h2>\n
    Muss ich die PO-Datei auf den Server laden?<\/strong> F\u00fcr WordPress nicht. Es liest nur Ihre MO- und PHP-Dateien. Behalten Sie Ihre PO-Datei trotzdem, denn nur sie k\u00f6nnen Sie bearbeiten.<\/p>\n
    Meine Website steht auf \u201eDeutsch (Sie)\u201c. Brauche ich dann eine eigene \u00dcbersetzung?<\/strong> Sie brauchen eine Datei mit dem K\u00fcrzel de_DE_formal<\/code>. Viele Plugins bekommen von WordPress.org auch ein Sie-Sprachpaket. Fehlt es, legen Sie Ihre eigene Datei unter diesem Namen an.<\/p>\n
    Kann ich eine MO-Datei direkt bearbeiten?<\/strong> Nein. Sie ist bin\u00e4r kompiliert. Bearbeiten Sie Ihre PO-Datei und kompilieren Sie neu.<\/p>\n
    Ich habe kompiliert, und nichts hat sich ge\u00e4ndert. Was zuerst?<\/strong> Suchen Sie eine .l10n.php<\/code> gleichen Namens. Ist sie \u00e4lter als Ihre MO-Datei, liest WordPress sie. Pr\u00fcfen Sie danach das K\u00fcrzel im Dateinamen.<\/p>\n
    Warum ist meine \u00dcbersetzung nach einem Update verschwunden?<\/strong> Ein Sprachpaket hat Ihre Datei in wp-content\/languages\/plugins\/<\/code> ersetzt. Bewahren Sie Ihre PO-Datei anderswo auf und kompilieren Sie neu.<\/p>\n
    Quellen<\/h2>\n