Beste Technik für Sprachweiche gesucht

[dtpop]

Hallo @all,
war ja schon lange nicht mehr hier ...
Eine Frage an die Fachwelt beschäftigt mich gerade:

Wie ist eine optimale Sprachweiche zu realisieren?

Es gibt ja diverse Weiterleitungstechniken. So z.B. meta refresh, Javascript oder per header-Versand.
Dabei soll folgendes realisiert werden: beim Aufruf der Startseite http://www.mydomain.xyz soll die Browsereinstellung des Benutzers ausgelesen werden und dann auf die entsprechende Sprache weitergeleitet werden, beispielsweise http://www.mydomain.xyz/en/home.php oder http://www.mydomain.xyz/de/home.php.

Das funktioniert auch hervorragend, hat nur einen Nachteil, dass die Suchanlage von Google etwas aus dem Tritt gerät. Die findet dann keine Startseite ohne Umleitung - und das mag die gar nicht gerne. Kennt jemand eine Möglichkeit diese Funktion dennoch benutzerfreundlich zu realisieren?

Auf jeden Fall schonmal Danke und Grüße,
Wolfgang

[Der-Dennis]

Hallo Wolfgang,

Du könntest doch in der PHP-Datei die Sprache auslesen und ohne Weiterleitung die Seite in entsprechender Sprache ausliefern. Wird keine Sprache gefunden, wird eine Standard-Einstellung verwendet. Und erst wenn der Benutzer eine Sprache auch wirklich ausgewählt hat, verwendest Du Konstrukte wie http://www.mydomain.xyz/en/.

Gruß, Dennis

[Beat]

Du könntest doch in der PHP-Datei die Sprache auslesen und ohne Weiterleitung die Seite in entsprechender Sprache ausliefern.

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

Wird keine Sprache gefunden, wird eine Standard-Einstellung verwendet. Und erst wenn der Benutzer eine Sprache auch wirklich ausgewählt hat, verwendest Du Konstrukte wie http://www.mydomain.xyz/en/.

du weisst, wozu example.org existiert?

mfg Beat

[Der-Dennis]

Hallo Beat,

Du könntest doch in der PHP-Datei die Sprache auslesen und ohne Weiterleitung die Seite in entsprechender Sprache ausliefern.

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

Richtig. Mir schien es nur so, als wäre es das, was dtpop erreichen möchte.

Wird keine Sprache gefunden, wird eine Standard-Einstellung verwendet. Und erst wenn der Benutzer eine Sprache auch wirklich ausgewählt hat, verwendest Du Konstrukte wie http://www.mydomain.xyz/en/.

du weisst, wozu example.org existiert?

Das habe ich aus dem Ursprungs-Post übernommen. Ansonsten ist mir die Spezifikation via example.org, etc., bekannt.

Gruß, Dennis

[Gunnar Bittersmann]

@@Beat:

nuqneH

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.

Das ist nicht böse. Im Gegenteil. Das ist Sprachvereinbarung.

Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

Das auch.

Qapla'

[Cybaer]

Hi,

Du könntest doch in der PHP-Datei die Sprache auslesen und ohne Weiterleitung die Seite in entsprechender Sprache ausliefern.
Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

Nein. Ich verwende üblicherweise ein ähnliches Verfahren - zumindest bei der Homepage. Je nach Spracheinstellung bekommt der User unter dem gleichen URL versch. Sprachen durch Weiterleitung auf "en", "de", etc., zw. denen er dann auch unabhängig von der Spracheinstellung wechseln, bzw. bookmarken kann.

In einer US-Suchmaschine wird jedoch unter dem generischen Homepage-URL immer der englischsprachige Content angeboten, in einer deutschen Suchmaschine der deutsche Content, etc.

Gruß, Cybaer

[Der Martin]

Hallo,

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

nicht unbedingt. Ich löse das normalerweise so, dass ich generische URLs verwende und die Sprache anhand
 - des HTTP-Headers Accept-Language
 - eines eventuell vorhandenen Cookies
 - oder eines eventuell vorhandenen URL-Parameters 'lang'
bestimme, wobei die Priorität in der Reihenfolge dieser Aufzählung zunimmt. Der URL-Parameter übersteuert also alle anderen Werte.

