Verschiedene Sprachen per Klick

[Simon]

Hi,
ich hoff der Themenbereich passt so ungefähr:

Da ich eine Homepage in mehreren Sprachen gestallten muss (Usereingaben usw. bleiben in der erstellen Sprache) bin ich grad am überlegen wie ich das am besten anstelle.

Ich hab schon öfters gesehen dass sowas mit JS gemacht wird nur bin ich mir dabei nicht so ganz sicher.

Ist es nicht vielleicht besser dass ich die ganzen Sachen die ich in mehreren Sprachen brauche in eine DB speicher, dann wenn ich sie brauch in ein array gebe?

Wäre froh über ein paar Tipps

MfG
Simon

[Steel]

Hoi!

Ich hab schon öfters gesehen dass sowas mit JS gemacht wird nur bin ich mir dabei nicht so ganz sicher.

Das ist auch gut so. JS fuer sowas zu benutzen ist nicht gerade die beste Wahl. (eher grober Unfug)

Ist es nicht vielleicht besser dass ich die ganzen Sachen die ich in mehreren Sprachen brauche in eine DB speicher, dann wenn ich sie brauch in ein array gebe?

Jepp. So wirds meistens gemacht. Heutzutage kommen die Inhalte der Seiten eh meist aus einer Datenbank. Da ist es nur ein kleiner Schritt auch die eher statischen Texte, wie Menueeintraege, Buttonbeschriftungen, etc. dort abzulegen.

Die Alternative ist natuerlich immer eine statische HTML Seite die fuer jede Sprache ein weiteres mal vorliegt.

Wäre froh über ein paar Tipps

Inwiefern? Eventuell welches CMS sowas kann?

[Simon]

Jepp. So wirds meistens gemacht. Heutzutage kommen die Inhalte der Seiten eh meist aus einer Datenbank. Da ist es nur ein kleiner Schritt auch die eher statischen Texte, wie Menueeintraege, Buttonbeschriftungen, etc. dort abzulegen.

Ja stimmt, da brauch in nur ein paar spalten mehr.

Die Alternative ist natuerlich immer eine statische HTML Seite die fuer jede Sprache ein weiteres mal vorliegt.

Nein, wäre nicht sinnvoll und zuviel arbeit falls sich was ändert.

Inwiefern? Eventuell welches CMS sowas kann?

Passt schon, wollt mich einfach nur versichern mit der DB

MfG
Simon

[Simon]

Was mir noch eingefallen ist:
Soll ich die Sprache in einer Session speichern oder geht es anderes besser?

[mrjerk]

Hallo,

Soll ich die Sprache in einer Session speichern oder geht es anderes besser?

Ich würde wohl idealerweise das Speichern in der Session UND in einem (permanenten, z.b. 1 Monat gültig oder so) Cookie vorsehen.

Hintergrund:
Wenn der User permanente Cookies erlaubt, kann sich der Browser seine Spracheinstellung merken und beim nächsten Besuch der Seite wieder entsprechend setzen.

Verbietet der User Cookies, so kann durch Speichern in der Session zumindest sichergestellt werden, dass innerhalb einer Browser-Session die Sprache gleich bleibt.

Viele Grüße,
Jörg

[ChrisB]

Hi,

Soll ich die Sprache in einer Session speichern oder geht es anderes besser?
Ich würde wohl idealerweise das Speichern in der Session UND in einem (permanenten, z.b. 1 Monat gültig oder so) Cookie vorsehen.

Ich würde idealster Weise beides lassen, und die Information dort unterbringen, wo sie hingehört: im URL des Dokumentes.

Hintergrund:
Wenn der User [...] Cookies erlaubt,

... dann ist er bestimmt kein Suchmaschinen-Roboter.

MfG ChrisB

[suit]

Ich würde idealster Weise beides lassen, und die Information dort unterbringen, wo sie hingehört: im URL des Dokumentes.

In einer dieser Varianten:

example.com/foo.de (nur sinnvoll, wenn die Dokumente in allen Sprachen denselben Namen haben)
de.example.com/foo
example.com/de/foo

[Gunther]

In einer dieser Varianten:

example.com/foo.de (nur sinnvoll, wenn die Dokumente in allen Sprachen denselben Namen haben)
de.example.com/foo
example.com/de/foo

oder unter verschiedenen TLDs (was AFAIK "gemeinhin" als die "beste/ idealste" Variante angesehen wird, ohne dass ich eine Diskussion darüber auslösen möchte).

Gruß Gunther

[Beat]

oder unter verschiedenen TLDs (was AFAIK "gemeinhin" als die "beste/ idealste" Variante angesehen wird, ohne dass ich eine Diskussion darüber auslösen möchte).

bätsch!

Was hat .ch mit Sprache zu tun?

mfg Beat

[Gunther]

Das war ja klar, dass wieder so ein Einwurf kommen musste.

oder unter verschiedenen TLDs (was AFAIK "gemeinhin" als die "beste/ idealste" Variante angesehen wird, ohne dass ich eine Diskussion darüber auslösen möchte).

bätsch!

Was hat .ch mit Sprache zu tun?

Keine Ahnung! Verrat' du es mir.
Dass es einen Zusammenhang zwischen einer TLD und einer Sprache gibt, habe ich aber auch nicht geschrieben. Wenn du daraus einen konstruierst/ ableitest, ist das dein Problem.

Trotzdem sehe ich als "brauchbare" Variante an, bspw. unter der TLD 'DE' die deutschsprachige Version einer Seite anzubieten und eine englischsprachige bspw. unter 'COM'.

Mein Posting hatte hauptsächlich 2 Gründe:
1. Vervollständigung der möglichen Varianten
2. Der Hinweis darauf, dass die von mir genannte Variante unter SEO-Sicht möglicherweise Vorteile gegenüber den anderen bietet.

Wenn du eine "bessere" Variante kennst, dann poste sie doch. Dann haben wir alle etwas davon.

Gruß Gunther

[Beat]

Das war ja klar, dass wieder so ein Einwurf kommen musste.

oder unter verschiedenen TLDs (was AFAIK "gemeinhin" als die "beste/ idealste" Variante angesehen wird, ohne dass ich eine Diskussion darüber auslösen möchte).

bätsch!

Was hat .ch mit Sprache zu tun?
Keine Ahnung! Verrat' du es mir.

krank!

Dass es einen Zusammenhang zwischen einer TLD und einer Sprache gibt, habe ich aber auch nicht geschrieben. Wenn du daraus einen konstruierst/ ableitest, ist das dein Problem.

Und worin liegt denn irgend eine Auswertungsvorteil gerade...

Trotzdem sehe ich als "brauchbare" Variante an, bspw. unter der TLD 'DE' die deutschsprachige Version einer Seite anzubieten und eine englischsprachige bspw. unter 'COM'.

... in SEO Hinsicht.

Die Betreiber der admin.ch Seite könnten dir auf jeden Fall den Nonsense-Ausweis bescheinigen.
Wer mehrere TLDs braucht, der hat ein Problem, das mit Sprache nichts zu tun hat. Und wenn es aus SEO-Sicht klug erscheint, TLDs zu horten, damit man keine gleichnamigen Mitkonkurrenten hat, dann hat man ein duplicate Content Problem, wodurch man dazu verdammt ist, sofort auf eine einzige Version umzuleiten.

mfg Beat

[Gunther]

Hallo Beat!

krank!

Die Betreiber der admin.ch Seite könnten dir auf jeden Fall den Nonsense-Ausweis bescheinigen.
Wer mehrere TLDs braucht, der hat ein Problem, das mit Sprache nichts zu tun hat. Und wenn es aus SEO-Sicht klug erscheint, TLDs zu horten, damit man keine gleichnamigen Mitkonkurrenten hat, dann hat man ein duplicate Content Problem, wodurch man dazu verdammt ist, sofort auf eine einzige Version umzuleiten.

Ich will mich nicht mit dir streiten. Deine Äußerungen wirken auf mich jedoch ziemlich rechthaberisch_ohne_dabei wirkliche Argumente zu nennen. Genauso vermisse ich_deine_Empfehlung, wie man denn nun unterschiedliche Sprachversionen einer Seite bereitstellen sollte.

IMO ist das ein Problem, für dass es nicht genau die eine Lösung gibt, sondern eben verschiedene Möglichkeiten, von denen jede ihre ganz eigenen Vor- & Nachteile hat.

Und ich sehe nicht, warum man eine Variante nicht wenigstens auch erwähnen sollte, nur weil_du_sie für unsinnig oder Nonsense hälst.

Mir wäre auch nicht bekannt, dass es dafür irgendwelche allgemeingültigen/ -verbindliche Standards gäbe, nach denen man sich folglich richten sollte/ müsste.

Dass diese Variante durchaus gebräuchlich ist/ verwendet wird, kannst du dir im Web an unzähligen Beispielen angucken.

Falls du keines finden solltest:
http://www.shell.de/
http://www.shell.com/

Und nochmal: Ich habe nie irgendeine Wertung oder Empfehlungen für oder gegen eine der genannten Varianten abgegeben. Das muss schlussendlich jeder für sich und seinen konkreten Fall entscheiden.
Du konstruierst hier Zusammenhänge aus Dingen, die nie jemand geschrieben oder behauptet hat und wirfst mit unbegründeten (durch nichts belegten) Behauptungen um dich.

Last but not least noch ein kurzes Zitat aus Google Webmaster/Website-Inhaber-Hilfe: "Verwenden Sie Domains auf oberster Ebene: Damit wir die richtige Version eines Dokuments bereitstellen können, sollten Sie vorzugsweise Domains der obersten Ebene verwenden, um landesspezifischen[1] Content zu präsentieren. Die Website "www.example.de" weist eher auf Deutschland-spezifischen Content hin als "www.example.com/de" oder "de.example.com"."
Aber wen interessiert schon Google ...!

Gruß Gunther

[1] Keine Ahnung, was Google nun genau darunter versteht. Aber auch wenn sie an jeder Ecke großartig auf ihr Übersetzungstool hinweisen, so glaube ich nicht, dass sie 2 Webseiten, die jeweils komplett in einer anderen Sprache verfasst sind, als Duplicate Content bewerten.

