Immer wieder neu erfunden und allzu oft schlechter, als was es schon gibt. Deshalb meine Regeln als Grundlage für die Diskussion.
1) Der User entscheidet aktiv
Der User fällt die Sprachauswahl aktiv mit einem Klick auf seine Sprache: Entweder auf einer vorgelagerten Sprachauswahlseite oder auf jeder beliebigen Contentseite.
Keine Technik, wo diese nichts nützt. Ja, der Browser schickt bei jedem Aufruf seine akzeptierten Sprachen im HTTP Request Header mit (vgl. RFC 2616) — sogar gewichtet. Die Website darf damit aber keine vorschnellen Entscheidungen fällen, da diese Mitgabe nicht unbedingt den aktuellen Bedürfnissen des Users entsprechen. Häufig weiss der User zudem nicht, wie sich diese «Accept Language» beeinflussen lässt und auch ich bin schon unzähliche Male in die Falle getappt und hatte plötzlich Software in einer Sprache installiert, die ich nicht wollte (fies in diesem Bezug ist der Java-Download).
Ein noch übleres, erlebtes Verhalten ist, dass eine Site meine Sprache aufgrund der ersten besuchten Seite bestimmt und mit einem persistenten Cookie auf bei mir «festschreibt». So komme ich über eine Suchmaschine direkt auf eine Seite und deren Sprache soll (für immer) meine bevorzugte Sprache sein… kaum!
2) Der User muss nur einmal entscheiden
Hat sich der User explizit für seine Sprache entschieden (vgl. 1), so darf die Plattform diese speichern und in der Zukunft als Vorgabe nutzen. So soll die Sprach-/Länderauswahlseite nicht mehr gezeigt werden; Eine spätere explizite Änderung durch den Nutzer muss aber jederzeit möglich sein. Die Vorgabe wird entsprechend angepasst.
3) Umschaltung ist auf jeder Seite rechts oben
Sprachumschaltung ist rechts oben auf jeder Seite der Webanwendung zu finden. Punkt.
4) Keine Flaggen aber Textlabel
Länderflaggen zur Sprachumschaltung sind falsch. Erstens gibt es in einem Land mehrere Sprachen (auch in den USA — bitte mal die Demographie in dem Grossstädten anschauen). Schweizer Flagge = vier Landessprachen (beim Rätoromanischen gäbe es noch mehrere unterschiedliche Varianten) und zahlreiche häufig gesprochene Sprachen.
Zweitens genügt die Sprache allein nicht, da eine Sprache zu einem Kulturkreis gehört. So beispielsweise Französisch in Afrika, Frankreich, der Schweiz, Kanada, Belgien etc. Sowohl Inhalte, Tonalität, Wortschatz wie auch Syntax unterscheiden sich. Je nachdem will ich mich anpassen (oder bewusst nicht, weil ich mit einem Landesimage arbeite).
So ist es übrigens auch in der relevanten Spezifikation drin: Eine Kombination von Sprache (nach ISO-639) und von Land (nach ISO-3166). Schön ist dass auch Sprachen ausserhalb von ISO im HTTP header codiert werden können, so beispielsweise Google auf Klingonisch.
5) Label haben mindestens zwei Buchstaben und sind in der Zielsprache
Die Textlabel (vgl. 4) rechts oben auf jeder Seite (vgl. 3) haben, sofern klar einem Kulturkreis zugeordnet, mindestens zwei Buchstaben. Am offensichtlichsten eignen sich dafür die Abkürzungen im Standard ISO-639. Möglich und teilweise besser (wegen der Grösse und somit der Einfachheit zum klicken) sind die ausgeschriebenen Sprachen und zwar in der Zielsprache. Als nicht Englisch / Französich auf der deutschen Seite aber english / franà§ais. Das Beispiel ist wegen der einfache Verständlichkeit ein bisschen zu simpel… aber stellen die ihr Handy mal auf Griechisch…
6) Die Sprache ist in der URI drin (und nicht als Parameter)
Ein bestimmte Informationselement hat eine eindeutige Referenzierung eine URI (das ist Grundlage von Hypertext — alles andere [z.B. eine ganze Website in index.asp] ist falsch). So gibt es eigentlich zwei gute Möglichkeiten. http://domaene.ch/news/item1.de.html resp. http://domaene.ch/news/item1.en.html (bei der Umsetzung hilft mod Negotiation von Apache ganz nett). Oder http://domaene.ch/de/news/item1.html resp. http://domaene.ch/en/news/item1.html.
An der Grenze des guten ist ein einziger Parameter im Stil http://domaene.ch//news/item1.html?lange=en aber auf keinen Fall ist die Sprache in der Session drin, sonst tut es nicht mit eindeutigen Referenzen, Suchmachinen etc.
Habe ich was vergessen und Diskussion ist erwünscht…
Sprachumschaltung auf Websites: Die Regeln.
S
irgendwie kommt da der ganze frust von vergeblich gesuchten Spracheinstellungen rüber 🙂 aber trotzdem gut das es einmal gesagt ist.
Gebe dir in fast allem recht. Nur vorgeschaltete Sprachauswahlseite finde ich uncool und ersetze ich mit Auswertung von Accept-Language. Wenn man damit 80 Prozent der Benutzer an den richtigen Ort geleitet hat spart man denen bereits allen einen Klick. Und die anderen 20 Prozent haben auch nicht mehr Klicks als mit Auswahlseite.
Ich vermute aber sowieso, dass man mit der Methode weit über 90 Prozent bereits ans richtige Ort leitet, da sehr viele Benutzer den Browser in ihrer Standardsprache verwenden und eben an den Default-Einstellungen nichts ändern.
Die Content Negotiation Methode von Apache finde ich eigentlich ganz gut. In der Praxis hat sie aber den Nachteil, dass aktive Sprachauswahl genau nicht berücksichtigt wird. Debian.org verwendet diese Methode. Wenn ich da auf einer Seite von Spanisch (meine Standard-Sprache) auf Englisch umstelle, erscheint die nächste Seite doch wieder auf Spanisch. Das liegt daran, dass Links nie auf eine explizite Sprachversion sondern immer auf die unqualifizierte Version des Dateinamens zeigen. (also auf index.html und nicht auf index.en.html).
Bankensoftware, oder zumindest die 2 die ich benutze (CS und YellowNet) sind da superschlimm.
Bei der Post kann ich die Sprache nur *vor* dem Login ändern (und da meine Browser englisch sind, ist das natürlich per default englisch, ich bin aber nicht soooo der Experte im Finanzenenglisch, darum will ich das nicht wirklich 🙂 ). Bei der CS kann ich wenigstens die Sprache auch *nach* dem Login ändern, aber die Spracheneinstellung, die’s bei den Optionen hat, wird nicht zur nächsten Sitzung gerettet… Dann also wieder alles von vorne. Auch die Post merkt sich nix, die stellen mir das nächste mal wieder frisch fröhlich die Englische Version hin.
Wie schwer kann sowas sein? 🙂
Und die Post (als auch die CS) schafft’s ja auch mit mir auf Papier auf Deutsch zu kommunizieren, wissen somit eigentlich, was meine Lieblingssprache ist, also macht doch das Webinterface in genau dieser Sprache.
Ach ja, die papierene Kommunikationssprache kann ich übrigens bei der Post im Web anpassen…
Mmmmh, ich habe erst im nachhinein mich erinnert, dass namics bei der PostFinance die Finger ja mit im Spiel hatte. Also nicht persönlich nehmen oder so 🙂 Weiss ja auch gar nicht, wer das Sprachen-«Desaster» nun schlussendlich verbrochen hat 🙂
Hi Christian… ja, wir haben bei PF den «Finger im Spiel» aber nicht bei der eBanking-Lösung (uff). Und wenn auch… hier auf dem namics Blog wird gesprochen (und nicht geblockt 😉
Hä, Jürg? Was empfiehlst Du da plötzlich? Soll ich auf einer Surftour 20x sagen, dass ich die Seite gerne in Deutsch sehen will? Nein das kann der Weisheit letzer Schluss nicht sein. Deine Devise: wieso soll man sich das Leben nicht für alle verkomplizieren, wenn es doch wenige auch einfacher haben können.
Hoi, ich habe mal auf meinem Blog die search.ch version der sprachumschaltung dokumentiert. Vieles davon ist eigentlich von Urban, aber er hat ja noch keinen Blog 🙂
Wir haben so auch das von Patrice erwähnte Problem lösen können.
Ich denke eine vorgeschaltete Sprachwahl sollte man immer verhindern wenn sie nicht sowieso mit einer anderen zwingenden Frage kombiniert werden kann. Das einzige mir bekannte Beispiel dafür sind aber juristische Zwänge bei Teilen von Bankensites, die aber eh schon jenseits der ersten sprachabhängigen Seiten liegen.
Danke für die Aufstellung, Jürg. Kann man den RSS-Feed automatisch in PPT umwandeln?
Sprachauswahl ist eines meiner Lieblingsthemen — weil sich konzeptionell seit zehn Jahren praktisch nichts geändert hat. Und technisch auch nicht viel Relevantes.
Habe just für die diesjährige Orbit-iEX deswegen für «Was User lieben» etwas darüber gemacht. Mein bewusstes Surfen zum Thema liess mir die Haare zu Berge stehen. Legionen von Schweizer Websites haben es immer noch nicht gelernt.
Mir scheint, das ist wieder eines der Themen, wo es diverse Lösungen gibt, manche gut, manche weniger gut, manche richtig schlecht, und weil man sich bei den guten nicht ganz und gar eindeutig festlegen kann, welches nun die beste ist, nimmt der ignorante Projektleiter das als Ausrede zu sagen: «Da gibt es keinen Standard, das ist eh Geschmackssache» — und macht dann eine von den schlechten.
Wie mein Lieblingsbeispiel SWISS: einfach das ganze Thema komplett ignorieren und immer auf Englisch beginnen, in einem Land, das zwar viele offizielle Landessprachen hat, zu denen aber Englisch nicht gehört. Der doofe User kann ja jedes Mal die Sprache wechseln. (De facto macht er das nicht, sondern er kämpft sich durch, selbst wenn er gar nicht so gut Englisch kann, wie wir in einer Testserie für die Netzwoche gesehen haben, mit den zu erwartenden negativen Folgen.) Die SWISS wechselt nicht mal nach dem Login die Sprache automatisch, und dann könnten sie sie ja wirklich einfach aus der Datenbank lesen.
Ganz wichtig ist auch der Punkt, den mehrere von Euch schon bringen, dass man den User automatisch gern unterstützen darf, aber letztendlich muss er jederzeit eingreifen können. Diese Maxime wird durch automatische Weiterleitung teilweise massiv verletzt, oft bei Sprachen, aber manchmal auch bei Ländersites — anderes Thema, aber verwandt. Neulich wollte ich zu AOL.com, was nicht ging, weil ich mit meinem Browser nur zu AOL.de durfte. Was macht der Amerikaner, der hier zu Besuch ist?
Noch ein Argument, dem User seine Freiheitsgrade zu lassen: Man kann praktisch nie alle möglichen Situationen voraussehen. Wir haben mal für eine Telco ein Interactive Voice Response System getestet, da hatten sie sich überlegt, man könne doch in den Fällen, in denen die Nummer übertragen wird, den Schritt Sprachauswahl weglassen und einfach nur die Rechnungssprache des Abonnenten anbieten (dass es nicht sinnvoll war, es nach der Sprachregion festzulegen, hatten sich sich schon selbst überlegt), dann spare der User einen Schritt, denn der sei eh bei solchen Systemen immer genervt. Ich habe mich gewehrt und vorgeschlagen, man könne gern immer mit der Rechnungssprache beginnen und die auf «für X drücken Sie 1» legen, aber bitte nicht die Auswahl verstecken.
Im Test hatten wir dann prompt eine Konstellation, wo eine Ehepartner die Sprache des rechnungsempfangenden anderen Partners nicht verstand, weiss nicht mehr genau, wie die Kombination war, aber die beiden lebten zusammen in Zürich und sprachen Englisch miteinander. Um das abzubilden müsste das System um einige Grössenordnungen intelligenter sein und vor allem merken, wer gerade anruft. Fazit von diesem Teilgebiet: Was auch immer wir uns beim Bauen von Applikationen ausdenken, die Realität ist fast immer komplizierter. Deswegen sollten wir genug denken, aber nicht zuviel.
Danke allerseits für die aktive Diskussion insb. das URI-Detail mit eingehenden Links. Ein paar Worte zu der von mir angesprochenen vorgelagerten Sprachauswahlseite (bevor ich diese evt. «abempfehle»).
So von ganz weit weg will ich auch keine vorgelagerte Seite. Aber
– Ich zeige diese pro persistentes Cookie nur einmal. Also Reto: Einmal im Leben auswählen.
– Sobald ich Sprache und Kultur/Land gemischt haben, brauche ich eine Nutzerauswahl. Früher mal ein schlechtes Beispiel aber heute gut ist http://www.sonyericsson.com/ (hmm jetzt grad looped es in einem Redirect also immer noch schlecht, aber das Prinzip stimmt 😉
– Mein Frust mit falsch installierter SW so auch auf Windows Update, Java Download und an anderen Orten ist so gross, dass sich unterdessen wählen will. So bei Bernie in seinem Post sagt: Viele Leute haben den Compi auf englisch installiert aber je nach Klick, Klack und Browser steht in der Accept Langage was anderes drin und umstellen ist mühsam. Möglicherweise bin ich da ein Sonderfall, aber bei http://www.search.ch scheint es ja ähnlich zu sein, dass viele Leute deutsche Queries mit einem englischen Accespt Language machen.
Ich weiss nicht mehr so recht, ob es die Auswahlseite braucht aber bei mir überwiegen die Negativerfahrungen bei der automatischen Erkennung. Am fiesesten Sprache auf Englisch und Download auf Deutsch (wegen der Accept Language)
Jürg, ich denke Downloads bzw. Software Installationen sind ja sicherlich noch einmal ein Spezialfall. Da sollte es ein vernünftiges und _genau_angeschriebenes_ Default geben und dann die anderen Varianten (Sprache, OS, Packaging, andere Versionen, etc.) unmittelbar daneben erreichbar machen.
aol.com -> aol.de ist natürlich ein Desaster. Google macht hier aber etwas ähnliches, merkt sich aber offenbar ob man es overrided.
Ansonsten denke ich immernoch, dass die Sprachwahl vermieden werden sollte. Wenn ich einfach (und zumindest in der Session persistent) umstellen kann, dann reicht mir das.
Nein auch wenn ich das nur 1x bewusst machen muss ist das 1x zuviel. Zudem haut es mir (und den armen Leuten bei der CS jeden Tag) die Cookies öfters raus. Kommt die für mich falsche Sprache, muss ich es ändern können. Das finde ich ok.
Ein Beispiel aus dem Leben. Wie wüde es Dir gefallen, wenn Dich jedes Mal wenn Du zuerst einen Laden betritts jemand fragt ob Du tatsächlich einkaufen möchtest? Du gehst dann jeden Tag dort einkaufen, wirst nicht mehr gefragt – aber plötzlich, nach 3 Monaten, fragt Dich wieder einer «Herr äh, Monsieur, wänd sie da würkli öpis poschtä?» Nein, lieber nicht.
Wie die alte Fasnacht etwas spät, aber ich habe trotzdem noch eine Frage resp. Ergänzung zu Punkt 3): Sprachumschaltung auf jeder Seite rechts oben.
Und wenn die Seite nicht in allen Sprachen existiert (z.B. auf Admin-Sites, die nicht durchgehend auf Englisch übersetzt werden)?
Ich sehe da grundsätzlich vier Varianten, wobei ich die erste bevorzuge:
1. gar kein Sprach-Link «English»;
2. ein inaktiver Link «English» (derzeit der Standard bei den neuen Admin-Sites);
3. aktiver Link «English», der auf eine Seite führt, die (auf Englisch) sagt, in welchen Sprachen diese Seite existiert und dorthin verlinkt;
4. aktiver Link «English», der auf die englische Fassung der Homepage führt.
Wenn eine Seite nicht in einer anderen Sprache existiert, braucht es auch keine Umschaltung. Eigentlich logisch und somit auch +1 für Variante 1.
Ein nicht aktiver Link stört da aktiv/inaktiv in der Service-Navigation nicht immer erkennbar ist. Und ein Link auf dieselbe Seite nützt sicher nichts.
Hi,
interessant. Woher stammt die Erkenntnis, dass die Sprachumschaltung oben rechts hinkommt? Gibt es da Studien über das Verhalten der User? Ich will eine Seite jetzt umbauen und informiere mich nun gerade über das Thema.
VG
Torsten
Guten Tag Herr Müller. Der Artikel stammt aus dem Jahre 2005 und seit dann hat sich sehr viel getan. Also bitte nehmen sie meine damaligen Tipps nicht mehr für «bare Münze» und recherchieren sie nach aktuellen Quellen. Der Ort «rechts oben» für die Sprachumschaltung finde ich (auch ohne Quelle zur Hand) immer noch für sehr gut geeignet.