Localizing Plugins and Themes

Currently, plugins and themes cannot be localized because their strings are not in the default WP catalog. To remedy this, I added the ability for plugins and themes to load their own catalogs.

To localize a plugin, call load_plugin_textdomain() at the top of your plugin, passing it a string to identify the domain.

load_plugin_textdomain('myplugin');

load_plugin_textdomain() looks in the plugin directory for a file called $domain-$locale.mo where $domain is the textdomain specified in the call to load_plugin_textdomain() and $locale is the language and country code specified in WPLANG. If WPLANG is en_AU and the domain is “myplugin”, the file loaded is wp-content/plugins/myplugin-en_AU.mo.

Now, when you markup strings in your plugin, you must specify the domain in the calls to __() and _e().

__('String to translate.', 'myplugin');

With all strings marked in this manner, your plugin is ready for localization. You just need to generate a POT file and give it to translators.

Theme catalogs are loaded with load_theme_textdomain(). load_theme_textdomain() looks in the active theme directory for a file called $locale.mo. Strings are marked in the same way that plugin strings are marked.

In summary, load_plugin_textdomain() and load_theme_textdomain() load translation catalogs for plugins and themes, respectively. __() and _e() now take a second argument which specifies the catalog in which to lookup strings. You must specify a domain when loading catalogs and marking strings for plugins and themes.

I’ll start localizing the Kubrick theme for 1.3 sometime soon. Mustering the motivation to start such a tedious task is difficult.

12 thoughts on “Localizing Plugins and Themes

  1. […] Si vous êtes vous-même développeur d’un thème ou d’un greffon, n’hésitez pas à créer une installation test de WP 2.0 et à vérifier le bon fonctionnement de vos créations. Et puisque vous y êtes, n’hésitez pas à appliquer cet excellent conseil à vos thèmes s’ils font appel aux fonctions de greffons particuliers. De même, pourquoi pas rendre plus facile la traduction et l’internationalisation de vos produits? (Plus d’infos à ce sujet également sur l’ancien wiki WP). […]

    Like

  2. […] Das nächste, was ich vor der Überarbeitung von “Slatystain” unbedingt angehen will, ist die Internationalisierungs-Funktionen von WordPress. Nun, wie fängt man an? OK, einen Editor für die .po .mo und .pot Dateien runterladen und los gehts. Die nötigen WP-Template Tags, also _e(“schreib mich in deiner Sprache”); und __(“gib mich an php zurück”); sind schonmal die Vorraussetzung, dass WordPress überhaupt einmal einen zu übersetzenden Text findet und im WordPress-Codex genauer beschrieben. Aber darauf, dass ich bei der Erklärung zur load_plugin_textdomain(‘myplugin’); bzw der zugehörigen load_theme_textdomain(‘myplugin’); Funktion Durchblick bekam (zehnmal Lesen, sowie intensives bis aggressives Starren brachten mich nicht weiter) konnte ich dann doch nicht warten und hab mir kurzer Hand an das Referenz-Theme in Sachen Übersetzung und Flexibilität “Giraffe” rangewagt. Und siehe da: Es ist alles noch viel komplizierter als ich dachte…, was aber auch daran liegen könnte, dass dieses Theme einfach vielzu raffiniert geschrieben wurde und zudem auch noch mit einem kleinem Plugin versehen wurde mit dem man es im Admin-Bereich anpassen kann. Wie es aussieht steht da noch einiges an “Draufstarren” auf dem Programm… … aber immerhin verstehe ich nun schonmal die Funktionsweise und so sind schoneinmal zwei Übersetzungen entstanden: zum Einen eine deutsche Sprachdatei für das Giraffe-Theme. Download auf der Giraffe Theme-Seite von John Godley. […]

    Like

  3. […] Das nächste, was ich vor der Überarbeitung von “Slatystain” unbedingt angehen will, ist die Internationalisierungs-Funktionen von WordPress. Nun, wie fängt man an? OK, einen Editor für die .po .mo und .pot Dateien runterladen und los gehts. Die nötigen WP-Template Tags, also _e(“schreib mich in deiner Sprache”); und __(“gib mich an php zurück”); sind schonmal die Vorraussetzung, dass WordPress überhaupt einmal einen zu übersetzenden Text findet und im WordPress-Codex genauer beschrieben. Aber darauf, dass ich bei der Erklärung zur load_plugin_textdomain(‘myplugin’); bzw der zugehörigen load_theme_textdomain(‘myplugin’); Funktion Durchblick bekam (zehnmal Lesen, sowie intensives bis aggressives Starren brachten mich nicht weiter) konnte ich dann doch nicht warten und hab mir kurzer Hand an das Referenz-Theme in Sachen Übersetzung und Flexibilität “Giraffe” rangewagt. Und siehe da: Es ist alles noch viel komplizierter als ich dachte…, was aber auch daran liegen könnte, dass dieses Theme einfach vielzu raffiniert geschrieben wurde und zudem auch noch mit einem kleinem Plugin versehen wurde mit dem man es im Admin-Bereich anpassen kann. Wie es aussieht steht da noch einiges an “Draufstarren” auf dem Programm… … aber immerhin verstehe ich nun schonmal die Funktionsweise und so sind schoneinmal zwei Übersetzungen entstanden: zum Einen eine deutsche Sprachdatei für das Giraffe-Theme. Download auf der Giraffe Theme-Seite von John Godley. […]

    Like

  4. […] Als ich vor etwa einem Jahr die Veröffentlichung vom “Slatystain”-Theme im WordPress-Forum bekannt gab, wurde ich recht schnell darauf hingewiesen, dass es besser sei, die in WordPress integrierte gettext-Funktionalität zu nutzen. Einfach deshalb, weil man Themes auf diese Weise schnell in andere Sprachen übersetzen kann. Man präsentierte mir einen Link zu einem Post, 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 mit den Funktionen load_plugin_textdomain() und load_theme_textdomain() intensiver beschäftigt und komme zu einem anderen Schluss: Überall wo es möglich ist, sollte man vermeiden die Performance von WordPress auszubremsen. 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 sinnvoll sein, denn im Backend ist die Performance eher zweitrangig. Themes sind aber meist so ein Kandidat. 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 einem Design auf ein anderes, sporadische Besucher seiner Seite unnötig verwirrt. Außerdem erfordert die Funktion einen Serverseitigen Mehraufwand. 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 load_theme_textdomain Funktion an. Besser gesagt: man kommt nicht drumrum. 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. 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 , unter http://boren.nu/archives/2004/11/01/localizing-plugins-and-themes/ oder in deutsch hier: http://www.zyblog.de/2006/01/06/wordpress-themes-lokalisieren/ Leserkommentare Sei der erste & kommentiere diesen Artikel. // Einen Kommentar verfassenDeine E-Mail Adresse ist erforderlich (wird aber nicht öffentlich angezeigt) […]

    Like

Comments are closed.