Wie man Fuzzy-Übersetzungen in WordPress .po-Dateien repariert

Sie haben jeden String übersetzt. Sie haben die Datei gespeichert, die .mo hochgeladen und Ihre Website aktualisiert. Und doch sind eine Handvoll Bezeichnungen immer noch hartnäckig auf Englisch. Sie öffnen die .po-Datei, finden den String, und da ist er, perfekt übersetzt. Warum ignoriert WordPress ihn also?

Die Antwort ist fast immer ein kleines Flag, das sich über dem Eintrag versteckt: #, fuzzy. Eine Fuzzy-Übersetzung ist gettexts Art zu sagen: „Diese Übersetzung könnte falsch sein, vertrauen Sie ihr also noch nicht.“ Und entscheidend ist, dass WordPress sich weigert, Fuzzy-Strings auf der Live-Site anzuzeigen, und stattdessen auf das ursprüngliche Englisch zurückgreift. Dies ist eine der am meisten missverstandenen Ursachen für das Problem „Meine Übersetzung wird nicht angezeigt“.

Dieser Leitfaden erklärt genau, was das Fuzzy-Übersetzungs-Flag bedeutet, warum es immer wieder in Ihren Katalogen erscheint und wie Sie Fuzzy-Strings in Poedit, auf der Befehlszeile und im großen Stil über einen gesamten Rückstand hinweg finden und löschen können. Sobald Sie den Mechanismus verstanden haben, verschwindet das Rätsel der fehlenden Übersetzungen.

Was bedeutet das Fuzzy-Flag eigentlich?

Das Fuzzy-Flag ist eine Markierung, die gettext einem Übersetzungseintrag hinzufügt, um anzuzeigen, dass die Übersetzung unsicher ist und einer menschlichen Überprüfung bedarf. In der rohen .po-Datei erscheint es als spezieller Kommentar direkt über dem String.

#: includes/cart.php:88
#, fuzzy
msgid "Add to cart"
msgstr "Im Warenkorb"

Diese Zeile #, fuzzy teilt jedem gettext-fähigen Tool, einschließlich WordPress, mit, dass der darunter stehende msgstr provisorisch ist. Die Übersetzung existiert, aber gettext betrachtet sie nicht als bestätigt.

Warum WordPress Fuzzy-Strings überspringt

Hier ist das Verhalten, das jeden überrascht. Wenn WordPress eine .mo-Datei kompiliert oder liest, behandelt es Fuzzy-Einträge als unübersetzt. Der String ist technisch in der Datei vorhanden, aber WordPress ignoriert ihn bewusst und zeigt stattdessen die ursprüngliche msgid an.

Aus Ihrer Sicht ist die Übersetzung also „fertig“, sie ist direkt in der Datei vorhanden. Aus der Perspektive von WordPress hat dieser String jedoch keine vertrauenswürdige Übersetzung, daher wird die englische Quelle gerendert. Dies ist genau der Grund, warum ein fertig aussehender Katalog auf der Frontend-Seite immer noch unübersetzten Text anzeigen kann.

Dieses Design ist beabsichtigt und, fairerweise, sinnvoll. Der Sinn des Fuzzy-Flags besteht darin, zu verhindern, dass ungeprüfte, potenziell falsche Übersetzungen stillschweigend live geschaltet werden. Stellen Sie sich einen String vor, der ursprünglich „Delete account“ lautete und später in „Deactivate account“ geändert wurde. Wenn gettext die alte Übersetzung blind beibehalten hätte, könnten Ihre Benutzer einen Button mit der Beschriftung „Delete account“ sehen, der tatsächlich nur deaktiviert – eine gefährliche Diskrepanz. Durch das Verbergen von Fuzzy-Strings zwingt gettext einen Menschen dazu, zu bestätigen, dass die Übersetzung immer noch der neuen Bedeutung entspricht, bevor sie an irgendjemanden gelangt. Das Flag ist ein Sicherheitsmechanismus, kein Fehler.

Warum erscheinen Fuzzy-Flags immer wieder?

Fuzzy-Flags sind nicht zufällig. Sie werden automatisch von gettext-Tools in zwei Hauptsituationen generiert, und das Verständnis beider zeigt Ihnen, wie Sie sie verhindern können.

Der Quellstring wurde geändert

Die häufigste Ursache ist eine Quellaktualisierung. Stellen Sie sich vor, der Entwickler ändert einen String in der nächsten Plugin-Version von „Add to cart“ zu „Add to basket“. Wenn Sie die neue Vorlage in Ihre bestehende Übersetzung zusammenführen, stellt gettext fest, dass die Quelle nicht mehr mit dem übereinstimmt, was Sie ursprünglich übersetzt haben. Anstatt Ihre alte Übersetzung wegzuwerfen, behält es sie bei, markiert sie aber als Fuzzy und sagt im Wesentlichen: „Das Englische hat sich geändert, also überprüfen Sie bitte noch einmal, ob Ihre Übersetzung noch passt.“

Automatisches Abgleichen durch Translation Memory und msgmerge

Die zweite Ursache ist das Fuzzy-Matching während einer Zusammenführung. Das Tool msgmerge aktualisiert eine alte Übersetzungsdatei anhand einer neuen Vorlage, und wenn es einen Quellstring findet, der einem früheren ähnlich, aber nicht identisch ist, kopiert es die alte Übersetzung und markiert sie als Fuzzy.

# Merge a new template into an existing translation.
# Similar-but-changed strings get marked #, fuzzy automatically.
msgmerge --update awesome-plugin-de_DE.po awesome-plugin.pot

Translation Memory in Desktop-Editoren verhält sich genauso: Wenn es einen Vorschlag aus einer nahezu passenden Übereinstimmung automatisch ausfüllt, markiert es das Ergebnis als Fuzzy, damit Sie daran denken, es zu überprüfen. In beiden Fällen erfüllt das Flag seine Aufgabe. Das Problem ist nur, dass die Fuzzy-Einträge dann unüberprüft bleiben und WordPress sie stillschweigend verbirgt.

Es gibt eine dritte, heimtückischere Quelle, die es wert ist, beachtet zu werden: Copy-Paste- und Massenimport-Tools. Einige Übersetzungsplattformen und Importskripte markieren standardmäßig jeden Eintrag als Fuzzy als konservative Maßnahme, da sie erwarten, dass ein Mensch jeden Eintrag danach bestätigt. Wenn Sie einen Katalog aus einem anderen System importieren und feststellen, dass jeder einzelne String plötzlich Fuzzy ist, ist dies normalerweise der Grund dafür. Die Übersetzungen können vollkommen in Ordnung sein, aber bis die Flags gelöscht sind, wird keine davon auf Ihrer Website erscheinen. Die Kenntnis der Herkunft der Flags sagt Ihnen, ob Sie wirklich jeden Eintrag überprüfen müssen oder ob ein selbstbewusstes Massenlöschen sicher ist.

Wie findet und behebt man Fuzzy-Strings?

Das Löschen von Fuzzy-Strings bedeutet, jeden einzelnen zu überprüfen und, sobald Sie bestätigen, dass die Übersetzung korrekt ist, das Flag zu entfernen. Es gibt drei praktische Möglichkeiten, dies zu tun, abhängig von der Größe der Aufgabe.

Fuzzy-Strings in Poedit beheben

Poedit macht dies am einfachsten. Öffnen Sie die .po-Datei und verwenden Sie die Such- und Filtersteuerungen, um nur Fuzzy-Einträge anzuzeigen; diese sind farbcodiert (normalerweise orange), sodass sie sofort auffallen. Klicken Sie auf jeden einzelnen, bestätigen oder korrigieren Sie die Übersetzung und schalten Sie dann den Fuzzy-Status mit der Tastenkombination aus (Bearbeiten und dann „Übersetzung ist unscharf“ oder die im Menü angezeigte Verknüpfung). Wenn Sie speichern, kompiliert Poedit eine saubere .mo neu, und die nun bestätigten Strings werden auf Ihrer Website angezeigt. Wenn Sie neu in diesem Editor sind, behandelt der vollständige Poedit-Leitfaden den Filter- und Überprüfungs-Workflow detailliert.

Fuzzy-Strings auf der Befehlszeile beheben

Für die Automatisierung oder große Kataloge ist die Befehlszeile schneller. Sie können Fuzzy-Einträge zählen und, sobald Sie sie in großen Mengen überprüft haben, die Flags entfernen, damit WordPress sie laden kann.

# Count how many fuzzy strings remain
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po | grep -c "msgid"

# Clear all fuzzy flags (only after you trust the translations)
msgattrib --clear-fuzzy --empty awesome-plugin-de_DE.po \
  --output-file=awesome-plugin-de_DE.po

Seien Sie vorsichtig beim Massenlöschen. Das Entfernen von Fuzzy-Flags ohne Überprüfung der Übersetzungen untergräbt den Zweck des Flags und kann tatsächlich falschen Text an Ihre Benutzer senden. Verwenden Sie den Befehlszeilenansatz, wenn Sie der Quelle der Übersetzungen vertrauen, und den manuellen Poedit-Weg, wenn dies nicht der Fall ist.