[Beat]

Last but not least noch ein kurzes Zitat aus Google Webmaster/Website-Inhaber-Hilfe: "Verwenden Sie Domains auf oberster Ebene: Damit wir die richtige Version eines Dokuments bereitstellen können, sollten Sie vorzugsweise Domains der obersten Ebene verwenden, um landesspezifischen[1] Content zu präsentieren. Die Website "www.example.de" weist eher auf Deutschland-spezifischen Content hin als "www.example.com/de" oder "de.example.com"."
Aber wen interessiert schon Google ...!

Kennst du den Unterschied zwischen Deutschland-spezifisch und Deutsch?

Nochmals die lapidare Frage: Was hat .ch mit Sprache zu tun.

Mit Recht nennt man SEO eine Gerüchteküche.

mfg Beat

[suit]

Kennst du den Unterschied zwischen Deutschland-spezifisch und Deutsch?

Genausoviel wie österreichspezifisch und deutschsprachig :)

Warum sollte ein in Österreich lebender Kroate beim Aufruf von rebell.at (schlechtes Beispiel - die Seite ist nicht Multilingual :D) Deutsch vorgesetzt bekommen und nicht Kroatisch, wenn diese Sprache verfügbar ist?

Die Auswahl der Sprache sollte immer primär von Accept-Langugage abhängig gemacht werden und sekundär (als Fallback) von ggf. andereren Faktoren (obwohl ich das nicht als sonderlich schlau erachte) - wie etwa der TLD, wo man zumindest auf die Intention des Besuchers schließen kann.

[Gunnar Bittersmann]

@@suit:

nuqneH

Die Auswahl der Sprache sollte immer primär von Accept-Langugage abhängig gemacht werden

Nein. Nicht, wenn dem Nutzer bei einem früheren Besuch dieser Website die durch Sprachvereinbarung (language negotiation) ausgehandelte Sprache nicht genehm war und er eine andere gewählt hatte und diese Information in einem Cookie festgehalten wurde.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

[…] und diese Information in einem Cookie festgehalten wurde.

bzw. in den Profildaten bei registrierten Nutzern

Qapla'

[Gunther]

@@Gunnar und suit:

Die Auswahl der Sprache sollte immer primär von Accept-Langugage abhängig gemacht werden und sekundär (als Fallback) von ggf. andereren Faktoren (obwohl ich das nicht als sonderlich schlau erachte) - wie etwa der TLD, wo man zumindest auf die Intention des Besuchers schließen kann.

Nein. Nicht, wenn dem Nutzer bei einem früheren Besuch dieser Website die durch Sprachvereinbarung (language negotiation) ausgehandelte Sprache nicht genehm war und er eine andere gewählt hatte und diese Information in einem Cookie festgehalten wurde.

[…] und diese Information in einem Cookie festgehalten wurde.
bzw. in den Profildaten bei registrierten Nutzern

Nachdem ich in diesem Thread ja sowieso schon als alleinstehend mit meiner Meinung bezeichnet wurde, will ich auch noch ein paar Anmerkungen, bzw. Fragen zu dem von euch so favorisierten Konzept beisteuern.

Ich halte dieses Konzept nämlich eher nur in einigen wenigen Ausnahmefällen für das geeignete Mittel der Wahl.

Das hat allerdings in erster Linie etwas damit zu tun, wie man bestimmte Dinge ansieht und einordnet.

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. Und jedes Dokument sollte seine eigene einzigartige URL haben.

Hinzukommt, dass es bspw. bei Blogs imo keinen Sinn macht, wenn meine "sprechende" URL aber für alle Sprachversionen dieselbe ist. Wieder ein Grund, jedem Dokument seine eigene URL zu verpassen.

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.

Nächste (wichtige) Frage: Wie sieht es mit den Suchmaschinen aus?
Was gibt ein Bot einer Suchamschine für eine Accept Language an?
Indiziert er dann nur eine evt. vorhandene und passende Version der Seite? Was ist mit den anderen Sprachversionen?
Oder gar eine Vorschalt-/ Auswahlseite?

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten 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.

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.

Ich will hier gar nicht in Abrede stellen, dass das Konzept für sich betrachtet durchaus in sich schlüssig und praktikabel erscheint. Aber eben nur für sich betrachtet. Ein "Webdesigner" muss aber immer mehrere Dinge irgendwie zusammen bringen und "unter einen Hut" kriegen. Und dabei scheinen mir zumindest die Nachteile in den allermeisten Fällen zu überwiegen.

Ein simpler Link wie etwa "There is also an English version of this page" auf der Seite tut es doch auch. 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 Autmatismen").

Das wollte ich schon seit einiger Zeit mal anmerken, u.a. weil Gunnar es ja auch "bei jeder Gelegenheit" anbringt, und der Thread passte jetzt gerade mal gut (auch auf die Gefahr hin, mit meiner Meinung abermals allein gegen den Rest des Forums zu stehen).

Gruß Gunther

[Beat]

Nur Kurz.
Ich bin einverstanden: Sprachinfo gehört in die URL.
Kein Cookie heisst oft autmatisch ein QueryString Token.
Gerade dadurch werden solche Seiten für Bots indexierbar.

Zu Meta Informationen.
Reine .txt Dateien erlauben gar keine Metainformationen. Solche Informationen können nur im HTTP-Header oder in der url transportiert werden.

Es ist Sache des Clients, die Sprache eines Dokuments zu erkennen.
HTML bietet lediglich eineige informierende Mechanismen, ohne dasss deren Fehlen das Dokument invalidieren würde.
Google erledigt mit dem Raten also seine Aufgabe als Client gegenüber .html wie .txt Dateien.

mfg Beat

[suit]

Nur Kurz.
Ich bin einverstanden: Sprachinfo gehört in die URL.

Aber nur optional.

example.com/foo = generisch
de.example.com/foo = deutschsprachig
en.example.com/foo = englischsprachig

Wenn der Benutzer "nicht sicher" ist und die generische Variante aufruft, soll die Sprache entsprechend gewählt werden.

[Længlich]

Úsài!

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?

Und jedes Dokument sollte seine eigene einzigartige URL haben.

Das aber auf jeden Fall. Schließlich soll der User die Sprachversionen ja auch gezielt ansteuern können.

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?

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.

Oder gar eine Vorschalt-/ Auswahlseite?

Bäh. Unnötig.

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten ist).

Mir wurscht, meine Seite enthält sowohl die Meta-Angabe als auch den Inhalt als auch @hreflang auf jedem Sprachlink. Da wird schon für jede Suchmaschine was bei sein.

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

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.

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.

Ich will hier gar nicht in Abrede stellen, dass das Konzept für sich betrachtet durchaus in sich schlüssig und praktikabel erscheint. Aber eben nur für sich betrachtet. Ein "Webdesigner" muss aber immer mehrere Dinge irgendwie zusammen bringen und "unter einen Hut" kriegen. Und dabei scheinen mir zumindest die Nachteile in den allermeisten Fällen zu überwiegen.

Verschiedene Vor- und Nachteile und verschiedene Anforderungen gibt es immer. Um eine Einzelfallbewertung wird man sich kaum drücken können.

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

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.

Das wollte ich schon seit einiger Zeit mal anmerken, u.a. weil Gunnar es ja auch "bei jeder Gelegenheit" anbringt, und der Thread passte jetzt gerade mal gut (auch auf die Gefahr hin, mit meiner Meinung abermals allein gegen den Rest des Forums zu stehen).

Ist durchaus eine interessante Angelegenheit und sicherlich eine ausführliche Diskussion wert. Und allein gegen den Rest stand auch Einstein. ;-)

Viele Grüße vom Længlich

[suit]

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.

Siehe z.B. hier (jeweils am Seitenende).
http://rebell.at/artikel/the-makers-of-star-wreck
http://rebell.at/artikel/die-star-wreck-macher

[Længlich]

Akakáume!

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.

Siehe z.B. hier (jeweils am Seitenende).
http://rebell.at/artikel/the-makers-of-star-wreck
http://rebell.at/artikel/die-star-wreck-macher

Nicht schlecht, aber ich würde ihn eher an den Seitenanfang setzen. Ich glaube nicht, daß ich so weit scrollen würde, wenn ich den Text nicht verstünde.
Eventuell auch noch etwas auffälliger formatieren – ich bin auch am Überlegen, ob ich ihn bei mir noch irgendwie stärker hervorheben soll.

Viele Grüße vom Længlich

[Beat]

Siehe z.B. hier (jeweils am Seitenende).
http://rebell.at/artikel/the-makers-of-star-wreck
http://rebell.at/artikel/die-star-wreck-macher

Übersetzungen von Interviews sind aus meiner Sicht echt ein Grenzfall. Ich würde das unterlassen.

mfg Beat

[suit]

Übersetzungen von Interviews sind aus meiner Sicht echt ein Grenzfall. Ich würde das unterlassen.

Naja, die Star-Wrek-Typen sprechen finnisch und englisch, Rebell.at ist seit jeher primär deutschsprachig. Ergo: Übersetzung in die Primärsprache, aber erhalt der Originalversion.

