Code Styling Project

Sehr lange Zeit beschäftige ich mich nun mit der Lokalisierung von WordPress. Deshalb habe ich auch mein Lokalisierungs-Plugin erweitert und an den neuen Sprachdateifunktionen von WordPress angepasst. Allerdings wurde mit der Version 2.8 nicht nur die Standard Textdomain benutzt sondern eine neue Textdomain für die Zeitzonen Namen, Länder und Orte eingeführt. Dies habe ich zum Anlass genommen, ein revolutionäres, neues Konzept im Sprachdatei-Plugin einzuführen: die automatische Trennung verschiedener Textdomains.

Hintergründe der Entwicklung

Alle mir bekannten gettext Tools, die Dateien scannen können, nehmen keine Rücksicht darauf, zu welcher Textdomain der entsprechende Aufruf gehört. Dies hatte mich schon immer in Plugins und Themes gestört, weil man dort Texte mit in die Datei bekommt, die eigentlich aus dem WordPress Hauptfile kommen und nicht nochmal “mitgeschleppt” oder übersetzt werden müssen.
Umso mehr hat mich bei der Version 2.8 von WordPress gestört, dass die neue Textdomain, die für Ländernamen, Orte und Zeitzonen integriert wurde, normal mit in der Hauptdatei erscheint aber als separate Datei geladen werden muß. Wir reden hier über mehr als 480 Strings, die samt ihrer Übersetzung die Sprachdatei gehörig aufblähen.
Deshalb hatte ich mich entschlossen, einen Weg zu finden, in einer *.po Datei mehrere Textdomains vermerken zu können und diese auch getrennt als *.mo Dateien erzeugen zu lassen.

Die ist nun möglich und nur ab der neuen Version 1.90 meines Plugins machbar.

Wie wirkt sich das auf die *.po Datei aus ?

Ich habe mich an den Standard der PO-Spezifikation gehalten jedoch ein neues Header Feld und einen neuen Kommentartyp eingeführt, der dies möglich macht. Hier ein Beispiel aus dem Demoplugin, das später in diesem Beitrag erläutert wird. Im Kopf befindet sich der zusätzliche Parameter X-Textdomain-Support und je nach Eintrag wird ein Kommentar zusätzlich mittels #@ angelegt, der die Textdomain(s) beschreibt.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

msgid ""
msgstr ""
"Project-Id-Version: HowTo - Multiple Textdomain Showcase v1.0\n"
"PO-Revision-Date: 2009-07-05 22:04+0200\n"
"Last-Translator: codestyling <info@code-styling.de>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n != 1;\n"
"X-Poedit-Language: German\n"
"X-Poedit-Country: GERMANY\n"
"X-Poedit-SourceCharset: utf-8\n"
"X-Poedit-KeywordsList: __;_e;__ngettext:1,2;_n:1,2;__ngettext_noop:1,2;_n_noop:1,2;_c,_nc:4c,1,2;_x:1,2c;_nx:4c,1,2;_nx_noop:4c,1,2;\n"
"X-Poedit-Basepath: ../\n"
"X-Poedit-SearchPath-0: .\n"
"X-Textdomain-Support: yes"
 
#: howto-multiple-textdomains.php:62
#@ hmt-backend
msgid "Howto Multiple Textdomains"
msgstr "Wie benutzt man mehrere Textdomains"

Was hat ein Plugin-Entwickler davon?

Einerseits kann man jetzt als Plugin-Entwickler endlich so oft man möchte auf die WordPress Sprachdatei zurückgreifen, ohne das die Texte in der Plugin Sprachdatei landen. Andererseits kann man mit diesem Konzept auch eine perfekte Trennung zwischen Front- und Backendsprachdatei betreiben. Das dieses eine sehr vernünftige Herangehensweise ist, zeigt sich z.B. an einigen Mailinglist Plugins, die selbst mehr als 500 Strings in der Sprachdatei haben, davon aber höchstens 10 im Frontend jemals zu sehen sein werden. Warum also nicht sauber trennen, denn der Speicher und die Geschwindigkeit der Seite wird es in Frontend Bereich danken.

Wo sind die Schattenseiten davon?

Die Nachteile dieser Lösung bestehen im Wesentlichen nur darin, dass der Parser die Textdomains natürlich erkennen können muss. Leider ist das nur möglich, wenn sie direkt als Strings angeben werden. Derzeit gibt es keinen einfachen und schnellen Weg, das mit Konstanten oder Klassen-Membern hinzubekommen.

1
2
3
4

define('TEXTDOMAIN_2', 'textdomain-2');
_e('Text 1', 'text-domain'); //funktioniert bestens
_e('Text 2', TEXTDOMAIN_2); //funktioniert nicht! würde mit höllisch viel Analysezeit auf zu finden sein
_e('Text 3', $this->l10n->textdomain); //funktioniert gar nicht

Das Lokalisierungsplugins benutzt dann die Standardtextdomain des Plugins/Themes, wenn es den Parameter nicht interpretieren kann.

Ein Demo-Plugin zum Verständnis samt Download

Damit das alles nicht nur reine Theorie ist, habe ich ein Demo-Plugin geschrieben, anhand dessen man sich das in Ruhe ansehen kann. Hauptzweck des Plugins ist, vor jeden blockquote automatisch einen einleitenden Text davorzusetzen (übersetzbar per Sprachdatei), ohne dass man dafür etwas machen muß. Das Ergebnis:

Das Plugin hat auch eine Admin Seite zu Demo-Zwecken, auf der ebenfalls übersetzbare Texte enthalten sind.

Beide Ansichten (Backend und Frontend) befinden sich in unterschiedlichen Sprachdateien und werden nur im Bedarfsfalle geladen. Damit erspart man sich im Frontend eine Menge “verschwendeten” Speichers wegen der unnötigen Backend-Strings und erhöht auch die Geschwindigkeit der Ausgabe.
Im Backend wiederum sind die Frontend-Strings unnötig und werden dort nicht geladen, stattdessen die Backend-Sprachdatei.

Im Editor des Lokalisierungsplugins würde das mit dem im Download befindlichen Demo-Plugins so aussehen:

Somit kann man also gezielt pro Textdomain eine eigene Sprachdatei (*.mo) erstellen lassen, obwohl alle Texte in einer einzigen Vorlage (*.po) enthalten sind. Ebenfalls sind so gleich auch die Teile aus der WordPress Hauptdatei mit einer eigenen Textdomain vertreten (sofern enthalten) und müssen gar nicht erst als Datei erstellt werden oder gar die Sprachdatei des Plugins belasten.

Download des Beispiel-Plugins

Ich habe soweit wie möglich den Code wieder auf englisch kommentiert und ebenfalls die Sprachdateien in Deutsch beigelegt. Ebenfalls enthalten ist eine Sprachdatei in en_US, die nur das Frontend betrifft, um zu demonstrieren, dass man auch die vorgegebenen Texte in englisch jederzeit “überladen” kann, wenn sie einem nicht gefallen.

aktueller Download: howto-multiple-textdomains.zip (76 downloads)

Ich hoffe, diese Möglichkeit bietet auch für euch einen Mehrwert, sie kann ebenfalls in Themes eingesetzt werden. Dort könnte man auf die gleiche Weise reine Backend Texte von den Frontend-Texten mit 2 verschiedenen Dateien machen. Allerdings muss man die Themedatei dann per load_theme_textdomain und die Backend Datei direkt mit load_textdomain laden lassen.

Ich bin gespannt auf euer Feedback dazu.