Fragen/ Anmerkungen zum Accept-Language Konzept

[Gunther]

Hi Længlich!

Für mich sind eine Webseite A in Deutsch und eine Webseite B in Englisch 2 völlig unterschiedliche Dokumente, auch wenn sie sich inhaltlich gleichen.

Ich würde sie eher als zwei Versionen des gleichen Dokuments ansehen, zumindest wenn sie (annähernd) den gleichen Inhalt haben. Sind »Harry Potter and the Half-Blood Prince« und »Harry Potter und der Halbblutprinz« zwei verschiedene Bücher? Wenn Du eines davon gelesen hast, ist das andere für Dich dann noch neu und spannend?

Das ist einer der Punkte, den ich mit "Das hat allerdings in erster Linie etwas damit zu tun, wie man bestimmte Dinge ansieht und einordnet." meinte. Denn wenn jemand des Englischen nicht mächtig ist, wird ihm das Buch »Harry Potter and the Half-Blood Prince« nichts nutzen.
Wenn ich alle verfügbaren Sprachen beherrsche, wäre die Version für mich ja auch "egal".

Und wie stufen wir die Sprache einer Webseite ein? Für mich gehört diese Info zu den Meta-Angaben. Dafür spricht u.a. dass es entsprechende meta Tags in HTML gibt. Betrachtet man es nun von der Seite des URL-Designs her, haben Meta-Angaben aber nichts in der URL zu suchen.

Hmm, interessanter Punkt. Aber ein sprechender URI enthält doch per definitionem Angaben zum Inhalt und damit Metadaten, oder?

Das ist wiederum Ansichts-/ Definitionssache. Nach meinem Verständnis ist der Titel einer der elementaren Bestandteile eines Dokuments und hat nichts mit Meta-Angaben zu tun. Dafür spricht imho auch wieder <meta> und <title> Tag in HTML.

Nächste (wichtige) Frage: Wie sieht es mit den Suchmaschinen aus?
Was gibt ein Bot einer Suchamschine für eine Accept Language an?

AFAIK gar keine, also bekommt er (erstmal) die Default-Sprache.

Indiziert er dann nur eine evt. vorhandene und passende Version der Seite? Was ist mit den anderen Sprachversionen?

Auf die kommt er über die in der Seite enthaltenen Sprachauswahl-Links (die aus u.a. diesem Grund IMHO kein Dropdown mit Javascript sein sollten). @rel="alternate" und @hreflang sagen ihm, daß er eine andere Sprachversion vorfinden wird.

Wobei sich dann immer noch die Frage/ das Problem stellt, wie man diese am besten auf der Seite einbaut. Auf der von Gunnar verlinkten Seite des W3C steht dazu nämlich nur: "Diese Sprachauswahl-Elemente müssen natürlich klar erkennbar sein und dem Nutzer verständlich, auch wenn er mit der gerade angezeigten Sprache nicht vertraut ist.". Und aus den diversen hier im Forum bereits geführten Diskussionen wissen wir ja, wie schwierig das in der Praxis ist.

Desweiteren ist dieses Konzept u.U. mit einem erheblichen Mehraufwand für den Autor verbunden, denn um den User nicht zu "nerven" mit diesem Konzept, muss man es möglichst "wasserdicht" machen. Da man sich (leider) nicht darauf verlassen kann, dass ein User Cookies akzeptiert (akzeptieren darf), muss man folglich zwangsweise mit Sessions und deren Fallback-Mechanismus arbeiten.

Nicht unbedingt; es geht auch mit Subdomains. Bei mir läuft es wie folgt:
http://en.quivira-font.com führt zur englischen Version.
http://de.quivira-font.com führt zur deutschen Version.
http://quivira-font.com und http://www.quivira-font.com werten die Accept-Languages aus (Deutsch, wenn der Browser lieber Deutsch will als Englisch, Englisch sonst).

Das System mit den entsprechenden Subdomains halte ich auch noch mit für die beste Variante. Dass sowohl 'http://quivira-font.com', als auch 'http://www.quivira-font.com' auf dieselbe Seite verweisen dagegen für einen Fehler. ;-)
Ferner zeigt dieses Beispiel aber meinen Einwand bezüglich "sprechender" URLs, denn auf der genannten Seite haben alle Seiten_nur_englische Bezeichnungen (Zeichen = characters.php usw.).
Ein "berühmter/ bekannter" Vertreter dieses Systems ist aber z.B. Wikipedia, wo u.a. auch sehr schön deutlich wird, dass sich URLs eben auch je nach Sprache unterscheiden.
Beispiel:
http://de.wikipedia.org/wiki/Indianer
http://en.wikipedia.org/wiki/Native_Americans_in_the_United_States

Die Sprachlinks in der Seite führen zu der entsprechenden Subdomain. Da alle seiteninternen Links relativ adressiert sind, bleibt die Subdomain auch ohne Session erhalten. Bei den allgemeinen Subdomain wird immer wieder die Accept-Language ausgewertet und kommt immer wieder zum gleichen Ergebnis.

Das wiederum ist eine nicht unerhebliche Anforderung an das zugrundeliegende Script, welche dann bspw. von der jeweiligen Weblog-Software auch erstmal erfüllt werden muss.

Ferner basiert das gesamte Konzept auf einer Konfigurationseinstellung des jeweiligen Browsers, von dem ein (extrem) hoher Anteil der User mit Sicherheit nicht einmal weiß, dass es diese Option überhaupt gibt, geschweige denn weiß, wie und wo man diese nach seinen Wünschen konfiguriert.