Ein sicherer Mittelweg ist es, die Fuzzy-Strings in eine separate Datei zu exportieren, nur diese zu überprüfen und sie dann wieder zusammenzuführen. Dadurch bleiben Ihre bestätigten Übersetzungen unberührt, während Sie sich nur auf die Einträge konzentrieren, die tatsächlich Aufmerksamkeit benötigen.

# Extract only the fuzzy entries for focused review
msgattrib --only-fuzzy --no-obsolete awesome-plugin-de_DE.po \
  --output-file=fuzzy-only.po

Fünfzig isolierte Strings zu überprüfen ist weit weniger fehleranfällig als das Scrollen durch einen tausendzeiligen Katalog auf der Suche nach orangefarbenen Zeilen, und es gibt Ihnen eine saubere Aufzeichnung dessen, was sich im letzten Update genau geändert hat.

Nach dem Löschen der Flags immer die .mo-Datei neu speichern oder neu kompilieren. Der Fuzzy-Status befindet sich in der .po-Datei, aber WordPress liest die binäre .mo-Datei. Solange Sie diese also nicht neu generieren, wird Ihr Frontend weiterhin Englisch anzeigen, obwohl die .po-Datei sauber aussieht. Poedit kompiliert beim Speichern automatisch neu; auf der Befehlszeile führen Sie msgfmt awesome-plugin-de_DE.po -o awesome-plugin-de_DE.mo aus. Das Vergessen dieses letzten Kompilierungsschritts ist einer der häufigsten Gründe, warum ein frisch ent-fuzzierter Katalog immer noch nicht angezeigt wird: Die Übersetzung ist in der Quelldatei bestätigt, aber die Binärdatei, die die Website tatsächlich lädt, ist veraltet.

Beachten Sie, dass Fuzzy-Einträge oft neben Plural-Strings erscheinen, wobei ein geänderter msgid_plural den gesamten Pluralblock als Fuzzy markieren kann. Wenn Ihr Fuzzy-Rückstand viele Zählungen und Mengen enthält, erklärt unser Leitfaden zu Gettext-Pluralen und komplexer Pluralisierung, warum diese Einträge bei Zusammenführungen besonders anfällig sind.

Den Fuzzy-Rückstand im großen Stil beseitigen

Ein einzelner Fuzzy-String ist eine Dreißig-Sekunden-Lösung. Ein Katalog mit vierhundert Fuzzy-Strings nach einem größeren Plugin-Update ist ein anderes Problem, und über ein Dutzend Sprachen hinweg wird es zu einem echten Engpass. Die Versuchung, die Flags ohne Überprüfung massenhaft zu löschen, ist genau der Weg, wie fehlerhafte Übersetzungen in die Produktion gelangen.

Eine sauberere Lösung besteht darin, die Fuzzy-Einträge frisch neu zu übersetzen, anstatt veraltete Übereinstimmungen abzusempeln. Wenn Sie einen Katalog durch SimplePoTranslate laufen lassen, erstellt die kontextbewusste KI eine aktuelle, bestätigte Übersetzung für jeden geänderten String. So entfernen Sie nicht nur ein Warn-Flag, sondern ersetzen unsichere Übereinstimmungen durch echte Übersetzungen. Syntax Locking hält jeden %s, %1$s, {count} und HTML-Tag während des Durchlaufs intakt, und Smart Batching verarbeitet große Kataloge nach dem Update in einem Arbeitsgang. Sie erhalten ein sauberes ZIP mit .po, .mo, .json, .php und .xliff, ohne verbleibenden Fuzzy-Rückstand, bereit zur Bereitstellung aus der Cloud.

Es lohnt sich, dies von der allgemeineren Frage zu unterscheiden, warum Übersetzungen überhaupt nicht angezeigt werden. Fuzzy-Flags sind eine spezifische Ursache, aber fehlende .mo-Dateien, falsche Dateinamen und Gebietsschema-Fehlpaarungen verursachen das gleiche Symptom. Für die vollständige Diagnose-Checkliste lesen Sie unseren Leitfaden zur Fehlerbehebung für nicht angezeigte Übersetzungen in WordPress, der Fuzzy-Strings als einen Punkt in einer größeren Liste behandelt.

Bereit, einen gesamten Fuzzy-Rückstand zu beseitigen und jeden String auf Ihrer Website anzuzeigen? Testen Sie SimplePoTranslate kostenlos – keine Kreditkarte erforderlich. Die kostenlose Stufe übersetzt Ihre .po-Datei neu und ersetzt unsichere Fuzzy-Übereinstimmungen durch saubere, bestätigte Übersetzungen.