Fragen/ Anmerkungen zum Accept-Language Konzept

[Længlich]

Haxajua!

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".

Das ist zwar alles richtig, aber davon werden die Übersetzungen IMHO keine neuen Bücher. Ich habe nur die englische Version gelesen, kenne dadurch aber trotzdem auch die Handlung der deutschen. Es gibt (wenn ich mich nicht explizit für die Übersetzung an sich interessiere) für mich keinen Grund, die deutsche Version auch noch zu lesen. Wenn es zwei wirklich verschiedene Bücher wären, würde ich vielleicht beide nacheinander lesen.

Aber ja, es ist Ansichtssache. Und in der Folge, daß die beiden Versionen einzeln adressierbar sein sollten, sind wir uns ja ohnehin einig.

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.

Wenn man den Titel nimmt, ja. Andere Möglichkeiten wären z.B. auch Autor und/oder Veröffentlichungsdatum.

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.

Stimmt. Da werden wir aber wohl keine abschließende Empfehlung finden, da das sehr stark vom Aufbau der jeweiligen Seite abhängt. Bei mir hat die ansonsten ungenutzte rechte obere Ecke regelrecht danach geschrieen, aber das wird bei anderen nicht immer so sein.
Zwecks Verständlichkeit gibt es ja auch diverse Ansätze, alle mehr oder weniger umstritten – am prominentesten wohl die Flaggendiskussion.

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. ;-)

Wo soll ich denn sonst mit denen hin? Eine Sprache kann ich aus »« oder »www« nicht rauslesen, und eine von beiden killen möchte ich nicht, da bei beiden von zahlreichen Benutzern erwartet wird, daß sie funktionieren.

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

Sprechende URLs in diesem Sinne habe ich ja quasi gar nicht, sondern eben nur einigermaßen passende englische Scriptnamen (sonst würde ich auch das ».php« weglassen; das interessiert den User ja auch nicht). Da ließe sich aber leicht mit mod_rewrite was machen, mal schauen.

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.

Ja, klar. Bei einem Eigenbau-Script wie meinem ist das aber nichtmal sonderlich kompliziert.

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". ;-)

Richtig. Das Problem hierbei ist, daß der Bot bei »quivira-font.com« die englische Version bekommt (soweit gut und gewollt), aber nicht weiß, daß andere Besucher eventuell eine andere Version sehen. Für ihn ist nur »de.quivira-font.com« deutsch, und die drei anderen sind die selbe englische Version.

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.

Bei Google nicht, aber durch den Sprachlink auf der Seite. Und wenn die SERP nicht explizit auf die en-Version verweist, kriegst Du u.U. direkt die deutsche Version (nämlich dann, wenn Dein Browser nach Französisch auch noch Deutsch als gern genommene Sprache angibt).

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". ;-)

Spezial vielleicht, aber nicht unbedingt selten. Praktisch jedes international operierende Unternehmen steht vor dieser Problemstellung. Selbst wenn Du Dich nur in einer Datenschutzerklärung auf §xy beziehen willst, wird sie schon länderspezifisch.

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.

ACK.

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.

Ja, bei mir wäre es, da ich keine länderspezifischen Inhalte habe, noch recht schmerzfrei mit .com und .de gegangen. Wenn Du dann allerdings wie oben beschrieben mit Französisch als Lieblingssprache gegoogelt hättest, wärst Du genauso auf der englischen Version gelandet und hättest die deutsche Version dann über den Sprachlink erreichen können. Da sehe ich keinen Vorteil.
Ein Nachteil liegt auf der Hand: Wenn ich dann mal länderspezifischen Content einbaue, bricht das System mit der Sprache in der TLD.
Ein weiterer: In manchen Ländern bekommst Du gar keine Domain, ohne dort einen Wohnsitz zu haben. Und noch einer: Zu vielen Sprachen gibt es eine naheliegende TLD, aber nicht zu allen. Welche würdest Du z.B. für Baskisch nehmen? .fr oder .es? Nicht gerade optimal. Und wenn, wohin dann mit Spanisch und Französisch?

Ich sehe in dem TLD-für-Sprachen-System viel mehr Nachteile als in der Verwendung von Subdomains.

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.

Möglich. Allerdings werde ich unter »Seiten aus Deutschland« auch so schon gefunden, also zieht Google diese Info wohl nicht aus der TLD.

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).

Okay, einen gewissen Zusatzaufwand bedeutet es natürlich schon, das gebe ich zu. Ob man den für gerechtfertigt hält, ist wieder Ansichtssache. Ich fand’s okay.

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.

Dem steht die Language Negotiation ja nicht im Wege, solange man die Sprachauswahllinks nicht rausnimmt. ;-)

Viele Grüße vom Længlich