Automatische Erkennung Browsersprache

[prego]

Hi,

ich bin gerade an einer mehrsprachigen Webseite dran. Umsetzungsmäßig so weit kein Problem.

Ich hab mir nur überlegt, das es ja schlecht wäre das unter http://www.example.com/ einmal (zB) englischer wie auch deutscher Text vorhanden ist. Das wäre ja unterschiedlicher Content auf der gleichen URL. Für Suchmaschinen denke ich nicht das Beste.

Um das ganze elegant zu lösen habe ich mich für Wildcard-Subdomains entschieden. *.example.com landet alles auf dem Webserver und anhand der Subdomain entscheidet die Seite welche Sprache sie anzeigt. http://de.example.com oder http://en.example.com.

Ziel ist es beim Aufruf von www.example.com die Sprache automatisch durch Auswerten von HTTP_ACCEPT_LANGUAGE zu erkennen und per 302 (oder doch vielleicht 301) auf die erkannte Sprache (also Subdomain) weiter zu leiten. Kann die Sprache nicht erkannt werden, wird eine Auswahlseite mit allen zur Verfügung stehenden Sprachen präsentiert, auf der der User selbst auswählen kann welche Sprachversion er sehen will.

Das ist soweit auch alles kein Problem, nur wie stelle ich sicher das Suchmaschinen immer diese Auswahlseite erhalten. Sendet (zB) google einen HTTP_ACCEPT_LANGUAGE Header in dem dann evtl Englisch steht? Wie erkenne ich ob ein wirklicher Browser oder ein Robot die Seite besucht?

Wär klasse wenn ihr mir ein paar Anregungen geben könntet

//edit:
Ich könnte die Spracherkennung natürlich auch per JavaScript machen. Damit bekommt der Robot die Auswahlseite, ebenso alle Leute mit deaktivierten Javascript.
Alle anderen werden automatisch (location.href) weiter geleitet. Damit umgehe ich auch das 301/302 Problem.

Was denk ihr?

[PHP-Desaster]

Automatisches Erkennen der Sprache ist nicht verkehrt, damit schließt der potentielle Kunde vielleicht nicht sofort wieder das Fenster. Allerdings sollte der Wechsel in eine andere Sprache immer möglich sein, also entsprechende Links präsentieren.
Ob Google eine Sprache mitsendet, weiß ich nicht, kann ich mir aber nur schwer vorstellen.

Von einer JS-Lösung würde ich Abstand nehmen, das ist ein imho ein serverseitiges Problem und eine Weiterleitung ist doch sauberer!

[prego]

Natürlich würde auf der Seite die Möglichkeit geboten die Sprache zu wechseln - ist ja im Endeffekt nur noch ein Wechsel der Subdomain

Wenn ich die Sache Serverseitig erkenne ist ja auch die Frage ob ich 301 (permantly) oder 302(temporarily) mache. 301 bedeutet ja das die Seite www.example.com permanent auf de.example.com umgezogen ist.

Ich müsste es halt generell hinkriegen das ich erkenne ob ein Browser oder ein Spider unterwegs ist.

Was ist ander JS Lösung so schlecht? Wenn kein JS da ist, wird ja immernoch die Möglichkeit geboten die Sprache selbst auszuwählen und Google hätte alle Links zum "abgrasen". Oder kann ich der JS die Sprache des Browsers garnicht raus finden?

[TobiaZ]

Wenn ich die Sache Serverseitig erkenne ist ja auch die Frage ob ich 301 (permantly) oder 302(temporarily) mache. 301 bedeutet ja das die Seite www.example.com permanent auf de.example.com umgezogen ist.

Eigentlich trifft eine temporäre Umleitung doch genau dein Vorhaben.

Im normalfall wird die Sprachauswahl gezeigt, wenn die aber nicht erforderlich ist, wird "ausnahmsweise" direkt weitergeleitet.

[combie]

Ich würde:

1. Browsersprache lesen (zumindest versuchen)
2. Links präsentieren um die Sprache wechseln zu können
3. Versuchen ein Cookie mit der Sprache zu setzen. ca. 0,5-1 Jahr
4. Wenn das nicht geht die Sprache an die Url hängen output_add_rewrite_var() evtl. elganter im pfad per modrewrite

Um Google eine gute Chance zu geben, sollte die Sprachauswahl auf jeder Seite zu sehen sein!

[prego]

Original geschrieben von combie

1. Browsersprache lesen (zumindest versuchen)
2. Links präsentieren um die Sprache wechseln zu können und natürlich wird es auf jeder Seite eine Dropdown Box mit Sprachauswahlen geben. Links sind hier glaub nicht so gut - da mit mehr als 10 Sprachen gerechnet wird. Evtl im Footer alle Sprachen in grau und oben des Dropdown...
3. Versuchen ein Cookie mit der Sprache zu setzen. ca. 0,5-1 Jahr
4. Wenn das nicht geht die Sprache an die Url hängen output_add_rewrite_var() evtl. elganter im pfad per modrewrite

