Sie haben eine Übersetzung 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-Übersetzungsdatei mit demselben Namen, und die hat Vorrang.
Auf deutschsprachigen Websites kommt eine zweite Ursache hinzu, die es im Englischen nicht gibt: WordPress kennt fünf deutsche Sprachvarianten. Läuft Ihre Website auf „Deutsch (Sie)“, sucht WordPress eine andere Datei als die, die Sie vermutlich kompiliert haben.
Diese Anleitung kompiliert WordPress-PO-Dateien mit drei Werkzeugen und zeigt Ihnen die Gründe, warum eine korrekte MO-Datei am Bildschirm trotzdem nichts ändert.
- Welche Datei WordPress tatsächlich liest
- Du oder Sie: das Gebietsschema im Dateinamen
- Kompilieren mit msgfmt oder Poedit
- Kompilieren mit WP-CLI, samt PHP-Datei
- Wohin die Datei gehört, und was sie überschreibt
- Als „fuzzy“ markierte Einträge erreichen die Website nie
- Texte aus JavaScript brauchen eine JSON-Datei
- Überprüfung
- AIOWS Language Compiler
- Häufige Fragen
- Quellen
Welche Datei WordPress tatsächlich liest
Drei Dateitypen tragen denselben Namen und erfüllen drei verschiedene Aufgaben:
| Datei | Wer sie liest | Was sie ist |
|---|---|---|
mein-plugin-de_DE.po | Sie, und Editoren wie Poedit | Die Textquelle. WordPress liest sie nie. |
mein-plugin-de_DE.mo | WordPress | Der kompilierte Binärkatalog. |
mein-plugin-de_DE.l10n.php | WordPress ab 6.5 | Derselbe Katalog als PHP-Array, schneller geladen. |
Liegen beide kompilierten Dateien vor, lädt WordPress ab 6.5 die .l10n.phpund ignoriert Ihre .mo. 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 Änderung unsichtbar.
Sie haben zwei Auswege. Erzeugen Sie die PHP-Datei mit, wie im Abschnitt zu WP-CLI gezeigt. Oder löschen Sie die veraltete .l10n.php; dann greift WordPress auf Ihre MO-Datei zurück. Stimmt die Datei und ändert sich trotzdem nichts, hilft Ihnen Plugin-Übersetzungen werden nicht angezeigtbei den Ursachen außerhalb der Datei.
Die Testseite für diesen Artikel zeigte es Schritt für Schritt. Eine .mound ihre .l10n.phpentstanden aus derselben PO-Datei, und Ihre Seite zeigte diesen Text. Nachdem ein Text geändert und nur die .moneu erzeugt war, blieb der alte Text stehen. Erst als wp i18n make-phpdie PHP-Datei neu schrieb, zeigte das nächste Neuladen den neuen.
Du oder Sie: das Gebietsschema im Dateinamen
WordPress bietet Ihnen fünf deutsche Sprachvarianten an, jede mit eigenem Kürzel:
| Sprache in den Einstellungen | Gebietsschema | Dateiname |
|---|---|---|
| Deutsch | de_DE | mein-plugin-de_DE.mo |
| Deutsch (Sie) | de_DE_formal | mein-plugin-de_DE_formal.mo |
| Deutsch (Österreich) | de_AT | mein-plugin-de_AT.mo |
| Deutsch (Schweiz) | de_CH | mein-plugin-de_CH.mo |
| Deutsch (Schweiz, Du) | de_CH_informal | mein-plugin-de_CH_informal.mo |
WordPress sucht die Datei mit genau dem Kürzel Ihrer Website, und steht Ihre Website auf „Deutsch (Sie)“, sucht es de_DE_formal. Eine sauber kompilierte de_DE-Datei liegt dann daneben und wird nicht geladen.
Prüfen Sie Ihr Kürzel unter Einstellungen› Allgemein› Website-Sprache, und benennen Sie Ihre PO- und MO-Datei danach. Pflegen Sie Ihre Übersetzung in der Sie-Form, gehört sie in die de_DE_formal-Datei, nicht in die de_DE-Datei.
Auf der Testseite blieb ein Plugin mit „Deutsch (Sie)“ im Profil und nur einer de_DE-Datei vollständig englisch; mit einer de_DE_formal-Datei daneben war es deutsch.
Kompilieren mit msgfmt oder Poedit
msgfmtist der Compiler von GNU gettext. Sie finden ihn auf den meisten Linux-Servern und in Git für Windows:
msgfmt --check --statistics -o mein-plugin-de_DE_formal.mo mein-plugin-de_DE_formal.po--checkprüft Ihren Dateikopf und Ihre Platzhalter wie %sund %dgegen den Originaltext. --statisticsnennt Ihnen, wie viele Einträge übersetzt, unscharf und unübersetzt sind. Lesen Sie diese Zeile, bevor Sie hochladen.
In Poedit schreibt das Speichern Ihrer PO-Datei standardmäßig die MO-Datei daneben. In Poedit 3.10 unter Windows und Linux finden Sie die Einstellung unter Datei› Einstellungen …› Allgemein, in der Gruppe „Bearbeiten“: „MO-Datei beim Speichern automatisch erstellen“. Auf dem Mac liegt sie in den Einstellungen im Poedit-Menü.
Keines der beiden Werkzeuge schreibt Ihnen die .l10n.php.
Kompilieren mit WP-CLI, samt PHP-Datei
Die i18n-Befehle von WP-CLI erzeugen beide Formate:
wp i18n make-mo wp-content/languages/plugins/mein-plugin-de_DE_formal.po
wp i18n make-php wp-content/languages/plugins/mein-plugin-de_DE_formal.poJeder Befehl schreibt seine Datei neben Ihre Quelle, wenn Sie kein Ziel angeben. Führen Sie nach jeder Änderung beide aus, dann kann Ihnen die veraltete PHP-Datei nicht passieren. Entfernen Sie aber vorher Ihre „fuzzy“-Markierungen: Beide Befehle übernehmen unscharfe Einträge, wie der Abschnitt dazu zeigt. make-phpkam mit WP-CLI 2.10.0, make-momit 2.5.0. Fehlt Ihnen einer der Befehle, prüfen Sie wp cli version.
Auf der Testseite antwortete WP-CLI 2.12.0 auf jeden der beiden Befehle mit einer Zeile: Success: Created 1 file.
Wohin die Datei gehört, und was sie überschreibt
Den Namen wählen Sie nicht selbst: Textdomain des Plugins, Bindestrich, Gebietsschema, Endung. Die Textdomain finden Sie in der Hauptdatei des Plugins, in der Zeile Text Domain:.
WordPress sucht zuerst in wp-content/languages/plugins/(Themes: wp-content/languages/themes/), dann im eigenen languages-Ordner des Plugins. Eine Datei im ersten Ordner gewinnt.
In genau diesen Ordner schreiben auch Ihre automatischen Übersetzungsaktualisierungen. Liefert WordPress.org ein neueres Sprachpaket für das Plugin, wird Ihre gleichnamige Datei ersetzt; Ihre Änderungen sind weg, und nichts sagt es Ihnen.
Pflegen Sie eine eigene Übersetzung, bewahren Sie Ihre PO-Datei außerhalb von wp-content/languages/auf, dann können Sie nach einem Update neu kompilieren. Was in dem Ordner bereits liegt, zeigt Ihnen WordPress-Sprachdateien scannen und verwalten.
Als „fuzzy“ markierte Einträge erreichen die Website nie
Ein unscharfer Eintrag ist einer, den Ihr Editor geraten hat oder dessen Originaltext sich geändert hat. Er trägt in Ihrer PO-Datei den Kommentar #, fuzzy. Poedit kennzeichnet ihn als „Benötigt Überarbeitung“.
msgfmtlässt unscharfe Einträge weg, wenn Sie nicht --use-fuzzyangeben, und Ihre vollständig übersetzte Datei kann so für jeden unscharfen Eintrag weiter Englisch zeigen. --statisticsnennt Ihnen deren Zahl.
Entfernen Sie die Markierung, nachdem Sie die Übersetzung geprüft haben, und kompilieren Sie neu. Kompilieren Sie nicht mit --use-fuzzy, um die Zahl zu verschönern. Ein unscharfer Eintrag ist unscharf, weil ihn noch niemand bestätigt hat.
WP-CLI hält sich nicht an diese Regel. Auf der Testseite schrieben wp i18n make-mound wp i18n make-phpaus WP-CLI 2.12.0 den unscharfen Eintrag als normale Übersetzung in ihre Dateien, und Ihr Bildschirm zeigte den unbestätigten Text. Kompilieren Sie mit WP-CLI, leeren oder bestätigen Sie vorher jeden unscharfen Eintrag.
Die Pluralzeile im Dateikopf lautet für alle deutschen Varianten nplurals=2; plural=(n != 1);. Kopieren Sie den Kopf aus einer bestehenden deutschen Übersetzung, wenn Sie eine PO-Datei von Hand anlegen.
Texte aus JavaScript brauchen eine JSON-Datei
Die Texte, die Sie im Block-Editor sehen und in Plugins, die ihre Oberfläche in JavaScript aufbauen, liest WordPress nicht aus Ihrer MO-Datei. Sie kommen aus JSON-Dateien mit Namen wie mein-plugin-de_DE_formal-, eine je Skript.
Ist der PHP-Teil übersetzt und eine Schaltfläche im Editor nicht, sehen Sie genau das. wp i18n make-jsonbaut Ihnen diese Dateien aus derselben PO-Datei.
Überprüfung
| Prüfung | Erwartet |
|---|---|
msgfmt --check --statisticsauf Ihrer PO-Datei | Keine Fehler. Unscharfe und unübersetzte Einträge in der erwarteten Zahl. |
| Einstellungen › Allgemein › Sprache der Website | Das Kürzel im Dateinamen passt zur Sprache der Website, also de_DE_formalbei „Deutsch (Sie)“. |
Ordner auflisten: .mound, falls vorhanden, .l10n.php | Beide jünger als Ihre Änderung. Ist die PHP-Datei älter als die MO-Datei, sitzen Sie in der Falle von oben. |
| Einen Eintrag als unscharf markieren, kompilieren, Bildschirm neu laden | Muss weiter den englischen Originaltext zeigen.Zeigt er Ihre Vermutung, hat Ihr Compiler unscharfe Einträge übernommen. |
Die letzte Zeile beweist Ihnen, dass Ihr Compiler die Markierung respektiert. Eine Prüfung, deren Zeilen alle bestehen, zeigt nur, dass Ihr Normalfall funktioniert. Diese zeigt, dass eine unbestätigte Übersetzung Ihre Besucher nicht aus Versehen erreicht.
Führen Sie sie mit dem Werkzeug aus, das Sie wirklich nutzen. msgfmtbesteht sie, und der AIOWS Language Compiler mit beiden seiner Compiler ebenso. Ein Compiler, der die Markierung ignoriert, fällt durch. Auf der Testseite bestand msgfmt1.0; WP-CLI 2.12.0 fiel mit make-mound mit make-phpdurch.
Wie AIOWS unterstützt:
AIOWS Language Compiler
Der Language Compiler, in der deutschen Oberfläche „Sprach-Compiler“, ist der Compiler für die eigenen Übersetzungen von AIOWS. Er ist kein allgemeiner PO-Editor für Ihre anderen Plugins, und die Grenzen unten sagen genau, wo die Linie verläuft.
Er kompiliert dort, wo AIOWS liest.Er macht aus den PO-Dateien im languages-Ordner Ihres AIOWS-Plugins MO-Dateien, einzeln oder alle mit „Alle Gebietsschemata kompilieren“. Lässt Ihr Server PHP msgfmtausführen, nutzt er msgfmt, sonst seinen eigenen Compiler. Beide lassen Ihre unscharfen Einträge weg, wie msgfmtes tut. Eine unbestätigte Übersetzung erreicht Ihre Bildschirme also nie. AIOWS bringt für die eigene Textdomain keine .l10n.phpmit, die PHP-Datei-Falle von oben betrifft diese Dateien also nicht. WordPress liest die MO-Datei, die das Modul für Sie schreibt.
Er zeigt Ihnen vorher, was fehlt.Der Reiter „Scannen“ vergleicht den Code des Plugins mit seinen PO-Dateien. Er meldet, wie viel der AIOWS-Oberfläche übersetzt ist, und listet leere und doppelte Einträge. Ein leerer Eintrag kompiliert ohne Fehler und zeigt trotzdem Englisch. Lesen Sie diese Liste also zuerst.
Er nimmt Ihre bearbeitete Datei an.„Hochladen / Verwalten“ übernimmt eine PO- oder MO-Datei, die Sie anderswo bearbeitet haben, etwa in Poedit, und legt sie dorthin, wo AIOWS sie lädt. Eine gleichnamige Datei wird ersetzt. Jede Datei dort können Sie auf demselben Bildschirm herunterladen. Nehmen Sie also vorher eine Kopie.
Der praktische Nutzen: Sie korrigieren eine Bezeichnung in der deutschen AIOWS-Oberfläche direkt im Backend, ohne SFTP und ohne lokale gettext-Installation.
Seine Grenzen, offen gesagt. Er kompiliert nur die Dateien im eigenen languages-Ordner von AIOWS. Für die PO-Datei eines anderen Plugins oder eines Themes nutzen Sie msgfmt, Poedit oder WP-CLI wie oben. Er schreibt nur MO-Dateien, keine .l10n.phpund 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ückbrauchen.
Häufige Fragen
Muss ich die PO-Datei auf den Server laden?Für WordPress nicht. Es liest nur Ihre MO- und PHP-Dateien. Behalten Sie Ihre PO-Datei trotzdem, denn nur sie können Sie bearbeiten.
Meine Website steht auf „Deutsch (Sie)“. Brauche ich dann eine eigene Übersetzung?Sie brauchen eine Datei mit dem Kürzel de_DE_formal. Viele Plugins bekommen von WordPress.org auch ein Sie-Sprachpaket. Fehlt es, legen Sie Ihre eigene Datei unter diesem Namen an.
Kann ich eine MO-Datei direkt bearbeiten?Nein. Sie ist binär kompiliert. Bearbeiten Sie Ihre PO-Datei und kompilieren Sie neu.
Ich habe kompiliert, und nichts hat sich geändert. Was zuerst?Suchen Sie eine .l10n.phpgleichen Namens. Ist sie älter als Ihre MO-Datei, liest WordPress sie. Prüfen Sie danach das Kürzel im Dateinamen.
Warum ist meine Übersetzung nach einem Update verschwunden?Ein Sprachpaket hat Ihre Datei in wp-content/languages/plugins/ersetzt. Bewahren Sie Ihre PO-Datei anderswo auf und kompilieren Sie neu.