So habe ich unter der generischen Adresse http://example.org/page die voll- oder halbautomatische Sprachauswahl, und kann mit http://example.org/page?lang=fr beispielsweise eine französische Sprachfassung erzwingen (falls vorhanden). Die ausgewählte Sprache wird dann wieder im Cookie (genauer: in der Session) gespeichert, so dass man bei nachfolgenden Seitenaufrufen den URL-Parameter wieder weglassen kann.

Wird keine Sprache gefunden, wird eine Standard-Einstellung verwendet.

Genau. Das habe ich drin für den Fall, dass die oben geschilderte Entscheidungskette eine Sprache herausbekommt, die ich nicht bieten kann.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin:

nuqneH

Sprachversionen sollen durch URIs unterscheidbar sein.

nicht unbedingt. Ich löse das normalerweise so, dass ich generische URLs verwende und die Sprache anhand […] eines eventuell vorhandenen URL-Parameters 'lang' bestimme

Das wäre dann ein sprachspezifischer URI und verschiedene Sprachversionen wären durch URIs unterscheidbar. (Der Query gehört zum URI.)

Qapla'

[Der Martin]

Hallo,

Sprachversionen sollen durch URIs unterscheidbar sein.
nicht unbedingt. Ich löse das normalerweise so, dass ich generische URLs verwende und die Sprache anhand […] eines eventuell vorhandenen URL-Parameters 'lang' bestimme
Das wäre dann ein sprachspezifischer URI und verschiedene Sprachversionen wären durch URIs unterscheidbar. (Der Query gehört zum URI.)

natürlich, ich betrachte in meinen Projekten aber die generischen URLs ohne Sprachangabe als die primären, in denen die Sprache nicht als Information enthalten ist. Wenn jemand eine Angabe *mit* lang-Parameter weitergibt, ist das natürlich in Ordnung, stellt aber aus meiner Sicht eher den Ausnahmefall dar.

Ciao,
 Martin

[Beat]

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

nicht unbedingt. Ich löse das normalerweise so, dass ich generische URLs verwende und die Sprache anhand

• des HTTP-Headers Accept-Language
• eines eventuell vorhandenen Cookies

Ein Cookie ist als Resultat aktiver Sprachwahl nicht ausreichend.
Referenziere eine optimale Sprachversion (ergo eine generische Form).
Ausser für Startseiten ist das ungeeignet.

• oder eines eventuell vorhandenen URL-Parameters 'lang'

oder irgend eine Information im Pfad der URI.

bestimme, wobei die Priorität in der Reihenfolge dieser Aufzählung zunimmt. Der URL-Parameter übersteuert also alle anderen Werte.

Eine aktive Sprachwahl sollte dazu führen, dass du mir sofort sprachspezifische URIs für Referenzzwecke lieferst. Ein Cookie wäre zu wenig.

So habe ich unter der generischen Adresse http://example.org/page die voll- oder halbautomatische Sprachauswahl, und kann mit http://example.org/page?lang=fr beispielsweise eine französische Sprachfassung erzwingen (falls vorhanden). Die ausgewählte Sprache wird dann wieder im Cookie (genauer: in der Session) gespeichert, so dass man bei nachfolgenden Seitenaufrufen den URL-Parameter wieder weglassen kann.

Genau das ist falsch. Liefere mir für Referenzzwecke die sprachspezifischen URIs.
In einem Backend eines CMS oder sonstigen privaten Bereich darf man es anders halten.

mfg Beat

[Beat]

Du könntest doch in der PHP-Datei die Sprache auslesen und ohne Weiterleitung die Seite in entsprechender Sprache ausliefern.

Böse. Dann hast du unter dem gleichen URI mehrere Sprachversionen.
Nö. Sprachversionen sollen durch URIs unterscheidbar sein.

Ich korrigiere mich:
Sprachversionen sollen durch URIs unterscheidbar sein.
Es ist jedoch möglich, generische URIs zu verwenden, die durch Content-Negotiotion auf spezifische URIs weiterleiten.
Es ist jedoch darauf zu achten dass:
-generische URIs für Index-Bots nicht die beste Wahl darstellen.
-generische URIs für Referenzzwecke nicht unbedingt geeignet sind.