[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

[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

[Gunnar Bittersmann]

@@Gunther:

nuqneH

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

Ebendiese Seite gibt doch ein gutes Beispiel, wie man es machen kann: Positionierung der Sprachauswahl an exponierter Stelle (sofort ohne zu scrollen sichtbar!), Beschriftung in der jeweiligen Zielsprache, Globus als Symbol für L10n.

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.

In der Wikipedia unterscheiden sich auch die Inhalte je nach Sprache; im Allgemeinen ist ein Artikel zu „Foo“ in der Sprache X keine Übersetzung des Artikels zu „Foo“ in der Sprache Y. Also hier nicht das beste Beispiel.

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

Ist es vielleicht sinnvoll, die Ressource hinter dem generischen URI von SEs nicht indizieren zu lassen, sondern nur die sprachspezifischen Versionen?

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.

Grundsätzlich sehe ich das so: Genauso wenig, wie Flaggen für Sprachen stehen, stehen TLDs für Sprachen.

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.

Das ist das Problem des Webseitenbetreibers. Er sollte es lösen, nicht auf die Besucher seiner Seiten abwälzen.

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.

Warum sollte ein Nutzer damit belastet werden, wenn es ihm eine Automatik doch abnehmen kann?

Qapla'

[Gunther]

Hi!

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten ist).

Mir wurscht, meine Seite enthält sowohl die Meta-Angabe als auch den Inhalt als auch @hreflang auf jedem Sprachlink. Da wird schon für jede Suchmaschine was bei sein.

Das Wichtigste[1] fehlt aber, nämlich im Head deiner jeweiligen Seite ein <link> Eintrag für jede verfügbare andere Sprachversion der jeweiligen Seite, also bspw. auf http://en.quivira-font.com/characters.php:

<link rel="alternate" title="Quivira 3.0 – Characters" type="text/html" hreflang="de" href="http://de.quivira-font.com/characters.php">  

Und wenn die Suchmaschinen wie Google solche Angaben dann auch vernünftig auswerten würden, indem sie bspw. zu jedem Ergebnis darunter auch noch jeweils die Links zu den alternativ verfügbaren Sprachversionen liefern würden, dann wäre die gesamte Problematik imho ein ganzes Stückchen kleiner.

Gruß Gunther

[1] Ob es nun wirklich_das_Wichtigste_ist kann man diskutieren - zumindest halte ich es für sehr wichtig.

[Længlich]

'Iorana!

Das Wichtigste[1] fehlt aber, nämlich im Head deiner jeweiligen Seite ein <link> Eintrag für jede verfügbare andere Sprachversion der jeweiligen Seite, also bspw. auf http://en.quivira-font.com/characters.php:

<link rel="alternate" title="Quivira 3.0 – Characters" type="text/html" hreflang="de" href="http://de.quivira-font.com/characters.php">

  
Gute Idee, baue ich noch ein. Danke!  
  

> Und wenn die Suchmaschinen wie Google solche Angaben dann auch vernünftig auswerten würden, indem sie bspw. zu jedem Ergebnis darunter auch noch jeweils die Links zu den alternativ verfügbaren Sprachversionen liefern würden, dann wäre die gesamte Problematik imho ein ganzes Stückchen kleiner.  
  
Oh ja!  
  

> [1] Ob es nun wirklich\_das\_Wichtigste\_ist kann man diskutieren - zumindest halte ich es für sehr wichtig.  
  
Keine Ahnung, aber es kann auf jeden Fall nicht schaden, und ein großer Aufwand ist es auch nicht.  
  
Viele Grüße vom Længlich  

-- 
Mein aktueller Gruß ist:  
Rapanui (gesprochen auf der Osterinsel)

[Gunnar Bittersmann]

@@Længlich:

nuqneH

Das Wichtigste[1] fehlt aber, nämlich im Head deiner jeweiligen Seite ein <link> Eintrag für jede verfügbare andere Sprachversion der jeweiligen Seite

Gute Idee, baue ich noch ein. Danke!

Ist es wirklich eine gute Idee, dieselbe Information zweimal in ein Dokument einzubauen? In der manuellen Sprachauswahl (die unbedingt vorhanden sein sollte) ist sie ja schonmal da. Als Informatiker gefällt mir solche Redundanz nicht.

Man könnte ja auch den 'a'-Elementen in der manuellen Sprachauswahl @rel="alternate" verpassen. (Keine Ahnung, ob das SEs irgendwie beeindruckt.)

Die Alternative wäre, die manuelle Sprachauswahl ausschließlich durch 'link[@rel="alternate"]'-Elemente im 'head' zu realisieren und diese per CSS anzeigen zu lassen. Allerdings scheitert dies an IrgendEinem Browser, der sich weigert, Elemente aus dem 'head' im Viewport darzustellen.

Qapla'

[suit]

Die Alternative wäre, die manuelle Sprachauswahl ausschließlich durch 'link[@rel="alternate"]'-Elemente im 'head' zu realisieren und diese per CSS anzeigen zu lassen. Allerdings scheitert dies an IrgendEinem Browser, der sich weigert, Elemente aus dem 'head' im Viewport darzustellen.

Eine weitere Alternative wäre ggf. ein schlaues JavaScript welches die Elemente aus dem head zerlegt und im body einbaut um dort als Sprachwechsler dargestellt zu werden ;) - dann klappts auch im IE ohne per Hand redundanzen zu erzeugen.

[Beat]

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten ist).

Mir wurscht, meine Seite enthält sowohl die Meta-Angabe als auch den Inhalt als auch @hreflang auf jedem Sprachlink. Da wird schon für jede Suchmaschine was bei sein.
Das Wichtigste[1] fehlt aber, nämlich im Head deiner jeweiligen Seite ein <link> Eintrag für jede verfügbare andere Sprachversion der jeweiligen Seite, also bspw. auf http://en.quivira-font.com/characters.php:

<link rel="alternate" title="Quivira 3.0 – Characters" type="text/html" hreflang="de" href="http://de.quivira-font.com/characters.php">

  
Da der Begriff "alternate" ziemlich lose definiert ist (gleicher Inhalt in einer anderen Aufbereitung = Dokumentformat/Sprache) kann google trotz des hreflang Attributs nicht ableiten, dass es sich um eine andere Sprachversion handelt.  
  
Google muss raten. Und die sicherste Weise, Bots zum Navigieren von Files zu bewegen, sind Links.  
HTMl gibt dir zwar Hinweismethoden, aber das gilt für andere Textformate nicht.  
  

> Und wenn die Suchmaschinen wie Google solche Angaben dann auch vernünftig auswerten würden, indem sie bspw. zu jedem Ergebnis darunter auch noch jeweils die Links zu den alternativ verfügbaren Sprachversionen liefern würden, dann wäre die gesamte Problematik imho ein ganzes Stückchen kleiner.  
  
Eben hier irrst du.  
  
mfg Beat

-- 