1. Ja
2. Das wird passieren wenn keine Erkennung möglich war, auf der Seite wird es ein Dropdown mit Sprachen geben, da mehr als 10 Sprachen erwartet werden. Evtl pack ich in den Footer alle anderen Sprachen als Links.
3. Es wird ein Cookie gesetzt werden das auf www.* ausgewertet wird und entsprechend weiter leitet
4. Das ganze läuft sowieso so über mod_rewrite, wenn das Cookie nicht funktioniert muss der User sich beim nächsten Besuch eben auf die Erkennung verlassen. Da der User im Normalfall die www.* Seite sowieso nicht sieht, wird er denke ich die de.* bookmarken und daher wieder kehren. Und wenn doch www, dann eben neue Auswahl wenn er denn schon kein Cookie annimmt

Und es wird ne 302 - ist logisch, da hast du völlig Recht Tobiaz.

Nur was mach ich mit den Robots? Wie erkenne ich ob ein User oder ein Spider unterwegs ist... Ich stells mir jetzt grad schwierig vor, rauszufinden ob GoogleBot nen HTTP_ACCEPT_LANGUAGE Header sendet...

[UzumakiNaruto]

index.html.de
index.html.en

der apache unterstützt das von hause aus ;-)
jenachdem mit welcher sprache sich der browser beim server meldet, wird entweder die index.html.de oder index.html.en ausgeliefert, AUCH wenn der Browser NUR index.html angefordert hat

[prego]

Ouh, das is gut zu wissen....

Aber ich hab keine index.html - sonder es läuft alles durch ne index.php die als Frontcontroller arbeitet...

Das löst aber im übrigen nicht das Problem das unter der selben URL unterschiedliche Inhalte/Sprachen ausgegeben werden. Oder leitet der Apache weiter?

[combie]

Das löst aber im übrigen nicht das Problem das unter der selben URL unterschiedliche Inhalte/Sprachen ausgegeben werden.

Das darf nicht!
Oder die Sumas sollen nur 1 Sprache finden.

auf der Seite wird es ein Dropdown mit Sprachen geben, da mehr als 10 Sprachen erwartet werden.

Ein Formular? Ungünstig!
Wird von den SUMAS nicht ausgewertet.
Links, müssen es sein.
Die Sprache als Get Parameter oder im Pfad, egal..

[TobiaZ]

quote:auf der Seite wird es ein Dropdown mit Sprachen geben, da mehr als 10 Sprachen erwartet werden.


Ein Formular? Ungünstig!
Wird von den SUMAS nicht ausgewertet.
Links, müssen es sein.

Spricht ja nichts dagegen, eine Liste von Links so zu formatieren, dass sie recht Platzsparend untergebracht ist und ggf. noch zufällig aussieht, wie ein dropdown (nur schöner)

[UzumakiNaruto]

was meinst ihr warum ihr alles in deutsch habt wenn ihr google.com/google.fr/google.co.jp besucht?

index.html.de war nur ein beispiel . .das geht auch mit index.php.de oder mit login.php.de

[prego]

Original geschrieben von TobiaZ
Spricht ja nichts dagegen, eine Liste von Links so zu formatieren, dass sie recht Platzsparend untergebracht ist und ggf. noch zufällig aussieht, wie ein dropdown (nur schöner)

Genau das war mein Gedanke - oder eben irgendwo auf der Seite noch links unterbringen...

@combie: Es ging ja um die vorgeschlagenen index.html.de Lösung. Das Problem hab ich ja durch Subdomains gelöst.

Nur wie bekomm ich jetzt raus ob ein Bot oder ein Browser auf der "Portal"-Seite ist?

[combie]

Nur wie bekomm ich jetzt raus ob ein Bot oder ein Browser auf der "Portal"-Seite ist?

Wozu?
Welchen Sinn soll das haben?

Ansonsten, kannst du das Server Array untersuchen...
Aber das ist alles unzuverlässig. Böse Bots erkennst du mit keinem Mittel.

[Blackgreetz]

@Combie: Er meint wohl Sumas (dessen Bots)

@prego: Wieso sollten die eine Sprache senden? Wäre unsinnig..
Wenn sie eine Sprache senden, dann wollen die auch nur den Inhalt der Sprache ... (aber normal suchen die sumas ja generell)..

ggf. dann den tipp von combie nutzen..

mfg

[combie]

@Combie: Er meint wohl Sumas (dessen Bots)

Ist mir schon klar...
Aber es gibt so viele davon
Und jeden Tag kommen welche dazu, zumindest fast.
Der Aufwand lohnt sich nicht. (sage ich mal so)