Sprachauswahl ohne Cookie oder Session

[translator]

Hallo,

es soll eine Sprachauswahl für eine Seite gebaut werden.
Diese soll ohne Cookies und ohne Session auskommen.
Also dachte ich entweder an subdomains, mit den Länderkürzeln, oder daran, einen Länderkürzel-Pfad einzuführen - da mir hierfür kein mod_reqrite zur Verfügung allerbestenfalls die forcetype-Variante gefällt mir das nicht soo gut.

http://en.example.de
http://example.de
http://de.example.de

Unter welcher Adresse würdet ihr die Deutsche-Version erreichbar machen? Widerspricht es sich, mit der Topleveldomain .de eine Englische Übersetzung anzubieten?

Der wechsel von de. nach en. wäre so allerdings Recht einfach, die Language wird einfach anhand der subdomain ausgelesen ansonsten können die selben Routinen und files abgerufen werden.

Oder lieber doch zwei Dateien en und de im Wurzelverzeichnis anlegen und forcetypen als PHP zu operieren?

Gruß

[Der Martin]

Hi,

es soll eine Sprachauswahl für eine Seite gebaut werden.
Diese soll ohne Cookies und ohne Session auskommen.

der Gedanke gefällt mir.

Also dachte ich entweder an subdomains, mit den Länderkürzeln

du meinst doch hoffentlich: mit Sprachkürzeln.

Widerspricht es sich, mit der Topleveldomain .de eine Englische Übersetzung anzubieten?

Wie man's nimmt. Für mich hat die TLD nichts mit der Sprache des Angebots zu tun, sondern ist eine rein organisatorische Sache. Aber unabhängig davon finde ich es ästhetisch nicht gerade schön, ein "en" oder auch ein "de" unterhalb einer typischen Länder-Domain zu haben. Dafür sollte man doch besser eine länder- und sprachneutrale TLD wählen (.com, .net, .org, .biz, .info).

Ciao,
 Martin

[translator]

Hallo,

Wie man's nimmt. Für mich hat die TLD nichts mit der Sprache des Angebots zu tun, sondern ist eine rein organisatorische Sache. Aber unabhängig davon finde ich es ästhetisch nicht gerade schön, ein "en" oder auch ein "de" unterhalb einer typischen Länder-Domain zu haben. Dafür sollte man doch besser eine länder- und sprachneutrale TLD wählen (.com, .net, .org, .biz, .info).

Hierbei müsste dann selbst die Standardsprache aber ein Sprachkürzel (ja) als subdomain oder Pfad erhalten.

Andrerseits bezeichnet die TLD für mich immernoch, entweder, woher die Präsenz kommt, oder ob sie eine org ist etc.

Somit wäre wohl die Subdomain dem Pfad vorzuziehen.
Wobei dabei die Frage zu klären wäre, ob die Standardsprache zweimal (mit und ohne Sprachkürzelsubdomain) erreichbar sein soll - doppelter Content - oder nur mit oder ohne.

Gruß

[dedlfix]

echo $begrüßung;

Widerspricht es sich, mit der Topleveldomain .de eine Englische Übersetzung anzubieten?
Wie man's nimmt. Für mich hat die TLD nichts mit der Sprache des Angebots zu tun, sondern ist eine rein organisatorische Sache. Aber unabhängig davon finde ich es ästhetisch nicht gerade schön, ein "en" oder auch ein "de" unterhalb einer typischen Länder-Domain zu haben. Dafür sollte man doch besser eine länder- und sprachneutrale TLD wählen (.com, .net, .org, .biz, .info).

Ich habe das Gefühl, dass sich hier dein Schönheitsempfinden und deine technischer Verstand widersprechen. Wie soll denn beispielsweise eine Firma aus Belgien (derzeit noch) im Web auftreten? .com statt .be nehmen, nur weil sie ihren Auftritt zwei- bis dreisprachig gestalten möchte?

