Webplattformen aller Art stehen, was die Jagd nach dem Nutzer angeht, untereinander in einem starken Wettbewerb. Eine Variante, die Reichweite der Unternehmung im Netz zu steigern, ist die Durchführung einer Internationalisierung.

Der Begriff Internationalisierung wird in verschiedenen Kontexten verwendet. Daher gibt es unterschiedliche Auffassungen, wie er zu verstehen ist. Am häufigsten wird der Themenkomplex in zwei Teile getrennt. Internationalisierung (Internationalization, kurz i18n) bezeichnet die Aufgabe, ein Programm so zu entwickeln, dass eine Anpassung an die Anforderungen von anderen Kulturen und Ländern möglich ist, ohne den Quellcode nachträglich verändern zu müssen. Die zweite Teilleistung ist die Lokalisierung (Localization, kurz l10n). Hier werden die Anforderungen, die ein Land stellt, konkret umgesetzt. Vorteilhaft an dieser Ansichtsweise ist die klare Trennung zwischen den beiden Teilleistungen: i18n beschreibt die Definition der abstrakten Schnittstellen und l10n füllt sie mit Leben.

Die Durchführung von i18n und l10n verspricht erhebliche Chancen, die Reichweite der eigenen Produkte zu vergrößern. Die Tatsache, dass man den Nutzerkreis durch die Erschließung neuer Sprachen und Länder ausweiten kann, ist nicht zu leugnen. Studien im E-Commerce belegen sogar, dass Menschen eher auf Plattformen kaufen, wo sie Informationen in ihrer Sprache präsentiert bekommen [1]. Daher begegnet einem im Beratungsalltag häufig die Auffassung von Produktmanagern, dass man „mal eben“ eine i18n durchführen oder von vornherein vorsehen könnte, weil eben so viel dafür spricht. Dass bei diesem Vorhaben neben den technischen Herausforderungen auch länderspezifische und kulturelle Unterschiede einfließen müssen, die über die Übersetzung der Sprache hinaus gehen, ist häufig unbekannt. Die Tabelle stellt die wesentlichen Spannungsfelder dar.

Jeder Kulturraum verfügt über gewachsene Ausprägungen. Dessen sollte man sich bewusst sein, wenn man ein i18n-Projekt startet. Kulturelle Aspekte wie Farbinterpretationen und die Leserichtung können sogar Änderungen am Layout erfordern. Diese Anforderungen sind nur schwierig zu erfüllen. Weitere Spannungsfelder findet man hier [2].

Die Spannungsfelder der i18n führen indirekt zu Implikationen bei der Projektdurchführung. So müssen die Entwickler bei jedem Release einen Übersetzungs-Zyklus anstoßen. Dieser lässt sich im Rahmen des Projektmanagements im Vorhinein planen, dennoch kommt es in der Regel zu Wartezeiten, wodurch sich der Entwicklungsprozess verlangsamt. Außerdem lassen sich Übersetzungen in den seltensten Fällen selbst durchführen. Die Beauftragung professioneller Übersetzer bindet zusätzliche finanzielle Ressourcen. Diese Investition wird aber empfohlen, zumal Übersetzungsfehler in hohem Maße unprofessionell auf den Nutzer wirken und in Segmenten wie dem E-Commerce „tödlich“ sind. Häufig reicht es jedoch noch nicht, dass der Übersetzer nur professionell sein Fach beherrscht, da Aspekte wie bestimmte Sprachstile gefragt sind. In einer „hippen“ Jugend-Community wird ein anderes Englisch gesprochen als auf einem Finanzportal. Dieses Einfühlungsvermögen für die sprachlichen Gepflogenheiten fremder Länder ist schwierig am Markt zu finden. In der Regel wird man an einem Team, welches vor Ort agiert und aus Einheimischen besteht, nicht vorbeikommen. Ein Negativbeispiel von vielen ist beispielsweise das Social Network StudiVZ [3], das sich inzwischen wieder aus dem Ausland zurückzieht [4].

Die vorherigen Abschnitte schildern, welche Dinge man bei i18n-Projekten beachten muss. Neben den organisatorischen Herausforderungen muss man sich auch den technischen Herausforderungen stellen. Diese bestehen im Wesentlichen darin, dass der Entwickler Lösungen für die in der Tabelle dargestellten Spannungsfelder finden muss. Schön für den Entwickler ist es, wenn man ein Framework verwendet, das einem den Großteil der Arbeit abnimmt. Wie eingangs erwähnt, gehört Ruby on Rails zu den innovativsten Frameworks, die es momentan im Web gibt. Die Macher von Rails haben an sehr vielen Stellen neue Standards geschaffen und die Latte für andere Frameworks höher gehängt. Was die Unterstützung von i18n angeht, sah es allerdings bisher recht düster aus: Es existierten lediglich verschiedene Lösungen in Form von Plugins und Gems, die allerdings alle nicht auf ganzer Linie überzeugen konnten. Einen guten Überblick über Lösungen für i18n mit Rails (< 2.2) inklusive Bewertung findet man in der Präsentation von Jan Krutisch auf der Rails-Konferenz 2007 [5].

