Code Styling Project

Seit längerer Zeit gibt es immer mal wieder das Problem, daß man Sprachdatei-Vorlagen (*.po Dateien), die mein Plugin erzeugt hat, zwar mit PoEdit öffnen konnte, jedoch daraus keine Sprachdatei erstellen konnte. Es war auch möglich, mit meinem Plugin eine nicht standard konforme Sprachdatei (*.mo) zuerstellen.

Ich habe mich nun auch diesem Problem angenommen und einen weiteren Bugfix in mein Plugin integriert. Mit Version 1.99.1 ist dieses Problem dann behoben.

Nachstehend liste ich mal eine kurz Aufzählung von Fundstellen im Netz, wo mehr oder weniger heftig über dieses Problem diskutiert und Behebungen skizziert wurden:

• Dennis Morhardt (www.dennismorhardt.de)
• WordPress Deutschland Forum
• Freelance Jobs

Um grundlegend erstmal zu wissen, was und warum das ein Problem darstellt, kommt hier eine kurz gehaltene Beschreibung des Phänomens. Als erstes braucht man mal ein wenig Codebeispiele, die ich mir aus WordPress 3.0.1 entliehen hab bzw. selbst zu Testzwecken erstellte.

existierendes Beispiel

Wie schon erwähnt, hier nun das real existierende Beispiel direkt aus dem WordPress 3.0.1 Core Code.

1
2
3
4
5
6
7
8
9
10
11
12

//file: wp-admin/includes/dashboard.php:264
// Categories
 $num = number_format_i18n( $num_cats );
 $text = _n( 'Category', 'Categories', $num_cats );
 
//file: wp-includes/taxonomy.php:55
'labels' => array(
     'name' => __( 'Categories' ),
     'singular_name' => __( 'Category' ),
     'update_item' => __( 'Update Category' ),
),
 

Der Begriff “Category” wurde sowohl in einer Pluralisierung als auch mit einfache Singular Variante benutzt. Normalerweise sind bei Übersetzungen diese beiden Sachen völlig verschieden, weil der Kontext, in dem es benutzt wird, nicht identisch ist. Mein Plugin hat das konsequenter Weise auch als 2 verschiedene Einträge behandelt, was dann aber dazu führt, dass PoEdit 2 mal die gleiche msgid (intern) erzeugt. Da es aber nicht zulässig ist, einen Eintrag mehr als einmal in der Vorlage zu haben, verschluckt sich dann PoEdit beim Erzeugen der Sprachdatei (*.mo) und weigert sich mit den entsprechenden Warnungen, diese zu erstellen.

künstliches Beispiel

Ich hab mir für Testzwecke und der weiteren Erklärung ein künstliches Beispiel erzeugt, um auch herauszuarbeiten, daß es allein mit dem Fix nicht getan ist. Die Programmierer sollten auch darauf achten, was sie da genau machen und sich ggf. eine wenig intensiver mit Lokalisierung befassen, wenn sie es denn schon einbauen.

1
2
3
4
5
6
7

<div>Testing container: 
 <?php _e('All'); ?> 
vs.
 <?php echo _n('All', 'All', $count); ?> 
vs. 
 <?php echo _n('All', 'Total', $count); ?>
</div>

Wieder das gleiche Problem: Singular Variante und Pluralisierung haben den gleichen Hauptschlüssel “All” bekommen. Zusätzlich gibt es aber eine weitere Pluralisierung, die sich jedoch nur im Schlüsselwort mit der anderen deckt, leider aber was anderes auszudrücken versucht.

Was macht nun der PoEdit damit, wenn man das dort aus den Quelldateien einlesen lässt ?
Das ist relativ einfach und sieht in der *.po Datei dann so aus:

1
2
3
4
5
6
7

#: index.php:11
#: index.php:13
#: index.php:15
msgid "All"
msgid_plural "Total"
msgstr[0] ""
msgstr[1] ""

Überraschung, nicht? Es kann am Ende nur einen geben, der “überlebt”. Die Pluralisierung All -> All ist leider gänzlich entschwunden und das es eine Singular Variante gibt, bekommt man auch nicht mit. Wenn man das dann übersetzt, wundert man sich unter Umständen, daß es nicht zum erwarteten Ergebnis an allen Stellen führt.

Bei der Lokalisierung dieses Beispiels wird nämlich eines völlig außer Acht gelassen, alle Texte, die irgendwo erscheinen, stehen immer in einem Kontext zum umgebenden Bereich oder Text. Demzufolge kann man solche Sachen auch mit den entsprechenden Kontext-Funktionen von gettext lösen oder formuliert die Stellen kollisionsfrei. Dies hier zu zeigen, würde den Rahmen allerdings sprengen.

Plugin Bugfix und Mehrwert für Entwickler/Übersetzer

Damit man überhaupt mitbekommen kann, daß etwas schief läuft (oder laufen kann), hat mein Plugin nicht nur den Fix bekommen sondern fügt auch Hinweise an, die man sowohl im PoEdit als auch in meinem Plugin sehen kann. Im Zweifelsfall kann man dann immer nochmal drüberschauen, ob und wie man das lösen könnte.
So sieht das dann in meinem Plugin aus:

Zusammenfassung

Mit der in Kürze erscheinenden Version 1.99.1 meines Plugins werden die erzeugten *.po Dateien wieder konform zu dem sein, was PoEdit versteht und auch zu Sprachdateien umzuwandeln sein. Wie man an diesen Beispielen sehen kann, ist die Lokalisierung einer Software nicht immer ein Kinderspiel und man braucht schon ein paar Grundkenntnisse über den Aufbau von Sprachen und deren Verwendung. Nur so lassen sich vernünftig übersetzbare Komponenten entwickeln.
Als Programmierer von Themes oder Plugins kann es nicht schaden, sich ein wenig mit dieser Materie zu befassen, wenn man den Anspruch hat, ebenfalls lokalisierbare Software zu veröffentlichen.