Ein neue Zeitalter bricht herein: Wir erleben personalisierte Homepages (z.B. Google Startseite, aber Yahoo und MSN sind mittlerweile mindestens genauso weit nachgezogen), man tut alles, dass der potenzielle Kunde Besucher machen kann, was er will. Im wird nichts vorgesetzt, sondern er hat (scheinbar) freie Auswahl. Sowas bindet doch, wird vielleicht der Psychologe sagen.
Das man so einen Service als “kleine” Website nicht immer anbieten kann, ist selbstverständlich. Es sprengt irgendwo ja auch den Rahmen.. genauso wie es (wirtschaftlich) totaler Unsinn ist, für eine Visitenkarten-Homepage ein komplettes Framework zu nutzen (geschweige denn, zu entwickeln).
Aber wie steht es eigentlich um die personalisierte Sprache? Was ist, wenn der Besucher kein Deutscher, Engländer, usw. ist? Die meisten machen sich darum keine Gedanken; im Gegenteil: es wird ein Gemauschel aus Deutsch-Englischen Begriffen verwendet und dieser Brei dann sogar noch veröffentlicht. Mh..
Schon lange gibt es verschiedene Techniken, wie man dies realisieren kann. Die einfachste Methode ist, wie viele kleine Seiten es machen: Man schreibt die gleiche Seite einfach mehrfach, jede in ihrer eigenen Sprache. Diese Methode kommt häufig bei statischen Seiten vor. Es versteht sich von sich selbst, dass in den meisten Fällen hier unwartbaren Code erhält. (Ausnahme: Verwendung von Projekt-Templates wie in Dreamweaver) Doch was tun?
Im Großen und Ganzen gibt es folgende Möglichkeiten:
- bereits o.g.: jede Sprache erhält ihre eigene Seiten über eine eigene URL
- man verwaltet alle Sprachstrings in einem Array oder in Konstanten/Variablen; man lädt je nach Bedarf eine Datei, die ein Array aufbaut (Beispiel: phpBB 2)
- man speichert die Templates jeweils in einer eigenen Sprache; der Unterschied zu 1. ist, dass die URL gleich bleibt
- man verwendet i18n und beispielsweise PHP’s gettext(), die Sprachstrings werden dann im System unter locales gehalten
Andre aka Blackflash beschreibt in seinem Blog, wie Punkt 4 i18n mit einer Klasse zu lösen wäre.
Aber war es das wirklich schon? Muss man als Entwickler jetzt umständlich in den MO/PO-Dateien rumkramen, um die Sprachen zu ändern? Geht das nicht einfacher?
Geht es! Wofür haben wir denn schon Techniken wie XML, XSL und Co, international-kompatible Charsets wie Unicode (UTF-8, UTF-16)?
Was braucht man dafür?
- Eine XML-Datei, welche die Daten hat. Als Beispiel verwenden wir ein kleines Formular zur Aufforderung, sich einzuloggen. Das die XHTML-Tags für Formulare und Listen verwendet werden, ist nicht notwendig, sondern nur Zufall. ([data.xml][2])
- Eine XML-Datei, welche die einzelnen Begriffe je Sprache aufgelistet hat. Die Struktur ist simpel zweidimensional ([languages.xml][3])
- Eine XSL-Datei, welche die in der data.xml gekennzeichneten Felder mit denen aus languages.xml ersetzt ([template.xsl][4])
- Ein PHP-Script, welches die Transformierung mittels XSLT-Processor annimmt. Welche Sprache verwendet wird, kann dabei theoretisch über Auslese der Useragentinformationen erfolgen (oder Benutzereinstellung) ([index.php][5])
Als Resultat erhalten wir: [deutsch][6], [englisch][7]
Das Ergebnis ist nicht ganz korrekt: Zunächst wird das XHTML-invalide Attribut i18n mitkopiert (also entweder nicht mitkopieren oder im Doctype erweitern) und die Ersetzung im Button erfolgt nicht korrekt.. dort müsste man also Anpassungen im Template machen (es muss eben ins Attribut value rein). Diese Nebensächlichkeiten sollen uns aber nicht davon abhalten, wie schön XSL und XML eben für Internationaliserung zu gebrauchen wären.
Den Vorteil, den ich hierbei sehe ist, dass diese Sprachdateien wesentlich einfacher zu bearbeiten und zu erweitern sind, als Methode über locales. Zwar ist man bei locales auch nicht Verzeichnisse gebunden, aber man muss a) die Dateien im umständlichen Syntax editieren, diese b) übersetzen (oder Umwandeln) und c) hochladen. Bei XML braucht man es nicht; es wird nochmal hochgeladen und editiert (ggf. durch ein Online-Tool).