nicht angemeldet dedlfix
Der Martin
Der Martin
Der Martin
dedlfix
Der Martin
Gunnar Bittersmann
User kann irgendwo auf der Website wählen, welche Sprache er gerne hätte. Zum Beispiel über einen Link rechts oben (English, Deutsch). Wie würdet ihr diese ausgewählte Information weiterschleifen? Was ist best practice?
a) In einer Sessionvariable?
b) Über die eine Abbildung im Pfad (example.com/de/categories vs. example.com/en/categories)
c) über query-string (example.com/categories/cars?lang=de)
a) wohl der Nachteil, dass die URL die Sprache nicht abbildet
b) gefällt mir persönlich am besten
c) unschöne URL
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt. Das soll bitte hier nicht diskutiert werden.
IMO kommt das darauf an, was das nun für Inhalte sind, frei zugänglich wäre mMn. b am besten (c kann ja definitiv durch mod_rewrite wegfallen)
Wenn es jetzt allerdings um eine Unterseite geht, die nur für registrierte Nutzer zugänglich ist und diese eine Sprache hinterlegt haben in ihren Profil-Informationen, wohl eher Variante a (wobei das immer noch nicht Variante b ausschließen muss)
Variante d, als Sub-Domain a la en.example.com werf ich einfach mal in den Raum, weil sich mir da gerade nicht die Vor- und Nachteile erschließen :s
MfG
bubble
IMO kommt das darauf an, was das nun für Inhalte sind, frei zugänglich wäre mMn. b am besten (c kann ja definitiv durch mod_rewrite wegfallen)
alle rewrites finden auf PHP-seite statt, es wird also alles erstmal krude auf die index.php weitergeleitet
RewriteRule ^(.*)$ index.php
wurde hier im Forum mal so empfohlen, mein kleines Framework basiert darauf und ich bin damit ganz zufrieden. c kann also defintiv genutzt werden. Oder ich hab dich falsch verstanden :)
Wenn es jetzt allerdings um eine Unterseite geht, die nur für registrierte Nutzer zugänglich ist und diese eine Sprache hinterlegt haben in ihren Profil-Informationen, wohl eher Variante a (wobei das immer noch nicht Variante b ausschließen muss)
Variante d, als Sub-Domain a la en.example.com werf ich einfach mal in den Raum, weil sich mir da gerade nicht die Vor- und Nachteile erschließen :s
ok, das würde auch noch gehen. Oder eigene Domain (example.de, example.com). Ist kein Riesenprojekt...
danke dir für deine Infos!
IMO kommt das darauf an, was das nun für Inhalte sind, frei zugänglich wäre mMn. b am besten (c kann ja definitiv durch mod_rewrite wegfallen)
alle rewrites finden auf PHP-seite statt, es wird also alles erstmal krude auf die index.php weitergeleitet
RewriteRule ^(.*)$ index.php
wurde hier im Forum mal so empfohlen, [...]
Ist ja auch richtig so, man kann direkt in PHP einfach viel mehr machen, als in .htaccess
c kann also defintiv genutzt werden. Oder ich hab dich falsch verstanden :)
Naja, ich wollt damit sagen, dass wenn man nicht a nutzt, b nehmen sollte statt c da das unter berücksichtigung von mod_rewrite (oder eigenem Script) eh einfach in einer Variablen landet, b aber definitiv "hübscher" (vllt. sogar suchmaschinen-freundlicher) ist
MfG
bubble
Tach!
alle rewrites finden auf PHP-seite statt, es wird also alles erstmal krude auf die index.php weitergeleitet
RewriteRule ^(.*)$ index.php
Ja, aber. Soll wirklich alles umgeschrieben werden, auch wenn es vorhandene Dateien betrifft? Üblicherweise möchte man die ausschließen und setzt diese beiden Bedingungen davor.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
Reguläre Ausdrücke sind gierig, so dass man bei .* kein ^ oder $ braucht, .* schnappt sich alles von vorn bis hinten. Selbst die Klammern kann man sich schenken, wenn man die URL nicht als Parameter an index.php hängen möchte. Und das braucht man nicht, weil die bereits im Script über $_SERVER['REQUEST_URI'] verfügbar ist.
Seit Apache 2.2.16 braucht man eigentlich alle drei Direktiven nicht mehr, denn dann steht FallbackResource zur Verfügung.
FallbackResource /index.php
Allerdings gibt es Einsatzfälle, da kommt FallbackResource zu spät. Es wird nämlich erst am Ende des Verarbeitungsprozesses aufgerufen während das Rewriting eher stattfindet. Leitet man zum Beispiel alles .php auf einen (F)CGI-Handler, dann übernimmt der die Verarbeitung auch bei nicht existierenden Dateien und FallbackResource kommt nicht mehr zum Zuge.
dedlfix.
Hallo,
a) In einer Sessionvariable?
b) Über die eine Abbildung im Pfad (example.com/de/categories vs. example.com/en/categories)
c) über query-string (example.com/categories/cars?lang=de)
ich nutze normalerweise eine Kombination von a) und c) mit zusätzlich vorgeschalteter Language Negotiation, wobei die Priorität der Angaben von oben nach unten zunimmt. In Pseudocode:
Haben wir einen URL-Parameter "lang" mit einer Sprachangabe, die wir unterstützen?
Ja: Sprache übernehmen und in Session speichern
Nein: Existiert ein Eintrag "lang" in der Session?
Ja: Sprache aus Session übernehmen
Nein: Wünscht sich der Client im Accept-Language-Header eine Sprache, die
wir unterstützen?
Ja: Sprache aus Header übernehmen
Nein: Festgelegte Default-Sprachvariante nehmen
Die Folge ist, dass man anfangs die Sprache bekommt, die man im Browser als bevorzugte Sprache eingestellt hat, aber jederzeit per URL-Parameter (bzw. entsprechende auf der Seite angebotene Links) die Sprachversion wechseln kann.
a) wohl der Nachteil, dass die URL die Sprache nicht abbildet
Das sehe ich eher als Vorteil: Ich kann eine sprachneutrale URL weitergeben, und jeder Nutzer bekommt unter derselben URL denselben Inhalt - nur eben in "seiner" Sprache.
b) gefällt mir persönlich am besten
Mir am wenigsten. ;-)
c) unschöne URL
Ja. Aber so wie ich es realisiere, habe ich diesen unschönen Query-String nur bei dem einen Aufruf, bei dem ich explizit die Sprache umstellen will. Beim Klick auf den nächsten Link ist der URL-Parameter wieder weg; die Information ist ja nun in der Session gespeichert.
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt. Das soll bitte hier nicht diskutiert werden.
Schade. Denn das ist IMO das Nächstliegende.
Ciao,
Martin
Hallo,
Das sehe ich eher als Vorteil: Ich kann eine sprachneutrale URL weitergeben, und jeder Nutzer bekommt unter derselben URL denselben Inhalt - nur eben in "seiner" Sprache.
aber nicht auf Anhieb oder? Eine URL
example.com/cars würde ein sich in Deutschland aufhaltender Amerikaner an deutschem Browser erstmal natürlich auf deutsch zu sehen bekommen (vorausgesetzt, die default-Sprache ist deutsch). Aber gut, das ist wirklich Kleinkrämerei... er kann ja dann seine Sprache wählen.
Gut, so mach ichs, das spart mir ne Menge Arbeit :) Ansonsten müsste ich meine ganze URL-Struktur umbauen.
c) unschöne URL
Ja. Aber so wie ich es realisiere, habe ich diesen unschönen Query-String nur bei dem einen Aufruf, bei dem ich explizit die Sprache umstellen will. Beim Klick auf den nächsten Link ist der URL-Parameter wieder weg; die Information ist ja nun in der Session gespeichert.
stimmt, das ist meines Erachtens gut so. Wie machst du das?
wenn ich auf example.com/categories/bikes/dirtbikes/234 bin und klicke auf den Sprachschalter, dann ist die URL dieses Sprachschalters:
example.com/categories/bikes/dirtbikes/234?lang=en
?
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt. Das soll bitte hier nicht diskutiert werden.
Schade. Denn das ist IMO das Nächstliegende.
Wie würde man da am besten vorgehen?
n'Abend,
Das sehe ich eher als Vorteil: Ich kann eine sprachneutrale URL weitergeben, und jeder Nutzer bekommt unter derselben URL denselben Inhalt - nur eben in "seiner" Sprache.
aber nicht auf Anhieb oder?
doch, im Idealfall schon. Das ist ja gerade der Sinn von Language Negotiation. Nur wenn aus irgendeinem Grund mal die Defaulteinstellung nicht passt, oder wenn ich unbedingt mal sehen will, wie der Text in Französisch lautet, muss ich korrigieren.
Eine URL example.com/cars würde ein sich in Deutschland aufhaltender Amerikaner an deutschem Browser erstmal natürlich auf deutsch zu sehen bekommen (vorausgesetzt, die default-Sprache ist deutsch). Aber gut, das ist wirklich Kleinkrämerei... er kann ja dann seine Sprache wählen.
Warum sollte ein Amerikaner, der sich in Deutschland aufhält, einen Browser verwenden, dessen bevorzugte Sprache(n) Deutsch an erster Stelle haben? Denkst du an öffentliche Surfstationen, Internet-Cafés oder Ähnliches? Ich glaube, diese Möglichkeiten verlieren langsam an Bedeutung, wo doch heute jeder, der sich für wichtig hält, sein Smartphone dabei hat.
Und sobald unser Amerikaner nun ein Endgerät nutzen kann, das ihm persönlich zur Verfügung steht (sei es sein eigenes Smartphone, sein eigenes Notebook oder ein PC, den ihm sein deutscher Geschäftspartner für die Dauer des Aufenthalts zur Verfügung stellt), wird er doch sehr wahrscheinlich die Spracheinstellungen auf "en-US" als erste bevorzugte Sprache einstellen.
c) unschöne URL
Ja. Aber so wie ich es realisiere, habe ich diesen unschönen Query-String nur bei dem einen Aufruf, bei dem ich explizit die Sprache umstellen will. Beim Klick auf den nächsten Link ist der URL-Parameter wieder weg; die Information ist ja nun in der Session gespeichert.
stimmt, das ist meines Erachtens gut so. Wie machst du das?
Hab ich doch in Kurzfassung erklärt. Wo ist der Punkt, den du nicht verstehst?
wenn ich auf example.com/categories/bikes/dirtbikes/234 bin und klicke auf den Sprachschalter, dann ist die URL dieses Sprachschalters:
example.com/categories/bikes/dirtbikes/234?lang=en
?
Im Prinzip ja, aber ich würde den Link an der Stelle nur verkürzt als href="?lang=en" formulieren. Den Rest kann der Browser selbst ergänzen. So kann ich die Sprachauswahl quasi-statisch einfügen und muss dort nicht auch noch auf jeder Seite den Link dynamisch anpassen.
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt. Das soll bitte hier nicht diskutiert werden.
Schade. Denn das ist IMO das Nächstliegende.
Wie würde man da am besten vorgehen?
"Language Negotiation" oder in Deutsch "Sprachvereinbarung" sollte dir als Futter für eine Suchmaschine nützen. Gunnar Bittersmann, auch Stamm-User hier im Forum, hat sich schon sehr intensiv mit dem Thema beschäftigt und einiges darüber geschrieben.
Ciao,
Martin
Warum sollte ein Amerikaner, der sich in Deutschland aufhält, einen Browser verwenden, dessen bevorzugte Sprache(n) Deutsch an erster Stelle haben? Denkst du an öffentliche Surfstationen, Internet-Cafés oder Ähnliches? Ich glaube, diese Möglichkeiten verlieren langsam an Bedeutung, wo doch heute jeder, der sich für wichtig hält, sein Smartphone dabei hat.
Und sobald unser Amerikaner nun ein Endgerät nutzen kann, das ihm persönlich zur Verfügung steht (sei es sein eigenes Smartphone, sein eigenes Notebook oder ein PC, den ihm sein deutscher Geschäftspartner für die Dauer des Aufenthalts zur Verfügung stellt), wird er doch sehr wahrscheinlich die Spracheinstellungen auf "en-US" als erste bevorzugte Sprache einstellen.
stimmt.
"Language Negotiation" oder in Deutsch "Sprachvereinbarung" sollte dir als Futter für eine Suchmaschine nützen. Gunnar Bittersmann, auch Stamm-User hier im Forum, hat sich schon sehr intensiv mit dem Thema beschäftigt und einiges darüber geschrieben.
Guck ich mir mal an. Danke!
Guten Morgen nochmal,
Ja. Aber so wie ich es realisiere, habe ich diesen unschönen Query-String nur bei dem einen Aufruf, bei dem ich explizit die Sprache umstellen will. Beim Klick auf den nächsten Link ist der URL-Parameter wieder weg; die Information ist ja nun in der Session gespeichert.
stimmt, das ist meines Erachtens gut so. Wie machst du das?Hab ich doch in Kurzfassung erklärt. Wo ist der Punkt, den du nicht verstehst?
wenn ich auf example.com/categories/bikes/dirtbikes/234 bin und klicke auf den Sprachschalter, dann ist die URL dieses Sprachschalters:
example.com/categories/bikes/dirtbikes/234?lang=en
?
Ich wollte eigentlich nur wissen, ob Du auf der selben Seite bleibst oder ob du zum Beispiel standardmäßig auf example.com/home umleitest (in der neuen Sprache). Sowas habe ich schon oft erlebt... was ist, wenn es die URL für die neue Sprache nicht gibt (zb. einen bestimmten Artikel)? Was machst du, wohin leitest du zum Beispiel weiter?
Das ist vielleicht ein dümmliche Frage, aber ich stelle sie trotzdem mal:
de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
de-de bedeutet ja deutsch (Deutschland), sehe ich das richtig? Äquivalent dazu en-us englisch (USA).
Wertest du das aus? Oder wertest du nur das Sprachkürzel aus, also de? Wäre dies hier dazu geeignet?
http://php.net/manual/de/locale.acceptfromhttp.php
Mahlzeit,
was ist, wenn es die URL für die neue Sprache nicht gibt (zb. einen bestimmten Artikel)? Was machst du, wohin leitest du zum Beispiel weiter?
Dann wird die aufgerufene Seite in einer Default-Sprache angezeigt mit einem Hinweis, dass es sie in der gewählten Sprache nicht gibt.
Alternativ wird sie einfach nicht verlinkt bzw. es gibt auf dieser Seite keine Sprachauswahl für eine nicht existierende Sprache.
Moin zurück,
Ich wollte eigentlich nur wissen, ob Du auf der selben Seite bleibst oder ob du zum Beispiel standardmäßig auf example.com/home umleitest (in der neuen Sprache). Sowas habe ich schon oft erlebt...
pfui, wer macht denn sowas? - Ja, das habe ich tatsächlich auch schon gesehen. Kann ich aber nicht leiden; wenn ich eine andere Sprache auswähle, möchte ich dabei nicht einen ganz anderen Inhalt bekommen. Deswegen sind meine Sprachwechsler-Links ja auch stark verkürzt, wie ich schon angedeutet habe: "?lang=de", "?lang=fr". So ergänzt der Browser selbst die Basis-URL der gerade angezeigten Seite.
was ist, wenn es die URL für die neue Sprache nicht gibt (zb. einen bestimmten Artikel)? Was machst du, wohin leitest du zum Beispiel weiter?
Aus meiner Darstellung in Pseudocode geht doch hervor, dass ich schließlich bei einer von mir bzw. vom Auftraggeber vorher festgelegten Default-Sprache lande, wenn ich keinen der Wünsche erfüllen kann. Das wird dann wohl meistens Deutsch oder Englisch sein.
Und diese Abfrage erfolgt natürlich bei jeder Seite separat. Es wäre also möglich, dass ich beispielsweise alle Seiten meiner Website in Deutsch, Englisch und Französisch anbiete, außer /aboutme, die nur in Deutsch verfügbar ist. Dann bekommt natürlich der Client, der sich Englisch oder Französisch wünscht, diese Seite trotzdem in Deutsch. Was sonst ...
Es gibt auch Beispiele dafür, wie man's nicht machen soll, etwa beim deutschen Wetterdienst. Wunschgemäß spricht der DWD Englisch mit mir, weil ich das als bevorzugte Sprache eingestellt habe. Einige Seiten sind da aber nur in Deutsch verfügbar - aber glaub nicht, dass ich dann eben die deutsche Fassung bekäme, nein! Nur einen lapidaren Hinweis, dass die gewünschte Information nicht in Englisch verfügbar sei.
Das ist vielleicht ein dümmliche Frage, aber ich stelle sie trotzdem mal:
So dümmlich ist sie nun auch wieder nicht. ;-)
de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
de-de bedeutet ja deutsch (Deutschland), sehe ich das richtig? Äquivalent dazu en-us englisch (USA).
Ja, zusätzlich mit Gewichtungsfaktoren.
Wertest du das aus? Oder wertest du nur das Sprachkürzel aus, also de?
Die Gewichtungsfaktoren ignoriere ich der Einfachheit halber (ehrlich gesagt, habe ich auch noch nicht wirklich verstanden, wie die gemeint sind) und nehme ansonsten von links nach rechts den ersten Eintrag, den ich bedienen kann. Und ich gebe zu, die Unterteilung nach Sprachvarianten, also etwa die Unterscheidung zwischen de-DE und de-AT oder zwischen en-US und en-GB, habe ich bisher auch nicht realisiert. Folglich betrachte ich beim User-Wunsch auch nur den Basistyp, also de oder en.
Wäre dies hier dazu geeignet?
http://php.net/manual/de/locale.acceptfromhttp.php
Weiß ich nicht, hab ich noch nie verwendet. Die Beschreibung klingt aber ganz vernünftig.
So long,
Martin
Tach!
de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Die Gewichtungsfaktoren ignoriere ich der Einfachheit halber (ehrlich gesagt, habe ich auch noch nicht wirklich verstanden, wie die gemeint sind) und nehme ansonsten von links nach rechts den ersten Eintrag, den ich bedienen kann.
Das ist quasi das ORBER BY in der ansonsten unsortierten Menge. Bei abwesendem q ist der Defaultwert 1.
dedlfix.
Hallo,
Die Gewichtungsfaktoren ignoriere ich der Einfachheit halber (ehrlich gesagt, habe ich auch noch nicht wirklich verstanden, wie die gemeint sind) und nehme ansonsten von links nach rechts den ersten Eintrag, den ich bedienen kann.
Das ist quasi das ORBER BY in der ansonsten unsortierten Menge.
oh, danke. Dann ergibt das auch einen Sinn. Ich war bisher der Meinung, die Priorität ergäbe sich aus der Reihenfolge - daher auch meine sequentielle Betrachtung von links nach rechts.
Sollte ich mein Script vielleicht etwas aufmöbeln ...?
Bei abwesendem q ist der Defaultwert 1.
Das war mir bekannt.
Ciao,
Martin
Hallo,
Haben wir einen URL-Parameter "lang" mit einer Sprachangabe, die wir unterstützen?
Ja: Sprache übernehmen und in Session speichern
Nein: Existiert ein Eintrag "lang" in der Session?
Ja: Sprache aus Session übernehmen
Nein: Wünscht sich der Client im Accept-Language-Header eine Sprache, die
wir unterstützen?
Ja: Sprache aus Header übernehmen
Nein: Festgelegte Default-Sprachvariante nehmen
Hier sehe ich eine Problematik, wenn verschiedene Seiten (PHP-Programme) unterschiedliche Sprachen anbieten. Etwa, wenn ein Projekt 5-sprachig, zusätzliche Seiten aber 6-sprachig sind. Die 6. Sprache sei spanisch.
Der Spanier ruft eine beliebige Seite über Google auf, die NICHT spanisch enthält. Nach deinem Entscheidungsbaum wird dann die Default-Sprache festgelegt, also deutsch.
Nun wechselt er auf eine Seite, die "es" zur Verfügung hätte, er wird aber weiterhin deutsch bedient.
Ich reiche die ursprüngliche Sprache immer weiter als GET- oder POST-Parameter (habe keine Sessions). Sie kann jederzeit durch manuelle Wahl geändert werden und wird dann weitergereicht. Ansonsten kann ich dein Beispiel nachvollziehen.
Eine "Default"-Sprache brauche ich nur, wenn jemand sprachlos daherkommt wie etwa die Suchmaschinen. Die werden dann auf deutsch (bei .de Domains) oder english (bei .eu oder .org) bedient.
Eine "Default"-Sprache brauche ich nur, wenn jemand sprachlos daherkommt wie etwa die Suchmaschinen. Die werden dann auf deutsch (bei .de Domains) oder english (bei .eu oder .org) bedient.
Auch das ist noch nicht problemfrei. Ich habe Seiten, in die Benutzer Nederlandse Text eingeben. Und das Projekt hat durchgängig "nl" Seiten, doch Google zeigt das "drumherum" in english, weil sie (die Gogle?) sprachlos daherkommt.
So könnte man immer weiter machen in der Sprachfindung ...
Linuchs
Hi,
Haben wir einen URL-Parameter "lang" mit einer Sprachangabe, die wir unterstützen?
Ja: Sprache übernehmen und in Session speichern
Nein: Existiert ein Eintrag "lang" in der Session?
Ja: Sprache aus Session übernehmen
Nein: Wünscht sich der Client im Accept-Language-Header eine Sprache, die
wir unterstützen?
Ja: Sprache aus Header übernehmen
Nein: Festgelegte Default-Sprachvariante nehmenHier sehe ich eine Problematik, wenn verschiedene Seiten (PHP-Programme) unterschiedliche Sprachen anbieten. Etwa, wenn ein Projekt 5-sprachig, zusätzliche Seiten aber 6-sprachig sind. Die 6. Sprache sei spanisch.
Der Spanier ruft eine beliebige Seite über Google auf, die NICHT spanisch enthält. Nach deinem Entscheidungsbaum wird dann die Default-Sprache festgelegt, also deutsch.
Nun wechselt er auf eine Seite, die "es" zur Verfügung hätte, er wird aber weiterhin deutsch bedient.
Ich hätte das jetzt anders interpretiert. Das Probjekt wird zuerst 6-sprachig angelegt. Spanier kommt auf die Seite und wählt implizit über seinem Accept-Header die Sprache "es". Nun wird ihm das erste Dokument, dass es vieleicht nicht auf spanisch gibt, auf deutsch angezeigt (mit dem Hinweis, dass es für dieses Dokument keine spanische Übersetzung gibt). Kommt er auf ein Dokukument mit spanisch, greift sein Accept-Header.
Warum sollte man ein Projekt, welches 6 Sprachen unterstützt, nur fünfsprachig anlegen?
Noch ein Nachtrag,
Ich hätte das jetzt anders interpretiert. Das Probjekt wird zuerst 6-sprachig angelegt. Spanier kommt auf die Seite und wählt implizit über seinem Accept-Header die Sprache "es". Nun wird ihm das erste Dokument, dass es vieleicht nicht auf spanisch gibt, auf deutsch angezeigt (mit dem Hinweis, dass es für dieses Dokument keine spanische Übersetzung gibt). Kommt er auf ein Dokukument mit spanisch, greift sein Accept-Header.
Warum sollte man ein Projekt, welches 6 Sprachen unterstützt, nur fünfsprachig anlegen?
es würde im Fall einer spanischen Seite nicht einfach die default-Sprache angzeigt werden dürfen, sondern in diesem Fall sollte wohl eine Sprache zugezogen werden, die sich ebenfalls im Acceptheader befindet, vermutlich "en". Man darf ja nicht vergessen dass deutsch eine Minderheitensprache ist.
Warum sollte man ein Projekt, welches 6 Sprachen unterstützt, nur fünfsprachig anlegen?
Das Projekt - im engen Sinn - ist sprachlos. Die Programme stellen nur Daten für die Platzhalter-Dateien bereit. Die Daten können in beliebig vielen Sprachen eingegeben werden. Alles, was UTF-8 darstellen kann. Aber wir sprechen nicht von den Daten, sondern von der Programm-Oberfläche.
Das war zunächst "de" und "en". Nun brauchte ich ein Konzept, um programmweise mehr Sprachen zu bedienen.
So kam es, dass ein Einzelprogramm entscheidet, was ausgeliefert wird, wenn die geforderte Sprache nicht vorrätig ist. Beim Wechsel zum nächsten Programm wird die Entscheidung neu getroffen.
Was ich nicht mache: In den 2.500 (?) möglichen Sprachen mitzuteilen, dass nun gerade diese Sprache nicht verfügbar ist. Hatte mal so eine Ansatz - wenigstens in den europäischen Sprachen - schleunigst wieder aufgegeben.
Also, wenn ein Programm 10-sprachig wird, ist damit das Projekt noch lange nicht 10-sprachig. Aber wer kann schon ein ganzes Projekt im Stück auf eine weitere Sprache erweitern?
es würde im Fall einer spanischen Seite nicht einfach die default-Sprache angzeigt werden dürfen, sondern in diesem Fall sollte wohl eine Sprache zugezogen werden, die sich ebenfalls im Acceptheader befindet, vermutlich "en".
Da hast du Recht, das werte ich (noch) nicht aus.
Man darf ja nicht vergessen dass deutsch eine Minderheitensprache ist.
Nein, nein. Deshalb schreibe hier bewusst in Deutsch, damit die Amis nicht mitlesen können.
Linuchs
@@Linuchs:
nuqneH
In den 2.500 (?) möglichen Sprachen
Leg mal ein paar drauf.
Oder zieh ein paar ab. https://twitter.com/codepo8/status/408602586829164546
Qapla'
Hi,
Haben wir einen URL-Parameter "lang" mit einer Sprachangabe, die wir unterstützen?
Ja: Sprache übernehmen und in Session speichern
Nein: Existiert ein Eintrag "lang" in der Session?
Ja: Sprache aus Session übernehmen
Nein: Wünscht sich der Client im Accept-Language-Header eine Sprache, die
wir unterstützen?
Ja: Sprache aus Header übernehmen
Nein: Festgelegte Default-Sprachvariante nehmenHier sehe ich eine Problematik, wenn verschiedene Seiten (PHP-Programme) unterschiedliche Sprachen anbieten. Etwa, wenn ein Projekt 5-sprachig, zusätzliche Seiten aber 6-sprachig sind. Die 6. Sprache sei spanisch.
gut, habe ich verstanden.
Der Spanier ruft eine beliebige Seite über Google auf, die NICHT spanisch enthält. Nach deinem Entscheidungsbaum wird dann die Default-Sprache festgelegt, also deutsch.
Richtig.
Nun wechselt er auf eine Seite, die "es" zur Verfügung hätte, er wird aber weiterhin deutsch bedient.
Falsch. Das passiert nur dann, wenn er zwischendurch nochmal explizit Deutsch "bestellt" hat. Beachte, dass ich die gewählte Sprache nur dann speichere, wenn sie ausdrücklich über den entsprechenden URL-Parameter angefordert wird. Solange sich die Sprache nur durch das automatische Auswahlverfahren ergibt, speichere ich nichts und die Auswahl wird für jede Seite unabhängig erneut durchlaufen.
Eine "Default"-Sprache brauche ich nur, wenn jemand sprachlos daherkommt wie etwa die Suchmaschinen. Die werden dann auf deutsch (bei .de Domains) oder english (bei .eu oder .org) bedient.
Warum siehst du einen Zusammenhang zwischen dem Domainnamen und der Sprache? Auch eine com- oder org-Domain kann primär deutsch sein.
Ciao,
Martin
Nun wechselt er auf eine Seite, die "es" zur Verfügung hätte, er wird aber weiterhin deutsch bedient.
Falsch. Das passiert nur dann, wenn er zwischendurch nochmal explizit Deutsch "bestellt" hat. Beachte, dass ich die gewählte Sprache nur dann speichere, wenn sie ausdrücklich über den entsprechenden URL-Parameter angefordert wird.
Okay, habe deine Vokabel "übernehmen" mit "speichern" verwexelt.
Warum siehst du einen Zusammenhang zwischen dem Domainnamen und der Sprache? Auch eine com- oder org-Domain kann primär deutsch sein.
Hmm, .com ist doch "commercial" und .org "organisation", also weltweit und regional unentschlossen?
Für mich macht es da Sinn, einem "sprachlosen", unentschlossenen Besucher (Google) english Text anzubieten. Wenn eine sprachloser Besucher .de aufruft, bekommt er de.
Linuchs
@@hossi:
nuqneH
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt.
Nein, darüber muss man zuerst nachdenken. Denn daraus, wie das implementiert wird, ergeben sich die anderen Dinge.
Lies mal bitte den Thread Sprachenwechlser durch.
Ich hoffe, die deutschen Übersetzungen funktionieren dann wieder. Solltest du bei den w3.org/International-Seiten noch einen PHP-Fehler bekommen, musst du '.en' an den Pfad anhängen (d.h. ans Ende bzw. vor '#') und vorläufig mit dem englischen Original vorlieb nehmen.
Das soll bitte hier nicht diskutiert werden.
Doch. Wo sonst, wenn nicht hier?
Qapla'
Hi,
Eine Spracherkennung in welcher Form auch immer (Browserlanguage etc) möchte mein Kunde erst im nächsten Schritt nachdenken, wenn überhaupt.
Nein, darüber muss man zuerst nachdenken. Denn daraus, wie das implementiert wird, ergeben sich die anderen Dinge.
na, wenn das so ist :)
Lies mal bitte den Thread Sprachenwechlser durch.
viel neues hat mir der Thread nicht eröffnet, ausser diesen Link von Dir:
http://www.w3.org/International/questions/qa-when-lang-neg.en
(ja, es gab noch einen PHP-Fehler)
Gut, rudimentär wusste ich darüber Bescheid. Ich führe mir jetzt nochmal kurz Martins Workflow zu Gemüte, das scheint recht vernünftig zu sein. So werde ich es wohl implementieren.
Danke an alle, mein Problem ist erstmal gelöst.
