Aus Abschnitt 1, „Hypertext Transfer Protocol HTTP“ über HTTP haben wir erfahren, wie schön das Web sein könnte. Browser beschreiben ihre Wünsche mit Accept-Headern, der Server wählt liebevoll das geeignete Dokument aus, kennzeichnet es durch Content-Header und schickt die Daten in genau der Form zurück, in der der geneigte Besucher der Webseite sie am liebsten sieht. Auf derlei leere Versprechungen fällt kein realistisch denkender Mensch hinein, aber dank des Web-Servers Apache und des Server-Moduls mod_negotiation funktioniert genau dies fast reibungslos, und dankenswerterweise völlig kostenlos.
Der Nutzen liegt auf der Hand, die Informationen werden in optimaler Form ausgeliefert, der Aufwand dafür hält sich stark in Grenzen, eine simple Namenskonvention reicht.
Gehen wir von einer Web-Site aus, die in Englisch, Deutsch, Russisch und Chinesisch verfügbar sein soll. Die Dokumente in Englisch und Deutsch sind - so wollen wir hier als Beispiel annehmen - in CP1252 (Windows-1252/Windows-Westeuropäisch) kodiert, die russischen Seiten liegen in KOI8-R vor, der chinesische Content in Unicode als UTF-8. In Abschnitt 1, „Hypertext Transfer Protocol HTTP“ haben wir bereits gelernt, wie wir über eine entsprechende Namenskonvention erreichen können, dass der Web-Server immer die richtigen Header für Content-Language und Content-Type mitschickt. Nehmen wir an, wir hätten folgende Zeilen in unsere Serverkonfiguration aufgenommen:
AddLanguage en .en 
AddCharset windows-1252 .en 
AddLanguage de .de 
AddCharset windows-1252 .de 
AddLanguage ru .ru 
AddCharset koi8-r .ru 
AddLanguage zh .zh 
AddCharset utf-8 .zh 
Options +MultiViews 
| Hier legen wir fest, dass alle Dateien, die auf .en enden, in englisch verfasst sind. |
| Alle englischen Dokumente sind in Windows-1252 kodiert (pfui!). |
| Deutsche Dokumente enden auf .de ... |
| ... und liegen ebenfalls in Windows-1252 vor. |
| Russische Dokumente (*.ru) ... |
| ... sind in KOI8-R kodiert. |
| Chinesische Dokumente (*.zh) ... |
| ... in UTF-8. |
| Und schließlich das Zauberwort MultiViews. |
Hinsichtlich der Namenskonvention sind nur zwei Dinge bemerkenswert: Was die Sprachzuordnung angeht, ist es sehr wahrscheinlich, dass genau diese Anweisungen bereits in der Server-Konfiguration enthalten sind. Die Zuordnung zu Charsets entspricht dagegen genau unserer (fiktiven) Umgebung. Wir wissen, dass alle unsere chinesischen Dokumente in UTF-8 kodiert sind. Wir können daher Namensungetüme wie index.html.zh.utf-8 umgehen, und die Sprachzuordnung gleichsam für das Charset missbrauchen.
Wenn wir nun beispielsweise eine Datei mit dem Namen testpage.html.ru auf dem Server anlegen, und mit einem Tool, das die HTTP-Header bewahrt, von dort holen, werden wir (nach einem Neustart bzw. Neuladen der Konfiguration des Apache) feststellen, dass der Server die gewünschten HTTP-Header geliefert hat:
Content-Type: text/html; charset=koi8-r Content-Language: ru
Der spannende Teil kommt allerdings noch. Dazu müssen wir unser Dokument in allen vier Versionen erzeugen, also die Dateien testpage.html.en, testpage.html.de, testpage.html.ru und testpage.html.zh. In jede Datei sollten wir zur eindeutigen Wiedererkennung etwas wie „Ich bin die englische Version.“ oder „Ich bin die russische Version.“ hineinschreiben (für unsere Testzwecke müssen die Dateien weder tatsächlich in der vermeintlichen Sprache verfasst sein, noch müssen sie das entsprechende Charset haben). Wir rufen die vier Dateien jetzt jeweils mit einem Web-Browser ab, und überprüfen so, dass wir die richtige Adresse verwenden.
Und jetzt ist endlich Weihnachten: Wir lassen beim Abruf der Datei die Endung mit dem Sprachkürzel einfach weg, fordern also statt http://meinserver/testpage.html.de die Seite http://meinserver/testpage.html ab. Und, siehe da, obwohl die Datei gar nicht existiert, kommt eine Antwort, genaugenommen eine der von uns erzeugten Dateien. Welche das ist, hängt von der Browserkonfiguration ab.
Testweise verstellen wir unsere Spracheinstellungen im Browser (bei Mozilla bzw. Netscape 7 über , beim Internet Explorer über ), schieben Deutsch, Englisch, Russisch und Chinesisch hoch und runter und sehen, wie der Server unsere neuen Sprachvorlieben umgehend honoriert, und jeweils das Dokument in der gewünschten Sprache ausliefert.
Damit das funktioniert müssen verschiedene Voraussetzungen erfüllt sein. Gerne vergessen, insbesondere, wenn unsere Datei index.html.* heißt: Die eigentlich „gemeinte“ Datei darf nicht existieren. Wollen wir also Content-Negotiation für eine Datei index.html ermöglichen, dann darf genau diese Datei am entsprechenden Ort auf dem Server nicht existieren. Stattdessen dürfen nur die Dateien mit den entsprechenden Sprachzusatz vorhanden sein.
Weiterhin muss das Server-Modul mod_negotiation in den Server einkompiliert und aktiviert sein. Wenn man es nicht explizit abgeschaltet hat, sollte dies jedoch der Fall sein.
Und schließlich müssen die Endungen, die wir für Content-Negotiation verwenden, wirklich am Ende des Dateinamens stehen. Hätten wir zum Beispiel zusätzlich die Endung .utf-8 für UTF-8-Dateien konfiguriert, wäre es prinzipiell egal, ob die tatsächliche Datei nun als testpage.html.zh.utf-8 oder testpage.html.utf-8.zh auf dem Server liegt. Sofern die Endung .html jedoch nicht ebenfalls der Content-Verhandlung zwischen Client und Server unterliegt, funktioniert der Mechanismus für testpage.utf-8.zh.html nicht.
Bei aller Begeisterung für das neu erlernte Feature sollte man es jedoch vermeiden, gleich übers Ziel hinauszuschießen. Dies lässt sich allerdings durch ungeschickte Verlinkung innerhalb der Site leicht erreichen. Wir hatten ja bereits festgestellt, dass eine Voraussetzung für die erfolgreiche dynamische Bestimmung des Contents darin besteht, dass die vom Browser eigentlich angeforderte Datei auf dem Server nicht existiert (insofern kann man sich Content-Negotiation als eine Art Fehlerbehandlung vorstellen). Dies ist tatsächlich keine Einschränkung, sondern ein Feature, denn dadurch lässt sich leicht erreichen, dass die einmal gewählte Sprache beibehalten wird. In englischen Dokumenten sollte man stets auf die jeweils englische Version anderer Dokumente verlinken, um den Benutzer nicht durch ständiges Wechseln der Sprache zu verwirren. In einer nach obigem Schema konzipierten Site würden Links aus englischen Dokumenten also nach /anderes/verzeichnis/seite.html.en und nicht nach /anderes/verzeichnis/seite.html zeigen. Dadurch, dass der Dateiname im Link vollständig angegeben ist, wird der Server auf Content-Negotiation verzichten, und ohne jede weitere Konfiguration die gewählte Sprache beibehalten.
Auf die gleiche Art und Weise lässt sich eine Sprachumschaltung realisieren. Es muss lediglich ein expliziter Link auf die anderen Sprachversionen ins Dokument eingefügt werden. Hierbei sollte man sich Tricks mit JavaScript tunlichst verkneifen, weil dies niemandem viel nützt, allerdings Besucherinnen mit softwaretechnischen und erst recht solchen mit körperlichen Nachteilen (Stichwort Barrierefreiheit) sehr schadet.
Besonders schlecht ist eine Realisierung der Sprachumschaltung mit Hilfe von onchange-Handlern für select-Elementen. Selbst wenn man in Kauf nimmt, dass die eigene Web-Site nur mit JavaScript bedienbar ist (und damit körperlich Behinderte faktisch von der Benutzung ausschließt), hat dies einen ganz entscheidenden weiteren Nachteil: Nicht nur Behinderte, auch Suchmaschinen verfügen nicht über JavaScript. Ist der Content in anderen Sprachen aber nur über JavaScript (die Verwendung von Cookies ist in diesem Kontext genauso schlecht) erreichbar, und nicht über reguläre Links, führt das dazu, dass die Teile der Web-Site, die in anderen Sprachen verfügbar sind, von externene Suchmaschinen nicht indiziert werden können.
Aus dem bisher Gesagten, insbesondere den Hinweisen zur Sprachpersistenz ergibt sich, dass es prinzipiell ausreichend ist, lediglich an wohldefinierten Ansprungstellen der Web-Site Content-Negotiation zu aktivieren. Innerhalb fester Content-Bereiche ist es eher verwirrend, wenn die Sprache gewechselt wird.
Daraus ergibt sich allerdings auch die Möglichkeit eines prinzipiell anderen Aufbaus der Site. Es wäre zum Beispiel denkbar, dass man lediglich an den Ansprungstellen die oben beschriebene Namenskonvention einhält, und von diesen Ansprungstellen aus, in abgeschlossene Bereiche verzweigt, also zum Beispiel Teilbäume unterhalb von Verzeichnissen en, de, ru und zh.
Welche Struktur vorzuziehen ist, hängt von den konkreten Gegebenheiten und Anforderungen ab. In der Regel ist ein Aufbau mit getrennten Verzeichnisbäumen eher komplizierter: Ein Link von einem (englischen) Dokument /en/a/b/c/index.html auf die entsprechende deutsche Version /de/a/b/c/index.html erfordert stets Kenntnis des kompletten Pfades. In statischen Webauftritten kann genau das jedoch zu erheblichen Problemen führen. Auch eine Verschiebung von Teilbereichen innerhalb der Site wird bei einem solchen Aufbau erheblich erschwert. Liegen die unterschiedlichen Sprachversionen jedoch immer innerhalb desselben Verzeichnisses, genügt stets ein konstanter Link auf die jeweils anderen Sprachen. Ein Link auf ./index.html.de funktioniert auch dann noch, wenn die Website komplett umstrukturiert wird.