WordPress-Plugin-Übersetzungen werden nicht angezeigt

WordPress-Plugin-Übersetzungen werden nicht angezeigt

Sie haben ein Plugin übersetzt, die Datei liegt auf dem Server, und Ihr Bildschirm zeigt trotzdem Englisch. Kaputt ist dabei nichts. WordPress sucht pro Plugin genau eine Datei, ausgewählt nach Ihrer Sprache, nach dem Dateinamen und nach dem Ordner. Stimmt eines davon um ein Zeichen nicht, meldet WordPress nichts und zeigt Ihnen Englisch.

Auf deutschen Websites kommt eine Falle dazu, die es im Englischen nicht gibt: Deutsch und Deutsch (Sie) sind für WordPress zwei verschiedene Sprachen. Bearbeiten Sie Ihre Übersetzung deshalb noch nicht. Finden Sie zuerst heraus, welche Datei WordPress für Sie tatsächlich liest. Jede Prüfung unten lief auf einer Testseite, mit einem kleinen Plugin, das jeden Text mit seiner Herkunftsdatei markiert.

Inhaltsverzeichnis

  1. Welche Sprache fragt WordPress an?
  2. Ihre Website siezt, das Plugin nicht
  3. Der Dateiname muss genau stimmen
  4. Eine Datei in wp-content/languages gewinnt
  5. Die .l10n.php daneben
  6. Texte aus JavaScript brauchen eine eigene Datei
  7. Zu früh geladene Übersetzungen
  8. Überprüfung
  9. AIOWS Language Compiler
  10. Häufige Fragen
  11. Quellen

Welche Sprache fragt WordPress an?

WordPress kennt zwei Spracheinstellungen, und Ihre Verwaltungsseiten folgen der, an die Sie vielleicht nicht denken:

EinstellungWo Sie sie findenWas sie steuert
Website-SpracheEinstellungen› Allgemein› Website-SpracheIhre öffentlichen Seiten
Ihre ProfilspracheBenutzer› Profil› Sprachejede Verwaltungsseite, die Sie sehen

Stellen Sie die Website auf Deutsch und Ihr eigenes Profil auf Englisch, sehen Sie, was die Testseite zeigte: die Plugin-Seite im Backend auf Englisch, obwohl eine richtige deutsche Datei vorhanden war.

Steht in Ihrem Profil der Standardwert der Website, folgt es der Website-Sprache. Steht dort eine Sprache, gilt diese auf Ihren Verwaltungsseiten, und zwar nur für Sie. Eine Kollegin kann dieselbe Seite in einer anderen Sprache sehen.

Ihre Website siezt, das Plugin nicht

Im Sprachmenü von WordPress stehen Deutschund Deutsch (Sie)nebeneinander. Dahinter stehen zwei Gebietsschemata, de_DEund de_DE_formal, und für jedes braucht ein Plugin eine eigene Datei.

Auf der Testseite lief das so ab: – Mit Deutsch (Sie)im Profil und nur einer de_DE-Datei blieb die Seite komplett englisch. WordPress weicht bei Plugins nicht auf de_DEaus. – Mit einer zusätzlichen de_DE_formal-Datei war sie deutsch.

Die Testseite mit Deutsch (Sie) im Profil und nur einer de_DE-Datei: alle Texte englisch.
Deutsch (Sie) eingestellt, nur Du-Datei vorhanden: Englisch.

Die förmliche Übersetzung ist auf translate.wordpress.org ein eigenes Projekt. Ein Sprachpaket gibt es erst, wenn dort 90 % der stabilen Texte übersetzt sind, und zwar für jedes Gebietsschema einzeln. Ein Plugin kann deshalb auf Deutsch fertig sein und auf Deutsch (Sie) noch gar nicht.

Liefert Ihr Plugin nur de_DEund Ihre Website läuft auf Deutsch (Sie), kopieren Sie dessen de_DE-Dateien unter dem Namen de_DE_formal. Ihre Leser werden dann geduzt, aber auf Deutsch.

Der Dateiname muss genau stimmen

Die Übersetzungsdatei eines Plugins heißt textdomain-gebietsschema.mo. Die Textdomain ist die Kennung des Plugins, meist sein Ordnername. Das Gebietsschema ist der volle Code, ohne Abkürzung:

Ihre SpracheinstellungDatei, die WordPress sucht
Deutschmein-plugin-de_DE.mo
Deutsch (Sie)mein-plugin-de_DE_formal.mo
Deutsch (Schweiz)mein-plugin-de_CH.mo
Deutsch (Österreich)mein-plugin-de_AT.mo

Eine Datei mein-plugin-de.mopasst zu keiner dieser Einstellungen. Auf der Testseite blieb eine verkürzt benannte Datei ebenso wirkungslos, im Versuch mit Türkisch: -tr.mowurde ignoriert, -tr_TR.mogelesen.

Eine Datei in wp-content/languages gewinnt

Die Übersetzung eines Plugins kann aus zwei Ordnern kommen: – aus wp-content/languages/plugins/, wohin WordPress die Sprachpakete von translate.wordpress.org lädt; – aus dem eigenen languages-Ordner des Plugins, der nur zählt, wenn das Plugin ihn mit load_plugin_textdomain()anmeldet.