Für mich ist die Sprache ein Parameter. Eine Sprache stellt keinen eigenen Bereich dar, muss also nicht als solcher (Domäne) gekennzeichnet werden. Es ist im Idealfall der gleiche Inhalt, nur anders dargestellt. Quasi wie eine Tabelle mit geänderter Sortierung.

Bei der Überlegung sollten auch technische Gegebenheiten und Einschränkungen eine Rolle spielen. Eine Domain stellt auch eine Abgrenzung bezüglich Browsercache und Scripting dar. Der Client lädt beim Sprachwechsel, so er über die Domain realisiert ist, alle Zusatzressourcen neu, wenn diese nicht auf einer weiteren, sozusagen gemeinsamen Domain liegen. Auch mögen es Browser nicht, wenn Scripts über Domaingrenzen hinwegzugreifen versuchen. Cookies lassen sich zwar einstellen, dass sie Subdomain-übergreifend sind, jedoch muss man dies stets beachten.

echo "$verabschiedung $name";

[translator]

Hallo,

das mit den Cachproblemen, Subdomainübergreifend und den Skripten finde ich sehr wichitg, jetzt wo dus sagst (auch wenn ich natürlich voreilig das jetzt schon so gelöst hatte).

Also bleibt eigentlich, wenn man es so sieht nur eine Sprachkürzel-Pfad-Url, wenn man es ohne Cookie und Session speichern möchte.
Selbst dann jedoch gaukelt man unterschiedliche Ressourcen vor. Obwohl nur in dasselbe Layout andere Texte gepackt werden.

Gruß

[translator]

P.S.: Selbst bei Selfhtml wird die Subdomain-Methode verwandt ...

[dedlfix]

echo $begrüßung;

P.S.: Selbst bei Selfhtml wird die Subdomain-Methode verwandt ...

Welche Gründe auch immer zu dieser Entscheidung führten. Hier geht man auch den Weg, gemeinsam genutzte Ressourcen unter einer eigenen Subdomain (src) anzulegen. Was dabei für Vorteile oder Probleme auftreten entzieht sich meiner Kenntnis.

echo "$verabschiedung $name";

[dedlfix]

echo $begrüßung;

Also bleibt eigentlich, wenn man es so sieht nur eine Sprachkürzel-Pfad-Url, wenn man es ohne Cookie und Session speichern möchte.
Selbst dann jedoch gaukelt man unterschiedliche Ressourcen vor. Obwohl nur in dasselbe Layout andere Texte gepackt werden.

Deswegen erwähnte ich den Parameter ?lang=xx. Gut, auch Parameter gehören genau genommen zum Namen einer Ressource, werden aber von Suchmaschinen anders als der Pfad behandelt.

echo "$verabschiedung $name";

[Der Martin]

Moin,

Für mich hat die TLD nichts mit der Sprache des Angebots zu tun, sondern ist eine rein organisatorische Sache. Aber unabhängig davon finde ich es ästhetisch nicht gerade schön, ein "en" oder auch ein "de" unterhalb einer typischen Länder-Domain zu haben. Dafür sollte man doch besser eine länder- und sprachneutrale TLD wählen (.com, .net, .org, .biz, .info).
Ich habe das Gefühl, dass sich hier dein Schönheitsempfinden und deine technischer Verstand widersprechen.

nicht unbedingt.

Wie soll denn beispielsweise eine Firma aus Belgien (derzeit noch) im Web auftreten? .com statt .be nehmen, nur weil sie ihren Auftritt zwei- bis dreisprachig gestalten möchte?

Eventuell, ja. Eine länderspezifische Domain würde ich als Betreiber nur dann wählen, wenn ich ganz sicher bin, dass ich nie Zielgruppen außerhalb der eigenen Landesgrenzen anspreche. Eine .de oder auch .be-Domain hat für mich etwas Provinzielles. Empfehlenswert höchstens für Ämter, Behörden und andere klar dem jeweiligen Land zugeordneten Webauftritte, z.B. die Websites von Städten und Gemeinden.

Für mich ist die Sprache ein Parameter. Eine Sprache stellt keinen eigenen Bereich dar, muss also nicht als solcher (Domäne) gekennzeichnet werden.

Richtig, das sehe ich auch so. Aber wenn ich schon eine .de-Domain wähle und damit zum Ausdruck bringe, dass mich nur Deutschland interessiert, sehe ich keinen Anlass, den Webauftritt mehrsprachig anzulegen.
Gut, man könnte jetzt für ausländische Mitbürger argumentieren, die sich vielleicht freuen, etwas in ihrer Muttersprache lesen zu können. Aber wer möchte seinen Webauftritt schon in Türkisch, Griechisch, Arabisch, Russisch, Italienisch und Chinesisch verfassen - um nur ein paar der hier als "Gastsprachen" auftretenden zu nennen.

Bei der Überlegung sollten auch technische Gegebenheiten und Einschränkungen eine Rolle spielen. Eine Domain stellt auch eine Abgrenzung bezüglich Browsercache und Scripting dar. Der Client lädt beim Sprachwechsel, so er über die Domain realisiert ist, alle Zusatzressourcen neu, wenn diese nicht auf einer weiteren, sozusagen gemeinsamen Domain liegen.

Das ist ein guter Gedanke ...

Schönen Tag noch,
 Martin

[dedlfix]

echo $begrüßung;

Wie soll denn beispielsweise eine Firma aus Belgien (derzeit noch) im Web auftreten? .com statt .be nehmen, nur weil sie ihren Auftritt zwei- bis dreisprachig gestalten möchte?

Eventuell, ja. Eine länderspezifische Domain würde ich als Betreiber nur dann wählen, wenn ich ganz sicher bin, dass ich nie Zielgruppen außerhalb der eigenen Landesgrenzen anspreche. Eine .de oder auch .be-Domain hat für mich etwas Provinzielles. Empfehlenswert höchstens für Ämter, Behörden und andere klar dem jeweiligen Land zugeordneten Webauftritte, z.B. die Websites von Städten und Gemeinden.

Auch weltweit agierende Firmen arbeiten provinziell. Das ist unter anderem den unterschiedlichen Gesetzen der Länder zu schulden oder hat anderen Gründe, die eine mehr oder weniger große Unterschiede im Angebot bedingen. Es ist einfacher example.de, example.be usw. als example.com/deutschland, example.com/belgië, example.com/belgique, example.com/belgien oder de.example.com, be.example.com zu propagieren (zumal ja zwecks Wiedererkennungswert immernoch ein www. davorgestellt wird).

Aber wenn ich schon eine .de-Domain wähle und damit zum Ausdruck bringe, dass mich nur Deutschland interessiert, sehe ich keinen Anlass, den Webauftritt mehrsprachig anzulegen.

Ich wählte das Beispiel Belgien aufgrund seiner drei Amtssprachen nicht umsonst. Mehrsprachige Regionen, die Regionales anbieten gibt es genügend. Brüssel ist zweisprachig. Auch in Deutschland gibt es zweisprachige Gegenden, beispielsweise die sorbischen Gebiete.

Gut, man könnte jetzt für ausländische Mitbürger argumentieren, die sich vielleicht freuen, etwas in ihrer Muttersprache lesen zu können. Aber wer möchte seinen Webauftritt schon in Türkisch, Griechisch, Arabisch, Russisch, Italienisch und Chinesisch verfassen - um nur ein paar der hier als "Gastsprachen" auftretenden zu nennen.

Es gibt auch anderssprachige Inländer. In Deutschland dürften Sorben auch Deutsch können, aber in Belgien kann man nicht erwarten, dass alle Einwohner mindestens Französisch und Niederländisch können (die kleine deutschsprachige Region mal unbeachtet gelassen).

Außerdem gibt es Touristen, die man ansprechen möchte, die die Landessprache(n) nicht sprechen. Auch für diese möchte man mehrsprachige Informationen bereithalten. Es gibt mehr als genug Gründe, Regionales auch mehrsprachig anzubieten.

echo "$verabschiedung $name";