Code Styling Project

Ich befasse mich nun schon eine Weile mit WordPress und den Lokalisierungsmöglichkeiten. Weil nun auch mein Lokalisierungsplugin einige Beliebtheit genießt, teste ich dieses auch mit den aktuellen Entwicklerversionen. Dabei stellte sich jedoch heraus, daß ein größerer Umbau in der Verarbeitung von Sprachdateien stattfindet. Es wird nicht nur die in WordPress benutzte Klassenstruktur neu geschrieben sondern auch Funktionen hinzugenommen aber auch einige als veraltet deklariert. Was das bedeutet und nach sich zieht, versuche ich kurz zu erläutern.

neue Klassenstrukturen

Ab WordPress 2.8 wird es einen neuen Unterordner in wp-includes geben, der auf den Namen pomo getauft wurde. Hier wird man in Zukunft alle Dateien finden können, die etwas mit der Behandlung der Sprachdateien zu tun haben. Die bereits bekannte streams.php (bekannt durch ein paar unschöne Abstürze) und deren Klassen werden gerade von Grund auf neu geschrieben.
An und für sich eine gute Sache, wenn man nicht schon wieder die gleichen Fehler einbauen würden, wie sie von mir in der derzeitigen Version gefixed wurden. Es wird so, wie es jetzt ist, durch mb_string overload Konfigurationen bei manchen Hostern wieder mal abstürzen (Ticket #5599). Mal sehen, ob ich wieder eingreifen muß …

Durch zusätzliche Klassen für das Lesen von *.mo und *.po Files bekommt das Ganze endlich ein wenig Kontur und kann dann evtl. auch mal anderweitig verwendet werden.

Übersetzungsfunktionen

Welch eine Überraschung, es kommen nicht nur neue Funktionen hinzu sondern es werden gleich mal ein paar bekannte Funktionen als veraltet erklärt. Die in der l10n.php deklarierten Funktionen im Einzelnen:

Funktion: __()

Diese Funktion wird beibehalten und arbeitet so wie bisher auch.

Funktion: _e()

Diese Funktion wird beibehalten und arbeitet so wie bisher auch.

Funktion: _c()

Diese Funktion wird beibehalten und arbeitet so wie bisher auch.

Funktion: __ngettext()

Die Pluralisierungsfunktion wird als _deprecated_function( __FUNCTION__, ‘2.8′, ‘_n()’ ); eingestuft und durch die Schreibweise _n() ersetzt. Man kann sie zwar noch aufrufen aber sie wird mit 2.9 vermutlich ausgebaut sein.

Funktion: __ngettext_noop()

Auch diese nicht so bekannte Pluralisierungsfunktion wird als _deprecated_function( __FUNCTION__, ‘2.8′, ‘_n_noop()’ ); eingestuft und durch die Schreibweise _n_noop() ersetzt. Man kann sie zwar noch aufrufen aber sie wird mit 2.9 vermutlich ausgebaut sein.

Kommen wir nun zu den Überraschungen, den weiteren ganz frisch eingeführten Funktionen:

Funktion: _x()

Diese Funktionen hat ein ähnliches Verhalten wie die Funktion _c(), sie wird für Kontext bezogene Ausgaben benötigt. Es folgen hier mal die beiden Funktionssignaturen aus der Entwicklerversion:

1
2

function _c($text, $domain = 'default')
function _x( $single, $context, $domain = 'default' )

Der eigentliche Unterschied besteht darin, das der Kontext nicht mehr im Text selbst enthalten ist sondern als gesonderter Parameter angegeben werden kann. Um dies zu verdeutlichen, hier mal an exemplarischen Aufrufen:

1
2
3

echo _c('Auto|vehicle', 'textdomain');
echo _x('Auto', 'vehicle', 'textdomain');
 

Dies hat aber auch Auswirkungen auf die Vorlage der Sprachdatei (*.po) Datei, denn dort wird das dann so aussehen:

1
2
3

msgctxt "vehicle"
msgid "Auto"
msgstr "Fahrzeug"

Die meisten Übersetzungstools verstehen und verarbeiten dies korrekt, auch PoEdit. Allerdings zeigt PoEdit diese Art der Kontexte nirgendwo an, das sollten die Übersetzer beachten!

Funktion:_nx()

Dies ist ebenfalls einen Erweiterung von _n() (oder bisher __ngettext()) und ermöglicht eine Kontext bezogene Übersetzung in der Pluralisierung. Die zugehörige Signatur sieht dann so aus:

1

function _nx($single, $plural, $number, $context, $domain = 'default')

Zusammenfassung

Wenn man sich anschaut, was nun auf einmal für ein Betrieb gemacht wird, Lokalisierung in WordPress voranzutreiben, dann kann fragt man sich, warum das mehr als 10 WordPress Versionen gebraucht hat! Dennoch begrüsse ich jeden Fortschritt, wenn gleich auch eine Menge Probleme und Aufgaben damit einhergehen:

• Plugin/Theme Autoren sollte anfangen, die veralteten Funktionen zu ersetzen
• Übersetzer haben jetzt neue Stolperfallen in den *.po Dateien, auf die man achten muß (neue Kontexte)
• Sprachdateibehandlung in WordPress muß nochmal eingehend geprüft werden vor Auslieferung der 2.8
• … und ich darf mein Sprachdatei-Plugin wieder mal umschreiben und anpassen, na toll !!!

Die Problematik mit den getrennten Sprachdateien von Front- und Backend ist auch mit dieser größeren Anpassung von Seiten WordPress nicht zu machen, das wird noch ein ganz schönes Stück Arbeit, das den Core Entwicklern zu erkären (Mailverkehr läuft bereits).