Hallo,
a) In einer Sessionvariable?
b) Über die eine Abbildung im Pfad (example.com/de/categories vs. example.com/en/categories)
c) über query-string (example.com/categories/cars?lang=de)
ich nutze normalerweise eine Kombination von a) und c) mit zusätzlich vorgeschalteter Language Negotiation, wobei die Priorität der Angaben von oben nach unten zunimmt. In Pseudocode:
Haben wir einen URL-Parameter "lang" mit einer Sprachangabe, die wir unterstützen?
Ja: Sprache übernehmen und in Session speichern
Nein: Existiert ein Eintrag "lang" in der Session?
Ja: Sprache aus Session übernehmen
Nein: Wünscht sich der Client im Accept-Language-Header eine Sprache, die
wir unterstützen?
Ja: Sprache aus Header übernehmen
Nein: Festgelegte Default-Sprachvariante nehmen
Die Folge ist, dass man anfangs die Sprache bekommt, die man im Browser als bevorzugte Sprache eingestellt hat, aber jederzeit per URL-Parameter (bzw. entsprechende auf der Seite angebotene Links) die Sprachversion wechseln kann.
a) wohl der Nachteil, dass die URL die Sprache nicht abbildet
Das sehe ich eher als Vorteil: Ich kann eine sprachneutrale URL weitergeben, und jeder Nutzer bekommt unter derselben URL denselben Inhalt - nur eben in "seiner" Sprache.
b) gefällt mir persönlich am besten
Mir am wenigsten. ;-)
c) unschöne URL
Ja. Aber so wie ich es realisiere, habe ich diesen unschönen Query-String nur bei dem einen Aufruf, bei dem ich explizit die Sprache umstellen will. Beim Klick auf den nächsten Link ist der URL-Parameter wieder weg; die Information ist ja nun in der Session gespeichert.
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt. Das soll bitte hier nicht diskutiert werden.
Schade. Denn das ist IMO das Nächstliegende.
Ciao,
Martin
Kriege kennen keinen Gewinner. Es gibt nur Verlierer und das sind wir.
(Hotti)
Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(