WordPress prüft wp-content/languages/plugins/zuerst.Legen Sie denselben Text in beide Ordner, jeweils mit seiner Herkunft markiert, zeigt Ihre Seite die Fassung aus dem Sprachpaket. Ändern Sie die Datei im Plugin-Ordner, so oft Sie wollen: Es ändert sich nichts.

Die Testseite: der PHP-Text zeigt die Fassung aus dem Sprachpaket, der Text aus dem Skript ist englisch.
Das Sprachpaket gewinnt, und die JSON-Datei im Plugin-Ordner wird nicht mehr gelesen.

Umgekehrt gilt es auch. Ruft Ihr Plugin load_plugin_textdomain()nie auf, wird es nur aus wp-content/languages/plugins/übersetzt. Ihre Datei im Plugin-Ordner bleibt wirkungslos, bis Sie sie dorthin verschieben.

Wie Sie eine korrigierte Datei kompilieren und wohin sie gehört, steht in WordPress-PO-Dateien in MO-Dateien kompilieren.

Die .l10n.php daneben

Seit WordPress 6.5 lädt WordPress eine .l10n.phpmit demselben Namen wie Ihre .moan deren Stelle. Auf der Testseite gewann eine .l10n.phpneben der .modes Sprachpakets. Eine .l10n.phpganz ohne .modaneben gewann ebenso.

Haben Sie eine .mobearbeitet, neu kompiliert, und nichts ändert sich, suchen Sie eine .l10n.phpgleichen Namens. Erzeugen Sie sie mit wp i18n make-phpaus Ihrer PO-Datei neu, oder löschen Sie sie, damit die .mogelesen wird.

Ein Unterschied überrascht viele. msgfmtlässt als „fuzzy“ markierte Einträge aus der .moweg, sie bleiben englisch. wp i18n make-phpaus WP-CLI 2.12.0 übernahm den unsicheren Eintrag, und die Testseite zeigte seine ungeprüfte Übersetzung. Entfernen Sie die Markierung bei Einträgen, die Sie behalten wollen, bevor Sie die PHP-Datei erzeugen, und lassen Sie die übrigen leer.

Texte aus JavaScript brauchen eine eigene Datei

Text, den ein Skript in Ihre Seite schreibt, berührt die .monie. Sie brauchen eine JSON-Datei, benannt nach Textdomain, Gebietsschema und dem MD5-Hash des Skriptpfads im Plugin, etwa mein-plugin-de_DE-0a1b2c….json. wp i18n make-jsonerzeugt sie aus Ihrer PO-Datei, und Ihr Plugin muss wp_set_script_translations()aufrufen.

Zwei Ergebnisse der Testseite sollten Sie kennen: – Ohne JSON-Dateiist Ihr PHP-Text deutsch und Ihr Skript-Text englisch, auf derselben Seite. – Mit einem Sprachpaketwird Ihre JSON-Datei im Plugin-Ordner ignoriert, und der Skript-Text fällt auf Englisch zurück. Legen Sie die JSON-Datei neben die Datei, die gewinnt.

Ist Ihre Seite halb deutsch, halb englisch, fangen Sie hier an.

Zu früh geladene Übersetzungen

Seit WordPress 6.7 schreibt ein Plugin, das vor der Aktion initeine Übersetzung anfordert, einen Hinweis in Ihr Debug-Protokoll. Er kommt auf Englisch, auch auf einer deutschen Website:

Translation loading for the mein-plugin domain was triggered too early.
This is usually an indicator for some code in the plugin or theme running
too early. Translations should be loaded at the init action or later.

Schalten Sie WP_DEBUG_LOGein und durchsuchen Sie Ihre wp-content/debug.lognach der Textdomain des Plugins. Auf der Testseite blieb ein Text, der schon beim Laden der Plugin-Datei übersetzt wurde, englisch, während der Rest Ihrer Seite deutsch war. Ihr Protokoll enthält dann den Hinweis.

Mit einer Datei beheben Sie das nicht. Schicken Sie den Hinweis an den Autor des Plugins: Der betroffene Code gehört an initoder später.

Überprüfung

Sie haben die Ursache gefunden, wenn Sie die Datei nennen können, die den Text liefert, und Ihr Bildschirm sich ändert, sobald sie fehlt.

PrüfungErwartet
Seite mit der Profilsprache öffnen, die nicht funktioniert, also genau Deutsch oder Deutsch (Sie)Diese Sprache. Sonst siehe den ersten Abschnitt.
Die Datei, die Sie für die liefernde halten, umbenennen, etwa in .mo.off, und neu ladenMuss sich ändern.Der Text fällt auf Englisch zurück oder auf die Fassung einer anderen Datei.
Den Namen zurücksetzen und neu ladenDie Übersetzung ist wieder da.
Einen PHP-Text und einen Skript-Text auf derselben Seite prüfenBeide übersetzt. Sonst siehe JavaScript.
debug.lognach der Textdomain durchsuchenDarfkeine Zeile „triggered too early“ enthalten.