Die Qualität der Sprachversionen ist entscheidend für den Umgang mit spezifischen URIs.
Bei Referenzen ist die qualitativ hochstehende Originalsprache zu bevorzugen.
Der Wechsel auf eine alternative Version sollte durch expliziten Userwunsch geschehen.

Ich kennen nur wenige Seiten, die mehrsprachig qualitativ ebenbürtig sind.
Frappierende Unterschiede gibt es in der Wikipedia. Hier darf man gar nicht mehr von Sprachversionen sprechen.

Content-Negotiation sagt leider zu wenig darüber aus, wie verständlich das ausgelieferte Dokument für den Leser ist. Verständlichkeit unterscheidet sich für Lesen und Schreiben und bezüglich Fachgebiet. Der Sinn von CN reduziert sich praktisch oft auf typische Bookmark- bzw Startseiten.

mfg Beat

[Gunnar Bittersmann]

@@Beat:

nuqneH

Es ist jedoch möglich, generische URIs zu verwenden, die durch Content-Negotiotion auf spezifische URIs weiterleiten.

Wobei der generische URI in der Adresszeile des Browsers stehenbleiben sollte.

Die Qualität der Sprachversionen ist entscheidend für den Umgang mit spezifischen URIs.

Hm.

Frappierende Unterschiede gibt es in der Wikipedia. Hier darf man gar nicht mehr von Sprachversionen sprechen.

Richtig. Das liefe unter „Multilingual, changed content“ [MONO-MULTILINGUAL], wenn überhaupt. Wenn man nicht gar die verschiedensprachigen Wikipedias als jeweils eigenständig ansieht.

Wikipedia-Artikel zu einem Begriff in verschiedenen Sprachen sind jeweils eigeneständige Artikel, wenn auch untereinander verlinkt. In den seltensten Fällen haben sie gleichen Inhalt.

„Sprachvereinbarung kann aber nicht mehr sinnvoll eingesetzt werden, wenn Webseiten nicht äquivalent sind […]“ [WHEN-LANG-NEG]

Der Sinn von CN reduziert sich praktisch oft auf typische Bookmark- bzw Startseiten.

Nein. Die Artikel auf der Website der W3C Internationalization (I18n) Activity sind ein gutes Gegenbeispiel. Dort ist (dummerweise) die Startseite gar nicht mehrsprachig.

Qapla'

[Beat]

Die Qualität der Sprachversionen ist entscheidend für den Umgang mit spezifischen URIs.

und

Der Sinn von CN reduziert sich praktisch oft auf typische Bookmark- bzw Startseiten.

Nein. Die Artikel auf der Website der W3C Internationalization (I18n) Activity sind ein gutes Gegenbeispiel. Dort ist (dummerweise) die Startseite gar nicht mehrsprachig.

Ich weiss nicht, was dein "Nein" mir sagen will.

Sie ist ein Beispiel verfehlter Anwendung. Nicht nur die Startseite lässt Content-Negotiation vermissen, sondern auch einige Unterseiten, wobei dann überraschend plötzlich doch eine Negotiation angewendet wird.
Dummerweise finde ich nirgendwo einen Link zur Sprachwahl.
Soviel also zum Thema, wie man's nicht machen soll.

mfg Beat

[Gunnar Bittersmann]

@@dtpop:

nuqneH

Es gibt ja diverse Weiterleitungstechniken. So z.B. […] Javascript

?? Wie möchtest du mit JavaScript die vom Nutzer bevorzugte(n) Sprachen ermitteln?

http://www.mydomain.xyz

[RFC2606]

soll die Browsereinstellung des Benutzers ausgelesen werden und dann auf die entsprechende Sprache weitergeleitet werden, beispielsweise http://www.mydomain.xyz/en/home.php oder http://www.mydomain.xyz/de/home.php.

Das funktioniert auch hervorragend, hat nur einen Nachteil, dass die Suchanlage von Google etwas aus dem Tritt gerät. Die findet dann keine Startseite ohne Umleitung

Dann machst du etwas falsch.

Vermutlich verlinkst du auf einer Seite nicht deren andere Sprachversionen? Der Nutzer sollte immer die Möglichkeit haben, selbst die Sprache zu wählen. [WHEN-LANG-NEG]

Dann sollte eine Suchmaschine auch alle Sprachversionen finden.

Qapla'