Gestern Abend flatterte eine Mail in mein Postfach aus dem WordPress-Entwicklerblog. Der Core-Entwickler Andrew Nacin beschreibt darin ausführlich die Pläne für die kommende WordPress Version 4.0, die sich derzeit in der Entwicklung befindet.

 Ein persönlicher Wunsch meinerseits wird direkt in Punkt 1 definiert: Die Auswahl der Sprache direkt im Installationsprozess. Aber lasst uns mal genauer schauen, was da von den fleißigen Entwicklern geplant ist und wobei noch viele fleißige Köpfe und Hände gebraucht werden.

  1. Hauptaugenmerk liegt auf der Möglichkeit, bei der Installation von WordPress direkt auch die gewünschte Sprache auszuwählen.
  2. Im Zuge dessen sollte es möglich sein, nachträglich im System auf eine andere Sprache zu wechseln, wobei dann das jeweilige Sprachpaket automatisch heruntergeladen wird.
  3. Eine Suche nach Plugins und Themes per Sprache soll direkt aus der Administration möglich sein.
  4. WordPress-Versionen sollen automatisch erzeugt und in den Core-Release-Prozess integriert werden.
  5. Übersetzte WordPress-Versionen (wie die deutsche Version) sollen zukünftig nur als initiale Downloads auf den jeweiligen Landesseiten verfügbar sein. Stattdessen sollen die Sprachpakete an sich transparenter für Updates zur Verfügung stehen.

Das ist viel Arbeit und eine große Herausforderung.

Was bedeutet das für die Nutzer der deutschsprachigen WordPress-Version?

1 ) Die Wahl einer Sprache bei der Installation von WordPress.

Wir kennen das Thema Sprachauswahl von diversen Software- und Betriebssystem-Installationen. Als erstes erscheint eine Dialogbox, die uns eine Auswahl an verfügbaren Sprachen anbietet. Jeder weitere Schritt während der Installation findet dann in der gewählten Sprache statt. Die Herausforderung liegt im Ablauf, wie die Sprachpakete gezogen werden. WordPress ist in über 130 Sprachen übersetzt. Viele davon werden von einer aktiven Community gepflegt – wie auch unsere deutsche Version – einige Sprachen werden nur rudimentär aktuell gehalten.

Die Sprachpakete könnten direkt nach der Auswahl von der zentralen Quelle auf wordpress.org heruntergeladen werden, oder es werden alle Sprachen als minimale Pakete, die nur für den Installationsprozess benötigt werden, im Downloadpaket dazugepackt. Wenn allerdings wordpress.org aus irgendwelchen Gründen nicht erreichbar ist oder der Download zu lange dauert, muss das ordentlich abgefangen werden.

Die andere Variante, nur abgespeckte Sprachpakete für alle verfügbaren Sprachen mitzuliefern bringt die Herausforderung für die Sprachen, die nicht so regelmäßig gepflegt werden oder unvollständig sind. Auch verzögert sich möglicherweise auch das Hinzufügen von neuen Sprachen. Natürlich könnte man auch die Sprache anhand der eingestellten Browsersprache oder des Ländercodes der IP automatisch anbieten, aber auch das ist nicht einfach.

Im Deutschen pflegen wir seit einigen Jahren zwei Sprachpakete: die DU-Version und die SIE-Version, um die informelle Anrede von der formellen Anrede zu unterscheiden. Es gibt aber auch Länder, die mehrere Dialekte pflegen müssen, wie die Schweiz oder Portugal, Luxemburg, oder die im Land mehrere Sprachen je Region neben der Amtssprache verwenden.
Alle diese Varianten pro „Grundsprache“ müssen als eigene Sprachpakete angelegt und gepflegt und im Installationsprozess auch beachtet werden.

2 ) Die Sprache in den allgemeinen Einstellungen einer WordPress Instanz wählen können

In WordPress MU (Multisite) gibt es derzeit die Möglichkeit, verschiedene Seiten mit unterschiedlichen Sprachen zu betreiben. Dies funktioniert allerdings nur mit den lokal installierten Sprachpaketen. Möchte man also eine Multisite mit drei verschiedenen Sprachen betreiben (DE / EN / NL) müssen diese Pakete auch im Verzeichnis /languages/ vorhanden sein. Das Plugin Multilingual Press nutzt genau dieses Core-Feature für Multisites, um mehrsprachige Webseiten mit WordPress zu realisieren.

