Beat: Redirect, Localization, SEO

Beitrag lesen

was ich jetzt nach mehrmaligem Ueberdenken immernoch nicht so ganz verstanden habe, ist, wie denn dann initial ueberhaupt automatisch jene Sprache aktiviert werden kann, welche der Benutzer in seinem Browser angegeben hat - und zwar OHNE einen Redirect auf PHP's Seite?

Es ist im Grunde eine der Aufgaben deiner mehrsprach-bewussten Seiten zu entscheiden.
a) Es ist ein CGI-Parameter angekommen.

  • ich bin zuständig
  • ich bin nicht zuständig
      Ich muss einen redirect senden auf eine URL, die dafür zuständig ist.
    b) Kein CGI-Parameter
  • aber auch kein Cookie.
        Ich sniffe mal an Accept-Language
        - Ich bin eine akzeptable Sprache. ich bin zuständig
          und setze ein Cookie
        - ich bin nicht erste Wahl.
          Ich muss einen Redirect senden auf eine URL, die dafür zuständig ist.
  • ein Cookie
      oh - das Cookie lautet aber anders
           Ich muss einen Redirect senden auf eine URL, die dafür zuständig ist.
      Ich bin die richtige Version für dieses Cookie.

Jetzt müssen sich einfach alle Seiten informieren können, welche Sprachen implementiert sind, um die Content-Negotiation zu betreiben.
Achtung Fallback-Mechanismus. Was, wenn eine Sprache implementiert ist, aber nicht die konkrete Seite?

  • Error-Seite muss Cookie setzen auf Fallback-Sprache.

Wenn deine Sprachinfo im Pfad vorliegen würde, bräuchtest du den Keks gar nicht.
Ein einfacher filetest in htaccess könnte ermitteln, ob eine Seite existiert.

Du kannst es natürlich auch so handhaben, dass das Formular für die Sprachwahl immer auf ein Sprachwahlscript zeigt, das dann die Konversion von CGI-Parameter zu Redirect nach Subdomain oder Pfad vornimmt.
Das entlastet die konkreten Sprachseiten von dieser Aufgabe.

mfg Beat

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