Das ist richtig, aber den Anteil der falsch konfigurierten Browser schätze ich eher gering. Denn unbedarfte User laden sich den Browser normalerweise in ihrer Sprache runter (bzw. kaufen die entsprechende Version ihres Betriebssystems, bei dem der sprachlich passende Browser oder Internet Explorer bei ist ;-) ), und in seinen Defaulteinstellungen gibt AFAIK jeder Browser diejenige Sprache als bevorzugte an, die er auch für seine eigene GUI verwendet.
Unpassend konfigurierte Browser erwarte ich eigentlich nur auf fremden Rechnern, z.B. in einem Internet-Café im Ausland. Und für solche Fälle gibt es ja die Sprachlinks in der Seite.

Die Frage, die imo am interessantesten dabei ist, ist doch "Wie kommt der Besucher überhaupt auf meine Seite?". Und hierbei geht es in erster Linie dann wieder um die Besucher, die das erste Mal auf meine Website kommen.
Die werden i.d.R. über eine Suchmaschine kommen. Um bei deinem Beispiel 'quivira-font.com' zu bleiben, dann listet mir Google sowohl Englische, als auch Deutsche Ergebnisse auf. Klicke ich jetzt (bewußt) auf eines der englischsprachigen Suchergebnisse, lande ich trotzdem auf der deutschen Seite. Das ist u.a. eines der Probleme von "Automatismen". ;-)
Suche ich dagegen nach Quivira (ohne weitere Einstellungen), dann listet mir Google erstmal nur das englischsprachige Suchergebnis deiner Seite auf. Und das alles, wenn ich als bevorzugte Sprache 'DE' in meinem Browser eingestellt habe. Wenn ich diese auf 'EN' ändere, dann taucht deine Seite so ca. an 339ster Stelle auf
Google führt schon selbst ein "Sniffing" der bevorzugten Sprache durch, und bietet daraufhin u.a. solche Links wie "Tipp: Suchen nur nach Ergebnissen auf Deutsch." an.

Und ein weiterer Punkt ist das Problem, wenn es keine passende Sprachversion der Seite gibt. Habe ich z.B. Französisch als bevorzugte Sprache in meinem Browser eingestellt, erfahre ich bei Google nicht, dass deine Seiten auch auf Deutsch verfügbar sind, weil mir ausschließlich die Englischen Suchergebnisse angezeigt werden.

Ein simpler Link wie etwa "There is also an English version of this page" auf der Seite tut es doch auch.

Solche Links muß es natürlich immer geben, s.o.

Und wenn ich meine unterschiedlichen Sprachversionen unter verschiedenen TLDs bereitstelle, dann dürften die allermeisten User "das System" auch ziemlich schnell verstehen (weil für sie "sichtbar" gegenüber irgendwelchen "unsichtbaren Automatismen").

Ja, das ist eine Möglichkeit. Klappt aber nur, wenn Du keine länderspezifischen Inhalte hast. Beispiel: Du verkaufst was in Deutschland und der Schweiz, und Deine Seite gibt es auf Deutsch und Französisch. Hier fände ich example.de und example.fr schon recht ungeschickt, da example.fr die Franzosen in die Irre führt (sie bekommen zwar die richtige Sprache, merken aber erst beim Lesen, daß die Seite nicht für sie gedacht ist). Ich bin mir auch nicht sicher, ob französischsprachige Schweizer auf die Idee kommen, die für sie bestimmte Version unter example.fr zu suchen.
Besonders blöd wird es, wenn Du dann aus rechtlichen Gründen für Deutschland und die Schweiz verschiedene Disclaimer und AGBs hast. IMHO ist die Situation mit example.de, de.example.ch und fr.example.ch wesentlich besser und klarer adressiert.

Ja, das ist einer dieser "Spezialfälle". ;-)
Grundsätzlich sehe ich das so: Solange es sich bei länderspezifischen TLDs um Länder handelt, in denen es nur eine offizielle Amtssprache gibt, dürfte man davon ausgehen, dass die Erwartungshaltung der User so aussieht, dass sie Seiten in der jeweiligen Sprache erwarten.
Länderspezifische Inhalte sollten, wenn sie unter einer länderspezifischen TLD angeboten werden, auf jeden Fall übereinstimmen.
Das funktioniert nur dann nicht, wenn ein Land mehrere Amtssprachen hat (wie z.B. die Schweiz).
Hier bietet sich dann das System der Subdomains an, um die verschiedenen Sprachversionen unter einer landesspezifischen TLD anbieten zu können. Diese Problematik dürfte sich aber hauptsächlich im e-commerce Sektor stellen.

Bei deinem Beispielfall mit 'quivira-font.com' stellt sich diese Problematik ja bspw. nicht. Natürlich kann man es hier auch so machen (wie du es ja auch getan hast), indem man auch hier alle verschiedenen Sprachversionen unter einer (generischen) TLD mit unterschiedlichen Subdomains anbietet. Allerdings hat diese Methode auch oben beschriebene Nachteile.

Der Vorteil unterschiedlicher (und teils länderspezifischer) TLDs *könnte* aber u.a. in einer jeweils höheren Relevanz bei der Bewertung seitens der Suchmaschinen liegen.

Aber so oder so sehe ich bei keiner der Varianten einen Vorteil in (oder gar die Notwendigkeit) einer automatischen Sprachwahl per Accept Language Header. Im Gegenteil halte ich die "Mehrkosten" und potentiellen Fehlerquellen bei der Erstellung, Wartung und Pflege einer Website im Vergleich zum (für mich fraglichen) Nutzen für völlig unverhältnismäßig. Deshalb würde ich es auch nicht einsetzen und in den allermeisten Fällen auch davon abraten (im Gegensatz zu Gunnar).

Ich finde, man darf getrost davon ausgehen, dass ein User ohne größere Probleme von alleine in der Lage ist, seine bevorzugte Version unter den angebotenen Sprachversionen herauszufinden.

Gruß Gunther