Ende November 2008 war es so weit: Mit der Veröffentlichung der Version 2.2 verfügt Ruby on Rails über eine integrierte API, die dem Entwickler die Arbeit deutlich erleichtert. Das Konzept ist gelungen, schlank und entschädigt Rails-Entwickler für alles, was vorher war.

i18n bei Rails 2.2 kommt mit einer sehr geringen Anzahl von Klassen und Modulen aus.

Wie bei vielen Dingen, die man mit Rails macht, ist der Einstieg sehr einfach gehalten. Falls man noch nicht die aktuellste Version von Rails installiert hat, sollte man mit „sudo gem update rails“ die Version 2.2.2 installieren. Als nächstes sollte man in der Datei „environment.rb“ den Standardwert für die Lokalisierung festlegen. „:en“ (Englisch) ist vordefiniert, für eine deutsche Übersetzung legt man den Wert „:de“ fest.

config.i18n.default_locale = :de

Lokaliserungen werden im Rails-typischen Yaml-Format im Verzeichnis „config/locales/*.yml“ abgelegt. Die Dateien müssen nach dem Symbol benannt werden, also „de“, „en“ etc. Kernmethoden in der i18n-API sind „translate“ und „localize“. „translate“ dient der Übersetzung von Zeichenketten, „localize“ übernimmt die Formatierung zum Beispiel von spezifischen Datums- und Zeitobjekten. In den Yaml-Dateien werden sowohl Übersetzungen als auch Formate festgelegt.

de:
	title: "Hallo Welt" # Übersetzung einer Zeichenkette 
	date:
		day_names: [Sonntag, Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag]
		abbr_day_names: [So, Mo, Di, Mi, Do, Fr, Sa]
		month_names: [~, Januar, Februar, März, April, Mai, Juni, Juli, August, September, Oktober, November, Dezember]
		abbr_month_names: [~, Jan, Feb, Mär, Apr, Mai, Jun, Jul, Aug, Sep, Okt, Nov, Dez]
	time:
		formats:
		default: "%H:%M Uhr" # Festlegung der Darstellung des Zeitformats
	am: "vormittags"
	pm: "nachmittags"

Es folgen Beispiele, die die Verwendung von „translate“ mittels Shortcut-Methode „t“ und „localize“ mittels Shortcut-Methode „l“ darstellen.

<%= t('title') %> # => Hallo Welt
<%= l(Time.now) %> # => 20:53 Uhr

Für die Lokalisierung von verschiedenen Formaten gibt es ein spannendes Projekt bei Github [6]. Sven Fuchs, einer der treibenden Kräfte des Rails-i18n-Projekts, stellt dort zahlreiche Yaml-Dateien mit Lokalisierungen zur Verfügung, sodass man eine Menge Zeit sparen kann, wenn man seine Seite internationalisiert. Aus dieser Quelle stammt auch der Inhalt der Yaml-Datei.

Internationalisierung mit Rails bietet noch deutlich mehr Funktionen als hier vorgestellt. Da man zahlreiche Quellen im Netz findet, die sämtliche Details beschreiben, sei an dieser Stelle auf diese verwiesen, um dem Motto „Don’t repeat others“ treu zu bleiben [7]
[8]
[9]. Rails 2.2 stellt eine tolle Weiterentwicklung in Bezug auf Internationalisierung dar. Entwickler bekommen damit eine abstrakte Schnittstelle an die Hand, die sie für ihre Zwecke nutzen und anpassen können. Die Anpassung ist dermaßen einfach, dass genügend Zeit bleibt, auch die kulturellen Aspekete der Internationalisierung zu bedenken.

Der Autor

Peter Grosskopf hat Anfang 2006 sein Herz an Ruby on Rails verloren. Mit seiner Firma, der Zweitag GmbH (zweitag.de), entwickelt er Webanwendungen mit Rails und iPhone-Apps. Zudem berät er Kunden aus dem Enterprise-Bereich, wie sie Elemente des Web 2.0 für Unternehmensanwendungen nutzen können. Mit brainr.de gründete er eine Plattform für Online-Brainstormings und war bis 2007 bei A better Tomorrow als CTO tätig.