nicht angemeldet Treziman
Gunnar Bittersmann
Gunnar Bittersmann
Treziman
Der Martin
Treziman
Gunnar Bittersmann
Hallo,
zur Zeit beschäftige ich mich mit einem Projekt, das zweisprachig gestaltet werden soll, deutsch und englisch. Ich mache sowas zum ersten Mal. Wie realisiert man das am besten? Meine erste Idee war, zwei Klassen zu erstellen und mittels javascript die jeweilige ein-, bzw. auszublenden. Das soll aber nicht optimal für Suchmaschinen sein, laut Google. Ausserdem müsste wohl in jedem Text-Tag ein lang="..." hinein, was wohl die Crawler durcheinander bringt. Ist ein User eingeloggt, braucht er nicht mehr über js wählen, da seine Sprachauswahl in der DB gespeichert wird.
Dann wäre da noch die Möglichkeit, alle Skripte zu duplizieren, die Texte darin zu übersetzen und in getrennten, der Sprache zugehörigen Unterordnern abzuspeichern. Scheint mir am besten zu sein.
Oder über Subdomains (de.example, en.example), wobei mir aber die Funktionalität unklar ist, da ein User ja zuerst auf der Startseite (example) landet und demnach zuerst die Sprache auswählen müsste. Ein registrierter User braucht das aber nicht mehr.
Wie würdet ihr vorgehen?
LG Treziman
@@Treziman
zur Zeit beschäftige ich mich mit einem Projekt, das zweisprachig gestaltet werden soll, deutsch und englisch. Ich mache sowas zum ersten Mal. Wie realisiert man das am besten? Meine erste Idee war, zwei Klassen zu erstellen und mittels javascript die jeweilige ein-, bzw. auszublenden.
Clientseitiges JavaScript? Keine so gute Idee. Du müsstest dann ja sämtliche Texte auf deutsch und englisch übertragen, obwohl nur eins davon benötigt wird.
Ist ein User eingeloggt, braucht er nicht mehr über js wählen, da seine Sprachauswahl in der DB gespeichert wird.
Neue Nutzer sollten ihre Sprache auch nicht auswählen müssen, denn das haben sie bereits getan – in den Spracheinstellungen ihrer Browser. Diese im HTTP-Header mitgesendete Angabe Accept-Language sollte dein Server beachten und die entsprechende Sprachversion ausliefern.
Wenn Nutzer ihren Browser nicht richtig eingestellt haben oder an einem fremden Computer sitzen, liefert language negotiation (Sprachvereinbarung) nicht immer das gewünschte Ergebnis. Deshalb muss auf jeder(!) Seite (nicht nur auf der Homepage) die Möglichkeit zur Sprachumschaltung vorhanden sein – und zwar auffindbar.
Dann wäre da noch die Möglichkeit, alle Skripte zu duplizieren, die Texte darin zu übersetzen und in getrennten, der Sprache zugehörigen Unterordnern abzuspeichern. Scheint mir am besten zu sein.
Oder über Subdomains (de.example, en.example)
Das läuft aufs selbe hinaus. Anstatt die Sprachversionen in verschiedene Ordner/Subdomains aufzuteilen, kannst du auch die Dateien im selben Ordner haben: seite3.de.html und seite3.en.html. Damit kann man im einfachsten Fall MultiViews nutzen, d.h. generische URLs https://example.net/seite3.
Bei der Registrierung eines Nutzers speicherst du dessen Sprachpräferenz. Wenn sie die Sprache nicht umgeschaltet hat, also das Ergebnis der automatischen language negotiation. Und bei manueller Umschaltung speicherst du den Wert – auch zu einem späteren Zeitpunkt nach der Registrierung. Und sobald du einen Wert in der Datenbank hast, hat dieser Vorrang, d.h. dann wird keine language negotiation mehr gemacht.
Ein bisschen Lesestoff hab ich dir schon gegeben; hier noch ein Überblick. Auf W3C Internationalization findest du noch weitere Artikel. Fun fact: die Artikel sind alle language negotiated, d.h. wenn dein Browser deutsch als Präferenz angibt, bekommst du sie in der deutschen Übersetzung – sofern vorhanden – zu lesen.
Fun fact 2: Ich habe gerade gestern erst wieder einen Vortrag zu mehrsprachigen Websites gehalten.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
super! Danke für die Hinweise! Ich habe mir alles mal durchgelesen. Sehr interessant war der Link zu "MultiView". Das hat mich auf die Idee gebracht, das vielleicht wie folgt zu lösen:
MudGuard
Rolf B$sprache="de"; (js)
$("#anzeige").load("..../example."+$sprache+".php");
Funktioniert auf jeden Fall.
Bei Registrierung wird die Sprachwahl mit in der DB gespeichert und kann später, nach dem Login, unter "Einstellungen" ("settings") immer geändert werden. Derweil ist die Sprache in einer Session gespeichert.
Die Startseite sieht so aus:
<!DOCTYPE HTML>
<html lang="de">
<head> <title>...</title>
<meta charset="utf-8" >
...
<meta name="language" content="DE,EN" >
<meta name="content-language" content="de,en" >
...
<meta http-equiv='content-type' content='text/html; charset=utf-8'>
Wäre das okay?
LG Treziman
Hallo,
Ich habe mir alles mal durchgelesen. Sehr interessant war der Link zu "MultiView". Das hat mich auf die Idee gebracht, das vielleicht wie folgt zu lösen:
was aber mit MultiViews herzlich wenig zu tun hat.
$sprache="de"; (js) $("#anzeige").load("..../example."+$sprache+".php");
Willst du den Textinhalt jedes einzelnen Elements per JS nachladen? Das werden dann, je nach Umfang und Komplexität der Seiten, ein paar Dutzend bis ein paar Hundert Einzelfragmente. Unnötig hohe Serverlast, viel Traffic.
Wenn du schon die Texte in der ausgewählten Sprache dynamisch nachladen willst, solltest du das lieber pro Seite in eine Ressource zusammenpacken (z.B. als JSON-Block), und dann clientseitig die Einträge aus dem JSON picken und in die entsprechenden Elemente im DOM einfüllen.
Aber ...
Funktioniert auf jeden Fall.
Nein. Nicht auf jeden Fall. Eventuell wird am Client kein JS ausgeführt (z.B. weil ein paranoider Nutzer oder ein Ad- und Scriptblocker das verhindert). Oder die Sprach-Ressource kann aufgrund eines Netzwerkproblems nicht nachgeladen werden. Dann steht der Besucher mit einer Seite ohne Text im Regen.
Wenn du also etwas in der Art machst, sollten die Texte zumindest in einer Default-Sprache schon im Markup stehen und dann bei Bedarf ausgetauscht werden.
Aber all das finde ich eigentlich suboptimal. Die beste Lösung ist aus meiner Sicht immer noch Language Negotiation. Dann geschieht der Kern der Sprachauswahl am Server, das hast du mehr oder weniger unter Kontrolle (jedenfalls mehr als clientseitige Abläufe). Und es wird nur das übertragen, was auch wirklich gebraucht wird.
Bei Registrierung wird die Sprachwahl mit in der DB gespeichert und kann später, nach dem Login, unter "Einstellungen" ("settings") immer geändert werden. Derweil ist die Sprache in einer Session gespeichert.
Ist beides okay - nur die Session ist halt spätestens dann wieder weg, wenn das Session-Cookie beim Besucher entsorgt wird.
<meta name="language" content="DE,EN" > <meta name="content-language" content="de,en" >Wäre das okay?
Was versprichst du dir von diesen beiden Meta-Angaben? Ich halte sie für nutzlos.
Einen schönen Tag noch
Martin
Hallo Martin,
auch Dir dankeschön für Deine Antwort!
was aber mit MultiViews herzlich wenig zu tun hat.
Korrekt, aber es hat mich auf die Idee gebracht, es so lösen zu können.
Willst du den Textinhalt jedes einzelnen Elements per JS nachladen?
Nein. JS kommt diesbezüglich hauptsächlich auf der Startseite vor, da ein User hier noch nicht eingeloggt ist.
Eventuell wird am Client kein JS ausgeführt (z.B. weil ein paranoider Nutzer oder ein Ad- und Scriptblocker das verhindert). Oder die Sprach-Ressource kann aufgrund eines Netzwerkproblems nicht nachgeladen werden. Dann steht der Besucher mit einer Seite ohne Text im Regen.
Auch richtig. Darum bekommt ein User eine Meldung mittels <noscript> angezeigt, dass er die Seite nur in vollem Umpfang nutzen kann wenn er JS erlaubt. Ohne JS gehts nicht. Die Seite wird standardmässig in deutsch ausgeliefert, mit oder ohne JS. Wird kein JS erlaubt, kann keine andere Sprache ausser deutsch ausgewählt werden. Ausser vielleicht mit Language Negotiation.
Die beste Lösung ist aus meiner Sicht immer noch Language Negotiation.
Damit beschäftige ich mich gerade.
Mit Cookies möchte ich eher nicht arbeiten, da ein User diese verbieten kann. PHP-Sessions dagegen nicht.
<meta name="language" content="DE,EN" >
<meta name="content-language" content="de,en" >
Sind diese beiden Meta-Tags denn nutzlos oder hälts Du sie nur dafür? Ich weiss es nicht. Wenn tatsächlich nutzlos, lösche ich sie.
LG Treziman
Hi,
Willst du den Textinhalt jedes einzelnen Elements per JS nachladen?
Nein. JS kommt diesbezüglich hauptsächlich auf der Startseite vor, da ein User hier noch nicht eingeloggt ist.
da greife ich einen Einwand von Gunnar nochmal auf: Der Einstieg kann von überall erfolgen, nicht unbedingt nur über die Startseite - z.B. durch ein Bookmark oder über eine Suchmaschine. Deshalb muss von jeder Seite aus auch ein Login verfügbar sein.
Die Seite wird standardmässig in deutsch ausgeliefert, mit oder ohne JS. Wird kein JS erlaubt, kann keine andere Sprache ausser deutsch ausgewählt werden.
Okay, das ist ein brauchbarer Kompromiss.
Mit Cookies möchte ich eher nicht arbeiten, da ein User diese verbieten kann. PHP-Sessions dagegen nicht.
Wenn du PHP-Sessions verwendest, dann verwendest du sehr wahrscheinlich auch Cookies. Das ist nämlich der übliche Weg, wie die Session-ID für PHP gespeichert und übermittelt wird.
> > <meta name="language" content="DE,EN" >
> > <meta name="content-language" content="de,en" >
Sind diese beiden Meta-Tags denn nutzlos oder hälts Du sie nur dafür?
Ich kannte diese meta-Typen bisher gar nicht, habe sie noch nirgends bewusst gesehen, geschweige denn selbst verwendet. Das W3C erklärt sie für veraltet und rät, die Sprache des Dokuments stattdessen im lang-Attribut des html-Elements zu notieren.
Falsch ist auf jeden Fall, gleich zwei Sprachen anzugeben. Dein Dokument ist entweder in Deutsch oder in Englisch gehalten, aber nicht beides. Oder meintest du Denglisch? 😉
Außerdem werden die Sprachkürzel normalerweise in Kleinbuchstaben notiert. Mit Großbuchstaben bezeichnet man die Länder, wobei die Korrelation von Ländern und Sprachen in den seltensten Fällen eine 1:1-Beziehung ist. Beispiele:
de-DE: Deutsch wie in Deutschland gesprochen
de-AT: Deutsch in der österreichischen Variante
en-US: Englisch (US-amerikanisch)
en: Englisch (nicht näher differenziert, "irgendein" Englisch)
Einen schönen Tag noch
Martin
@Martin
Der Einstieg kann von überall erfolgen, nicht unbedingt nur über die Startseite - z.B. durch ein Bookmark oder über eine Suchmaschine. Deshalb muss von jeder Seite aus auch ein Login verfügbar sein.
Nein, so soll es nicht sein. Ein User kann nicht in den Mitgliederbereich wenn er sich zuvor nicht eingeloggt hat. Sollte ein Bookmark gesetzt worden sein und der User will später wieder auf diese Unterseite, wird er zur Startseite umgeleitet, muss sich zuerst einloggen und darf dann weiter. So lautet der Auftrag. Nach erfolgreichem Login wird der User in den Mitgliederbereich weitergeleitet. Hier findet er zunächst vom Layout her dieselbe Seite wie die Startseite, nur dass in der Navigation einige Optionen mehr verfügbar sind. Es ist wie hier, wenn man nicht angemeldet ist, kann man keinen Beitrag schreiben.
Die beiden Meta-Tags sind entfernt! Danke für den Hinweis.
Session und Cookies. Ich bin nicht so sehr Insider. Wenn man mit PHP-Sessions arbeitet, werden dann automatisch auch Cookies gesendet? Bewusst mache ich das nicht, weil mich eh diese ewige Abfrage auf Webseiten nervt. Wer ist bloss auf diese "geniale..." Idee gekommen??? 🤪
Am Anfang der Startseite steht jetzt bei mir nur:
<!DOCTYPE HTML>
<html lang="de">
<head> <title>...</title>
<meta charset="utf-8" >
Sollte also reichen bezüglich der Sprache.
Erstmal einen schönen Samstag allen!
Treziman
Hallo,
Der Einstieg kann von überall erfolgen, nicht unbedingt nur über die Startseite - z.B. durch ein Bookmark oder über eine Suchmaschine. Deshalb muss von jeder Seite aus auch ein Login verfügbar sein.
Nein, so soll es nicht sein. Ein User kann nicht in den Mitgliederbereich wenn er sich zuvor nicht eingeloggt hat. Sollte ein Bookmark gesetzt worden sein und der User will später wieder auf diese Unterseite, wird er zur Startseite umgeleitet, muss sich zuerst einloggen und darf dann weiter. So lautet der Auftrag.
ein dämlicher Auftrag. In so einem Fall sehe ich es als Pflicht der Webentwickler, den Auftraggeber darauf hinzuweisen, dass er da Mist verlangt und zumindest zu versuchen, ihn in diesem Punkt zu beraten.
Es ist wie hier, wenn man nicht angemeldet ist, kann man keinen Beitrag schreiben.
Das stimmt nicht. Das SELF-Forum ist eines der wenigen Foren im Netz, die man auch ohne Anmeldung und Registrierung nutzen kann. Ja, auch Beiträge schreiben.
Was ohne Registrierung nicht geht, sind Schmankerln wie individuelle Einstellungen oder Post an andere Nutzer schreiben. Oder Beiträge bewerten.
Session und Cookies. Ich bin nicht so sehr Insider. Wenn man mit PHP-Sessions arbeitet, werden dann automatisch auch Cookies gesendet?
Naja, überleg mal: An irgendeinem Merkmal muss der Server den Besucher doch wiedererkennen, um ihm wieder die richtigen Session-Werte zuzuordnen. Das ist die sogenannte Session-ID. Kommt der Request gleich mit einem Cookie an, das eine Session-ID enthält, sucht PHP beim Aufruf von session_start() die dazu passenden Session-Werte raus und stellt sie dem Script zur Verfügung. Liefert der Client keine oder eine ungültige Session-ID, wird an dieser Stelle eine neue Session erzeugt.
Es gibt noch die Möglichkeit, die Session-ID als URL-Parameter zu übergeben, aber das hab ich noch nirgendwo gesehen.
Bewusst mache ich das nicht, weil mich eh diese ewige Abfrage auf Webseiten nervt.
Mich auch. Dabei ist sie meist gar nicht nötig. Cookies, die notwendig sind, um eine gewisse Funktionalität anzubieten, bedürfen keiner Einwilligung.
Wer ist bloss auf diese "geniale..." Idee gekommen??? 🤪
Leute, die die DSGVO nicht wirklich verstanden haben.
Einen schönen Tag noch
Martin
@@Der Martin
da greife ich einen Einwand von Gunnar nochmal auf: Der Einstieg kann von überall erfolgen, nicht unbedingt nur über die Startseite - z.B. durch ein Bookmark oder über eine Suchmaschine. Deshalb muss von jeder Seite aus auch ein Login verfügbar sein.
Und es muss von jeder Seite aus auch die Sprachumschaltung verfügbar sein, damit Nutzer zur Registrierung gelangen können.
> > <meta name="language" content="DE,EN" > > > <meta name="content-language" content="de,en" >Ich kannte diese meta-Typen bisher gar nicht, habe sie noch nirgends bewusst gesehen, geschweige denn selbst verwendet. Das W3C erklärt sie für veraltet und rät, die Sprache des Dokuments stattdessen im lang-Attribut des html-Elements zu notieren.
Für die Sprache des Dokuments (d.h. des Inhalts) war content-language auch nicht gedacht; dafür war schon immer das lang-Attribut da.
content-language diente zur Angabe der Sprache(n) der Zielgruppe.
Falsch ist auf jeden Fall, gleich zwei Sprachen anzugeben.
Nö. In bestimmten Fällen konnte das richtig sein, bspw. wenn so wenig Text auf der Seite ist, dass er gleich auf deutsch und auf englisch auf derselben Seite steht.
Als Grund für die Abschaffung vermute ich (bzw. glaube mich zu erinnern), dass das selten verwendet wurde, und wenn, dann oftmals falsch (zur Angabe der Sprache des Inhalts).
Dein Dokument ist entweder in Deutsch oder in Englisch gehalten, aber nicht beides.
Im lang-Attribut darf natürlich nur eine Sprache angegeben werden.
Und wenn die Sprache auf einer Seite wechselt, müssen die anderssprachigen Stellen ihr eigenes lang-Attribut tragen:
<html lang="de">
⋮
<p>
„<span lang="en">It’s a town full of losers
and we’re pulling out of here to win</span>“,
singt Bruce Springsteen in „<span lang="en">Thunder Road</span>“,
dem Eröffnungslied des Albums <i lang="en">Born to Run</i>.
</p>
Außerdem werden die Sprachkürzel normalerweise in Kleinbuchstaben notiert. Mit Großbuchstaben bezeichnet man die Länder
Ja, das ist Konvention. Die Verarbeitung der Sprachkürzel und Landeskürzel sollte aber immer case-insensitive erfolgen.
(Der vorigige Satz ist auch ein Beispiel einer anderssprachigen Stelle mit eigenem lang-Attribut.)
wobei die Korrelation von Ländern und Sprachen in den seltensten Fällen eine 1:1-Beziehung ist.
Siehe https://forum.selfhtml.org/self/2020/jul/26/dropdown-menu-zur-sprachenerweiterung/1773831#m1773831.
de-DE: Deutsch wie in Deutschland gesprochen
de-AT: Deutsch in der österreichischen Variante
Die Unterschiedung ist IMHO nicht sinnvoll. Als Locale ja (damit bei der formatierten Ausgabe eines Datums für Ösis „Jänner“ geschrieben wird), aber nicht als Sprachangabe. Es ist normal, dass innerhalb des Deutschen regional unterschiedliche Wörter verwendet weden („Möhrrübe“/„Möhre“/„Karotte“), und die Abweichungen zwischen Nord- und Süddeutschland (was beides de-DE wäre) sind größer als die zwischen Süddeutschland und Österreich.
de-CH hingegen macht Sinn, da in der Schweiz in der Schriftsprache einiges anders ist: kein ß, andere Anführungszeichen (nicht „so“ oder »so«, sondern «so»).
(Und wieder ein lang-Attribut mitten im Satz.)
🖖 Живіть довго і процвітайте
@Martin
ein dämlicher Auftrag. In so einem Fall sehe ich es als Pflicht der Webentwickler, den Auftraggeber darauf hinzuweisen, dass er da Mist verlangt und zumindest zu versuchen, ihn in diesem Punkt zu beraten.
Irgendwann kommt beim Besprechen des Layouts und der Funktionalität der Punkt wo man sagen muss: "Jawohl, gut, so machen wirs.". Warum ist klar - der Auftraggeber zahlt.
Ich hatte mal einen Kunden, der seine Artikel über seine Webseite verkauft hat. Er kam zu mir und wollte, dass beim Aufrufen seiner Startseite am oberen Bildschirmrand eine Laufschrift von rechts nach links lief und momentane Angebote enthielt. Ich habe ihn damals gefragt, ob er diese Laufschrift auf jeder seiner Unterseiten haben wollte. Nein, wollte er nicht, mit der Begründung, dass dies seine Kunden irritieren würde. Also nur auf der Startseite. Wollte ein Kunde bei ihm einen Artikel bestellen oder bezahlen, musste er sich einloggen, hatte er sich zuvor registriert. Die Webseite stammte nicht von mir, aber hier war es so, dass sich seine Kunden von überall einloggen konnten und danach, ob mans glaubt oder nicht, auf der Startseite landeten, um wiedermal die Laufschrift sehen zu müssen...
Ich halte mich hier mal mit einer Beurteilung über Sinn, Zweck, Abenddämmerung und Essgewohnheiten bescheiden zurück...
Übrigens, bevor ich diese Laufschrift eingebaut habe, landeten seine Kunden nach dem Login auch auf der Startseite. 🙂
Es ist wie hier, wenn man nicht angemeldet ist, kann man keinen Beitrag schreiben.
Das stimmt nicht. Das SELF-Forum ist eines der wenigen Foren im Netz, die man auch ohne Anmeldung und Registrierung nutzen kann. Ja, auch Beiträge schreiben.
Das ist mir bisher noch gar nicht aufgefallen. Das bedeutet ja, dass hier jeder seinen grammatikalen Müll anonym abladen könnte?!😜 Jessusmariaundjosef!
Die Sache mit Sessions und Cookies leuchtet mir ein. Aber wie läuft das denn, wenn ein User keine Cookies zulässt? Es müsste trotzdem ein Cookie an den Browser gesendet und gespeichert werden, da ansonsten die PHP-Session nicht funktioniert?
Es gibt noch die Möglichkeit, die Session-ID als URL-Parameter zu übergeben, aber das hab ich noch nirgendwo gesehen.
Ironie an:
Das ist aber ein völlig normales Verfahren, das ich immer anwende. Damit handle ich absolut kollektiv-konform und erlaube es unbedarften Hackern vereinfacht eine Session-ID abzufangen und sich einrahmen zu lassen...👍
Ironie aus
Leute, die die DSGVO nicht wirklich verstanden haben.
Ob das wohl dieselben waren, die sich einst zwischen Schampus, Sieben-Gänge-Menü und ein paar Miezen über die Raucher Gedanken gemacht haben und auf Bahnsteigen ein paar Striche malen liessen...?
@Gunnar
Und es muss von jeder Seite aus auch die Sprachumschaltung verfügbar sein, damit Nutzer zur Registrierung gelangen können.
Äh, Gunnar, bei allem Respekt. Daraus lese ich, dass ein User, will er die Sprache umschalten, ein Registrierungsformular vorgesetzt bekommt? Du meinst das sicher anders?
Besagter Auftraggeber wünscht, dass die Sprache auf der Startseite mittels JS ausgewählt werden kann, nach Registrierung und Login kann der User dies dauerhaft unter "Einstellungen" tun. Da, wo man z.B. auch die Email ändern kann, was nicht geht wenn man nicht eingeloggt ist. Letzteres ergibt, meiner Meinung nach, auch Sinn.
Aber nochmal eine grundsätzliche Frage. Ich habe bei Google bezüglich Sprachauswahl gelesen und so verstanden, die Crawler wären "irritiert" wenn sie auf Folgendes stiessen: z.B.
<div id='Sprachauswahl'>
<p class='ger' lang='de'>Text in deutsch</p>
<p class='eng' lang='en'>Text in english</p>
</div>
Ich könnte das nachvollziehen. Ist das so?
Der Sonntag kann kommen...
LG Treziman
Moin,
ein dämlicher Auftrag. In so einem Fall sehe ich es als Pflicht der Webentwickler, den Auftraggeber darauf hinzuweisen, dass er da Mist verlangt und zumindest zu versuchen, ihn in diesem Punkt zu beraten.
Irgendwann kommt beim Besprechen des Layouts und der Funktionalität der Punkt wo man sagen muss: "Jawohl, gut, so machen wirs.". Warum ist klar - der Auftraggeber zahlt.
ja schon ... es ist trotzdem ein dämliches Konzept. Nutzerfreundlich geht anders.
Das SELF-Forum ist eines der wenigen Foren im Netz, die man auch ohne Anmeldung und Registrierung nutzen kann. Ja, auch Beiträge schreiben.
Das ist mir bisher noch gar nicht aufgefallen. Das bedeutet ja, dass hier jeder seinen grammatikalen Müll anonym abladen könnte?!😜 Jessusmariaundjosef!
Stimmt, und das passiert ja auch regelmäßig. Aber hier sind zum Glück ein paar Stammgäste und Moderatoren beinahe rund um die Uhr aktiv, so dass ein Spam- oder Trollbeitrag meist schnell wieder weg ist.
Die Sache mit Sessions und Cookies leuchtet mir ein. Aber wie läuft das denn, wenn ein User keine Cookies zulässt?
Dann hat er Pech, und das sessionbasierte Login geht halt nicht.
Leute, die die DSGVO nicht wirklich verstanden haben.
Ob das wohl dieselben waren, die sich einst zwischen Schampus, Sieben-Gänge-Menü und ein paar Miezen über die Raucher Gedanken gemacht haben und auf Bahnsteigen ein paar Striche malen liessen...?
Vielleicht nicht dieselben, aber dieselbe Sorte. Du meinst die Striche auf dem Bahnsteig, die ein etwa 2x3m grißes Rechteck beschreiben, das dann "Raucherzone" genannt wird? Klar, der Qualm weiß natürlich, dass er dieses Rechteck nicht verlassen darf.
@Gunnar
Und es muss von jeder Seite aus auch die Sprachumschaltung verfügbar sein, damit Nutzer zur Registrierung gelangen können.
Äh, Gunnar, bei allem Respekt. Daraus lese ich, dass ein User, will er die Sprache umschalten, ein Registrierungsformular vorgesetzt bekommt?
Nein, genau das nicht! Gunnar meint, dass das Umschalten der Sprache auf jeder Seite möglich sein muss,[1] unabhängig davon, ob angemeldet oder nicht. Und wenn man angemeldet ist, kann diese Präferenz dann auch gespeichert werden.
Besagter Auftraggeber wünscht, dass die Sprache auf der Startseite mittels JS ausgewählt werden kann
Warum per Javascript, und warum nur auf der Startseite?
Aber nochmal eine grundsätzliche Frage. Ich habe bei Google bezüglich Sprachauswahl gelesen und so verstanden, die Crawler wären "irritiert" wenn sie auf Folgendes stiessen: z.B.
<div id='Sprachauswahl'> <p class='ger' lang='de'>Text in deutsch</p> <p class='eng' lang='en'>Text in english</p> </div>Ich könnte das nachvollziehen. Ist das so?
Was soll daran merkwürdig sein? Das einzig Merkwürdige ist das Fehlen eines aktiven Elements, also vorzugsweise eines Links auf die ausgewählte Sprachfassung.
Der Sonntag kann kommen...
Und er bedeutet leider auch, dass meine Winterferien vorbei sind und ich morgen wieder zur Arbeit gehen darf. Schade, ich hatte mich gerade an die freien Tage gewöhnt. 🙃
Einen schönen Tag noch
Martin
Denn auch ein Besucher, der kein Deutsch kann, aber über ein Bookmark oder einen Suchtreffer auf einer x-beliebigen Seite landet, sollte wenigstens den Sprachwähler finden und auf (s)eine Sprache umstellen können, die er versteht. ↩︎
@@Treziman
Das stimmt nicht. Das SELF-Forum ist eines der wenigen Foren im Netz, die man auch ohne Anmeldung und Registrierung nutzen kann. Ja, auch Beiträge schreiben.
Das ist mir bisher noch gar nicht aufgefallen. Das bedeutet ja, dass hier jeder seinen grammatikalen Müll anonym abladen könnte?!😜 Jessusmariaundjosef!
Wenn’s doch nur der grammatikale wäre! 🤨
Und es muss von jeder Seite aus auch die Sprachumschaltung verfügbar sein, damit Nutzer zur Registrierung gelangen können.
Äh, Gunnar, bei allem Respekt. Daraus lese ich, dass ein User, will er die Sprache umschalten, ein Registrierungsformular vorgesetzt bekommt? Du meinst das sicher anders?
Ja, anders:
Jemand, der kein Deutsch versteht, kommt auf die eine Seite und kann mit dem Link „Anmelden“ nichts anfangen. Die Sprachumschaltung muss also schon vorher verfügbar sein, bevor Nutzer sich anmelden oder einloggen. Oder anders gesagt: damit sie sich anmelden oder einloggen können.
🖖 Живіть довго і процвітайте
Vielleicht nicht dieselben, aber dieselbe Sorte. Du meinst die Striche auf dem Bahnsteig, die ein etwa 2x3m grißes Rechteck beschreiben, das dann "Raucherzone" genannt wird? Klar, der Qualm weiß natürlich, dass er dieses Rechteck nicht verlassen darf.
Genau die meine ich. Dieter Nuhr hat sich darüber mal ausgelassen und gefragt: "Wer kommt auf sowas?" Eben genau die Sorte "Denker" ... 😀
Ja, anders:
Jemand, der kein Deutsch versteht, kommt auf die eine Seite und kann mit dem Link „Anmelden“ nichts anfangen. Die Sprachumschaltung muss also schon vorher verfügbar sein, bevor Nutzer sich anmelden oder einloggen. Oder anders gesagt: damit sie sich anmelden oder einloggen können.
Okay. Ich versuche nachfolgend mal die bisherige Struktur zu verdeutlichen. Wie alles programmiertechnisch umgesetzt wird, ist meine Sache und dem Auftraggeber egal. Das Layout und die Bedienbarkeit ist NICHT (allein) meine Sache. Hier kann auch ich nur in beratender Funktion auftreten.
Es sieht bis jetzt also wie folgt aus:
Startseite:
[label.png]; darunter links beginnend:
Deutsch / German [ger.png](deutsche Fahne) English / International[int.png](englische Fahne)
Ich weiss, habs gelesen, die Flaggen haben nix mit der Sprache zutun. Aber --> Auftraggeber: "...als Blickfang könnten sie hilfreich sein..."
Okay, hab alles umlabelt und mit IDs (für JS) versehen. Dies ist das Sprachauswahlmenü auf der Startseite mit den kleinen Fähnchen als Blickfang.
Es folgt eine <h1> und darunter die Navigation als Liste mit genau 8 Links:
Link 1
Link 2
Link 3 (Registrieren)
Link 4 (Anleitung)
Link 5 (LOGIN)(Ich denke, dass verstehen auch diejenigen, die veranlassen Striche auf Bahnsteigen zu zeichnen. Bin mir aber nicht 100%ig sicher.)
Es folgen 3 weitere Links zu Datenschutz, Impressum und AGB.
Mehr ist auf der Startseite nicht. Hinter Link 1 + 2 verbergen sich nur Erklärungstexte, die im Bedarfsfall angezeigt werden (per JS).
Kommt nun ein Spanier (oder Sylvia) auf die Seite, wird diese in deutsch ausgeliefert. Der Spanier sieht die Fähnchen und klickt in den Bereich "English...". Die Sprache wird umgestellt und alles weitere, was auf der Startseite gezeigt werden soll, erscheint dann auch in englisch - alles, auch AGB etc. Deswegen hier auf der Startseite JS, da der Spanier weder registriert noch eingeloggt ist.
Der Spanier, der, nebenbei bemerkt, in Schweden in einem griechischen Restaurant sitzt und sich vom türkischen Ober englischen Tee servieren lässt, während er auf einem taiwanesischen Smartphone auf deutschen Webseiten herumsurft, findet nun Gefallen an der Webseite und klickt auf "Register". Das Registrierungsformular wird auf englisch angezeigt. Er gibt seine Daten ein (Email, PW etc.), u.a. auch seine bevorzugte Sprache. In diesem Fall Englisch. Ist alles okay, wirds gespeichert (DB).
Nach einem Login startet eine Session und enthält auch seine Spracheinstellung. Eigentlich braucht der Spanier die Sprache nicht mehr umstellen, da er mit deutsch nichts anfangen kann. Er hat aber trotzdem die Möglichkeit dazu, und zwar unter "Daten ändern", bzw. "Change data". Er braucht sich dann auch nicht extra aus- und wieder einloggen, da die Sessionvariable per AJAX geändert wird.
Anhand der Session kann nun im Mitgliederbereich die Sprache festgestellt werden.
Auf der Startseite ist also das Menü zur Sprachauswahl links dauerhaft deutlich über der Navi zu sehen und kann jederzeit genutzt werden.
Ich würde ja einen Screenshot machen und hier mal posten. Aber das darf ich nicht, weil zumindest, soviel ich weiss, die Domain noch nicht registriert ist. Aber vielleicht könnt ihr euch einigermassen vorstellen, wie es aussieht. Kritik und Gewaltandrohung bitte an --> Auftraggeber...
@Martin
Kopf hoch! Es kommen wieder mal Ferien!😃
LG Treziman
Hallo,
Du meinst die Striche auf dem Bahnsteig, die ein etwa 2x3m grißes Rechteck beschreiben, das dann "Raucherzone" genannt wird? Klar, der Qualm weiß natürlich, dass er dieses Rechteck nicht verlassen darf.
Genau die meine ich. Dieter Nuhr hat sich darüber mal ausgelassen und gefragt: "Wer kommt auf sowas?" Eben genau die Sorte "Denker" ... 😀
das ist derselbe Quatsch wie mit den Feinstaub-Verbotszonen. Fahr mal in Gedanken von Heilbronn kommend die A81 nach Süden. Sobald die Abfahrten zu den Vororten und Randgebieten von Stuttgart kommen (Ludwigsburg, S-Zuffenhausen, S-Feuerbach), steht an jeder Abfahrt ein Schild, das mindestens eine blaue Feinstaub-Plakette vorschreibt (bis vor ein paar Jahren genügte noch die grüne). So soll die Luftqualität in den Ortschaften nicht leiden. Denn auch wenn die fiesesten Dreckschleudern die Autobahn runterdonnern: Der Feinstaub weiß genau, dass er an der Straße bleiben muss und nicht abziehen darf.
Und bitte jetzt kein Diesel-Bashing: Es dürfte mittlerweile jedem klar sein (auch wenn manche es nicht zugeben wollen), dass nur ein geringer Teil des verkehrsbedingten Feinstaub-Aufkommens aus dem Auspuff dringt. Einen wesentlich höheren Anteil hat Abrieb, z.B. von Reifen und Bremsen.
Okay. Ich versuche nachfolgend mal die bisherige Struktur zu verdeutlichen.
Danke, ich glaube, ich hatte sie vorher schon verstanden. Nur kann ich das Konzept bzw. den Ansatz nicht gutheißen. Ich mache daher ein Gegenangebot und versuche dir zu erklären, wie ich das mit der Sprachumschaltung machen würde bzw. hier und da auch schon gemacht habe.
Zentral in der Navigation jeder Seite steht ein Sprachwähler. Der sieht ungestylt etwa so aus:
<ul id="lang-picker">
<li><a href="?lang=de">Deutsch</a></li>
<li><a href="?lang=en">English</a></li>
<li><a href="?lang=fr">Français</a></li>
<li><a href="?lang=nl">Nederlands</a></li>
</ul>
Das ist clientseitig erstmal alles. Wann immer der Besucher durch Anklicken eines Sprach-Links ausdrücklich eine bestimmte Sprache wählt, wird die aktuelle Seite neu geladen, aber mit dem URL-Parameter lang und einem ISO-Sprachkürzel als Wert.
Serverseitig beginnt mein Script mit einem session_start(). Dann eine mehrstufige Abfrage:
Fertig. Kommt ein Besucher von irgendwoher, bekommt er zunächst die Sprachfassung, die sich sein Browser wünscht; er kann das aber jederzeit umstellen, das wird auch gespeichert. Der Wert aus der Session hat Vorrang vor dem Browser-Default. Und der URL-Parameter hat nochmal Vorrang gegenüber allem anderen, der gewinnt immer.
Was erreiche ich damit? Ich kann jederzeit, auf jeder beliebigen Seite des Webauftritts die Sprache umstellen und muss dafür keinen Umweg über die Startseite machen.
In deinem Fall müsste noch dazukommen, dass die Sprache zusätzlich auch in den Benutzer-Einstellungen gespeichert wird und von da aus beim Script-Befinn sowie nach einem Login auch in die Session kopiert wird.
Einen schönen Tag noch
Martin
@@Der Martin
Zentral in der Navigation jeder Seite steht ein Sprachwähler. Der sieht ungestylt etwa so aus:
<ul id="lang-picker"> <li><a href="?lang=de">Deutsch</a></li> <li><a href="?lang=en">English</a></li> <li><a href="?lang=fr">Français</a></li> <li><a href="?lang=nl">Nederlands</a></li> </ul>
Aber nur etwa. Was fehlt: Die Angaben der Sprachen der Linkbeschriftungen. ☞ language switch
Serverseitig beginnt mein Script mit einem session_start(). Dann eine mehrstufige Abfrage:
- Enthält der HTTP-Request einen Accept-Language-Header? Dann nimm den ersten darin gelistete Sprachcode, den du auch bedienen kannst. Wenn der Besucher also Accept-Language: it,de,en anfragt, picke ich mir "de" raus, weil ich Italienisch nicht im Sortiment habe.
- Ist in der Session der Code für eine unterstützte Sprache gespeichert? Dann nimm den.
Meinst du das mit fall thru?
Die einmal vom Nutzer gewählte Sprache muss Priorität gegenüber der aus dem Accept-Language-Header haben.
Das heißt, wenn der Nutzer eine Sprache gewählt hat, muss man den Accept-Language-Header gar nicht auswerten.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Serverseitig beginnt mein Script mit einem session_start(). Dann eine mehrstufige Abfrage:
- Enthält der HTTP-Request einen Accept-Language-Header? Dann nimm den ersten darin gelistete Sprachcode, den du auch bedienen kannst. Wenn der Besucher also Accept-Language: it,de,en anfragt, picke ich mir "de" raus, weil ich Italienisch nicht im Sortiment habe.
- Ist in der Session der Code für eine unterstützte Sprache gespeichert? Dann nimm den.
Meinst du das mit fall thru?
ja, das meine ich mit "mehrstufig". Jede Entscheidung kann das bisherige Ergebnis der vorangegangenen Stufen wieder überschreiben.
Die einmal vom Nutzer gewählte Sprache muss Priorität gegenüber der aus dem Accept-Language-Header haben.
Das heißt, wenn der Nutzer eine Sprache gewählt hat, muss man den Accept-Language-Header gar nicht auswerten.
Das stimmt zwar, schadet aber auch nicht. Ich finde es übersichtlicher, Schritt für Schritt in Richtung höherer Prioritäten vorzugehen.
Einen schönen Tag noch
Martin
@@Treziman
Genau die meine ich. Dieter Nuhr hat sich darüber mal ausgelassen und gefragt: "Wer kommt auf sowas?" Eben genau die Sorte "Denker" ... 😀
Sich auslassen ist auch das Einzige, was der Nuhr noch draufhat. Wenn der irgendwann mal lustig gewesen sein sollte, dann ist das sehr lange her. Der kann bestenfalls noch als Beispiel dafür herhalten, dass der öffentlich-rechtliche Rundfunk nicht linksgrün-dominiert ist („vErSiFfT“), sondern dass da auch rechte Kotzbrocken ihr Stammtischgegröhle absondern dürfen.
🖖 Живіть довго і процвітайте
n'Abend,
Genau die meine ich. Dieter Nuhr hat sich darüber mal ausgelassen und gefragt: "Wer kommt auf sowas?" Eben genau die Sorte "Denker" ... 😀
Sich auslassen ist auch das Einzige, was der Nuhr noch draufhat. Wenn der irgendwann mal lustig gewesen sein sollte, dann ist das sehr lange her.
der will auch nicht nur einfach lustig sein - er will provozieren und die Leute dreimal um die Ecke dazu bringen, über bestimmte Dinge nachzudenken. Mir gefällt beispielsweise auch sein Buch Gibt es intelligentes Leben?
Darin kommt er nach vielen Betrachtungen zu der Erkenntnis: Ja, vielleicht gibt es intelligentes Leben. Aber nicht so, wie die meisten von uns sich das vorstellen.
Sondern eher so bei Amöben. Die hadern nicht mit ihrem Leben, die versuchen nicht dauernd, etwas Besseres zu erreichen - die versuchen einfach, mit dem zurechtzukommen, was sich ihnen bietet.
Einen schönen Tag noch
Martin
@@Treziman
English / International[int.png](englische Fahne)
Wirklich? Ich glaub das nicht.
Die englische Fahne (Georgskreuz) dürften den meisten (incl. dir?) unbekannt sein (wenn nicht gerade Fußball-WM ist oder Darts-WM).
Du meintest vermutlich nicht die englische Fahne, sondern die britische?[1] ☞ Union Jack
Ich weiss, habs gelesen, die Flaggen haben nix mit der Sprache zutun. Aber --> Auftraggeber: "...als Blickfang könnten sie hilfreich sein..."
Warum kein Sprachumschalter-Icon als Blickfang? ☞ language switch
🖖 Живіть довго і процвітайте
[Ergänzung] genauer gesagt: die Fahne des Vereinigten Königreichs ↩︎
Hi,
Du meintest vermutlich nicht die englische Fahne, sondern die britische?[^UK] ☞ Union Jack
und vermutlich auch nicht eine Fahne, sondern eine Flagge …
cu,
Andreas a/k/a MudGuard
Hallo,
Du meintest vermutlich nicht die englische Fahne, sondern die britische?[^UK] ☞ Union Jack
und vermutlich auch nicht eine Fahne, sondern eine Flagge …
eine Fahne ist oft auch eine Flagge; eine Flagge ist oft auch eine Fahne. Die Fahne ist ein im Wind wehender Fetzen Stoff; die Flagge ist das Symbol, das einen Staat repräsentiert.
Das ist ebenso eine Erbsenzählerei wie bei Führerschein und Fahrerlaubnis: Der Führerschein ist das amtliche Dokument, das bestätigt, dass der Inhaber eine Fahrerlaubnis hat.
Immerhin unterscheidet der Bußgeldkatalog auch sehr genau zwischen Fahren ohne Führerschein und Fahren ohne Fahrerlaubnis. Ersteres (z.B. wenn man den Lappen gerade mal nicht dabei hat) ist eine Ordnungswidrigkeit, die mit einem Bußgeld geahndet werden kann; es liegt aber im Ermessen des kontrollierenden Beamten, auch mal ein Auge zuzudrücken und einfach zu glauben, dass man im Besitz einer gültigen Fahrerlaubnis ist. Zweiteres ist aber AFAIK eine Straftat (z.B. wenn man sich trotz eines vierwöchigen Fahrverbots ans Steuer setzt) und wird auch kompromisslos geahndet.
Einen schönen Tag noch
Martin
@@MudGuard
und vermutlich auch nicht eine Fahne, sondern eine Flagge …
Mir lag’s auf der Zunge.
Wollte gerade nach dem Unterschied fragen, aber da ha’m wa’s ja.
🖖 Живіть довго і процвітайте
Hallo und guten Morgen,
eine Fahne hat auch einer, der sich volltrunken hinters Steuer setzt - egal ob mit oder ohne Führerschein - und sich aufgrund seines Promillegehalts selbst die Fahrerlaubnis erteilt. Er wedelt mit der Fahne vor der Verkehrskontrolle herum und muss spätestens nach Entlassung aus der Ausnüchterungszelle "Flagge zeigen" und sagen: "Ja, Herr Wachtmeister, ich hatte den Kanal rappelvoll!". Hier ist der Unterschied zwischen Fahne und Flagge allerdings sehr gravierend...
@Gunnar
Klar, ich meine den Union Jack. Wenn man über die Briten philosophiert sagt man auch oft "Engländer".
Die englische Fahne (Georgskreuz) dürften den meisten (incl. dir?) unbekannt sein (wenn nicht gerade Fußball-WM ist oder Darts-WM).
EINSPRUCH! Die englische Fahne ist mir sehr wohl bekannt... aus dem Film "Braveheart"... Aber wenn die Engländer bei einem Turnier Fussball spielen, schaue ich demonstrativ einen Western, um sie zu ärgern!😀
Warum kein Sprachumschalter-Icon als Blickfang?
Weil ich das Layout nicht bestimmen darf. Ich könnte dem Auftraggeber mal vorschlagen, die Fahne der EU als einzelne dort zu platzieren. Dann wird er sicher fragen, ob denn die Engländer noch in der EU sind... Und was ein Chinese mit der EU-Flagge anfangen soll... Wenn ich ihm dann erkläre, dass er mit Engländer eigentlich die Briten meint und der Chinese sicher wüsste, dass er bei einem Klick in den EU-Fahnenbereich nicht derselbigen beitreten muss, bin ich den Auftrag los und muss mir einstweilen für nachts eine andere Beschäftigung suchen, statt zu programmieren. Hier muss ich mich untertänigst fügen, da der Kunde eben zwei Fahnen wünscht.😉
Kurz: Das Layout ist - leider - tabu!
Ich habe mir trotzdem mal die Mühe gemacht und zwei Screenshots erstellt, allerdings dann mit Photoshop bearbeitet. Das Layout sollte man aber erkennen. Aha, man kann nur ein Bild hochladen. Wie dürftig ist das denn? Ist das die "Müllbremse" gegen international-anonymen Grafikterror?😀
Gut, ein Bild reicht auch. Hier die responsive Version.
Ansich kein grosses Ding.
Ich schaue gerade, wie der Ablauf funktioniert. Wie gesagt, ich muss mich zum ersten Mal mit Sprachauswahl beschäftigen. Nach meinem augenblicklichen Stand wäre das folgendermassen:
Anfrage an den Server:
<a href="https://www.example.de?lang=de">
lang=de wird wie eine GET-Variable angehängt?
Auf dem Server liegen die Dateien:
index.de.html und index.en.html
Und nun sucht sich der Server die richtige Variante heraus? Erscheint mir etwas zu einfach...😉
Ich schau erstmal mal weiter...
Danke und LG Treziman
@@Treziman
Wenn man über die Briten philosophiert sagt man auch oft "Engländer".
Ach, tut man das?
Das solltest du keinen Schotten hören lassen. Der spießt dich sonst auf den Pfeifen seines Dudelsacks auf.
Aha, man kann nur ein Bild hochladen.
Ach, ist das so?
🖖 Живіть довго і процвітайте
Hallo Gunnar,
Das solltest du keinen Schotten hören lassen. Der spießt dich sonst auf den Pfeifen seines Dudelsacks auf.
Jau, da haste allerdings Recht!😀
Wieso kannst Du vier Pics hochladen und ich nur eins??? Hab "durchsuchen" gemacht, dann "Bild hinzufügen", mit dem ersten. Dann mit dem zweiten dasselbe. Da wurde das erste überschrieben... Oder vielleicht sollte ich nicht soviel Kaffe trinken?
Sieh mal einer an - jetzt gehts! Ich vermute, das Hochladen von mehr als einem Pic geht aus Sicherheits- oder Jugendschutzgründen erst ab 6.00 Uhr?😜
Bis später Treziman
Die Frage kommt immer mal wieder ...
Hallo,
also, ich hab jetzt mal folgendes gebaut:
Startseite (index.php):
<?php
$grundspr = $_SERVER["HTTP_ACCEPT_LANGUAGE"];
$languag="en"; // Sprache erstmal grundsätzlich auf englisch
if(strpos($grundspr,"de",0) !== false){
$languag = "de";
}
?>
<!DOCTYPE HTML>
<html lang="de">
<head> <title>Sprachwahl</title>
<meta charset="utf-8" >
</head>
<body>
<a href='wechs/main_sprache.php?lang=de'>in Deutsch</a>
<a href='wechs/main_sprache.php?lang=en'>in Englisch</a>
</body>
</html>
Die Folgeseite (hier einfach main_sprache.php):
<?php
$grundspr = $_SERVER["HTTP_ACCEPT_LANGUAGE"];
$languag="en"; // Sprache erstmal grundsätzlich auf englisch
//hier wäre nach LOGIN zuerst gespeicherte Sprache aus DB
//$languag = (aus DB)
if(isset($_GET["lang"]) && ($_GET["lang"]=="de" || $_GET["lang"]=="en"))
{
$lang = $_GET["lang"];
}else{
if(strpos($grundspr,"de",0) === false){
$lang = "en";
}
}
if($lang=="de" || $lang=="en"){
$languag=$lang;
}
$version = "ausgabe_".$languag.".php";
include_once($version);
?>
In den beiden Includes ($version) steht zum Testen jetzt einfach nur : "Alles in deutsch" oder "Alles in englisch".
Das funktioniert zwar, bedeutet aber, dass JEDES Skript vom Code her doppelt hinterlegt sein muss, wobei sich nur der Text sprachlich ändert. Da auf den Folgeseiten mehr Code als Text enthalten ist, schaue ich mal, wie ich das am besten mache.
Vielen Dank nochmal an Martin und Gunnar! Auch für die Aufklärung der britischen Nationalverhältnisse in Verbindung mit der Unterscheidung zwischen Wimpel und Bettlaken...👍😃
Bis bald und LG Treziman
@@Treziman
$grundspr = $_SERVER["HTTP_ACCEPT_LANGUAGE"];
Was soll grundspr bedeuten?
Variablen mal deutsch, mal englisch zu benennen ist auch keine gute Idee.
Und warum kopierst du $_SERVER["HTTP_ACCEPT_LANGUAGE"] überhaupt in eine Variable um?
$languag="en"; // Sprache erstmal grundsätzlich auf englisch
$language mit e.
if(strpos($grundspr,"de",0) !== false){ $languag = "de"; }
Die Abfrage ist falsch. In mehrfacher Hinsicht.
1. Wenn der gesendete Accept-Language-Header bspw. en-US,en;q=0.7,de;q=0.3 ist, dann will der Nutzer bevorzugt Englisch haben, nicht Deutsch.
Du darfst nicht nur nach dem Vorkommen von de suchen, sondern musst auch die Reihenfolge der Sprachen im Accept-Language-Header beachten.
2. Das Vorkommen von de heißt nicht unbedingt Deutsch. Es gibt eine Vielzahl anderer Sprachen, deren dreibuchstabiges Kürzel de enthält. [IANA Language Subtag Registry]
(Fun fact: Auch Google hatte das mal falsch gemacht.)
Du müsstest also nach \bde\b suchen. Aber auch das ist nicht ganz sicher.
Für de fällt mit kein sinnvolles Beispiel ein, aber für it. Ein Südtiroler könnte de-it (in Italien gesprochenes Deutsch) in seinem Accept-Language-Header stehen haben. Wenn man diesen nach \bit\b durchsucht, ergibt es einen Treffer. Es wäre aber falsch, daraus zu folgern, dass die italienische Sprachvariante ausgeliefert werden soll.
Man müsste also auch prüfen, ob das gefundene it (bzw. de) auch wirklich ein Sprachkürzel ist und kein anderer Bestandteil des Sprachcodes; also ob kein - (oder _) unmittelbar davor steht. [Language Tags]
3. Dass Sprachcodes case-insensitive verarbeitet werden müssen, sagte ich schon. DE muss gleichbehandelt werden wie de.
🖖 Живіть довго і процвітайте
Hallo Gunnar,
das Interpretieren dieses Headers ist ziemlich komplex. Dafür müsste es doch eigentlich fertige Bausteine geben, oder?
Rolf
Moin,
das Interpretieren dieses Headers ist ziemlich komplex. Dafür müsste es doch eigentlich fertige Bausteine geben, oder?
Im Wiki gäbe es da was …
Gruß
Tobias
Hallo tk,
um einen alten IBM Spruch aufzugreifen:
"Wenn Selfhtml wüsste, was Selfhtml alles weiß..." 😉
Ich finde die dort vorgestellte Funktion im Hinblick auf Testbarkeit und SoC allerdings Käse. Für das PHP von 2003 vermutlich ok, aber seitdem hat sich einiges getan. Aber ich werd wohl nicht dazu kommen, das aufzugreifen.
Rolf
Hi,
Für
defällt mit kein sinnvolles Beispiel ein, aber fürit. Ein Südtiroler könntede-it(in Italien gesprochenes Deutsch) in seinem Accept-Language-Header stehen haben.
da-de?
Dänisch, wie es von der dänischen Minderheit in Schleswig-Holstein gesprochen wird?
cu,
Andreas a/k/a MudGuard
Du darfst nicht nur nach dem Vorkommen von
desuchen, sondern musst auch die Reihenfolge der Sprachen im Accept-Language-Header beachten.
https://www.rfc-editor.org/rfc/rfc2616#section-14
... ist „sowas von 1999“. Soweit ich das Zeug verstehe soll das wohl wie folgt aufgelöst werden: (Darin sind wohl außerdem auch noch Leerzeichen erlaubt…)
String:
en-US,en-CA,en-AU;q=0.9;en;q=0.7,de;q=0.3
Resultat:
| LANG | Quality |
|---|---|
| en-US | 1 |
| en-CA | 0.9 |
| en-AU | 0.9 |
| en | 0.7 |
| (+ en-*) | (0.7) |
| de | 0.3 |
| (+ de-*) | (0.3) |
Wer auch immer das erfunden hat gehört in die CSV-Parser-Hölle verbannt, sollte aber zuvor ausreichend lang wegen des Unsinns bezüglich der notlosen und sodann auch noch unsinnigen Reihenfolge und Zuordnung von Sprache und Wichtung (die auch noch mit einem Float!) beschimpft werden. Eine simple Reihenfolge der Präferenzen hätte völlig genügt...
Um noch mehr Senf dazuzugeben:
zur Zeit beschäftige ich mich mit einem Projekt, das zweisprachig gestaltet werden soll, deutsch und englisch.
Wenn du dir Sorgen um die Suchmaschinenfreundlichkeit machst, dann bleibt dir gar nichts anderes übrig, als jede Sprache in einem eigenen URL-Pfad unterzubringen. Nur auf diese Weise kannst du sicherstellen, dass wirklich alle Seiten aller Sprachen von Automaten erkannt werden.
Auf eine Auswahl über Cookies, von jedwelchem Javascript-Spielkram ganz zu schweigen, ist in dieser Hinsicht kein Verlass, auch wenn Google damit mittlerweile leidlich umgehen kann.
Die angesprochene Multiviews-Methode mit /blafasel/index.de.php ist für meinen Geschmack aus mehreren Gründen eine schlechte. Du müsstest dasselbe Skript mehrfach speichern (weiteres siehe unten) und die Angabe von /blafasel/index.xyz ist in meinen Augen überflüssig (/blafasel/ reicht) und zudem ausgesprochen hässlich, wenn man auch noch auf .php verweist, weil unlogisch (der Besucher möchte kein PHP-Skript sehen, sondern ein HTML-Dokument, also sollte die Endung .html sein, nicht .php).
Deine Möglichkeiten würden sich bis hier schon mal auf die Frage beschränken, ob du lieber /de/blafasel/, ein Hauptverzeichnis je Sprache für alle Seiten, benutzen willst oder /blafasel/de/, ein Unterverzeichnis je Seite je Sprache.
Letzteres bietet zweierlei Vorteile:
Unter /blafasel/ erfolgt eine automatische Wahl entsprechend der vom Browser gemeldeten Präferenz Accept-Language oder der Benutzereinstellung, /blafasel/de und /blafasel/en bleiben festgelegt auf die jeweilige Sprache. Es könnte ja durchaus sein, dass sich mal jemand ausdrücklich auf eine Formulierung in einer Sprachfassung bezieht ("Das ist auf Englisch aber anders als auf Deutsch beschrieben!!einself").
Je nach Webserver hast du zudem eine einfache Möglichkeit, je Seite nur ein Skript speichern zu müssen: /blafasel/index.php. Die Adresse lautet hier /blafasel/, ihr Aufruf führt wie bekannt zur Ausführung von /blafasel/index.php. Bei Aufruf von /blafasel/de/ würde weiterhin /blafasel/index.php ausgeführt, das Anhängsel /de/ bekommst du zusätzlich in der Variablen $_SERVER["PATH_INFO"] übermittelt.
Beim Apache-Webserver in Verbindung mit PHP ist Option IIRC normalerweise eingeschaltet, weitere Infos siehe https://httpd.apache.org/docs/2.4/mod/core.html#acceptpathinfo
Der Nachteil ist eine etwas verschlungene Pfadstruktur. Unterseiten von /blafasel/de/ liegen nicht unter /blafasel/de/dings/ sondern unter /blafasel/dings/de. Die Variante /de/blafasel/ und /de/blafasel/dings/ ist zweifelsohne geradliniger. Sie erfordert allerdings Klimmzüge bei der Organisation der Skripte, um doppelte Speicherung zu vermeiden.
Bei anderen Völkern werden URLs gar nicht direkt auf Skriptdateien umgesetzt, sondern jede URL landet bei einem zentralen Skript und wird dort sozusagen von Hand aufgebrochen:
app = Application([
url(r"/", MainHandler),
url(r"/story/([0-9]+)", StoryHandler, dict(db=db), name="story")
])
(Nur mal als Anregung ein Stück Python aus dem Tornado-Server; du siehst hier, wie zwei Pfade, "/" und "/story/123", mittels regulärer Ausdrücke für Unterfunktionen namens MainHandler und StoryHandler registriert werden. Mit PHP geht sowas natürlich auch und hier wäre der Ansatz, Pfade nach dem Schema /de/blafasel/ ohne Doppelgemoppel abzuarbeiten.)
Die Möglichkeit, eine Sprache manuell zu wählen, solltest du auf jeder Seite vorsehen. Manche Leute sprechen weder die eine, noch die andere Sprache gut und behelfen sich damit, von allem etwas aufzuschnappen.
Von einer Sprachfassung sollten alle Verweise ausschließlich auf Seiten in dieser Sprachfassung gehen, unabhängig von der Sprachwahl: In /blafasel/de/ wird nur auf /blafasel/dings/de verwiesen. Selbst wenn jemand Englisch eingestellt hat, wird es seinen Grund haben, dass er eine deutschsprachige Seite aufgerufen hat und dieser Grund dürfte weiter Bestand haben, wenn er zur nächsten Seite wechselt.
Dann wäre da noch die Möglichkeit, alle Skripte zu duplizieren, die Texte darin zu übersetzen und in getrennten, der Sprache zugehörigen Unterordnern abzuspeichern. Scheint mir am besten zu sein.
Du möchtest deinen Seiten- und Programmcode nicht doppelt speichern; du möchtest die Texte in mehreren Sprachen speichern. Denselben Kram an mehreren Stellen zu definieren ist eine Garantie, über kurz oder lang eine Änderung an einem der Speicherorte vergessen durchzuführen.
Die übliche PHP-Nutzung bringt leider mit sich, dass alles in eine Datei gewürgt wird: Programm, Seitenstruktur, Text (gerne auch noch CSS und Javascript). Insofern wirst du vor allem bei diesem Aspekt umdenken müssen.
Je Seite ein Skript, eine HTML-Datei, mehrere Text-Dateien, dabei je Sprache eine Text-Datei. Die Text-Datei wird je nach Sprache vom aufgerufenen Skript hinzugeladen und ihr Inhalt in das Gerüst der HTML-Datei eingebaut.
Um nochmal aus der Tornado-Anleitung zu klauen:
<html>
<head>
<title>FriendFeed - {{ _("Sign in") }}</title>
</head>
<body>
<form action="{{ request.path }}" method="post">
<div>{{ _("Username") }} <input type="text" name="username"/></div>
<div>{{ _("Password") }} <input type="password" name="password"/></div>
<div><input type="submit" value="{{ _("Sign in") }}"/></div>
</form>
</body>
</html>
Beachte die geschweiften Klammern. Solche Vorlagensysteme (Neudeutsch Templates) gibt es sicher auch fix und fertig für PHP.
@@Rosenköhl
Um nochmal aus der Tornado-Anleitung zu klauen:
Schlecht geklaut. Das HTML ist fehlerhaft.
Wie so oft mangelt es Webentwicklern an den Grundlagen: HTML.
<html>
Hier fehlt die Angabe der Sprache der aktuellen Seite.
<html lang="{{ lang }}">
<form action="{{ request.path }}" method="post"> <div>{{ _("Username") }} <input type="text" name="username"/></div> <div>{{ _("Password") }} <input type="password" name="password"/></div> <div><input type="submit" value="{{ _("Sign in") }}"/></div> </form>
Hier fehlen die zugänglichen Beschriftungen der Eingabefelder.
<form action="{{ request.path }}" method="post">
<div>
<label for="username">{{ _("Username") }}</label>
<input type="text" name="username" id="username"/>
</div>
<div>
<label for="password">{{ _("Password") }}</label>
<input type="password" name="password" id="password"/>
</div>
<div><button type="submit">{{ _("Sign in") }}</button></div>
</form>
Die <div>-Elemente drumherum sind nicht unbedingt erforderlich.
<input type="submit"> war nicht unbedingt falsch, aber sowas von veraltet. Das hab ich gleich mal durch einen <button> ersetzt. Wobei type="submit" der Default ist, also weggelassen werden kann.
🖖 Живіть довго і процвітайте
Um nochmal aus der Tornado-Anleitung zu klauen:
Schlecht geklaut. Das HTML ist fehlerhaft.
Das ist nicht fehlerhaft, schlimmstenfalls lückenhaft, und vor allem in diesem Kontext –der Verwendung von Vorlagen für Übersetzungen– komplett wurscht und damit am Thema vorbeikommentierte Besserwisserei.
@@Rosenköhl
Das HTML ist fehlerhaft.
Das ist nicht fehlerhaft
HTML-Code, der grundlegende Standards missachtet, ist fehlerhaft.
und vor allem in diesem Kontext –der Verwendung von Vorlagen für Übersetzungen– komplett wurscht
Grundlagen von HTML lassen sich oft nicht als solche vermitteln, sondern an konkreten Beispielen. Wie diesem.
und damit am Thema vorbeikommentierte Besserwisserei.
Einfach nur: nein.
🖖 Живіть довго і процвітайте
Guten Abend allerseits,
@Gunnar
Deine Kritik ist in jeglicher Hinsicht vollkommen berechtigt, auch wenn ich sie hier nicht für ganz richtig am Platze halte. Das Erste, was ich damals gelernt habe, war, dass ein Programmierer niemals auslernt. Hinter Kritiken stehen Tips und Anregungen, die ich versuche herauszulesen und umzusetzen. Daher in jedem Fall Danke für Deine Kritik! Nur, ich habe diesen Codeschnipsel kurz geschrieben, um mal zu probieren, Martins Tip zu testen und zu sehen, was überhaupt unter "echo $_SERVER['HTTP_ACCEPT_LANGUAGE']" angezeigt wird, da ich mich, wie schon erwähnt, zum ersten Mal mit Mehrsprachigkeit beschäftigen muss. Daher dann erstmal zum Probieren die Abfrage mittels strpos(). Dass die Abfrage im Projekt anders aussehen muss ist mir völlig klar.
Desweiteren habe ich gelernt, niemals den Originalcode zu veröffentlichen! Und der sähe selbstverständlich im Projekt anders aus! Warum hier nur "$grundspr" und "$languag": ich lege beim Testen keinen grossen Wert auf Genauigkeit. Anders im fertigen Skript, wo man Variablen ggf. öfter verwendet. Ich verrate hier mal, dass ich im Skript die Variable "$sprache" durchweg verwende, also deutsch. Aus demselben Grund speichere ich auch $_SERVER["HTTP_ACCEPT_LANGUAGE"] in eine Variable, weil ich zu faul bin, im Skript ggf. jedesmal diesen langen Namen schreiben zu müssen. Genauso verfahre ich übrigens mit $_GET[], $_POST[] und $_SESSION[], nach dem Motto:
Jeder programmiert auf seine Weise, der Eine laut, der Andere garnicht, denn er schreibt im Selfhtml-Forum: "Kann mir mal jemand den Code schreiben. Ich weiss nicht wie das geht!"
Ich möchte auch mal an der Erfahrenheit eines Webentwicklers schnuppern und etwas Kritik zurückgeben:
Was soll grundspr bedeuten?
Gunnar, Du hast hier das "$" vergessen!😜
(HURRA! Ich habe Gunnar kritisiert!)😀
Um noch etwas beim Blödsinn zu bleiben...
(Fun fact: Auch Google hatte das mal falsch gemacht.)
GUNNAR! Du wagst es Google zu kritisieren!? Ich bin empört! Erschüttert! Wenn das Elon Musk erfährt, kauft er Selfhtml auf und macht es dicht!🙃
Trotzdem, bleib so!👍
@Rosenköhl
Erstmal danke für Deinen Beitrag!
Wenn du dir Sorgen um die Suchmaschinenfreundlichkeit machst, dann bleibt dir gar nichts anderes übrig, als jede Sprache in einem eigenen URL-Pfad unterzubringen. Nur auf diese Weise kannst du sicherstellen, dass wirklich alle Seiten aller Sprachen von Automaten erkannt werden.
Das ist tatsächlich ein Aspekt, den ich im Auge haben muss --> Auftraggeber. Daher werde ich es wohl so gestalten: "/blafasel/de/".
Das würde auch die Sache vereinfachen, kommt der Auftraggeber mal auf die Idee, weitere Sprachen zu implementieren.
@all
Ich denke, die Idee zuerst mal zu testen, ob ein User überhaupt Deutsch im Browser eingestellt hat, ist nicht verkehrt. Denn, falls nicht, kriegt er grundsätzlich die englische Version angezeigt. Falls doch ist die Reihenfolge entscheidend. Letztendlich kann man die Sprache auch umstellen.
Noch eine Frage zum Abschluss: Inwieweit kann man eigentlich anhand der IP-Adresse feststellen, aus welchem Land (Staat, bevor wieder Kritik kommt😊, siehe --> Fahne und Flagge...) ein User kommt?
Einstweilen LG Treziman
P.S. Und seid bitte lieb zueinander...
Nochmal kurz zum Thema Suchmaschinen:
Ich habe die Idee die Startseite so zu gestalten, dass zuerst die Sprachabfrage erfolgt und erst dann der Inhalt der Seite, entweder ganz oder nur im <body>, mittels include() geladen wird. Da die Seite aber zunächst unvollständig ist weiss ich nicht, inwieweit sich das auf Suchmaschinen auswirkt, bzw. wie eine Suchmaschine arbeitet. Wird hier include() berücksichtigt? Weiss das jemand?
Danke.
Treziman
@@Treziman
… dann der Inhalt der Seite, entweder ganz oder nur im <body>, mittels include() geladen wird.
Du meinst PHP include()
Da die Seite aber zunächst unvollständig ist
Zu welchem Zeitpunkt sollte die Seite clientseitig unvollständig sein?
🖖 Живіть довго і процвітайте
Hallo Gunnar,
nein, nicht clientseitig. Da kommt ja das Ergebnis der Anfrage an. Ich meine, wenn eine Suchmaschine die Seite durchsucht. "Sieht" eine Suchmaschine die Seite wie ein Client? Dann würde include() berücksichtigt. Wenn nicht, findet die Suchmaschine quasi eine leere (oder halbleere) Seite. Ich weiss eben nicht, wie die Suchmaschinen vorgehen.
Da es sich bei include() um PHP handelt, wirds ja serverseitig ausgeführt. Die Frage ist, anders formuliert, ob eine Suchmaschine ein Ergebnis einer Anfrage an den Server erhält oder eben nicht. Der fehlende Code der Startseite steht ja in der zu includierenden Datei.
Weisst Du, was ich meine?
@@Treziman
"Sieht" eine Suchmaschine die Seite wie ein Client?
Eine Suchmaschine ist ein Client.
Sie crawlt das Web, indem sie Anfragen über HTTP stellt. Wie die Antworten serverseitig generiert werden, bekommt sie ebensowenig mit wie andere Clients (z.B. Webrowser).
🖖 Живіть довго і процвітайте
@Gunnar
Eine Suchmaschine ist ein Client.
Das muss man wissen. Damit ist die Frage geklärt.
Super, danke!
Leider fehlt mir dieses Hintergrundwissen...
LG Treziman
Hallo,
Eine Suchmaschine ist ein Client.
Sie crawlt das Web, indem sie Anfragen über HTTP stellt.
wie auch sonst?
Wie die Antworten serverseitig generiert werden, bekommt sie ebensowenig mit wie andere Clients (z.B. Webrowser).
wahsaga hat das damals noch etwas schöner formuliert. 😉
Einen schönen Tag noch
Martin