Ein Plugin ist laut PO-Datei vollständig übersetzt, zeigt aber auf einer Website englische Texte und auf einer anderen Installation desselben Servers deutsche. Die Dateien sind vorhanden; in der betroffenen Anfrage weichen jedoch Locale oder Textdomain ab, oder WordPress lädt einen anderen Katalog.
Dieser Beitrag zeigt, wie Sie den fehlenden Text von der Quellnachricht über Textdomain und Locale bis zur tatsächlich geladenen MO- oder JSON-Datei verfolgen.
- 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 Plugin-Übersetzung erscheint nur, wenn Ausgangstext, Kontext, Textdomain, Locale und gegebenenfalls Pluralform zum geladenen Katalog passen. Dateiname und Ablageort müssen außerdem dem verwendeten WordPress-Lademechanismus entsprechen. Ein vorhandener PO-Eintrag allein belegt daher noch keinen Treffer zur Laufzeit.
PHP-Texte werden meist über gettext und MO-Dateien geladen. JavaScript-Übersetzungen können dagegen eigene, an Domain und Skript gebundene JSON-Kataloge benötigen. Beide Wege sollten getrennt geprüft werden.
Ein realistisches WordPress-Beispiel
Im Frontend wird ein Plugin-Text korrekt auf Deutsch ausgegeben, in wp-adminbleibt derselbe Funktionsbereich englisch. Die Website-Sprache ist Deutsch, der angemeldete Benutzer verwendet jedoch eine andere Locale. Zusätzlich stammt der Admin-Text aus JavaScript. Das Team prüft deshalb nicht nur die MO-Datei, sondern auch Benutzer-Locale, Skript-Handle und den zugehörigen JSON-Katalog.
Warum es wichtig ist und wann es eingesetzt wird
Fehlende Übersetzungen sind selten durch beliebiges Leeren von Caches oder Kopieren weiterer Sprachdateien lösbar. Ohne eine genaue Zuordnung können mehrere gleichnamige Kataloge entstehen, die sich je nach Anfrage gegenseitig überlagern und beim nächsten Update überschrieben werden.
Eine gezielte Prüfung ist sinnvoll, wenn einzelne Texte, bestimmte Bereiche oder nur eine Locale betroffen sind. Fehlt die Ausgangsnachricht im aktuellen Katalog, muss dieser aus der maßgeblichen Vorlage aktualisiert werden. Weicht der Quelltext im Plugin ab, gehört die Übersetzung zum neuen String und darf nicht unter einem alten Eintrag erzwungen werden.
Der einfache Weg für Einsteiger
- Notieren Sie den exakten englischen Ausgangstext, die betroffene Seite und die aktive Plugin-Version.
- Vergleichen Sie Website- und Benutzer-Locale; die Administration kann eine andere Sprache als das Frontend verwenden.
- Prüfen Sie Textdomain, Dateinamen und Sprachordner des geladenen Plugins.
- Stellen Sie fest, ob der Text aus PHP oder JavaScript stammt.
- Testen Sie nach der Korrektur genau diesen Text in einer frischen Anfrage der vorgesehenen Locale.
Der technische Weg
Erstellen Sie für einen fehlenden PHP- und einen fehlenden JavaScript-Text jeweils eine kurze Lookup-Spur: Ausgangstext, Kontext, Textdomain, Locale, erzeugter Dateiname, mögliche Ladepfade und tatsächlich gewählter Katalog. Damit lassen sich Namensfehler, späte Domain-Registrierung und getrennte JSON-Builds auseinanderhalten.
Durchsuchen Sie Plugin-, Theme- und globale Sprachverzeichnisse nach älteren Katalogen derselben Domain. Prüfen Sie im Code, wann die Textdomain geladen und welchem Skript die JavaScript-Übersetzung zugeordnet wird. Kompilieren Sie nur die nachweislich zuständige PO-Quelle neu.
Wenn der korrigierte Text erst nach einem Prozessneustart erscheint, leeren Sie gezielt den relevanten Laufzeitcache; dort können Sprachkataloge oder Opcodes zwischengespeichert sein. Eine allgemeine Cache-Bereinigung sollte nicht die eigentliche Ursache verdecken.
Risiken, häufige Fehler, Backup und Rollback
Bearbeiten Sie keine automatisch verwalteten Sprachpakete als dauerhafte Lösung. Plugin- oder WordPress-Updates können solche Änderungen ohne Hinweis ersetzen. Ebenso riskant ist es, die Textdomain an einen bequemen Dateinamen anzupassen, obwohl der Quellcode eine andere Domain verwendet.
Sichern Sie die betroffenen Sprachdateien samt Pfad und Dateirechten. Bei Parsefehlern, beschädigten Zeichen oder Änderungen an anderen Übersetzungen stellen Sie die vorherigen Dateien wieder her. Eigene Kataloge benötigen anschließend einen dokumentierten, updatefesten Build- und Ablageprozess.
Wie AIOWS unterstützt:
AIOWS Language Compiler
AIOWS Language Compiler unterstützt die Prüfung von WordPress-Sprachquellen und kann aus einer freigegebenen PO-Datei die passende MO-Datei erzeugen. Das hilft, wenn der geladene Laufzeitkatalog veraltet ist oder nach einer Korrektur neu gebaut werden muss.
Vor dem Kompilieren müssen Locale, Textdomain, Quelle und Ziel eindeutig sein. Kontrollieren Sie anschließend die erzeugte Datei und rufen Sie einen konkreten übersetzten Text im Frontend oder in der Administration auf. Erst dieser Test zeigt, dass WordPress den vorgesehenen Katalog tatsächlich lädt.
Das Modul ergänzt keine fehlenden Strings, ändert keine falsche Textdomain im Plugin und erzeugt keine JavaScript-Zuordnung, die im Quellcode fehlt. Es schützt manuell abgelegte Dateien auch nicht vor späteren Updates. Scheitert der Test, stellen Sie den zuvor gesicherten Katalog wieder her und klären Ladereihenfolge, Locale und Build-Prozess.
Passende AIOWS-Artikel
- WordPress-PO-Dateien in MO-Dateien kompilieren
- WordPress-Sprachdateien scannen und verwalten
- Cache für mehrsprachige WordPress-Websites konfigurieren
Fazit und empfohlener Weg
Verfolgen Sie einen fehlenden Text über Quelle, Kontext, Domain, Locale, Katalog, Pfad und Ladezeit. Neu gebaut oder verschoben wird nur der nachweislich zuständige Katalog; PHP- und JavaScript-Übersetzungen werden getrennt geprüft. Eigene Übersetzungen gehören in einen unterstützten, updatesicheren Build- und Ablageprozess, nicht in ein ersetzbares Sprachpaket.
