Als ich vor etwa einem Jahr die Veröffentlichung vom “Slatystain”-Theme im englischen WordPress-Forum bekannt gab, wurde ich recht schnell darauf hingewiesen, dass es besser sei, die in WordPress integrierte gettext-Funktionalität zu nutzen. Dabei geht es kurz gesagt darum, dass es mit einer speziellen Schreibweise möglich ist Textpassagen so zu hinterlegen, dass WordPress sie erkennen kann. Nun benötigt WordPress nur noch eine Sprachdatei im .mo-Format für das jeweilige Theme und ein Sprachkürzel in der Datei wp-config.php, mit dem man die bevorzugte Sprache seines Weblogs festlegt. Der Vorteil liegt auf der Hand: wiederkehrende Elemente eines Themes werden auf diese Weise schnell in die bevorzugte Sprache des Bloggers übersetzt.
Man präsentierte mir einen Link zu einem Artikel, doch was ich dort fand, hab ich entweder nicht verstanden, oder ich war einfach zu faul alle Theme-Dateien nocheinmal durchzugehen… ;)
Inzwischen habe ich mich also mit den Funktionen load_plugin_textdomain() und load_theme_textdomain() intensiver beschäftigt. Nach der Einarbeitung in PoEdit und die WordPress-Funktion hielt ich das zunächst für eine tolle Sache, und für Plugins mag es auch eine sinnvolle Sache sein, denn im Backend ist die Performance eher zweitrangig. Mittlerweile komme ich aber zu einem anderen Schluss: Diese “Localizing”-Funktion ist ein Baustein von vielen, die deinen WordPress-Weblog langsam machen. Wenn man bereits wegen einer vielzahl installierter Plugins (manchmal reicht schon ein schlecht geschriebenes Plugin, um die Datenbank-Queries in die Höhe zu treiben) lange Ladezeiten hat, wird einem der Verzicht auf diese Funktion nicht merklich helfen und man sollte sich schon radikalere Schritte überlegen (benötigt man wirklich all die tollen Plugins?)… Doch wer optimieren will, für den lohnt sich ein Blick in die Theme-Dateien seines Designs. Überall wo es möglich ist, sollte man vermeiden die Performance von WordPress unnötig auszubremsen. Selbst die eingedeutschte Version von WordPress vom WordPress.de-Team kommt mit einem hardgecodeten Kubrik daher. Zuerst dachte ich, dass dies daran liegt, dass die Funktionen load_theme & load_plugin_textdomain recht unbekannt sind, doch da lag ich falsch.
Zum Einen sollte man sich bewußt machen, dass man mit dem regelmäßigen Wechsel von seinem Blog-Design auf ein anderes, sporadische Besucher seiner Seite unnötig verwirrt. Hat man sich also für ein Design entschieden oder sich eines selbst geschrieben sollte man sich fragen ob man diese “Multilingual”-Funktion tatsächlich benötigt. Mein Hauptargument gegen diese Funktion in Themes ist, dass sie einen Serverseitigen Mehraufwandverursacht, weshalb ich hier nun nach einigen gegenteiligen Tönen von der Verwendung abraten will. Auch das WordPress-Deutschland Team scheint sich der Nachteile bewußt zu sein, was, denke ich, Grund für das hardgecodete Kubrik-Design ist.
WordPress hat sicher größere Schwachstellen in Sachen Performance, sei es das mit PHP bewerkstelligte Umschreiben der URL (mod_rewriting genannt) oder seine übermäßigen Datenbank-Queries, doch in den meisten Fällen wird man seinen Blog einfach nur dazu verwenden über Gott & die Welt zu schreiben und das Design eher selten wechseln.
Die Funktion kommt also selten zum Einsatz und dient in erster Linie dazu dass Blogger verschiedener Nationalität ein Theme nutzen können. Ich empfehle lieber das Anpassen an die eigenen Bedürfnisse (sei es in Sachen Design wie auch der Sprache).
Anders sieht es mit Seiten aus, deren Zielgruppe international beschaffen ist: Hier müssen Beiträge sowohl in mehreren Sprachen verfasst werden und auch die wiederkehrenden Elemente eines Designs sollten dem Besucher verständlich sein.
Die Besucher werden mit Sicherheit auch Ihre eigene Sprache auswählen, sofern man Ihnen diese Option denn anbieten will.
Auch in diesem Fall wird WordPress es einem danken wenn man geschickt die Ressourcen seines Servers schont und hardgecodete (also händisch an die jeweilige Sprache angepasste) Themes anstelle der load_theme_textdomain() Funktion verwendet.
Die Mehrsprachigkeit erreicht man trotzdem, indem man einen Theme-Switcher verwendet. Der Ansatz dabei ist der, dass man mehrere Lokalisationen ein und desselben Themes installiert, die Themes in der style.css umbenennt in zB: “deutsch” und “english” und dann dem Besucher per Theme-Switcher die Option der Sprachwahl bietet. Dabei sollte man lediglich beachten dass man ein international verständliches Datumsformat verwendet.
Einzig in dem Fall, wenn die Autoren des Weblogs/Webseite aus verschiedenen Sprachbereichen kommen bietet sich die gettext-Funktion an. Besser gesagt: man kommt nicht drumrum. Aber auch hier ist es in Sachen Performance cleverer diese nur im Backend zu verwenden. Eine von John Godley beschriebene Herangehensweise ermöglicht es, die gesamten Spracheinstellungen von WordPress mit einem Mausklick zu ändern. Und das sowohl im Frontend wie auch im Backend, was auch das Verwalten oder Editieren der Seite / Beiträgen enorm vereinfachen dürfte. Damit das funktioniert braucht man natürlich die entsprechenden Sprachdateien.
Eine kleine Verbesserung seines Code-Schnipsels gibt es sowohl als Kommentar in seinem Beitrag oder in deutscher Sprache im WordPress.de-Forum. Der Trick dabei ist, die jeweilige Namen der setlocale an die Datei wp-config.php zu übergeben. Genial simpel und schon ist der komplette Weblog in einer anderen Sprache. Meine Modifizierung besteht lediglich in einem Redirect zur Seite auf der der Besucher die Sprachauswahl getroffen hat. Somit geschieht der Sprachwechsel etwas eleganter.
Aber wie gesagt: Wenn man ein schönes Design gefunden das man für seinen einsprachigen Weblog verwenden will, es aber zB. in Englisch ist, sollte man es lieber im Editor seiner Wahl übersetzen. WordPress auch so schon langsam genug. Wenn man sich sicher ist, dass es unbedingt diese Funktionen sein müssen (zB weil es um ein Plugin, nicht aber um ein Theme handelt) findet man weitere Informationen zu deren Handhabung unter
- http://codex.wordpress.org/Localizing_WordPress (englisch)
- http://boren.nu/archives/2004/11/01/localizing-plugins-and-themes/
- oder auf deutsch: http://www.zyblog.de/2006/01/06/wordpress-themes-lokalisieren/
Mein Fazit: Localizing Plugins ist ne feine Sache - Localizing Themes sollte man ohne die load_theme_textdomain-Funktion machen.
Schlagworte: Code, multilingual, WordPress
Hm… grundsätzlich eine richtige Idee und bei meinem eigenen Weblog code ich sowieso alles von Hand. Wenn man allerdings ein Theme für ein breiteres Publikum bereitstellen will, zählen neben der Performance (die u.U. durch load_theme_textdomain() auch nicht sooo dramatisch abfällt) auch andere Faktoren, wie z.B. eine leichte Installation und ein möglichst unkomplizierter Aufbau der Dateistruktur.
Mein Relaxation-Theme gibt es mittlerweile in 5 Sprachen, weil das Bearbeiten der .po-Dateien offensichtlich recht simpel ist. Würde ich hardcodierte Dateien bereitstellen, wäre es zweifelhaft, ob sich Franzosen oder Italiener näher mit einer pseudo-multilingualen Version beschäftigen würden. ;-) Auch das zwingend notwendige Installieren eines Theme-Switchers ist möglicherweise nicht jedermanns Sache.
Optimal ist die von Dir beschriebene Variante für jeden, der sich selbst ein Theme schreibt oder eines anpaßt. Dann einfach alles in den Quellcode rein, so wie man es haben möchte. :-)
Genau aus dem Grund wurde mir ja auch diese Funktion nahegelegt. Jeder, der schon das lokalisierte Theme hat, braucht nur noch ne Sprachdatei und alles passt. Fertig.
Ich versteh nur nicht recht, warum Sie das dann noch sollten? Das man sich mit dem Lokalisieren beschäftigt oder beschäftigen muss, rührt ja doch daher, dass es eben nicht Usus ist, Themes von Beginn an mehrsprachig bereitzustellen - was ja auch keiner verlangt oder erwartet. Ich möchte lediglich den Hinweis geben, dass es die Mühe nicht wert ist load_theme_textdomain extra in ein Theme einzubauen, weil dies halt oft unnötig die Serverressourcen beansprucht.
Falsch. Meine Aussage ist der Wahrheit letzter Schluss ;), Naja im ernst: Nur Weblogs, die eben diese erwähnte Multilingualität aufwiesen, also mehrsprachig sind profitieren von der Funktion. Alle anderen quälen nur Ihren Server.
Meiner Meinung nach sollte man die Sprachdateien lediglich zum generieren der Themedateien verwenden, nicht aber im Weblog einsetzen.
Bitte? Das habe ich nirgends behauptet. Weder zum Lokalisieren ist der Theme switcher nötig, noch im Spezialfall „multilingualer Weblog“ wo meine Empfehlung tatsächlich einen Theme-Switcher vorsieht (Begründung siehe oben), aber auch klar auf die „normale“ Variante hinweise. Letzten Endes bleibt das ja jedem selbst überlassen. Was spricht denn deiner Meinung nach gegen die Theme-Switcher Umsetzung?
Ich selbst nutze in meinen Theme dKret2 Gettext und bin überzeugt, dass Performancegründe eine untergeordnete Rolle spielen. Der große Vorteil einer externen Sprachdatei ist, dass Fehler eines Themes schnell beseitigt werden können, ohne dass Dritte ihre Sprachdateien aktualisieren müssen. Außerdem kann so jeder seine Seite entsprechend der Zielgruppe “sprechen” lassen (Sie/du usw.)
Aber klar doch, jedem sein Progrämmchen. PoEdit ist halt einfach zu bedienen. Die Unterschiede in der Performance gibt es aber (vgl. zB. diesen Benchmark) weshalb ich den Editor vorziehe. Eine Datei ausgeben ist halt nunmal schneller als aus zwei Dateien eine zu generieren. Bin ich zumindest von überzeugt ;) Da WordPress die langsamste der im Benchmark verglichenen Varianten verwendet (die damit aber auch wieder unabhängig von der korrekten Server-Konfiguration ist) funzt sie halt auch ohne Provider-Support und passt zur einfachen Weblog-Theme Installation.
Ist ja nur meine subjektive Meinung, und muss nicht überall richtig sein (gerade Blogdesigns sollen unkompliziert funktionieren). Ein Kunde, für den aber sowieso viele individuelle Vorgaben umgesetzt werden müssten, die Seite CMS-Charakter bekommt (also ohne Blogtypische Dinge wie Trackback/Kommentare/Pings, etc.) auskommt, sollte man schon auch Fokus auf Vitesse legen. Da ist gettext’n/hartkodieren ja auch nur ein Aspekt, auf den ich aufmerksam machen wollte. Für Blogs benötigt man ja ohnehin selten Mehrsprachigkeit. (und wenn gibts dafür zB. Gengo). Im Punkt “Markup ändern, Sprachdatei beibehalten” geb ich mich geschlagen ;) das ist tatsächlich dufte :)