Das Umbenennen entscheidet es für Sie. Auf der Testseite schaltete das Umbenennen der .moaus dem Sprachpaket den Text auf die Fassung aus dem Plugin-Ordner um. Die Datei, die Sie bearbeitet hätten, war nie die auf Ihrem Bildschirm.

Ändert sich beim Umbenennen nichts, hat WordPress Ihre Datei nicht gelesen. Suchen Sie dann eine .l10n.php, eine zweite Kopie in einem anderen Ordner oder einen Seiten-Cache, der Ihnen eine ältere Fassung ausliefert.

Benennen Sie die einzige .moum, wird Ihr PHP-Text englisch, Ihr Skript-Text bleibt deutsch. Jede Art von Text hat ihre eigene Datei, also prüfen Sie jede.

Wie AIOWS unterstützt:

AIOWS Language Compiler

Der Language Compiler, im deutschen Menü „Sprach-Compiler“, verwaltet Ihre AIOWS-Übersetzungen. AIOWS lädt sie anders als das Plugin in diesem Artikel, und die Fallen oben wirken sich für Sie deshalb anders aus.

Er nimmt bewusst den eigenen Ordner zuerst.Für die Sprachen, die AIOWS mitliefert, Deutsch und Türkisch, lädt AIOWS die Datei aus seinem eigenen languages-Ordner und setzt sie an die Stelle eines Sprachpakets für seine Textdomain in wp-content/languages/plugins/. Ein älteres Paket dort kann neu ausgelieferte Texte nicht verdecken. Auf der Testseite änderte ein untergeschobenes Paket mit anderer Beschriftung, .mound .l10n.php, nichts an Ihren AIOWS-Seiten.

Er lässt Sie auf Deutsch (Sie) nicht im Englischen stehen.Für ein deutsches Gebietsschema ohne eigene Datei, etwa de_DE_formal, gibt Ihnen AIOWS seine de_DE-Übersetzung. Genau die Falle aus dem zweiten Abschnitt tritt bei AIOWS also nicht auf.

Der Sprach-Compiler mit Deutsch (Sie) im Profil: Menü und Seite deutsch, Gebietsschema de_DE_formal, keine eigene formal-Datei.
Deutsch (Sie) ohne eigene Datei: AIOWS nimmt seine de_DE-Übersetzung.

Er zeigt Ihnen, was fehlt.Der Reiter „Scannen“ vergleicht den Code von AIOWS mit jeder Ihrer PO-Dateien und meldet übersetzte, leere, doppelte und fehlende Einträge je Gebietsschema. Lesen Sie die Spalten „Leer“ und „Fehlende Quellenabdeckung“: Sie nennen, was fehlt, und die Abdeckung rundet einen fehlenden Text nie auf 100 % auf.

Er kompiliert sicher ohne msgfmt.„Kompilieren“ macht aus Ihren AIOWS-PO-Dateien MO-Dateien, mit GNU msgfmt, wenn Ihr Server es erlaubt, sonst mit dem eigenen Compiler. Beide lassen unsichere und unübersetzte Einträge weg, ein unfertiger Text zeigt Ihnen also Englisch, nie eine leere Stelle.

Seine Grenzen, offen gesagt. Er arbeitet nur mit dem eigenen languages-Ordner von AIOWS. Die Übersetzungen Ihrer anderen Plugins und Ihres Themes kompilieren Sie mit msgfmt, Poedit oder WP-CLI. Er schreibt nur .mo-Dateien, keine .l10n.phpund kein JSON für Skripte. Und er untersucht nicht, wie andere Plugins laden: Profilsprache, zu frühe Aufrufe oder eine zweite Kopie einer Datei prüfen Sie mit der Überprüfung oben.

AIOWS Language Compiler ansehenAIOWS-Pläne vergleichen

Häufige Fragen

Ich habe die Übersetzung hochgeladen und den Cache geleert. Warum ist es noch englisch?Prüfen Sie zuerst Ihre Profilsprache, dann Du oder Sie, dann den Dateinamen, dann ob eine Datei in wp-content/languages/plugins/Ihre verdrängt.

Fällt WordPress von de_DE_formalauf de_DEzurück?Bei Plugins nicht. AIOWS tut es für sich selbst; Ihre anderen Plugins brauchen eine eigene de_DE_formal-Datei.

Warum ist das Plugin im Frontend übersetzt, im Backend aber nicht?Ihre Profilsprache bestimmt Ihr Backend, die Website-Sprache Ihre öffentlichen Seiten.

Bleibt meine eigene Übersetzung bei einem Update erhalten?Eine Datei im Plugin-Ordner verschwindet, wenn ein Update diesen Ordner ersetzt. Bewahren Sie Ihre PO-Datei woanders auf und kompilieren Sie nach Updates neu.

Wo sehe ich, welche Texte noch fehlen?In Ihrer PO-Datei oder in der Liste unübersetzter Einträge Ihres Editors. Für AIOWS zählt der Reiter „Scannen“ sie je Sprache. Mehr zum Lesen von Sprachdateien steht in WordPress-Sprachdateien scannen und verwalten.

Quellen

Ähnliche Beiträge

All in One WP Settings holenZum Plugin