WordPress Core Strings ohne Verlust beim nächsten Update überschreiben

Auf dem letzten WP Meetup Potsdam hat Caspar eine kleine Einführung in das Thema Multisite gegeben. Dabei päsentierte er auch kurz das Einrichten eines neuen Blogs im Netzwerk. Als er sich im Dashboard angemeldet hatte wies er uns auch darauf hin, dass er die Bezeichnung „Dashboard“ in „Übersicht“ umbenannt hat, da dies wohl für einige Kunden besser verständlich ist.

Der falsche Weg

Auf die Nachfrage, wie er es denn umbenannt hätte, musste er dann zugeben, dass er die originale Datei überschrieben hat. Oder er hatte sie komplett kopiert und dann den einen String geändert, das weiß ich nicht mehr so genau. Aber auf jeden Fall waren wir uns alle einige, dass dies eine sehr schlechte Lösung des Problems ist. Spätestens beim nächsten großen Update, wie z.B. bald auf Version 3.4, wird auch die Übersetzungsdatei wohl wieder überschrieben werden müssen. Alle geänderten Übersetzungen sind somit verloren und müssen erneut überschrieben werden. Ich war mit aber sehr sicher, dass es dafür eine bessere Lösung gibt.

Der richtige Weg

Vor einiger Zeit habe ich dem Artikel Lokalisierung für Child Themes am Beispiel von Thematic beschrieben, wie man in einem Child-Theme die Übersetzungen für Strings im Parent Theme überschreiben kann. Ich war mir sehr sicher, dass dies auch für die WordPress Core Strings funktionieren muss. Bei Core-Übersetzungen wird ja in den Übersetzungsfunktionen keine Domain angegeben. Daher war die erste Vermutung, dass man einfach einen leeren String für das Einbinden der Übersetzungsdatei verwenden muss. Aber das war nicht ganz korrekt. Man muss den String „default“ als Parameter verwenden. Damit ist es dann möglich, eine eigene Übersetzungsdatei zu laden. In dieser Datei müssen aber nicht alle Strings enthalten sein. Es reicht aus, wenn man nur die zu überschreibenden aufführt. Die Einbindung dieser mo-Datei geschieht dann wie folgt:

load_textdomain( 'default', dirname( __FILE__ ).'/'.get_locale().'.mo' );

In diesem Beispiel befindet sich dann z.B: die Datei de_DE.mo im selben Verzeichnis wie die Datei, in die diese Zeile eingefügt wurde. Dies kann in eurem Theme aber auch in einem Plugin geschehen. Im Falle von Capsar ist es sogar am sinnvollsten, das ganze als „must-use“ Plugin im Ordner /wp-contents/mu-plugins/ abzulegen. Ich habe das ganze natürlich auch mal für euch fertig vorbereitet und ihr könnt es hier herunterladen und einfach als Plugin installieren:

Download

Fazit

Auch hier hat sich wieder gezeigt, wie flexibel WordPress ist. Auch mein Grundsatz „Don’t hack the core, never!“ (auf Deutsch würde man wohl sagen „Nur gucken, nicht anfassen!“) wurde dadurch mal wieder bestätigt. Ich habe bisher wirklich noch kein Problem gefunden, dass ich nicht durch ein paar Zeilen Code in der functions.php Datei oder durch ein kleines Plugin lösen konnte, ohne den Core anfassen zu müssen. Das einizige, was einem hier noch passieren könnte ist eine Änderung des zu übersetzenden Strings in einer neuen Version. Dann müsste natürlich auch die Übersetzungsdatei angepasst werden. Aber eben auch nur die wenigen Strings darin und auch nur die, die sich geändert haben.

Was haltet ihr von meiner Lösung? Hättet ihr gedacht, dass so etwas mit nur einer Zeile Code möglich ist? Habt ihr vielleicht auch ähnlich tolle Fixes parat? Über Kommentare würde ich mich wie immer sehr freuen.

