Bernhard Kau hat mit Language Fallback ein neues WordPress Plugin im Repertoire mit dem man einfach eine zweite Sprache als Plan B festlegen kann, falls die eigentliche nicht verfügbar ist.
WordPress gibt es in sehr vielen Sprachen, so viel steht fest. Lokale Communities kümmern sich um die Übersetzung der Software und leisten damit eine großartige Arbeit innerhalb der WordPress Community. Seit ein paar Versionen kann man zudem bei der Installation die Sprache wählen und WordPress lädt automatisch die jeweilige Sprachdatei runter. Und hat man sich einmal falsch entschieden so kann man die Sprache auch bequem im Backend ändern.
Caspar hatte vor kurzem über Twitter verkündet, dass inzwischen sogar die Deutsch (Sie) Version im Backend auszuwählen sein. Das sind großartige Neuigkeiten. Allerdings gibt es mit der ganzen Thematik ein Problem und dem hat sich Bernhard Kau angenommen.
https://twitter.com/glueckpress/status/620866636384309249
Das Problem
Bernhard hat ein Problem erkannt, welches mit den Sprachen auftaucht. Die Frage die bleibt ist nämlich: Was passiert wenn die präferierte Sprache nicht verfügbar ist?
Über das Backend legt man zwar seine Standard-Sprache fest und WordPress lädt die Sprachdatei für den Core herunter, aber Themes und Plugins bieten ihre eigenen Sprachdateien an und wenn WordPress für das entsprechende Plugin oder Theme keine Datei für diese Sprache findet, dann fällt es zurück ins Englische.
Dies ist oftmals nicht der ideale Weg.
Die Lösung
Hat man zum Beispiel als Sprache Deutsch (Sie) ausgewählt ist die Wahrscheinlichkeit sehr hoch, dass ein Plugin / Theme diese Sprachdatei nicht vorrätig hat. Eine Deutsche Sprachdatei, also informelles Deutsch, ist allerdings oftmals vorhanden. Somit wäre es schlauer, erst nach der informellen Sprachdatei zu suchen bevor WordPress am Schluss Englisch als Sprache wählt.
Mit Language Fallback (GitHub) hat Bernhard genau dieses Problem gelöst. Mit der Aktivierung des Plugins kann man unter Einstellung > Allgemeineine Einstellung für den Fallback vornehmen.
Derzeit ist es nur möglich eine Sprache als Fallback festzulegen. Im Plugin kann man allerdings einen Filter finden mit dem man die Funktionalität etwas erweitern kann.
Über den Filter fallback_locale kann man zum Beispiel ein Array mit mehreren Locales festlegen, die das Plugin nacheinander ausprobiert. Somit ist es möglich eine ganze Kette von Fallbacks festzulegen. Wäre zum Beispiel de_CH_formal (Deutsch (Schweiz) (Sie)) als Standardsprache festgelegt, so könnte man als Fallback folgende Kette festlegen:
de_CH_formal -> de_DE_formal -> de_CH -> de_DE -> en_US
<?php
/**
* Einfache Function um eine Kette von Fallbacks festzulegen
*
* @param $locales array mit den Fallback locales
* @param $domain textdomain nach der gerade gesucht wird
* @param $locale standard locale, vom User festgelegt
* @return $locales
*/
function fallback_chain( $locales, $domain, $locale ) {
$locales = array();
array_push( $locales, 'de_CH_formal' );
array_push( $locales, 'de_DE_formal' );
array_push( $locales, 'de_CH' );
array_push( $locales, 'de_DE' );
return $locales;
}
add_filter( 'fallback_locale', 'fallback_chain', 10, 3 );
Ich habe das mit der aktuellen Version 1.0.3 versucht, allerdings habe ich da noch einen Bug gefunden. Sobald das Problem behoben ist sollte der obige Code auch funktionieren wie gedacht.
Update 10. Aug. 10:56: Mein Pull Request wurde gemerged und sollte mit der nächsten Version für alle verfügbar sein.
Eine Einstellung über die GUI ist dafür allerdings noch nicht verfügbar. Dies wird aber sicherlich auch noch in naher Zukunft passieren.
Der zweite Hook load_textdomain_mofile, der dieses Plugin erst möglich macht und ein Hook vom WordPress Core ist, lässt den Pfad zur ursprünglichen .mo Datei ändern und somit auf eine andere Sprachdatei verweisen. Damit könnte man eigene Sprachdateien mit teilweise anderen Übersetzungen verwenden.
Fazit
Das Plugin ist zwar nicht groß, aber es bietet einen gewaltigen Mehrwert wenn man mit Sprachen hantiert, die nicht gerade zu den meist übersetzen Sprachen gehören. Damit kann man sicherstellen, dass der Kunde / User notfalls eine andere Sprachedatei angeboten bekommt mit der er mehr anfangen kann als mit Englisch.
Ah super! Vor allem hatte ich mich nach der Textdomain für formales Deutsch gefragt. Nicht das ich schon begonnen hätte zu recherchieren, aber das muss ich jetzt ja auch nicht mehr 😀 Danke für den Post und die Info 🙂
Prima Artikel, vielen Dank!
> Somit wäre es schlauer, erst nach der informellen Sprachdatei zu suchen bevor WordPress am Schluss Englisch als Sprache wählt.
An dieser Stelle würde ich mir mehr Hintergrund wünschen. Momentan hört sich das so an, als wäre jemand im Core-Team einfach nicht schlau genug gewesen, ein „richtiges“ Fallback umzusetzen. Hinter der Core-Lösung steckt aber ein durchdachtes und logisch schlüssiges Konzept. Dessen kurze Erläuterung darf in einem Tutorial wie diesem eigentlich nicht fehlen, finde ich.
Kannst du da einen Einblick geben. Ich habe da keine genauen Infos und für mich als „Enduser“ kommt es halt leider so vor. Vielleicht kannst du das relativieren 🙂
Musste auch erst suchen, aber hier fing’s wohl an. TL;DR im Ticket dazu.
Ist ein komplexes Thema; wie so häufig, wenn es um Sprache geht, geht es impliziert auch um Kultur oder sogar Politik. In unserem de_DE-Kontext ist ein Fallback zur (einzigen) informellen Version vielleicht sinnvoller als zu Englisch; aber wie sieht es z.B. in der Schweiz aus? Ein Fallback von de_CH_formal zu de_DE_formal wäre sicher sinnvoller, als zu de_CH.
Nicht zuletzt es gibt auch Sprachen, in denen ist die formelle Version gleich eine ganz andere Sprache. Für Papiamentu z.B. könnte, soviel ich weiß, also formelle Version, je nach Kontext und Karibikinsel, Niederländisch oder Englisch herangezogen werden.
Langen Kommentar geschrieben und dann durch Hinweis gemerkt, dass ich deinen Satz komplett aus dem Kontext gerissen hatte. :/ Sorry, alles gut, Ergänzung nicht notwendig.