Mehrsprachigkeit

[Der Martin]

Hallo,

Ermittlung der Sprache

d) Der Nutzer hat eine Standardsprache und kann sie auf Wunsch gezielt ändern.

dein d) ergibt sich aus meinem a) (HTTP-Header aufgrund der Browser-Einstellungen) und meinem c) (URL-Parameter zur gezielten Sprachauswahl). Nochmal im Einzelnen:

1. Auswertung des Accept-Language-Headers. Der gibt mir die vom Besucher in seinem Browser eingestellte(n) Sprache(n). Damit gehe ich zunächst ins Rennen.

2. Nachsehen, ob der Besucher ein Cookie hat, in dem eine Sprache vermerkt ist. Das bedeutet nämlich, dass er bei einem früheren Seitenabruf mal gezielt eine andere als seine Default-Sprache ausgewählt hat. Die hat dann Vorrang vor dem Accept-Language-Header.

3. Nachsehen, ob ein URL-Parameter (z.B. lang=fr) mitgesendet wurde. Das bedeutet, der Besucher hat sich gerade jetzt bei diesem Seitenabruf entschlossen, die Sprache zu wechseln, und alles, was ich vorher ermittelt habe, ist damit hinfällig. Die bis hierher ermittelte Sprache speichere ich nun in einem Cookie.

4. Nachsehen, ob ich die gewünschte Sprache überhaupt im Angebot habe. Ups, Französisch? Hab ich nicht, also muss ich auf einen von mir gewählten Standardwert zurückgreifen. Zum Beispiel Deutsch. Der eigentliche Wunsch Französisch bleibt dennoch im Cookie gespeichert - vielleicht ist eine andere Seite meines Webauftritts ja doch in Französisch verfügbar.

Ich fürchte, da erwartest du zuviel. Sowas in eine bestehende Website nachträglich zu integrieren, ist nicht mal eben zwischen Aufstehen und Frühstück getan.

Jein. Dass das nicht zwischen Tür und Angel geht, ist mir klar. Aber: Nutze ich ein CMS (wie Wordpress) und will den daraus entstehenden Code in eine Seite einbinden, werde ich immer das Problem haben dass ich mir nie sicher sein kann, ob nun wirklich alle Informationen und Funktionen vollständig und korrekt sind. Bei einer einfachen HTML-JS-Kombination, von der ich weiß dass sie eigenständig funktionsfähig ist, kann ich das schon.

Okay, das stimmt.

Der Arbeitsaufwand wird weitaus geringer sein, vor allem jedoch kann ich das unabhängig vom verwendeten CMS machen und ggf. in das Vorhandene einpflegen.

Ich habe noch nie ein CMS verwendet. Aber ich stelle es mir schwierig vor, den Output eines CMS wieder aufzuarbeiten und daraus wieder Urdaten für das CMS zu generieren. Außerdem: Was willst du damit erreichen?

Soll / muss für jede Variable eine eigene .htm-Datei erstellt werden?

Du meinst, für jede Sprache? - Nein, siehe oben.

Nicht für jede Sprache; für jede Variable.
Also nach deinem Beispiel wären das feld_anred.htm
feld_titel.htm
feld_vname.htm
feld_nname_required.htm
feld_submit_aen.htm

Nein, um Himmels Willen! Dann müsstest du ja die fertige Seite aus vielen Fragmenten zusammenstückeln.

Bei 10-20 Variablen stelle ich mir das durchaus noch praktikabel vor. Bei 2-300 eher unübersichtlich. Da wäre eine einzelne Datenbank oder (Excel)tabelle weitaus übersichtlicher, insbesondere wenn die einzelnen Variablen inhaltlich miteinander zusammen hängen. So habe ich eben alle Informationen auf einem Blick und nicht in hunderte Einzeldateien verpackt.

Eben, so hatte ich das auch gemeint.

Sprache	anred	titel	vname
de	anred_de	titel_de	vname_de
en	anred_en	titel_en	vname_en
...	anred_...	titel_...	vname_...

Verständlicher so?

Ja. Und wie gesagt: Ich würde Zeilen und Spalten tauschen.

Mittelhöhere Prio hat, dass das Endergebnis als PWA taugt. Das sollte damit ebenfalls noch möglich sein?

Das eine hat mit dem anderen nichts zu tun, denke ich.

Weiß ich nicht. In dem Moment wo ich eine Funktion einbaue, die ständig oder sehr häufig den Server braucht - also eine serverseitige Logik, die immer wieder angesteuert werden muss - sollte es mit der PWA-Option vorbei sein.

Ja, okay. Aber das Auswählen der Sprache und das Ersetzen der Platzhalter findet ja eigentlich nur einmal statt - nämlich dann, wenn die Seite sowieso vom Server geholt wird.

Live long and pros healthy,
 Martin