><o(((°>           ><o(((°>  

   <°)))o><                     ><o(((°>o  
Der Valigator leibt diese Fische

[Gunther]

Da der Begriff "alternate" ziemlich lose definiert ist (gleicher Inhalt in einer anderen Aufbereitung = Dokumentformat/Sprache) kann google trotz des hreflang Attributs nicht ableiten, dass es sich um eine andere Sprachversion handelt.

Dann sollen sie ein geeignetes rel-Attribut einführen analog zu rel="canonical".

Google muss raten.

Müssten sie nicht.
Und inwieweit es Aufgabe einer Suchmaschine ist, vom Autor in einem Dokument gemachte Angaben zu "verifizieren" sei dann auch nochmal dahingestellt.

Und die sicherste Weise, Bots zum Navigieren von Files zu bewegen, sind Links.

Ist <link> keiner (dem ein Bot folgen könnte)?

HTMl gibt dir zwar Hinweismethoden, aber das gilt für andere Textformate nicht.

Keine Ahnung was du mir damit sagen willst.
Geht es hier nicht in erster Linie um HTML-Dokumente?

Und wenn die Suchmaschinen wie Google solche Angaben dann auch vernünftig auswerten würden, indem sie bspw. zu jedem Ergebnis darunter auch noch jeweils die Links zu den alternativ verfügbaren Sprachversionen liefern würden, dann wäre die gesamte Problematik imho ein ganzes Stückchen kleiner.

Eben hier irrst du.

Ja, wie immer.
Gut, dass du immer richtig liegst mit deiner Meinung und deinen Ansichten.
Ich würde mich hier gerne mit anderen Usern sachlich über verschiedene Ansichten, Meinungen und Praktiken austauschen. Dabei beanspruche ich keineswegs für mich, dass meine Meinungen und Ansichten richtig sind, oder die einzig wahren.
Das scheint mit dir aber nicht möglich zu sein - schade eigentlich. Aber wie ich schon erwähnte, wirken deine Beiträge auf mich eher rechthaberisch bis arrogant, ohne dabei wirkliche Argumente und/ oder Erläuterungen dafür zu beinhalten, warum ich bspw. "Eben hier irre". Solche Aussagen alleine helfen weder mir, noch anderen Usern wirklich weiter.

Gruß Gunther

[Beat]

Und wenn die Suchmaschinen wie Google solche Angaben dann auch vernünftig auswerten würden, indem sie bspw. zu jedem Ergebnis darunter auch noch jeweils die Links zu den alternativ verfügbaren Sprachversionen liefern würden, dann wäre die gesamte Problematik imho ein ganzes Stückchen kleiner.

Eben hier irrst du.
Ja, wie immer.

Erwartest du, dass Google für jeden Wikientrag eine Selectbox in die SERPS stellt?
Du weisst genau, wie fern dortige Sprachversionen von Translations sind.

Gut, dass du immer richtig liegst mit deiner Meinung und deinen Ansichten.

Gut dass du das einsiehst.

Ich würde mich hier gerne mit anderen Usern sachlich über verschiedene Ansichten, Meinungen und Praktiken austauschen. Dabei beanspruche ich keineswegs für mich, dass meine Meinungen und Ansichten richtig sind, oder die einzig wahren.

Und warum driftest du ins persönliche ab?

Das scheint mit dir aber nicht möglich zu sein - schade eigentlich. Aber wie ich schon erwähnte, wirken deine Beiträge auf mich eher rechthaberisch bis arrogant, ohne dabei wirkliche Argumente und/ oder Erläuterungen dafür zu beinhalten, warum ich bspw. "Eben hier irre". Solche Aussagen alleine helfen weder mir, noch anderen Usern wirklich weiter.

Es hilft dir also nicht weiter, wenn ich dich auf den Charakter von "alternate" Hinweise?

mfg Beat

[Gunnar Bittersmann]

@@Længlich:

nuqneH

Bei den allgemeinen Subdomain wird immer wieder die Accept-Language ausgewertet und kommt immer wieder zum gleichen Ergebnis.

Also eventuell immer wieder zum gleichen falschen Ergebnis. Nicht nur Sylvia wird darüber verärgert sein.

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.

Es ist aber nervig, bei der Navigation durch die Website auf jeder Seite erneut die Sprache umstellen zu müssen.

„Kann sich www.example.be nicht einfach merken, dass sie kein Flämisch lesen kann?“

Qapla'

[Længlich]

Goojee ik koo!

Bei den allgemeinen Subdomain wird immer wieder die Accept-Language ausgewertet und kommt immer wieder zum gleichen Ergebnis.

Also eventuell immer wieder zum gleichen falschen Ergebnis. Nicht nur Sylvia wird darüber verärgert sein.

Nein, sobald Sylvia einmal auf einen Sprachlink klickt, verläßt sie ja die allgemeine Subdomain. Die Vorgehensweise entspricht dem letzten Absatz im von Dir verlinkten Abschnitt des W3C-Artikels.
Mein Satz oben trifft nur zu, wenn Sylvia den Sprachlink nicht verwendet – daraus schließe ich, daß die durch Language Negotiation ausgewählte Sprache die für sie angenehmste ist (sonst würde sie ja wechseln), und halte es für richtig, daß sie auf der nächsten Seite wieder die selbe bekommt.

Viele Grüße vom Længlich

[Gunnar Bittersmann]

@@Længlich:

nuqneH

Nein, sobald Sylvia einmal auf einen Sprachlink klickt, verläßt sie ja die allgemeine Subdomain.

Mein Denkfehler.

Qapla'

[Ulysses]

Hi!

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.

Für yahoo-slurp kann ich das nicht bestätigen. Ich habe vor einiger Zeit mal den HTTP_ACCEPT_LANGUAGE-Header protokolliert, die nächsten paar Monate aber leider keinen Zugriff auf die gesammelten Daten. Jedoch finden sich im yahoo-cache Seiten (diese z.B.), die zeigen, dass yahoo-slurp einen HTTP_ACCEPT_LANGUAGE-Header sendet.
FG Ulysses

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Eigentlich hat Længlich schon (fast) alles gesagt, dennoch meine 0.02 €:

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.

Für mich sind es zwei Versionen desselben Dokuments.

Und jedes Dokument sollte seine eigene einzigartige URL haben.

Und auch jede Sprachversion eines Dokuments sollte ihren eigenen einzigartigen URI haben. Nicht zuletzt deshalb, weil von jeder Sprachversion jede andere verlinkt sein muss, damit der Nutzer die Sprache umschalten kann.

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.

Mit „meta Tags“ [sic! sic!] meinst du die 'Content-Language'-HTTP-EQUIV-Angabe? Diese gibt aber nicht die Sprache des Textes einer Webseite an.

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

Die werden über die oben erwähnten Links gefunden.

Oder gar eine Vorschalt-/ Auswahlseite?

Die sollte nicht gefunden werden, weil sie gar nicht vorhanden sein sollte.

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten ist).

Woher weißt du das?

Desweiteren ist dieses Konzept u.U. mit einem erheblichen Mehraufwand für den Autor verbunden

Fehlende Sprachvereinbarung ist u.U. mit einem erheblichen Mehraufwand für den Nutzer verbunden.

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 ein Problem der Gestaltung der UIs der Browser, nicht des Konzepts der Sprachvereinbarung.

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

Warum sollte es einem Nutzer zugemutet werden, solchen Link erst zu finden und darauf zu clicken, wenn er doch Englisch schon als bevorzugte Sprache in seinem Browser eingestellt hat? Dann soll er doch gleich das bekommen, was er möchte: die englische Sprachversion dieses Dokuments.

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Eigentlich hat Længlich schon (fast) alles gesagt, dennoch meine 0.02 €:

Ja, schön ... . :-)
Denn schließlich bist du ja einer der größten Verfechter dieses "Systems".

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.

Für mich sind es zwei Versionen desselben Dokuments.

Und hier liegt doch schon der erste Knackpunkt.
Definiere doch bitte mal "Versionen desselben Dokuments".
Unterschiedliche Versionen_eines_Dokuments kann es doch bei dem derzeitigen Konzept des Webs gar nicht geben, sondern vielmehr nur inhaltsgleiche (wenn z.B. in eine bestimmte Sprache übersetzt) Dokumente.
Dafür spricht auch

Und jedes Dokument sollte seine eigene einzigartige URL haben.

denn damit handelt es sich für mich per se schon um_unterschiedliche_Dokumente.

Und auch jede Sprachversion eines Dokuments sollte ihren eigenen einzigartigen URI haben. Nicht zuletzt deshalb, weil von jeder Sprachversion jede andere verlinkt sein muss, damit der Nutzer die Sprache umschalten kann.

Und nochmal: Ein Dokument A, welches unter einem anderen URI als Dokument B zu erreichen ist, ist ein eigenständiges Dokument. Wodurch es sich von Dokument A unterscheidet, spielt dabei erstmal überhaupt keine Rolle.

Außerdem können sich die Dokumente auch inhaltlich je nach Sprachversion unterscheiden, z.B. durch unterschiedliche Worterklärungen im Text oder andere Quellenangaben.

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.

Mit „meta Tags“ [sic! sic!] meinst du die 'Content-Language'-HTTP-EQUIV-Angabe?

Nicht nur. Genauso könntest du auch <meta name="dc.language" content="en" /> nehmen.

Diese gibt aber nicht die Sprache des Textes einer Webseite an.

Ja, Spitzfindigkeiten. Auf den von dir verlinkten Quellen finden sich dann u.a solche Aussagen:
"Meta element with Content-Language
The use of a meta element in the document head with the http-equiv attribute set to Content-Language is not mentioned directly in the HTML specification, ...
As such, it is the only currently available mechanism for authors to declare such metadata inside the document, and therefore potentially useful." - Quelle
Und genauso könnte man besagte Textstelle für die gegenteilige Argumentation heranziehen. Das ist imo übrigens ein häufiges Problem bei Texten des W3C & Co.! Da ist dann meist die Rede von "Einerseits dies, andererseits das" oder "In einigen Fällen dies, in anderen Fällen das". Das ist zumindest für "Nicht-Profis" oft wenig hilfreich. Weil anstatt dass ich eine Baustelle vernünftig abschließen kann, habe ich in Null Komma Nix auf einmal 20 Tabs in meinem Browser und mind. 3 neue Baustellen - aber das nur mal am Rande.

Alleine schon die Aussage "HTTP-EQUIV-Angabe hingegen gibt die Sprache(n) des Zielpublikums an" finde ich wenig sinnvoll. Wenn ich eine Webseite mit Englischem Text verfasse, was interessiert mich dann die Sprache des Zielpublikums!? Die kann mir doch völlig wurscht sein. Zielpublikum ist vielmehr jeder User, der des Englischen mächtig ist. Und selbst das ist nicht zwingend, denn warum sollte ich User "ausschließen" wollen, die sich die Seite ggf. übersetzen lassen wollen?
Es erscheint mir unsinnig, wenn ich als Autor irgendwelche Spekulationen anstellen soll und diese dann auch noch in mein Dokument einbauen soll.

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

Die werden über die oben erwähnten Links gefunden.

Ja, nur nach meinen Beobachtungen leider nicht (immer) unter den Suchergebnissen aufgelistet.

Oder gar eine Vorschalt-/ Auswahlseite?

Die sollte nicht gefunden werden, weil sie gar nicht vorhanden sein sollte.

Auch das ist imo wieder Ansichtssache.
Wenn ein User einen Request absetzt, der nicht eindeutig auf ein bestimmtes Dokument verweist, dann müsste dieser mit einem 404 beantwortet werden, anstatt aufgrund irgendwelcher "Parameter" zu raten, was der User jetzt eigentlich für ein Dokument haben wollte und ihm dann mit 200 einfach eines auszuliefern.
Auch wenn du das Beispiel für unpassend/ ungeeignet erachtest, ich finde es durchaus zu gebrauchen - siehe: http://wikipedia.org/
Im übrigen entsteht so eine Situation nur dann, wenn ich bspw. Subdomains für meine unterschiedlichen Sprachversionen verwende.
Wenn ich für jede Sprache eine eigene TLD verwende (Nein, die TLD gibt _nicht_die Sprache an - sie steht in keinem direkten Kontext zur jeweiligen Sprache), kann so eine Situation gar nicht eintreten.

Google bspw. ignoriert die Meta-Angaben zur Sprache auf einer Webseite und "erkennt/ ermittelt" die Sprache einer Seite automatisch (mit hoher Treffsicherheit, wenn die Seite fast ausschließlich in einer Sprache gehalten ist).

Woher weißt du das?

Das schreiben Google Mitarbeiter u.a. in den Google-Foren. Wissen tue ich das also so gesehen nicht, gehe aber bis zum Beweis des Gegenteils zumindest erstmal davon aus.
Das ist ja ein weiteres der Probleme, die sich dem Website-Admin/ -autor stellen. Gute Platzierungen in den Suchmaschinen (oder eigentlich genauer: bei Google) sind wichtig. Leider verraten die jeweiligen Firmen nicht alle Methoden und Praktiken, die sie an-/ verwenden. Also ein weiterer "Unsicherheitsfaktor". Denn aktuell würde ich bspw. Umsetzungen, die eine bessere Platzierung bei Google & Co. "versprechen", jeder Empfehlung des W3Cs vorziehen.

Desweiteren ist dieses Konzept u.U. mit einem erheblichen Mehraufwand für den Autor verbunden

Fehlende Sprachvereinbarung ist u.U. mit einem erheblichen Mehraufwand für den Nutzer verbunden.

Sorry, aber das glaube ich nun wirklich weniger. Wenn überhaupt dann besteht der Mehraufwand in einem Klick mehr, den es im übrigen bei deinem System genauso geben kann.

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 ein Problem der Gestaltung der UIs der Browser, nicht des Konzepts der Sprachvereinbarung.

Aha. Browser-Bugs bei der Interpretation von CSS sind auch ein Problem der jeweiligen Browser-Engine. Trotzdem kann man sie in der Praxis nicht einfach ignorieren.
Und es erscheint mir auch wenig sinnvoll, ein Haus auf einem "maroden" Fundament zu errichten. Sprich, wenn ein Konzept auf einer "instabilen" Grundlage basiert, dann ist es für mich nicht praxistauglich.
Das ist ja u.a. genau das, was ich mit "dass das Konzept für sich betrachtet durchaus in sich schlüssig und praktikabel erscheint" meinte. In der Praxis kann man es aber nicht nur 'isoliert' betrachten und dann fangen die Probleme/ Unzulänglichkeiten an.

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

Warum sollte es einem Nutzer zugemutet werden, solchen Link erst zu finden und darauf zu clicken, wenn er doch Englisch schon als bevorzugte Sprache in seinem Browser eingestellt hat? Dann soll er doch gleich das bekommen, was er möchte: die englische Sprachversion dieses Dokuments.

1. Ob ein Klick mehr gleich eine Zumutung darstellt, wage ich zu bezweifeln.
2. Wer einen in seiner favorisierten Sprache beschrifteten Link an exponierter Stelle nicht findet, dem kann man eh nicht helfen.
3. Propagierst du für die manuelle Sprachauswahl doch genau dasselbe Konzept.
4. Trifft das vermutlich eh nur auf den aller geringsten Teil der Besucher zu, da die meisten wohl über eine Suchmaschine kommen werden, wo sie bereits in den Suchergebnissen die "passende" Seite gefunden haben, oder über Links von anderen Webseiten, die vermutlich auch schon in der vom User gewünschten Sprache gehalten sind und dementsprechend auch gleich auf die "passende" Seite verlinken.
5. Gehst du davon aus, dass jeder User diese Einstellung in dem verwendeten Browser auch tatsächlich nach seinen Wünschen konfiguriert hat, bzw. dazu in der Lage ist. Ist dann auch noch die Frage, was wenn überhaupt, die größere "Zumutung" ist?
6. Hast du ein Problem, wenn es keine passende Spracheversion zu den vom User "gewünschten" Sprachen gibt.

Gruß Gunther

[Beat]

Für mich sind es zwei Versionen desselben Dokuments.
Und hier liegt doch schon der erste Knackpunkt.
Definiere doch bitte mal "Versionen desselben Dokuments".
Unterschiedliche Versionen_eines_Dokuments kann es doch bei dem derzeitigen Konzept des Webs gar nicht geben, sondern vielmehr nur inhaltsgleiche (wenn z.B. in eine bestimmte Sprache übersetzt) Dokumente.
Dafür spricht auch

Und jedes Dokument sollte seine eigene einzigartige URL haben.
denn damit handelt es sich für mich per se schon um_unterschiedliche_Dokumente.

Das Wort 'Dokumente' ist in diesem Fall höchst unglücklich.
Ressource ist wohl das richtige Wort.
Dokumente sind Dateien, die auf einem Filesystem liegen. Sie suggerieren einen permanenten Inhalt.
Ressourcen tun das nicht.

Dadurch muss man natürlich auch individuell feststellen:

• welche Teile einer Ressource permanent sind.
• welche Teile Resultat einer Abfrage sind, die nicht in einer url repräsentiert werden können.
• welche Teile Modifikationen der Ansicht darstellen.

Wenn Abfragen im Spiel sind, haben wir immer die Qual der Wahl:
POST oder GET oder beides
POST-Abfragenzustände können (derzeit noch) nicht von Bots indexiert oder als Lesezeichen aufgenommen werden. (Google arbeitet daran.)

Die Sprache einer Ressource kann ich als Modifikation der GUI auffassen.
Eine Modifikation der GUI bedeutet aber nicht eine automatisch Modifikation der Abfrageresultate.
Strategie: die Sprache der äusseren GUI-Schale kann als GET Data vermittelt werden. Bei geeigneten Mittel als Teil des Pfades, als Query-Parameter oder als Subdomain.

Man sollte also immer eine konkrete Anwendung im Auge behalten, bevor man eine Lösung favorisiert.

Query-Strings, obwohl in Zeiten von SEO verpönt, sind

• betrieblich notwendig
• das ursprüngliche Mittel um einen modifizierbaren Aspekt einer Ressource darzustellen.

Wenn du eine komplettübersetzung einer statischen Deutschen Seite ins Englische vornimmst, so haben wir nicht einen modifizierbaren Zustand, wir haben eine redigierte eigenständige Version.
Als autonome HTML Dateien kannst du sie mit einer individuellen url im Sinne von Pfad oder Subdomain angeben.

Wenn du diese zwei Versionen dann lediglich als Datenquelle verwendest, um eine andere Ressource zu füttern,
  dann wird die Sprache der Daten im Sinne des lang Attributs repräsentiert für den angezeigten Datenabschnitt. Nun aber hat die abfragende Ressource ihre eigene url und die Sprache der äusseren GUI mag modifizierbar sein. Abragen können modifizieren, welche Sprachversionen gefiltert ausgegeben werden. Hier ist der Querystring, und GET bzw GET/POST angesagt.

Ich wollte das einfach mal so betrachten weil
SINNVOLLE MEHRSPRACHIGKEIT meist nur in hochkomplexen Netzwerken erstellt und betreut wird und im Kontext rudimentär stimmig angedeutet wird.

Meines Wissens ist die Blender Dokumentation ein gutes Beispiel davon, dass koordinierte Übersetzung oft fehl schlägt, da sich dort für englisch und deutsch zwei eigene Dokumentations-Communities gebildet haben, die nicht miteinander kommunizieren.

Andere Bereiche sind die Touristen- und Reisebranche. Sie müssen mehrsprachige GUIs vorhalten, haben aber oft mit Datenbeständen zu tun, für die keine intensive Sprachbetreuung notwenidg ist (Fahrzeiten von Zügen etc...)

Der Laie und Einzelkämpfer ist um so mehr in aller Regel ausserstande, Mehrsprachigkeit überhaupt zu betreuen, ausser in demonstrativen Versuchen oder in halbherzigen CMS GUIs.
Wo eine Website nicht mehrheitlich mehrsprachig abgebildet werden kann, macht meiner Ansicht nach language-negotiation wirklich keinen Sinn.
Für eine ausnahmsweise ordentlich übersetzte statische Seite ist das schlicht ein Overkill.
Hier ist der ausdrückliche Link zu einer anderssprachigen Version, wie du ihn in einem anderen Posting vorschlugst, die richtige Wahl.

Zum Schluss aber ein weiterer wichtiger Punkt.
Jede Datenquellenklasse, welcher möglicher Sprachversion unterliegt, braucht die Metainformation Sprache, und zwar unabhängig davon, wie die Datenquelle gespeichert wurde.
Soweit ich weiss, kümmert sich niemand darum, die Sprache zu erfassen, zu speichern, und bei abfragen und ausgaben zu berücksichtigen, in welcher Forengäste oder andere Artikelsupplier Formulare befüllen.

mfg Beat

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Unterschiedliche Versionen_eines_Dokuments kann es doch bei dem derzeitigen Konzept des Webs gar nicht geben, sondern vielmehr nur inhaltsgleiche (wenn z.B. in eine bestimmte Sprache übersetzt) Dokumente.

Ja, wenn wir denn Erbsen zählen, ist der Begriff „inhaltsgleich“ besser als „dasselbe“.

Und jedes Dokument sollte seine eigene einzigartige URL haben.
denn damit handelt es sich für mich per se schon um_unterschiedliche_Dokumente.

Ach ja? Hinter den voneinander verschiedenen URIs http://example.net und http://www.example.net verbergen sich i.A. dieselben Dokumente. Und das ist auch gut so.[tm]

Und nochmal: Ein Dokument A, welches unter einem anderen URI als Dokument B zu erreichen ist, ist ein eigenständiges Dokument. Wodurch es sich von Dokument A unterscheidet, spielt dabei erstmal überhaupt keine Rolle.

Doch. Wenn A und B inhaltsgleich (äquivalent) sind, bietet sich Sprachvereinbarung unter einem generischen URI an.

Außerdem können sich die Dokumente auch inhaltlich je nach Sprachversion unterscheiden, z.B. durch unterschiedliche Worterklärungen im Text oder andere Quellenangaben.

„Sprachvereinbarung [ist] irrelevant, wenn die Seiten nicht äquivalent sind, also in verschiedenen Sprachen nicht den gleichen Inhalt haben.“ [WHEN-LANG-NEG]

Diese gibt aber nicht die Sprache des Textes einer Webseite an.
Ja, Spitzfindigkeiten.

Nein. [HTTP-AND-LANG]

Auf den von dir verlinkten Quellen finden sich dann u.a solche Aussagen: […]
Und genauso könnte man besagte Textstelle für die gegenteilige Argumentation heranziehen.

??

Wenn ich eine Webseite mit Englischem Text verfasse, was interessiert mich dann die Sprache des Zielpublikums!? Die kann mir doch völlig wurscht sein. Zielpublikum ist vielmehr jeder User, der des Englischen mächtig ist.

Also ist die Sprache des Zielpublikums in diesem Fall Englisch.

Und selbst das ist nicht zwingend, denn warum sollte ich User "ausschließen" wollen, die sich die Seite ggf. übersetzen lassen wollen?

??

Indiziert er dann nur eine evt. vorhandene und passende Version der Seite? Was ist mit den anderen Sprachversionen?
Die werden über die oben erwähnten Links gefunden.
Ja, nur nach meinen Beobachtungen leider nicht (immer) unter den Suchergebnissen aufgelistet.

Wenn man nach englischen Begriffen sucht, wäre es auch verwunderlich, wenn unter den Suchergebnissen auch die deutsche Übersetzung auftaucht, die die englischen Begriffe gar nicht enthält.

Wenn ein User einen Request absetzt, der nicht eindeutig auf ein bestimmtes Dokument verweist, dann müsste dieser mit einem 404 beantwortet werden,

Ein generischer URI verweist auf ein bestimmtes Dokument. Von diesem wird eine bestimmte Sprachversion ausgeliefert; von „not found“ kann keine Rede sein.

anstatt aufgrund irgendwelcher "Parameter" zu raten, was der User jetzt eigentlich für ein Dokument haben wollte

Content negotiation ist keine Raterei.

Fehlende Sprachvereinbarung ist u.U. mit einem erheblichen Mehraufwand für den Nutzer verbunden.
Sorry, aber das glaube ich nun wirklich weniger. Wenn überhaupt dann besteht der Mehraufwand in einem Klick mehr,

Und der Wartezeit auf die nächste Seite. Das ist genau ein Click und die Wartezeit zu viel.

den es im übrigen bei deinem System genauso geben kann.

Wenn die Einstellungen im Browser nicht den tatsächlichen Wünschen des Nutzers entsprechen, ja.

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.

Ja. Aber von diesem „(extrem) hohe[n] Anteil der User“ hat ein (extrem) hoher Anteil den Browser in der Sprachversion installiert, in der sie auch Webseiten am liebsten zu lesen bekommen möchten. Sprachvereinbarung bringt ihnen also das gewünschte Ergebnis. Diese Nutzer müssen dann gar nicht unbedingt wissen, wie man die bevorzugten Sprachen im Browser einstellt.

1. Ob ein Klick mehr gleich eine Zumutung darstellt, wage ich zu bezweifeln.

Alles, was den Nutzer unnötig belastet und von seinem Ziel abhält, ist für ihn eine Zumutung.

3. Propagierst du für die manuelle Sprachauswahl doch genau dasselbe Konzept.

Ja, klar. Sprachvereinbarung – „fast immer, aber nicht ausschließlich.“ [WHEN-LANG-NEG]

5. Gehst du davon aus, dass jeder User diese Einstellung in dem verwendeten Browser auch tatsächlich nach seinen Wünschen konfiguriert hat, bzw. dazu in der Lage ist.

Nein, denn wenn das nicht der Fall ist, steht die manuelle Sprachauswahl zur Verfügung.

Ich sehe keinen Grund, den vielen Nutzern, deren Browser (mit oder ohne ihres Zutun) ihren Wünschen entsprechend konfiguriert sind, automatisch die richtige Sprachversion auszuliefern.

6. Hast du ein Problem, wenn es keine passende Sprachversion zu den vom User "gewünschten" Sprachen gibt.

Das ist kein Argument gegen Sprachvereinbarung, denn das Problem besteht ohne Sprachvereinbarung auch.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Berichtigung:

Ich sehe keinen Grund, den vielen Nutzern, deren Browser (mit oder ohne ihres Zutun) ihren Wünschen entsprechend konfiguriert sind, <ins>nicht</ins> automatisch die richtige Sprachversion auszuliefern.

Und nach einigem Überlegen ist mir auch noch ein Beispiel eingefallen, wo Textsprache und Sprache des Zielpublikums unterschiedlich sind:

Jiddisch ist für Deutsche ja durchaus verständlich; hebräische Buchstaben lesen können allerdings die wenigsten, wohl aber Jiddisch in lateinischer Transkription.

Jiddisch in lateinischen Buchstaben geschrieben wäre also:

Textsprache (@lang/@xml:lang des 'html'-Elements): yi (genauer: yi-Latn)

Sprache(n) des Zielpublikums (Content-Language im HTTP-Header/HTTP-EQUIV-Angabe im Dokument): de (oder auch: de,en,es,fr,…); nicht aber yi (denn dieses Zielpublikum würde den Text ja in hebräischer Schrift erwarten)

Qapla'

[Gunther]

@@Gunnar:

nuqneH

Und jedes Dokument sollte seine eigene einzigartige URL haben.
denn damit handelt es sich für mich per se schon um_unterschiedliche_Dokumente.

Ach ja? Hinter den voneinander verschiedenen URIs http://example.net und http://www.example.net verbergen sich i.A. dieselben Dokumente. Und das ist auch gut so.[tm]

Das sehe ich (und definitiv nicht nur ich) anders - siehe u.a.: URL normalization

Und nochmal: Ein Dokument A, welches unter einem anderen URI als Dokument B zu erreichen ist, ist ein eigenständiges Dokument. Wodurch es sich von Dokument A unterscheidet, spielt dabei erstmal überhaupt keine Rolle.

Doch. Wenn A und B inhaltsgleich (äquivalent) sind, bietet sich Sprachvereinbarung unter einem generischen URI an.

Das setzt zusätzlich aber auch noch voraus, dass nicht nur die Dokumente inhaltsgleich (äquivalent) sind, sondern auch der Dokumentname. Damit fallen dann schon mal alle Anwendungen raus, die sprechende URLs (die ich für sehr "nützlich" erachte) verwenden.

Außerdem können sich die Dokumente auch inhaltlich je nach Sprachversion unterscheiden, z.B. durch unterschiedliche Worterklärungen im Text oder andere Quellenangaben.

„Sprachvereinbarung [ist] irrelevant, wenn die Seiten nicht äquivalent sind, also in verschiedenen Sprachen nicht den gleichen Inhalt haben.“ [WHEN-LANG-NEG]

Was das W3C ja aber quasi in 'Multilingual, changed content' empfiehlt.
Fallen also weitere Sites aus.

Indiziert er dann nur eine evt. vorhandene und passende Version der Seite? Was ist mit den anderen Sprachversionen?
Die werden über die oben erwähnten Links gefunden.
Ja, nur nach meinen Beobachtungen leider nicht (immer) unter den Suchergebnissen aufgelistet.

Wenn man nach englischen Begriffen sucht, wäre es auch verwunderlich, wenn unter den Suchergebnissen auch die deutsche Übersetzung auftaucht, die die englischen Begriffe gar nicht enthält.

Das ist aber bspw. i.d.R. bei jeglichen Fachartikeln nicht der Fall. So wird auf einer in Deutsch verfassten Seite mit an Sicherheit grenzender Wahrscheinlichkeit der Begriff 'CSS' oder 'Cascading Style Sheet' genauso auftauchen, wie in der Englischen Fassung.

Wenn ein User einen Request absetzt, der nicht eindeutig auf ein bestimmtes Dokument verweist, dann müsste dieser mit einem 404 beantwortet werden,

Ein generischer URI verweist auf ein bestimmtes Dokument.

Ja, dann kann dieses auch, ohne irgendwelche sonstige Dinge im Hintergrund, ausgeliefert werden.

Von diesem wird eine bestimmte Sprachversion ausgeliefert; von „not found“ kann keine Rede sein.

Der Punkt um den es mir hierbei geht ist der: Entweder setzt ein User einen eindeutigen Request ab und erhält daraufhin das angeforderte Dokument ausgeliefert, oder alles andere führt zu einem 404er. Das Konzept der Sprachvereinbarung hebelt dieses einfache Konzept aus, indem es dem User unter Umständen ein Dokument ausliefert, welches dieser in dieser Form gar nicht haben wollte -> schlecht!

Fehlende Sprachvereinbarung ist u.U. mit einem erheblichen Mehraufwand für den Nutzer verbunden.
Sorry, aber das glaube ich nun wirklich weniger. Wenn überhaupt dann besteht der Mehraufwand in einem Klick mehr,

Und der Wartezeit auf die nächste Seite.

Das war vielleicht vor 10 Jahren noch ein Argument - heute imho eher weniger.

Das ist genau ein Click und die Wartezeit zu viel.

Da das mit Sprachvereinbarung genauso passieren kann, also so oder so (in wenigen Ausnahmefällen) eben unvermeidlich.

den es im übrigen bei deinem System genauso geben kann.

Wenn die Einstellungen im Browser nicht den tatsächlichen Wünschen des Nutzers entsprechen, ja.

Beispiel:
Deine Website bietet ein Dokument in Deutsch und Französisch an. Jetzt kommt der Spanier zu Besuch, der auch noch Portugiesisch und Englisch spricht vorbei. Er hat seinen Browser seinen Wünschen entsprechend auch auf Spanisch, Englisch und Portugiesisch konfiguriert. Und nu? Schuld des Users?

Der m.M.n. viel entscheidendere Punkt dabei ist doch eher die Frage, wieso so ein User überhaupt jemals auf deiner Seite landen sollte?

Lässt du dir von der Suchmaschine deiner Wahl Ergebnisse auf Arabisch, Chinesisch oder Japanisch anzeigen (jetzt mal vorausgesetzt, du bist dieser Sprachen nicht mächtig, so wie ich)?

Und würdest du auf einen Link klicken, der in einer Sprache verfasst ist, die du nicht verstehst? Nur um dann ggf. zu gucken, ob diese Website dir aufgrund deiner Einstellungen im Browser nicht doch eine für dich verständliche Version anbietet?

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.

Ja. Aber von diesem „(extrem) hohe[n] Anteil der User“ hat ein (extrem) hoher Anteil den Browser in der Sprachversion installiert, in der sie auch Webseiten am liebsten zu lesen bekommen möchten. Sprachvereinbarung bringt ihnen also das gewünschte Ergebnis. Diese Nutzer müssen dann gar nicht unbedingt wissen, wie man die bevorzugten Sprachen im Browser einstellt.

Das stimmt alles wieder nur solange, wie es eine Übereinstimmung zwischen den gewünschten und den vorhandenen Sprachen gibt.

1. Ob ein Klick mehr gleich eine Zumutung darstellt, wage ich zu bezweifeln.

Alles, was den Nutzer unnötig belastet und von seinem Ziel abhält, ist für ihn eine Zumutung.

Aha, Sprachvereinbarung mitunter also auch.

3. Propagierst du für die manuelle Sprachauswahl doch genau dasselbe Konzept.

Ja, klar. Sprachvereinbarung – „fast immer, aber nicht ausschließlich.“ [WHEN-LANG-NEG]

5. Gehst du davon aus, dass jeder User diese Einstellung in dem verwendeten Browser auch tatsächlich nach seinen Wünschen konfiguriert hat, bzw. dazu in der Lage ist.

Nein, denn wenn das nicht der Fall ist, steht die manuelle Sprachauswahl zur Verfügung.

Ich sehe keinen Grund, den vielen Nutzern, deren Browser (mit oder ohne ihres Zutun) ihren Wünschen entsprechend konfiguriert sind, automatisch die richtige Sprachversion auszuliefern.

6. Hast du ein Problem, wenn es keine passende Sprachversion zu den vom User "gewünschten" Sprachen gibt.

Das ist kein Argument gegen Sprachvereinbarung, denn das Problem besteht ohne Sprachvereinbarung auch.

Also ist es doch eins dagegen, denn dann bringt mir der hohe Aufwand für die Sprachvereinbarung keinen Nutzen. Aufwand ohne Nutzen -> schlecht!

Ich denke, wir können das hier aber jetzt auch mal abschließen. Es dürften wohl genügend Punkte diskutiert, und unterschiedliche Meinungen und Ansichten geäußert worden sein, dass sich jeder selbst eine Meinung bilden kann, bzw. genügend Quellen vorfindet, um sich weiter zu informieren.

Was mir nur immer aufstößt, ist deine beharrliche Aussage: "Es ist immer angebracht, Sprachvereinbarung (language negotiation) einzusetzen."!
Beispiele gefällig? Bitte:
http://forum.de.selfhtml.org/archiv/2009/2/t182801/#m1213135
http://forum.de.selfhtml.org/archiv/2009/3/t184548/#m1224157
http://forum.de.selfhtml.org/archiv/2009/3/t184805/#m1225571
Zwar verlinkst du auch immer auf http://www.w3.org/International/questions/qa-when-lang-neg, aber trotzdem erweckst du damit imho einen falschen Eindruck.

Denn wenn ich mir angucke in wievielen Fällen

• nicht inhaltsgleiche/ äquivalente Dokumente je nach Sprachversion
• keine gleichen Dateinamen (z.B. bei "sprechenden" URLs)
• keine passende Sprachversion vorhanden
• User hat keine Möglichkeit den verwendeten Browser entsprechend zu konfigurieren (z.B. Internet-Café)
• Browser-Bugs (siehe http://forum.de.selfhtml.org/archiv/2009/3/t184379/#m1222857)

Sprachvereinbarung nicht angebracht, oder von Vorteil ist,
und dem gegenüber den Aufwand dafür betrachte

• Server Konfiguration
• Einschränkungen im URL-Design
• Session/ Cookie Handling im Script

und das dann noch mit der Größe der "potentiellen Zielgruppe"

• imho im wesentlichen beschränkt auf Erstbesucher, die nicht richtig gesucht haben oder einem ihnen "fremdsprachlichen" Link gefolgt sind

in Relation setze,
verglichen mit der (einmaligen) Zumutung für einen User, zusätzlich einmal einen weiteren Link anzuklicken und somit eine Seite zusätzlich laden zu müssen, dann ist

mein Fazit: Sprachvereinbarung ist eher in den wenigsten Fällen angebracht!

Und selbst da, wo sie evt. angebracht wäre, gibt es viel zu viele "Fallstricke", weil etliche verschiedene Bereiche da mit hinein spielen, die alle korrekt gehandhabt werden müssen, damit die ganze Sache nachher auch wirklich funktioniert.

Ob sich dieser ganze Aufwand mit den damit verbundenen Fehlerquellen für einen meiner Meinung nach minimalen User Kreis überhaupt lohnt, muss jeder selber wissen.

Gruß Gunther

[Gunnar Bittersmann]

@@Gunther:

nuqneH

Ach ja? Hinter den voneinander verschiedenen URIs http://example.net und http://www.example.net verbergen sich i.A. dieselben Dokumente. Und das ist auch gut so.[tm]
Das sehe ich (und definitiv nicht nur ich) anders - siehe u.a.: URL normalization

Worin siehst du einen Widerspruch zwischen dem dort unter “Removing ‘www’ as the first domain label” und dem von mir Gesagtem?

Doch. Wenn A und B inhaltsgleich (äquivalent) sind, bietet sich Sprachvereinbarung unter einem generischen URI an.
Das setzt zusätzlich aber auch noch voraus, dass nicht nur die Dokumente inhaltsgleich (äquivalent) sind, sondern auch der Dokumentname. Damit fallen dann schon mal alle Anwendungen raus, die sprechende URLs (die ich für sehr "nützlich" erachte) verwenden.

Was spricht dagegen, die generische Ressource http://example.net/why_language_negotiation_is_useful per serverseitiger Weiterleitung auch als http://example.net/warum_sprachvereinbarung_nützlich_ist anzubieten?

Der Punkt um den es mir hierbei geht ist der: Entweder setzt ein User einen eindeutigen Request ab und erhält daraufhin das angeforderte Dokument ausgeliefert, oder alles andere führt zu einem 404er. Das Konzept der Sprachvereinbarung hebelt dieses einfache Konzept aus, indem es dem User unter Umständen ein Dokument ausliefert, welches dieser in dieser Form gar nicht haben wollte -> schlecht!

Hier vermischt du zwei Dinge. Es gibt keine Direktverbindung zwischen Nutzer und Server. Es gibt eine Verbindung zwischen Nutzer und seinem Browser (das UI) und eine zwischen Browser und Server (HTTP).

Ein Sever kann niemals das liefern, was ein Nutzer haben will, sonden immer nur das, was der Client angibt haben zu wollen.

Und Sprachvereinbarung tut genau dies. Sie liefert dem Client(!) unter keinen Umständen ein Dokument aus, welches dieser in dieser Form gar nicht haben wollte -> gut!

Wenn was ein Nutzer haben will und was der Client angibt haben zu wollen nicht übereinstimmt, ist das keine Schwachstelle des Konzepts der Sprachvereinbarung.

Deine Website bietet ein Dokument in Deutsch und Französisch an. Jetzt kommt der Spanier zu Besuch, der auch noch Portugiesisch und Englisch spricht vorbei. Er hat seinen Browser seinen Wünschen entsprechend auch auf Spanisch, Englisch und Portugiesisch konfiguriert. Und nu?

Er bekommt das Dokument entweder in der Sprachversion, die als Default eingestellt ist, oder einen Hinweis, in welchen Sprachen das Dokument verfügbar ist.

Und würdest du auf einen Link klicken, der in einer Sprache verfasst ist, die du nicht verstehst? Nur um dann ggf. zu gucken, ob diese Website dir aufgrund deiner Einstellungen im Browser nicht doch eine für dich verständliche Version anbietet?

Nein. Wie gesagt, die Suchmaschine sollte alle Sprachversionen des Dokuments kennen, so dass die für mich verständliche Sprachversion unter den Suchtreffern ist.

Alles, was den Nutzer unnötig belastet und von seinem Ziel abhält, ist für ihn eine Zumutung.
Aha, Sprachvereinbarung mitunter also auch.

?? Wie sollte Sprachvereinbarung den Nutzer belasten? Sie entlastet die meisten Nutzer.

Das ist kein Argument gegen Sprachvereinbarung, denn das Problem besteht ohne Sprachvereinbarung auch.
Also ist es doch eins dagegen, denn dann bringt mir der hohe Aufwand für die Sprachvereinbarung keinen Nutzen.

Du ziehst dich immer wieder an den kleinen Teil der Nutzer hoch, für die Sprachvereinbarung nicht die für sie passende Sprachversion liefert. Für die allermeisten Nutzer tut sie das jedoch, ist also nützlich.

• Browser-Bugs (siehe http://forum.de.selfhtml.org/archiv/2009/3/t184379/#m1222857)

Die Einstellung der bevorzugten Sprachen (mit Prioritätenreihenfolge) ist in Chrome schon längst implementiert.

Auch für Safari lassan sich die bevorzugten Sprachen einstellen – übers Betriebssystem (siehe http://forum.de.selfhtml.org/archiv/2009/3/t184379/#m1222909). (Safari für Windows ist kein ernstzunehmender Browser.)

und das dann noch mit der Größe der "potentiellen Zielgruppe"

• imho im wesentlichen beschränkt auf Erstbesucher

Nein, auch auf alle Besucher, bei denen Sprachvereinbarung bei vorigen Besuchen der Seite das richtige Ergebnis gebracht hat. Also auf die Mehrheit. (Von „beschränkt“ würde ich dann nicht reden.)

die nicht richtig gesucht haben oder einem ihnen "fremdsprachlichen" Link gefolgt sind

Oft folgen Nutzer auch Links nicht von einer Suchmaschine, sondern von anderen Webseiten. Und wenn diese URIs dann generisch sind, bekommt fast jeder Nutzer automatisch die Sprachversion, die ihm am besten passt.

„Sprachvereinbarung ist nützlich, denn wenn Jaap einen Link innerhalb von www.example.be an Pierre mailt, bekommt Pierre die französische Version zu lesen, obwohl Jaap die flämische gelesen hatte.“ [WHEN-LANG-NEG]

Früher war dies für Nutzer mit Präferenz "de,en" bei Artikel noch die englische Version. Dann hatte sich irgendjemand ;-) die Mühe gemacht, das zu übersetzen, und nun ist es die deutsche –  unter demselben URI! Besser geht’s nicht.

Qapla'

[Ulysses]

Hi!

„Sprachvereinbarung ist nützlich, denn wenn Jaap einen Link innerhalb von www.example.be an Pierre mailt, bekommt Pierre die französische Version zu lesen, obwohl Jaap die flämische gelesen hatte.“ [WHEN-LANG-NEG]

Früher war dies für Nutzer mit Präferenz "de,en" bei Artikel noch die englische Version. Dann hatte sich irgendjemand ;-) die Mühe gemacht, das zu übersetzen, und nun ist es die deutsche –  unter demselben URI! Besser geht’s nicht.

Leider vergisst man offensichtlich auch beim W3C dies konsequent durchzuziehen. So wird beim Artikel Apache MultiViews language negotiation set up unter „Further reading“ ausgerechnet für den Artikel "When to use language negotiation“ ein sprachspezifischer URI angegeben (http://www.w3.org/International/questions/qa-when-lang-neg.en)

FG Ulysses

[Gunnar Bittersmann]

@@Ulysses:

nuqneH

Leider vergisst man offensichtlich auch beim W3C dies konsequent durchzuziehen. So wird beim Artikel Apache MultiViews language negotiation set up unter „Further reading“ ausgerechnet für den Artikel "When to use language negotiation“ ein sprachspezifischer URI angegeben (http://www.w3.org/International/questions/qa-when-lang-neg.en)

Autsch! Danke für den Hinweis. Ich werd ihn bei Gelegenheit an Richard Ishida weiterleiten.

Qapla'

[Gunther]

Kennst du den Unterschied zwischen Deutschland-spezifisch und Deutsch?

Ja.

Nochmals die lapidare Frage: Was hat .ch mit Sprache zu tun.

Nochmals die lapidare Frage: Wer sagt, dass es etwas damit zu tun hat?

Mit Recht nennt man SEO eine Gerüchteküche.

Wie man es nennt und ob da was dran ist, spielt doch gar keine Rolle. Fest steht aber, dass es auf den Ergebnisseiten der Suchmaschinen immer eine Reihenfolge gibt und dass es für so manchen Webseitenbetreiber von Interesse ist, bei bestimmten Suchbegriffen möglichst weit oben zu stehen.

Die Diskussion, die du anscheinend gerne führen möchtest, hat nichts mit meinem ursprünglichen Posting zu tun und ich habe nicht vor das andere Thema mit dir zu diskutieren. Dazu gibt es, wie ebenfalls bereits erwähnt, ausreichend Archivmaterial. Du stellst nur m.M.n. den unzulässigen Schluss her, dass eine TLD automatisch immer etwas mit der Sprache einer Website zu tun haben muss. Das ist alleine bei generischen TLDs ja zwangsläufig schon mal nicht möglich. Und außerdem vermisse ich immer noch irgendwelche Argumente deinerseits.

Aber du kannst ja gerne einen neuen Thread aufmachen, wenn du das Thema nochmal diskutieren möchtest. Vielleicht poste ich dann da auch meine persönliche Meinung zu_diesem_Thema.

Gruß Gunther

[Beat]

Du stellst nur m.M.n. den unzulässigen Schluss her, dass eine TLD automatisch immer etwas mit der Sprache einer Website zu tun haben muss.

krank!

Deine Meinung ist hier wohl einzigartig.
Ich versuche dies von Anfang an in Abrede zu stellen und dementsprechend auch den Nutzen der TLD als Sprachhinweis in Frage zu stellen.

Das ist alleine bei generischen TLDs ja zwangsläufig schon mal nicht möglich. Und außerdem vermisse ich immer noch irgendwelche Argumente deinerseits.

.de hat mehr mit einem Rechtsgebiet zu tun und tendenziell mit einem locale, das vielerlei Parameter aufweist.
Währung, Dezimalkomma
unverbindlich: Rechtsgebiet.
und wie Google andeutet: Landeszentriert.
dem gegenüber stehen generische TLDs, die entweder ein commerzielles globales Interesse verfechten .com, oder interessenorientiert sind wie .org.
Dabei waren dies zu Beginn reine US TLDs.

Eine TLD gibt also eine Information vor, welche sich mit Sprache eher zufällig deckt. Deshalb sollte man die TLD nicht als Sprachinformation verwenden, und dein zitierter Güggelitext gibt auch keine solche Empfehlung.

Was sich hingegen deckt, sind google de und example.de. Das ist der Kern deines Punktes, aber er hat immer noch nichts mit Sprache zu tun.

mfg Beat

[Gunther]

Du stellst nur m.M.n. den unzulässigen Schluss her, dass eine TLD automatisch immer etwas mit der Sprache einer Website zu tun haben muss.

krank!

Also so langsam fasse ich das als Beleidigung auf, und würde dich von daher sehr bitten, dich "normal" auszudrücken - danke!

Deine Meinung ist hier wohl einzigartig.

Das mag ja sein (, was ich allerdings nicht wirklich glaube).

Ich versuche dies von Anfang an in Abrede zu stellen und dementsprechend auch den Nutzen der TLD als Sprachhinweis in Frage zu stellen.

Und im selben Satz tust du es doch schon wieder: "den Nutzen der TLD als Sprachhinweis"
Davon war nie die Rede!
Es ging und geht einzig darum, dass wenn ich bspw. eine Website mit deutschen Texten unter einer DE Domain bereitstelle, wie ich diese dann auch in anderen Sprachen anbieten kann!
Und wenn du dich noch so sehr darüber aufregst, oder es gar "krank" findest, bleibe ich dabei, dass man dafür auch verschiedene TLDs verwenden kann. Ob es dir nun passt oder nicht. Wenn du eine TLD als "Sprachhinweis" interpretierst, kann ich ja nichts dafür.
Und nochmal: Ich habe mit keinem Wort erwähnt, dass das die "beste" oder "einzig sinnvolle" Methode ist. Hier ging es in erster Linie darum, suits Varianten zu vervollständigen.

Das ist alleine bei generischen TLDs ja zwangsläufig schon mal nicht möglich. Und außerdem vermisse ich immer noch irgendwelche Argumente deinerseits.

.de hat mehr mit einem Rechtsgebiet zu tun und tendenziell mit einem locale, das vielerlei Parameter aufweist.
Währung, Dezimalkomma
unverbindlich: Rechtsgebiet.
und wie Google andeutet: Landeszentriert.
dem gegenüber stehen generische TLDs, die entweder ein commerzielles globales Interesse verfechten .com, oder interessenorientiert sind wie .org.
Dabei waren dies zu Beginn reine US TLDs.

Das mag ja alles richtig sein (oder auch nicht). Und was hat das mit dem eigentlichen Thema zu tun?

Eine TLD gibt also eine Information vor, welche sich mit Sprache eher zufällig deckt.

Oder eben auch nicht - na und?
Gibt es irgendwelche "Vorschriften" darüber, in welcher Sprache die Inhalte unter einer bestimmten TLD verfasst sein müssen? Wohl eher nicht.
Wenn überhaupt, dann hat es wohl am ehesten etwas mit der Erwartungshaltung von Usern zu tun.

Deshalb sollte man die TLD nicht als Sprachinformation verwenden,

Das sagt ja auch keiner.
Nur du willst mir (uns) das hier die ganze einreden.

und dein zitierter Güggelitext gibt auch keine solche Empfehlung.

Da stimme ich dir zu. Der war auch in erster Linie zu den Punkten SEO und Duplicate Content gedacht.

Ich glaube auch nicht, dass Google irgendwo eine Empfehlung bezüglich der Gestaltung/ Struktur mehrsprachiger Websites gibt (jedenfalls ist mir keine bekannt - würde mich aber durchaus über einen entsprechenden Link freuen), weil es eben keine_eindeutig_beste Lösung gibt.

Was sich hingegen deckt, sind google de und example.de. Das ist der Kern deines Punktes, aber er hat immer noch nichts mit Sprache zu tun.

Keine Ahnung was du meinst.

Für mich hat sich das Thema aber auch jetzt erledigt.
Ich denke wir sind uns wenigstens darin einig, dass eine TLD nichts über die Sprache der Site aussagt. Das schließt aber imho keinesfalls aus, verschiedene Sprachversionen einer Site unter verschiedenen TLDs anzubieten.

Gruß Gunther

[suit]

oder unter verschiedenen TLDs (was AFAIK "gemeinhin" als die "beste/ idealste" Variante angesehen wird,

Eine länderspezifische TLD als Sprachkennzeichnung zu verwenden ist mindestens genauso dumm[1] wie Flaggen zur Sprachkennzeichnung zu verwenden.

ohne dass ich eine Diskussion darüber auslösen möchte).

Du bist gut :) du gehst wohl auch zum Friseur, ohne dir die Haare "machen" lassen zu wollen.

[1] ich möchte damit nicht ausdrücken, dass die breite Masse dumm ist :p

[Der Martin]

Hallo,

du gehst wohl auch zum Friseur, ohne dir die Haare "machen" lassen zu wollen.

ich habe noch nicht erlebt, dass beim Friseur Haare "gemacht" wurden. Wär vielleicht 'ne tolle Sache für manche Männer mit größer werdender Stirn. ;-)

Aber mein Kollege war vor einiger Zeit auch sprachlos, als er nachmittags erwähnte, er müsse heute etwas früher gehen - er habe noch einen Termin beim Friseur, damit er wieder schön werde. Ich habe ihn nur kritisch angesehen und gesagt, "Nee, vergiss es, heutzutage machen die keine Enthauptungen mehr."
Nicht dass das böse gemeint war - bei uns herrscht manchmal ein etwas derber, aber dennoch herzlich gemeinter Umgangston, und es ist eine ausgewogene Sache von Geben und Nehmen.

[1] ich möchte damit nicht ausdrücken, dass die breite Masse dumm ist :p

Warum nicht? Man muss auch die Wahrheit vertragen können ...

Ciao,
 Martin

[Gunther]

Die Geier kreisen wieder ...!

Eine länderspezifische TLD als Sprachkennzeichnung zu verwenden ist mindestens genauso dumm[1] wie Flaggen zur Sprachkennzeichnung zu verwenden.

Siehe meine Antwort auf Beats Posting.

ohne dass ich eine Diskussion darüber auslösen möchte).

Du bist gut :) du gehst wohl auch zum Friseur, ohne dir die Haare "machen" lassen zu wollen.

Ja, zum Rasieren! ;-)

Du ziehst ebenfalls den gleichen, aber falschen Schluss, dass diese Variante dazu dienen soll, eine_Sprachkennzeichnung_vorzunehmen. Das habe ich (bewußt) nicht geschrieben und auch nicht gemeint.

Und "ohne dass ich eine Diskussion darüber auslösen möchte" bezog sich genau darauf, dass jetzt hier wieder über ein Thema debatiert wird, was mit der eigentlichen Sache nur indirekt zu tun hat. Wen das interessiert, der kann sich dazu im Archiv informieren.

Gruß Gunther

[Steel]

Hi!

[1] ich möchte damit nicht ausdrücken, dass die breite Masse dumm ist :p

Dann lass ich es mir halt auf'n Shirt drucken.

[Gunnar Bittersmann]

@@mrjerk:

nuqneH

Ich würde wohl idealerweise das Speichern in der Session UND in einem (permanenten, z.b. 1 Monat gültig oder so) Cookie vorsehen.

Und beim ersten Aufruf der Seite sollte der Nutzer automatisch die seinen Browsereinstellungen entsprechende Sprache zu lesen bekommen: Es ist immer angebracht, Sprachvereinbarung (language negotiation) einzusetzen.

Lösung mit Cookies: Content Negotiation: why it is useful, and how to make it work

Qapla'