Nachtrag:

Ich habe mal ein allgemeines Plugin geschrieben, mit dem man über eine einfache Ordnerstruktur die Sprachdateien des Cores, sowie von Plugins und Themes überschreiben kann. Das Plugin findet ihr bei Github unter dem Namen „textdomain-overwrite“. Dort wird auch beschrieben, wie die Ordnerstruktur aussehen muss.

Veröffentlicht von

Bernhard ist fest angestellter Webentwickler, entwickelt in seiner Freizeit Plugins, schreibt in seinem Blog über WordPress und andere Themen, treibt sich gerne bei den WP Meetups in Berlin und Potsdam herum und läuft nach Feierabend den ein oder anderen Halbmarathon.

14 Kommentare » Schreibe einen Kommentar

  1. Danke für den sehr nützlichen Tipp! Zur Rettung meiner Ehre muss ich sagen: ich habe selbstverständlich keine Core-Datei überschrieben! 😉 Bei mir sieht’s so aus:

    function backend_custom_translations_de_DE( $text ) {    
    $words = array( 'Dashboard' => 'Übersicht' );    
    return str_replace( array_keys( $words ), $words, $text );
}
add_filter('gettext', 'backend_custom_translations_de_DE', 10, 4);
add_filter('ngettext', 'backend_custom_translations_de_DE', 10, 4);

    Allerdings ist meine Lösung trotzdem weniger schlau, weil eben nur der String „Dashboard“ gefiltert wird, völlig unabhängig von den dazugehörigen bestimmten oder unbestimmten Artikeln. So liest man dann manchmal „das Übersicht“. Das lässt sich mit deiner Einbindung einer komplett eigenen Übersetzungsdatei natürlich gut beheben.

    • Hey, den Filter „gettext“ kannte ich ja noch garnicht. Der kann unter Umständen schon mal helfen. Aber ich denke mit meiner Lösung funktioniert das auch alles ohne diesen Trick.

      Zur Verbesserung deiner Funktion hättest du natürlich auch Reguläre Ausdrücke verwenden können, um nur genau den String „Dashboard“, nicht aber Strings, mit dem Begriff „Dashboard“ zu überschreiben. Aber ich poste hier jetzt mal keine bessere Lösung, sonst kommt noch jemand auf die Idee, diese auch zu verwenden, statt sauber eine Übersetzungsdatei zu verwenden 😉

  2. Hi Bernhard,

    As WordPress is made in Texas, all core strings are written in American English. If I need my website to display text in American English, but want to change some of the strings, what do I need to do then without changing the core?

    Or can I use ‚default-en_US.mo‘ with your textdomain-overwrite plugin?

    Kind regards,

    Willem-Siebe Spoelstra

  3. Hey Bernhard,
    nochmal eine Frage für Blöde. Hab´ jetzt dein plugin installiert und die Datei de_DE.mo in default-de_DE.mo neu abgespeichert und in das gleiche Verzeichnis geladen. wp-content/languages/

    Was muss ich jetzt in deinem plugin genau abändern, damit er die default-de_DE.mo Datei verwendet? Kriege das irgendwie nicht hin. Danke für Deine Hilfe. Bin da jetzt schon seit 2 Tagen am rumprobieren.
    Viele Grüße aus Hamburg.
    Uli

  5. Hallo Bernhard,

    bevor ich probiere, frag ich lieber: wie verhält sich Dein äußerst nützliches Plugin im Multisite-Modus?

    Danke und Gruß,

    Volker

    • Hallo Volker,

      auch in einer Multisite funktioniert es. Ein Feature, dass ich allerdings noch nachreichen möchte, ist die Steuerung von unterschiedlichen Übersetzungen pro Seite einer Multisite. Das ist aber nicht ganz so einfach. Wenn ich dazu aber eine Lösung gefunden habe, dann stelle ich es wohl ins Plugin-Verzeichnis.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert