Inhalte stehen in Zusammenhang mit Taxonomien, die sich ihrerseits selbst auch auf unterschiedliche Weise übersetzen lassen.
Daneben gibt es noch das Problem der "User given Strings" und der Mail-Kommunikation zwischen Benutzern und Website. Mehrsprachigkeit ist zugegebenerweise eines der anstrengenderen Themen in Drupal.

Am Beginn eines mehrsprachigen Projektes steht immer die Entscheidung für ein adäquates Sprach-Konzept. Dennoch stoßen wir trotz toll ausgedachter Konzepte immer wieder an Grenzen. Module funktionieren nicht einheitlich / vollständig oder so, wie der Laie es erwartet. Es gibt zwei unterschiedliche Konzepte wie Mehrsprachigkeit im Code behandelt wird. Da ist die t()-Funktion sowie ehemalige tt()-Funktion, die jetzt i18nstrings() heißt. Wenn man von einer Website mehr erwartet, als dass sie nur bestimmte Inhalte über einen Sprach-Switcher umschalten kann, kann man mitunter schier verzweifeln und sollte im Projekt eine Menge Zeit dafür einplanen.

Dennoch ist das Konzept von Drupal aus meiner Sicht richtig und vielversprechend und ich habe noch nirgends ein leistungsfähigeres System dieser Komplexität gesehen.

Karsten entwickelte die Idee, ein eigenes Sprint-Camp für alle i18n-Maintainer im europäischen Raum zu organisieren. Die Idee wurde von den Entwicklern positiv aufgenommen, so dass aus dem ursprünglich geplanten Wochenende auf Wunsch der Teilnehmer sogar ein fünftägiges Event wurde. Neben den beiden Core-Entwicklern Gábor Hojtsy aus Ungarn und Jose Reyero aus Spanien hatten wir Teilnehmer aus der Schweiz, den Niederlanden und natürlich Deutschland mit an Board.

Meine Mitarbeit auf dem i18n Sprint Camp als Nicht-Entwickler.

Ich war natürlich neugierig, wie unser erstes selbst-organisiertes Camp funktioniert. Dabei habe ich mich in erster Linie als Organisator und Zuschauer betrachtet, der das Team mit Catering-Service unterstützen kann.

So war ich regelrecht etwas erschrocken, als ich während der Vorstellungsrunde das Feedback erhielt "That's great - Sitebuilder können wir hier gut gebrauchen. Schau doch gleich mal die Issue-Queue durch."

Bislang habe ich nur im deutschsprachigen DrupalCenter gelegentlich Supportanfragen mit beantwortet. Als Nicht-Entwickler habe ich mich auf drupal.org nie weiter heran getraut, als eigene "Issues" zu "posten", wenn ich auf ein Fehlverhalten bei Modulen gestoßen bin das ich gut reproduzierbar eingrenzen und beschreiben kann. Tendenziell war ich dabei eher zurück haltend, da ich fast nie sicher sein kann, dass nicht irgendeine Fehlkonfiguration meinerseits vorliegt und ich anderen Entwicklern mit meiner Meldung unnötige Arbeit verursache.

Allein in der Issue-Queue zu i18n sammeln sich derzeit rund 450 offene Anfragen, deren jüngste Kommentare zum Teil mitunter noch aus 2008 stammten. Daneben kommen noch die Issues aus allen anderen Modulen, die mit Mehrsprachigkeit zu tun haben. Meine erste Aufgabe war überraschend banal. Gabor schlug vor, ich solle erst mal sämtliche Issues zu Drupal 5 durchsehen, inwieweit sie eine Relevanz für Drupal 7 oder höher besitzen und sie ansonsten kommentarlos zu schließen.

Um mir nicht den Zorn all derer auf mich zu ziehen, die seit 2008 verzweifelt auf Support ihrer Probleme warten, habe ich dies mit einem vorsichtigen Hinweis erledigt, dass Drupal 5 nicht länger supported wird. Ich bin zuversichtlich, dass ich mir mit den 20 bis 30 Issues, die ich in diesem Zuge geschlossen habe, die höchste Abschluss-Quote aller Anwesenden gesichert habe ;-)

Anschließend habe ich mit den ältesten Issues zu Drupal 6 beschäftigt

Issues von 2009 beantworten, damit sie verschwinden

Es ist schon etwas bitter, wenn man Anfragen aus 2009 nur deswegen beantwortet, damit sie nicht länger in der Queue herum liegen. Die User haben sich inzwischen entweder mit dem Fehler arrangiert, sich selbst geholfen oder in Grauen abgewandt. Dennoch gibt es nur zwei Möglichkeiten - entweder werden die Issues kommentarlos geschlosssen, oder es muss sich jemand die Arbeit machen und sich damit auseinander setzen.

Den Einstieg fand ich enorm schwierig. Zunächst hat mich die schiere Masse der Tasks ziemlich überwältigt. Zumal ich in den meisten Fällen - immer dann, wenn es um Code-Probleme ging - nicht viel zu machen glaubte.

Aufräumen der Issue-Queue

Irgendwann habe ich damit begonnen, einzelne Tasks einfach nur zu validieren und habe mitunter festgestellt, dass ich einige Tasks mit gutem Gewissen schließen konnte, da die beschriebenen Effekte in meiner Testumgebung auf heutigem Code-Stand nicht mehr reproduzierbar waren. Dabei wurde mir klar, wie riesig komplex so eine Queue ist. Offenbar wurden einige Probleme ohne Bezug auf bestimmte Issues inzwischen gelöst. Es gibt also viele Duplikate innerhalb der Issues.

Mir ist aufgefallen, dass manchmal der Versions-Stand der Module nicht passte. Feature-Requests betreffen nicht eine bestimmte Version, sondern den Master. Diese Issues zu löschen könnte dazu führen, dass vielleicht wertvolle Ideen verloren gehen.

Manche Issues habe ich schlicht nicht verstanden. Sie waren so wenig präzise formuliert, dass ich keine Möglichkeit hatte die Konstellation nachzubauen.

Bislang habe ich mir die Arbeit des Issue-Fixings immer so vorgestellt, dass die Entwickler, die mit den Modulen vertraut sind, die beschriebenen Fehler im Code identifizieren und beheben. Tatsächlich muss zunächst erst einmal untersucht werden,

  • ob das beanstandete Verhalten tatsächlich unerwünscht im Sinne der Modul-Funktionalität ist,
  • ob der Fehler mit dem Modul (hier: i18n) überhaupt zusammen hängt und
  • ob er sich reproduzieren lässt.
  • Möglicherweise werden auch noch nähere Angaben von dem Melder benötigt. Besonders "lästig" sind die Issues, die vom Maintainer auf "postponed" (es werden mehr Informationen benötigt) gesetzt werden, aber keine weiteren Angaben vom Melder dazu folgen.

Bevor also die "eigentliche" Coding-Arbeit los gehen kann ist einige Vorarbeit erfordlich, die im Grunde von jedermann miterledigt werden kann, der sich mit der Funktionsweise der Module etwas beschäftig hat. Hier können wir alle die Maintainer entlasten, die sich dadurch besser auf wirkliche Fehlerbeseitigung und Weiterentwicklung konzentrieren können.

Socializing

Als Rahmenprogramm waren wir Freitag abend gemeinsam in einem äthiopischen Restaurant essen und haben uns Samstag durch das Filmmuseum führen lassen mit anschließenden Sightseeing vom Potsdamer Platz zum Reichstag. Das Filmmusem hat die Exponate zum Teil mit beeindruckenden Spiegeleffekten in Szene gesetzt. Das H&M Foto habe ich deswegen hier mit veröffentlicht, da mir erst beim dritten Hinschauen aufgefallen ist, das die gesamte Gebäudefassade hinter der Plakat auf Leinwand gemalt und aufgepannt ist. Ich hoffe, man kann dies beim genauen Hinsehen auf dem Foto erkennen...

Zum Abschluss hat Stephan Luckow eine tolle Grillparty für die Teilnehmer gezaubert

Das Sprintcamp wurde von allen Teilnehmern übereinstimmend als großen Erfolg gewertet und wird in Zukunft mit anderer inhaltlicher Ausrichtung - ich persönlich plädiere für ein Deployment Sprint-Camp - sicherlich wiederholt werden.

Danke an die Sponsoren

Eine Review von Jose zum Tag 2 des Camp findet sich hier.
Zum Thema Mehrsprachigkeit gibt es eine eigene Gruppe auf drupal.org..

Ohne die Unterstützung der Sponsoren, die das Camp bereitwillig und großzügig unterstützt haben, hätte dieses Camp nicht statt finden können. Insofern möchte ich den Sponsoren an dieser Stelle noch einmal herzlich danken: