{"id":2256,"date":"2026-06-28T13:34:19","date_gmt":"2026-06-28T10:34:19","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2256"},"modified":"2026-08-02T12:10:42","modified_gmt":"2026-08-02T12:10:42","slug":"wordpress-plugin-uebersetzungen-werden-nicht-angezeigt","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-plugin-uebersetzungen-werden-nicht-angezeigt\/","title":{"rendered":"WordPress-Plugin-\u00dcbersetzungen werden nicht angezeigt"},"content":{"rendered":"

Ein Plugin ist laut PO-Datei vollst\u00e4ndig \u00fcbersetzt, 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\u00e4dt einen anderen Katalog.<\/p>\n

Dieser Beitrag zeigt, wie Sie den fehlenden Text von der Quellnachricht \u00fcber Textdomain und Locale bis zur tats\u00e4chlich geladenen MO- oder JSON-Datei verfolgen.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS Language Compiler<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Was das Thema bedeutet<\/h2>\n

    Eine Plugin-\u00dcbersetzung erscheint nur, wenn Ausgangstext, Kontext, Textdomain, Locale und gegebenenfalls Pluralform zum geladenen Katalog passen. Dateiname und Ablageort m\u00fcssen au\u00dferdem dem verwendeten WordPress-Lademechanismus entsprechen. Ein vorhandener PO-Eintrag allein belegt daher noch keinen Treffer zur Laufzeit.<\/p>\n

    PHP-Texte werden meist \u00fcber gettext und MO-Dateien geladen. JavaScript-\u00dcbersetzungen k\u00f6nnen dagegen eigene, an Domain und Skript gebundene JSON-Kataloge ben\u00f6tigen. Beide Wege sollten getrennt gepr\u00fcft werden.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Im Frontend wird ein Plugin-Text korrekt auf Deutsch ausgegeben, in wp-admin<\/code> bleibt derselbe Funktionsbereich englisch. Die Website-Sprache ist Deutsch, der angemeldete Benutzer verwendet jedoch eine andere Locale. Zus\u00e4tzlich stammt der Admin-Text aus JavaScript. Das Team pr\u00fcft deshalb nicht nur die MO-Datei, sondern auch Benutzer-Locale, Skript-Handle und den zugeh\u00f6rigen JSON-Katalog.<\/p>\n

    Warum es wichtig ist und wann es eingesetzt wird<\/h2>\n

    Fehlende \u00dcbersetzungen sind selten durch beliebiges Leeren von Caches oder Kopieren weiterer Sprachdateien l\u00f6sbar. Ohne eine genaue Zuordnung k\u00f6nnen mehrere gleichnamige Kataloge entstehen, die sich je nach Anfrage gegenseitig \u00fcberlagern und beim n\u00e4chsten Update \u00fcberschrieben werden.<\/p>\n

    Eine gezielte Pr\u00fcfung ist sinnvoll, wenn einzelne Texte, bestimmte Bereiche oder nur eine Locale betroffen sind. Fehlt die Ausgangsnachricht im aktuellen Katalog, muss dieser aus der ma\u00dfgeblichen Vorlage aktualisiert werden. Weicht der Quelltext im Plugin ab, geh\u00f6rt die \u00dcbersetzung zum neuen String und darf nicht unter einem alten Eintrag erzwungen werden.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Notieren Sie den exakten englischen Ausgangstext, die betroffene Seite und die aktive Plugin-Version.<\/li>\n
    2. Vergleichen Sie Website- und Benutzer-Locale; die Administration kann eine andere Sprache als das Frontend verwenden.<\/li>\n
    3. Pr\u00fcfen Sie Textdomain, Dateinamen und Sprachordner des geladenen Plugins.<\/li>\n
    4. Stellen Sie fest, ob der Text aus PHP oder JavaScript stammt.<\/li>\n
    5. Testen Sie nach der Korrektur genau diesen Text in einer frischen Anfrage der vorgesehenen Locale.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      Erstellen Sie f\u00fcr einen fehlenden PHP- und einen fehlenden JavaScript-Text jeweils eine kurze Lookup-Spur: Ausgangstext, Kontext, Textdomain, Locale, erzeugter Dateiname, m\u00f6gliche Ladepfade und tats\u00e4chlich gew\u00e4hlter Katalog. Damit lassen sich Namensfehler, sp\u00e4te Domain-Registrierung und getrennte JSON-Builds auseinanderhalten.<\/p>\n

      Durchsuchen Sie Plugin-, Theme- und globale Sprachverzeichnisse nach \u00e4lteren Katalogen derselben Domain. Pr\u00fcfen Sie im Code, wann die Textdomain geladen und welchem Skript die JavaScript-\u00dcbersetzung zugeordnet wird. Kompilieren Sie nur die nachweislich zust\u00e4ndige PO-Quelle neu.<\/p>\n

      Wenn der korrigierte Text erst nach einem Prozessneustart erscheint, leeren Sie gezielt den relevanten Laufzeitcache; dort k\u00f6nnen Sprachkataloge oder Opcodes zwischengespeichert sein. Eine allgemeine Cache-Bereinigung sollte nicht die eigentliche Ursache verdecken.<\/p>\n

      Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/h2>\n

      Bearbeiten Sie keine automatisch verwalteten Sprachpakete als dauerhafte L\u00f6sung. Plugin- oder WordPress-Updates k\u00f6nnen solche \u00c4nderungen ohne Hinweis ersetzen. Ebenso riskant ist es, die Textdomain an einen bequemen Dateinamen anzupassen, obwohl der Quellcode eine andere Domain verwendet.<\/p>\n

      Sichern Sie die betroffenen Sprachdateien samt Pfad und Dateirechten. Bei Parsefehlern, besch\u00e4digten Zeichen oder \u00c4nderungen an anderen \u00dcbersetzungen stellen Sie die vorherigen Dateien wieder her. Eigene Kataloge ben\u00f6tigen anschlie\u00dfend einen dokumentierten, updatefesten Build- und Ablageprozess.<\/p>\n

      \n

      Wie AIOWS unterst\u00fctzt:<\/p>\n

      AIOWS Language Compiler<\/h2>\n

      AIOWS Language Compiler unterst\u00fctzt die Pr\u00fcfung 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.<\/p>\n

      Vor dem Kompilieren m\u00fcssen Locale, Textdomain, Quelle und Ziel eindeutig sein. Kontrollieren Sie anschlie\u00dfend die erzeugte Datei und rufen Sie einen konkreten \u00fcbersetzten Text im Frontend oder in der Administration auf. Erst dieser Test zeigt, dass WordPress den vorgesehenen Katalog tats\u00e4chlich l\u00e4dt.<\/p>\n

      Das Modul erg\u00e4nzt keine fehlenden Strings, \u00e4ndert keine falsche Textdomain im Plugin und erzeugt keine JavaScript-Zuordnung, die im Quellcode fehlt. Es sch\u00fctzt manuell abgelegte Dateien auch nicht vor sp\u00e4teren Updates. Scheitert der Test, stellen Sie den zuvor gesicherten Katalog wieder her und kl\u00e4ren Ladereihenfolge, Locale und Build-Prozess.<\/p>\n

      AIOWS Language Compiler ansehen<\/a>AIOWS-Tarife vergleichen<\/a><\/p>\n<\/section>\n

      Passende AIOWS-Artikel<\/h2>\n