Nun ist geplant, diese Auswahl auch für Single-Installationen anzubieten. Hierbei können wieder unterschiedliche Abläufe umgesetzt werden. Sollte bei der Sprachauswahl das Paket von WordPress.org nicht erreichbar sein, werden nur die Sprachen zur Auswahl angeboten, die lokal schon installiert sind.

3 ) Plugins und Themes über das Dashboard nach verfügbaren Sprachvarianten durchsuchen

Hier kommt eine Option ins Spiel, die schon länger geplant ist. Seit WordPress 3.4 werden die Sprachen zentral über translate.wordpress.org von den jeweiligen Communities gepflegt, bisher aber nur für den WordPress-Core. Die Plattform soll nun auch für Plugin- und Theme-Anbieter geöffnet werden, so dass auch Plugins und Themes zentral übersetzt werden können. Somit können Plugins und Themes direkt nach verfügbaren Sprachen gefiltert werden. Derzeit werden nur einige Plugins und mobile Apps zusätzlich zum WordPress Core gepflegt: BuddyPress oder die WordPress App für iOS, Android beispielsweise.

4 ) Alle lokalisierten Pakete sollen automatisch generiert werden und Teil des Core-Release-Prozess werden

Bisher haben von WordPress.org akkreditierte Community-Mitglieder für die jeweiligen Sprachen die Versionen bei Updates erstellt. Dies war auch der Grund für die DE-Edition, die noch weitere Anpassungen enthielt als die Standard-Version, die über de.wordpress.org zu beziehen war. Seit WordPress 3.8 können wir auf die spezielle Edition verzichten, weil der Release-Prozess immer besser wurde. Heute passen wir die liesmich.html an, packen die Sprachpakete zusammen, und dann wird über ein zentrales Deployment-System die deutsche WordPress-Version zum Download bereitgestellt. Dies bedeutet für die Beteiligten, dass sie sich Stunden um die Ohren hauen, um im #wordpress-dev IRC Chat auf das offizielle „Go“ zu warten, um dann zeitnah nach dem offiziellen Release der neuen Version auch das deutsche Update ausrollen können. Dies heißt auch darauf zu achten, ob alle verfügbaren Sprachen vollständig übersetzt sind.

Mit der geplanten Änderung soll es nun möglich sein, dass der Chef-Entwickler, der das Update freigibt, auch automatisch alle weiteren Sprachversionen ausliefern kann. Allerdings ist hier immer noch zu beachten, dass die Übersetzungen der Dateien licence.html, readme.html und die Kommentare in der wp-config-sample.php auch irgendwie zentral gepflegt werden und im Deployment-Prozess dann dynamisch erstellt werden müssten.

5 ) Lokalisierte Pakete sollen nur als initiale Downloads verwendet werden. ÜBersetzungen werden transparent aktualisiert.

Die WordPress-API soll so eingerichtet werden, dass bei einem WordPress-Update die Sprachen getrennt vom Core aktualisiert werden. Dies heißt, dass keine Sprachdateien mehr überschrieben werden, wenn es nicht notwendig ist. Was aber auch im Gegenzug bedeutet: Wenn jemand einen Tippfehler oder eine Inkonsistenz in der deutschen Sprachdatei findet, diese dann als neuen Vorschlag einreicht, von den Validatoren dann genehmigt wurde, kann die aktualisierte Sprachdatei dann auch als separates Update im Dashboard angezeigt werden. Also können Sprachpakete unabhängig vom Core-Update aktualisiert werden.

Fazit

Wie ihr seht, wird hier viel unter der Motorhaube von WordPress gearbeitet und es braucht noch viele hilfreiche Hände. Wer sich berufen fühlt, aktiv daran mitzuarbeiten, ist herzlich eingeladen, sich einzubringen. Schau dir dazu das Handbuch für die aktive Mithilfe für WordPress an (englisch).

Weitere Details zu den einzelnen Aufgaben mit Verlinkungen zu den jeweiligen Tickets im Trac findet ihr im offiziellen Beitrag von Andrew Nacin: Internationalization goals for 4.0.