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ädnlich 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.

function array_to_table($a){
	$t='<table>';
	$t.='<tr><th>'.implode('</th><th>', array_keys($a[0])).'</th></tr>';
	foreach($a as $row){
		$t.= '<tr><td>'.implode('</td><td>', $row).'</td></tr>';
	}
	return $t.='</table>';
}

// Ausgabe der Tabelle
echo array_to_table($mysqli->queries);