nicht angemeldet Robert B.
Linuchs
Linuchs
Linuchs
Der Martin
Der Martin
Der Martin
Der Martin
Der Martin
Linuchs
Gunnar Bittersmann
Ich habe mir eben folgenden Artikel durchgelesen:
https://wiki.selfhtml.org/wiki/Internationalisierung
Eine Frage blieb jedoch unbeantwortet: Wie mache ich das?
Oder genauer, brauche ich ein neues HTMl-dokument (pro Sprache),auf das ich dann jeweils verlinke? Oder kann ich das in einem Dokument machen (d.h. ich schreibe den Text einfach mehrfach), und der Nutzer schaltet je nach Belieben um, ohne das Dokument zu wechseln?
Zumindest mir scheint letzteres zu sinnvoll, als dass es das nicht geben könnte. Allerdings finde ich nichts dazu.
Moin,
Ich habe mir eben folgenden Artikel durchgelesen:
https://wiki.selfhtml.org/wiki/InternationalisierungEine Frage blieb jedoch unbeantwortet: Wie mache ich das?
Oder genauer, brauche ich ein neues HTMl-dokument (pro Sprache),auf das ich dann jeweils verlinke?
Siehe dort den Abschnitt zu Content-Negotiation: Du hast für jede Sprache eine Datei
und der Webserver liefert die zum Accept-Language-Header passende Datei für den Aufruf von seite (oder seite.html) aus, z.B. für Deutsch die seite.de.html und für österreichisches Deutsch die seite.de-AT.html (z.B. im Jänner). Dafür muss die Nutzerin allerdings die richtige Sprache im Browser eingestellt haben.
Du kannst die „Language-Negotiation“ aber auch per Cookie lösen, in dem die präferierte Nutzersprache abgelegt und ausgewertet wird.
Der Vorteil ist, dass du im Allgemeinen einen Link auf seite.html hast, der für jede Sprache den richtigen Inhalt liefert.
Oder kann ich das in einem Dokument machen (d.h. ich schreibe den Text einfach mehrfach), und der Nutzer schaltet je nach Belieben um, ohne das Dokument zu wechseln?
Das setzt bei der Nutzerin zwingend JavaScript voraus und – sofern die richtige Sprache per default angezeigt werden soll – noch ein „Language Negotiation“ in deiner JavaScript-Logik. Und Suchmaschinen bekommen alle Sprachen auf einmal serviert, d.h. du brauchst zwingend die Auszeichnung mit dem lang-Attribut.
Zumindest mir scheint letzteres zu sinnvoll, als dass es das nicht geben könnte. Allerdings finde ich nichts dazu.
Vielleicht ist es doch nicht so sinnvoll …
Viele Grüße
Robert
Das setzt bei der Nutzerin zwingend JavaScript voraus
Nur, wenn die Option nicht bereits im HTML angelegt ist.
Vielleicht ist es doch nicht so sinnvoll …
Ich hole etwas aus:
Möchte ich eine Seite zb in 10+ Sprachen übersetzen - was bei einem internationalen Unternehmen oder Onlineshop nicht viel ist - müsste ich bei einer Änderung, die über bloßen Text hinaus geht - zb eine neue Funktion einfügen, eine bestehende erweitern oder ändern - exakt dieselbe Handlung in 10 verschiedenen Dokumenten durchführen, was bei 40, 50 Änderungen irgendwann... . Und das widerspricht jeglicher mir bekannten modernen Auffassung von Programmierung. Denn eine gleichbleibende Standardtätigkeit immer wieder manuell zu wiederholen führt zu großem Aufwand (Kosten), macht den Prozess fehleranfällig und zugleich die Fehlersuche schwer.
Eine Website in mehreren Sprachen anzubieten ist nicht ungewöhnlich, im Gegenteil eine häufige Standardtätigkeit. Daher hatte ich hier auf eine zeitgemäße, praktische Lösung gehofft (von der ich einfach noch nichts weiß).
Du verstehst meinen Punkt?
Servus!
Das setzt bei der Nutzerin zwingend JavaScript voraus
Nur, wenn die Option nicht bereits im HTML angelegt ist.
Vielleicht ist es doch nicht so sinnvoll …
Ich hole etwas aus:
Möchte ich eine Seite zb in 10+ Sprachen übersetzen - was bei einem internationalen Unternehmen oder Onlineshop nicht viel ist - müsste ich bei einer Änderung, die über bloßen Text hinaus geht - zb eine neue Funktion einfügen, eine bestehende erweitern oder ändern - exakt dieselbe Handlung in 10 verschiedenen Dokumenten durchführen, was bei 40, 50 Änderungen irgendwann... . Und das widerspricht jeglicher mir bekannten modernen Auffassung von Programmierung. Denn eine gleichbleibende Standardtätigkeit immer wieder manuell zu wiederholen führt zu großem Aufwand (Kosten), macht den Prozess fehleranfällig und zugleich die Fehlersuche schwer.
Gut erkannt!
Deshalb laufen gefühlt 99% aller Shops eben mit einem CMS:
Das HTML der Webseite sieht mehr oder weniger einfach aus - die Kunst sind die Scripte des CMS.
Eine Website in mehreren Sprachen anzubieten ist nicht ungewöhnlich, im Gegenteil eine häufige Standardtätigkeit. Daher hatte ich hier auf eine zeitgemäße, praktische Lösung gehofft (von der ich einfach noch nichts weiß).
Du verstehst meinen Punkt?
Ja. Heute ist HTML die Grundlage für Webseiten. Das meiste wird heutzutage aber nicht mehr in HTML gemacht, sondern in Skripten in PHP, JavaScript, etc auf dem Server.
Herzliche Grüße
Matthias Scharwies
Hallo Matthias,
Das meiste wird heutzutage aber nicht mehr in HTML gemacht, sondern in Skripten in PHP, JavaScript, etc auf dem Server.
Da hier von .html - Dateien die Schreibe ist: Wie kann der Server überzeugt werden, auch in denen PHP-Code auszuführen?
Wenn (im bestehenden Projekt) zu .html-Dateien verlinkt wird, kann man die ja nicht erfolgreich gegen .php-Dateien tauschen.
Gruß, Linuchs
Tach!
Da hier von .html - Dateien die Schreibe ist: Wie kann der Server überzeugt werden, auch in denen PHP-Code auszuführen?
Auf dieselbe Weise, wie man ihm beibringt, .php-Dateien an PHP zu übergeben. Oder noch allgemeiner formuliert, so wie man für jegliche Dateien(dungen) konfiguriert, was mit ihnen geschehen soll. Das ist je nach Webserver unterschiedlich.
Auch im Falle PHPs mit dem Apachen gibt es mehrere Möglichkeiten, wie es installiert ist und wie es dann mit ihm zusammenspielt. Details zur jeweiligen Konfiguration kann man der Dokumentation des jeweiligen Systems zu entnehmen. Eine der Möglichkeiten (Apache mit PHP als Modul) ist im PHP-Handbuch beschrieben. Die Auswahl der Dateien wird dort über FilesMatch geregelt.
Bei Provider-Installationen suche man in der dortigen Dokumentation.
dedlfix.
Hallo Linuchs,
wenn man nur ein paar HTML Dateien hat und der Rest eh PHP ist, sollte die Serverlast nicht unnötig hochgehen, wenn man auch HTML durch PHP jagt.
Wenn man aber sehr viele statische HTML Dateien hat, sollte man sich das gut überlegen, oder fein einstellen, welche Dateien nach PHP gelangen. Ein zwischengeschalteter PHProzessor kostet Zeit und verhindert eventuell auch statisches Caching im Server. Im IIS sind das zwei Schalter: Caching statischer Inhalte und Caching dynamischer Inhalte, keine Ahnung was ein Indianer da so treibt.
Statt HTML Dateien durch PHP zu jagen, solltest Du die betroffenen HTML Dateien auf PHP kopieren, eine Redirect- oder Rewrite-Rule anlegen (mod_alias bzw mod_rewrite im Apache), und die HTML Datei löschen, wenn die Rule funktioniert. Das kannst Du für Ordner machen, oder für Dateien. Bevor Du großzügig Rewrites setzt, lies When not to use mod_rewrite.
Interne Links kannst Du danach gemütlich anpassen, und wenn ein User eine der HTML Seiten gebookmarked hat, wird er umgeleitet. Irgendwann leitest Du den mod_rewrite dann auf eine "This Resource has moved, please change your Bookmark to..." Seite um.
Rolf
Hallo Rolf,
danke für deine immer wieder überraschend detaillierte Auskunft.
In diesem Fall konntest du mein Allgemeinwissen erhöhen, ich arbeite fast nur mit php-Dateien und sei es - bei sonst statischen Seiten - dass das Datum der letzten Änderung (filemtime) angezeigt wird.
Gruß, Linuchs
Tach!
Möchte ich eine Seite zb in 10+ Sprachen übersetzen - was bei einem internationalen Unternehmen oder Onlineshop nicht viel ist - müsste ich bei einer Änderung, die über bloßen Text hinaus geht [...] exakt dieselbe Handlung in 10 verschiedenen Dokumenten durchführen, was bei 40, 50 Änderungen irgendwann... . Und das widerspricht jeglicher mir bekannten modernen Auffassung von Programmierung.
Das widerspricht auch der Praxis, zumindest in den genannten Beispielen. In einem internationalen Unternehmen wird der Webauftritt nicht von der IT-Abteilung gepflegt. Die IT-Abteilung hat da lediglich die Aufgabe eine den Anforderungen entsprechende Software zu besorgen, die von den Laien in der PR-Abteilung bedient werden kann. Dieses CMS muss immer zur Verfügung stehen und nicht nur solange der Kollege, der das programmiert hat, im Unternehmen angestellt ist.
Einen Shop mit mehr als drei Produkten betreibt man auch nicht mit einer losen Sammlung von HTML-Seiten. Selbst wenn man keine Von-der-Stange-Software dafür nimmt, erstellt man da sinvollerweise ein datenbankbasierendes System. Und mit der dafür verwendeten Software kann man dann auch die als Templates vorhandenen Seiten mit Inhalten füllen, auch sprachspezifischen.
Eine Website in mehreren Sprachen anzubieten ist nicht ungewöhnlich, im Gegenteil eine häufige Standardtätigkeit. Daher hatte ich hier auf eine zeitgemäße, praktische Lösung gehofft (von der ich einfach noch nichts weiß).
Die technischen Grundlagen hast du schon gelesen. Die nächste Frage ist erstmal eine organisatorische. Wie soll der Betrieb mit diesem System ablaufen? Besonders ist zu klären, wer die Inhalte pflegen soll. Dazu kommen noch weitere Anforderungen an das System. Am Ende wird es darauf hinauslaufen, dass das besorgte oder selbst erstellte System für all die Anforderungen eine serverseitige Programmiersprache benötigt und ein Template-System ent-/erhält, das mit Inhalten aus einer Datenhaltung bestückt wird.
dedlfix.
Hi there,
Siehe dort den Abschnitt zu Content-Negotiation: Du hast für jede Sprache eine Datei
- seite.html.de
- seite.html.de-AT
- seite.html.en
- seite.html.fr
- …
also
ist höchstens ein theoretisches Konzept. Nicht nur denk ich, daß das irgendjemand, der professionell damit befasst ist, macht, noch denke ich, daß irgendjemand einen Vorteil davon hätte.
und der Webserver liefert die zum
Accept-Language-Header passende Datei für den Aufruf vonseite(oderseite.html) aus, z.B. für Deutsch dieseite.de.htmlund für österreichisches Deutsch dieseite.de-AT.html(z.B. im Jänner).
Jänner ist keineswegs ein exklusiv-österreichischer Ausdruck. Nachdem die österreichische Sprachvarianten alle (bis auf die Sprache der Trachtenpärchen hinter dem Arlberg) aus dem Ost-Mittel-Bayrischen stammen trifft das auf sehr viele Ausdrücke zu. Das führt uns dann zu einer
oder ähnlichem Mist. (Jaja, ich weiß schon, Hochdeutsch, Duden, Amtsprache etc. - aber so redet ja erst recht niemand)
Dafür muss die Nutzerin allerdings die richtige Sprache im Browser eingestellt haben.
Die findest Du in dem Fall garantiert nicht. Abgesehen davon, weil's eben nichts bringt. Die paar Merkbefreiten, die "Januar" auf der einen oder "Jänner" auf der anderen Seite nicht verstehen (wollen), die sollen's entweder lernen oder blöd sterben. Auch wenn das Interent mittlerweile zu einem Tummelplatz und Austauschmedium für Idioten geworden ist muß man das nicht auch noch fördern; auch und besonders nicht, weil die eben auch zu blöd wären, die "richtige" Sprache im Browser einzustellen.
Ich kann Dir in diesem Beispiel auch deshalb nicht recht geben, weil das, abgesehen vom Nichtnutzen, im Erstellen resp. Berücksichtigen auch einen Aufwand bedeutet, den Dir unter Garantie keiner zu bezahlen bereit wäre...
Mit anderen Worten: Wir lassen „de-AT“ einfach aus den Beispielen und dein Rant ist verdampft.
Mit anderen Worten: Wir lassen „de-AT“ einfach aus den Beispielen und dein Rant ist verdampft.
Es ist einfach schön, wenn man sich verstanden fühlt...
@@klawischnigg
Jänner ist keineswegs ein exklusiv-österreichischer Ausdruck.
Ich hab irgendwo gelesen, dass „Jänner“ die ursprüngliche Bezeichnung des Monats im Deutschen war. Die Übernahme der lateinischen Form erfolgte erst später.
Sagt ihr in Österreich eigentlich auch „Feber“ oder habt ihr da die lateinische Form übernommen?
Die paar Merkbefreiten, die "Januar" auf der einen oder "Jänner" auf der anderen Seite nicht verstehen (wollen), die sollen's entweder lernen oder blöd sterben.
Ich will nicht verstehen, was eine „Karotte“ ist!!1 Ich will, dass du mir die Rezeptseite in einer Sprachversion anbietest, wo da „Mohrrübe“ steht!!1elf
Ich kann Dir in diesem Beispiel auch deshalb nicht recht geben, weil das, abgesehen vom Nichtnutzen, im Erstellen resp. Berücksichtigen auch einen Aufwand bedeutet, den Dir unter Garantie keiner zu bezahlen bereit wäre...
Analog: britisches vs. amerikanisches Englisch. Oder europäisches vs. lateinamerikanisches Spanisch.
Bei europäischem vs. brasilianischem Portugiesisch bin ich mir nicht sicher. Da könnten die Unterschiede doch so groß sein, dass verschiedene Sprachvarianten angebracht wären.
TL;DR: Verschiedene Sprachvarianten de-DE/de-AT/de-CH anzubieten macht keinen Sinn.
Was nicht heißt, dass man es bei der Kennzeichnung der Sprache im lang-Attribut nicht genaunehmen sollte. lang="de-AT" kann eine Rechtschreibprüfung davon abhalten, über „Geschoß“ mit ß zu meckern; lang="de-CH" über „gross“ nicht mit ß.
😷 LLAP
Hi there,
Sagt ihr in Österreich eigentlich auch „Feber“ oder habt ihr da die lateinische Form übernommen?
Also, im zumindest im östlichen Österreich sagt niemand "Feber", obwohl der Ausdruck natürlich bekannt ist (ich denke, das wird bei den Trachtenpärchen nicht viel anders sein). Nicht mehr, früher wurde der Ausdruck wohl eher verwendet - was vielleicht noch zu erwähnen wäre, daß sich im österreichischen Amtsdeutsch, das ausser der ärmelschonertragenden Bevölkerung ohnehin praktisch niemand verwendet hat, sich solche Ausdrucksformen viel länger gehalten haben. Ich kann mich noch erinnern, wie wir als Kinder in den sechziger Jahren mit alten Stempeln herumgespielt haben, auf denen Beschriftungen wie "Feber" etc. zu finden waren.
Die paar Merkbefreiten, die "Januar" auf der einen oder "Jänner" auf der anderen Seite nicht verstehen (wollen), die sollen's entweder lernen oder blöd sterben.
Ich will nicht verstehen, was eine „Karotte“ ist!!1 Ich will, dass du mir die Rezeptseite in einer Sprachversion anbietest, wo da „Mohrrübe“ steht!!1elf
Richtig. Das führt dann zu so skurilen Erscheinungen wie deutsche Untertitel zu deutschem Ton im Prekariatsfernsehen (ich meine jetzt nicht die Untertitelung von Dialekten, da kann die Grenze zur Verständlichkeit eingeräumterweise recht schnell erreicht sein, gleiches gilt für Schwyzerdütsch (oder wie immer man das schreibt;)))
Analog: britisches vs. amerikanisches Englisch. Oder europäisches vs. lateinamerikanisches Spanisch.
Bei europäischem vs. brasilianischem Portugiesisch bin ich mir nicht sicher. Da könnten die Unterschiede doch so groß sein, dass verschiedene Sprachvarianten angebracht wären.
In der Schriftsprache nicht. Und beim gesprochenen Wort sind afaik die Unterschiede zwischen "spanischem" Spanisch und lateinamerikanischem Spanisch eher höher als zwischen portugisischem und brasilianischem Spanisch. Wobei sich das lateinamerikanische Spanisch ja auch unter sich sozusagen noch einmal gewaltig unterscheidet. Castro hat nie gesprochen wie Peron (auch wenn sie sich sonst nicht viel zu sagen gehabt hätten😉)
Was nicht heißt, dass man es bei der Kennzeichnung der Sprache im
lang-Attribut nicht genaunehmen sollte.lang="de-AT"kann eine Rechtschreibprüfung davon abhalten, über „Geschoß“ mit ß zu meckern;lang="de-CH"über „gross“ nicht mit ß.
Ja, ok, das ist ein Aspekt, den ich nicht berücksichtigt habe, aber auch das dürfte, ich schätze einmal, einen nicht einmal in Promille ausdrückbaren Anteil der Anwender betreffen...😉
Ich gönne euch den Spaß gern.
Zugleich denke ich, eine solche Grundsatz-Diskussion wäre in einem eigenen Thread besser aufgehoben. Evtl. sowas wie "Sprachangabe: Wie Feingranular? - Vor- und Nachteile".
Vielleicht kann das Ergebnis dann sogar im Wiki-Artikel kurz zusammengefasst / eingearbeitet werden? :)
Moin,
Und beim gesprochenen Wort sind afaik die Unterschiede zwischen "spanischem" Spanisch und lateinamerikanischem Spanisch eher höher als zwischen portugisischem und brasilianischem Spanisch.
Portugiesisches (und brasilianisches) Spanisch kommt mir sehr spanisch vor.
Viele Grüße
Robert
Hallo Robert,
allerdings. Den Portugiesen und Brasilianern Spanisch vorzuwerfen (von den mehr als 20 Millionen portugiesischen Muttersprachlern in Afrika ganz zu schweigen), uh oh, ich glaube, es sind schon aus geringeren Anlässen Kriege ausgebrochen… Der olle Alfons rotiert jetzt vermutlich in seinem Sarkophag.
Rolf
Hi there,
Und beim gesprochenen Wort sind afaik die Unterschiede zwischen "spanischem" Spanisch und lateinamerikanischem Spanisch eher höher als zwischen portugisischem und brasilianischem Spanisch.
Portugiesisches (und brasilianisches) Spanisch kommt mir sehr spanisch vor.
Kein Wunder, jetzt wo Du das sagst kommt's sogar mir merkwürdig, um nicht zu sagen, spanisch, vor...😉
Hallo,
Ich will nicht verstehen, was eine „Karotte“ ist!!1 Ich will, dass du mir die Rezeptseite in einer Sprachversion anbietest, wo da „Mohrrübe“ steht!!1elf
das Beispiel hast du vermutlich als Textbaustein vorrätig. 😉
In meinem Elternhaus (Migrationshintergrund: Ruhrgebiet) nannte und nennt man dieses Gemüse Möhre, hier im Schwäbischen meist Gelbe Rübe, manchmal auch Karotte.
Mit dem Begriff Mohrrübe oder Möhre fällt man hier in der Gegend in jedem Fall auf.
Analog: britisches vs. amerikanisches Englisch. Oder europäisches vs. lateinamerikanisches Spanisch.
Ich habe schon mehrfach gehört, in Mexico würde das "beste" Spanisch der Welt gesprochen - also im Hinblick darauf, wie gut es mit Lehrbüchern und Sprachkursen zusammenpasst.
Live long and pros healthy,
Martin
Auch ohne Gruß
Seit den 1980er Jahren beschäftige ich mich mit multilingualem Programmieren (das war noch vor dem Internet). Damals (unter Cobol) waren Programmcode und angezeigter Bildschirm-Inhalt noch in einer Datei. Fast jedes Schrauben an der Oberfläche brachte Programmfehler mit sich (was schief gehen kann, geht irgendwann schief).
Für ein großes Kundenprojekt und meinen Web-Veranstaltungskalender, von der Pike an selbst programmiert, habe ich vor 13 Jahren eine Lösung gefunden, die ich noch nicht bereut habe.
Jedes Programm besteht aus einer .php - und einer .html - Datei. PHP bereitet die wechselnden Daten auf und übergibt sie als Array dem Unterprogramm display.php, das seinerseits die .html-Datei liest, die dortigen Platzhalter füllt und an den Browser sendet.
Dieses Unterprogramm erkennt auch, alternative Sprach-Konstrukte in der Form ###deutsch###english###nederlands###, erzeugt daraus ein Array und ersetzt das Konstrukt durch $arr[0] im Fall deutsch. Zu Beginn gab es noch französisch und polnisch, aber von dort kamen keine Interessenten.
Das System geht noch weiter. Da in vielen Programmen gleichartige input-Felder benötigt werden, trage ich in der .html-Datei nur noch ein
Matthias Scharwies
Rolf B
Tabellenkalk[feld_anred]
[feld_titel]
[feld_vname]
[feld_nname_required]
[feld_submit_aen]
display.php liest die Datei /felder/feld_anred.htm, setzt den Inhalt anstelle des Aufrufs und erst danach wird die Sprache ausgewertet:
<p><l>###Anrede###Salutation###Aanhef###</l>
<input [disabled]
type = 'text'
name = 'anred'
title = 'anred'
maxlength = 10
size = 10
value = '[anred]'
placeholder = "Herr Mr. Dhr."
/></p>
Top, wie man Cobol-Strategien in die Neuzeit übertragen kann! Was macht Dein Cookie-Thema?
Was macht Dein Cookie-Thema?
Nach wie vor unbefriedigend, ich lebe mit der Lücke.
Zur Ermittlung, welche Sprache genommen wird:
Höchste Priorität hat die per GET oder POST übergebene Sprache, die von Programm zu Programm weitergegeben wird.
Fehlt diese, wird die Sprachenkennung des Browsers ausgewertet. Zuerst Stelle 1 und wenn im Programm vorhanden, diese. Sonst die nächsten Angaben des Browsers.
Wird keine der Browser-Sprachen von diesem Einzelprogramm unterstützt, wird english ausgeliefert, aber per GET oder POST diese Sprache weitergegeben, sodass ein anderes Programm mit dieser Sprache dann „korrekt“ ausliefert.
Somit ist eine Schritt- für Schritt-Erweiterung programmweise auf neue Sprachen möglich, ebenso wie die Rücknahme nicht mehr genutzter Sprachen.
Bei Programmen, die Mails versenden (Newsletter), wird die Sprache aus dem Stammsatz des Empfängers genommen. Da gibt es kein GET, PUT oder Browser.
Hallo Linuchs,
mit PHP habe ich aktuell noch gar keine Erfahrungen. So wie ich das verstanden habe:
Anstelle eines Texts wird eine Variable eingesetzt, und PHP verbindet dann die Variable mit einer Datei und setzt anhand einer Spracheinstellung den richtigen aktuellen Wert (Text in Sprache X). Dem Nutzer wird anschließend ein "sauberes" HTML gezeigt.
Soweit richtig?
Für mein Projekt ist insbesondere der Punkt "leichte Integration" wichtig, d.h. es soll sich einfach mittels Copy Paste in eine bestehende Website einbauen lassen. So wie ich das verstehe kann sich der Nutzer das reine HTML (+JS) in Wunschsprache ausdrucken lassen, damit sollte das möglich sein (theoretisch könnte ich die dann auch lokal ausdrucken und passend hosten). Lasse ich mir aber lieber noch von jemandem bestätigen, der das Wissen sollte. ;)
Soll / muss für jede Variable eine eigene .htm-Datei erstellt werden? Wenn ja wird das wohl schnell unübersichtlich. Kann ich auch eine beliebige SQL-Datenbank (ich habe gerade MariaDB im Kopf) verwenden? Oder hat jemand bessere / alternative Vorschläge?
Mittelhöhere Prio hat, dass das Endergebnis als PWA taugt. Das sollte damit ebenfalls noch möglich sein?
Danke
Ammeres
Moin,
Anstelle eines Texts wird eine Variable eingesetzt, und PHP verbindet dann die Variable mit einer Datei und setzt anhand einer Spracheinstellung den richtigen aktuellen Wert (Text in Sprache X). Dem Nutzer wird anschließend ein "sauberes" HTML gezeigt.
Soweit richtig?
ja, "im Prinzip" schon.
Etwas allgemeiner formuliert: Anstatt fester Texte stehen Platzhalter im Quellcode. Eine serverseitige Logik (z.B. PHP, weil's populär und sehr verbreitet ist) ersetzt diese Platzhalter durch den tatsächlichen Text in der gewünschten Sprache, bevor der so aufbereitete HTML-Code an den Client ausgeliefert wird.
Dabei treten allerdings mehrere Teilprobleme nacheinander auf.
Ermittlung der Sprache: Welche Sprache der Client haben möchte, ermittle ich dabei aus a) dem Accept-Language-Header im HTTP-Request, b) aus einem Cookie (Client hat einmal explizit eine Sprache gewählt und die wird gespeichert), und c) aus einem URL-Parameter (damit der Client überhaupt aktiv eine Sprache auswählen kann). Dann muss noch geprüft werden, ob man den Sprachwunsch des Clients auch bedienen kann, und falls nicht, müsste man auf eine Ersatzlösung zurückfallen, z.B. Englisch oder Deutsch.
Notation der Platzhalter im Code: Man kann sich fragen, ob man eher eine Art Template-Syntax nutzen möchte, z.B. etwas wie [[ÜBERUNS]], das Script nach diesem Muster [[PLATZHALTER]] suchen und ersetzen lässt, oder ob man direkt mit PHP-Code den Text an der gewünschten Stelle ausgeben möchte, also etwa <?=$Text['ÜBERUNS']?>. Die erste Vatiante ist im Template-Quellcode vielleicht etwas besser lesbar und sie ist zunächst mal von der verwendeten Scriptsprache unabhängig; bei der zweiten Methode entfällt das Search & Replace.
Speichern der Textfragmente: Elegant ist sicher eine Datenbank-Tabelle mit dem Platzhalter als Key (erste Spalte) und den sprachspezifischen Texten in weiteren Spalten. Dann hätte man bei jedem Seitenaufruf noch den Overhead einer Datenbankabfrage. Wenn ein DB-Zugriff sowieso der Regelfall ist, kommt's darauf nicht an; wenn nur allein wegen der Mehrsprachigkeit eine Datenbank ins Spiel kommt, ist das vielleicht mit Elefanten auf Mücken geschossen. Alternativ könnte man die Texte in einer separaten Datei speichern (z.B im CSV-Format), was aber auch nicht unbedingt effizienter ist. Oder direkt als PHP-Array in den Seitenquellcode. Das ist weniger schön zu pflegen, und man macht sich wieder von der verwendeten Scriptsprache abhängig.
Für mein Projekt ist insbesondere der Punkt "leichte Integration" wichtig, d.h. es soll sich einfach mittels Copy Paste in eine bestehende Website einbauen lassen.
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.
So wie ich das verstehe kann sich der Nutzer das reine HTML (+JS) in Wunschsprache ausdrucken lassen, damit sollte das möglich sein (theoretisch könnte ich die dann auch lokal ausdrucken und passend hosten). Lasse ich mir aber lieber noch von jemandem bestätigen, der das Wissen sollte. ;)
Da verstehe ich jetzt nicht, was du eigentlich meinst.
Soll / muss für jede Variable eine eigene .htm-Datei erstellt werden?
Du meinst, für jede Sprache? - Nein, siehe oben.
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.
Live long and pros healthy,
Martin
Ermittlung der Sprache
d) Der Nutzer hat eine Standardsprache und kann sie auf Wunsch gezielt ändern.
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.
Der Arbeitsaufwand wird weitaus geringer sein, vor allem jedoch kann ich das unabhängig vom verwendeten CMS machen und ggf. in das Vorhandene einpflegen.
So wie ich das verstehe kann sich der Nutzer das reine HTML (+JS) in Wunschsprache ausdrucken lassen, damit sollte das möglich sein (theoretisch könnte ich die dann auch lokal ausdrucken und passend hosten). Lasse ich mir aber lieber noch von jemandem bestätigen, der das Wissen sollte. ;)
Da verstehe ich jetzt nicht, was du eigentlich meinst.
Du kennst dich damit aus. Du hast gesagt "Jup, funktioniert so." Damit ist's bestätigt!
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
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.
| Sprache | anred | titel | vname |
|---|---|---|---|
| de | anred_de | titel_de | vname_de |
| en | anred_en | titel_en | vname_en |
| ... | anred_... | titel_... | vname_... |
Verständlicher so?
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. Das will ich vermeiden, deshalb frage ich eben nach.
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:
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.
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.
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.
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
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?
Man könnte die Informationen kopieren und Verhalten beobachten und dann nachbauen. Aber das ist nicht unbedingt niederschwellig.
Nein, um Himmels Willen! Dann müsstest du ja die fertige Seite aus vielen Fragmenten zusammenstückeln.
Ganz genau das war auch mein Gedanke, und den fand ich dezent unerfreulich. ;)
Ja. Und wie gesagt: Ich würde Zeilen und Spalten tauschen.
Aus technischer oder organisatorischer Sicht? Text ist meist länger und Bildschirme sind im Querformat, daher eignet sich zum schreiben eine invertierte Tabelle sicherlich besser, ja. Gibt es auch technische Aspekte dafür?
Gibt es ein Programm, dass sich dafür besonders gut eignet / einbinden lässt? Ggf. in Kombination mit GitHub?
Ich habe zwar Excel vorgeschlagen, bin dem gegenüber allerdings selbst dezent skeptisch.
Bis zur praktischen Umsetzung wird es noch etwas dauern. Ich mach zuerst ein reines HTML (JS) in Deutsch. Das kann ich dann später per Copy-Paste in die Datei übertragen. So habe ich bildlicher vor Augen, wo ich welche Variablen brauche, wie ich diese in der Tabelle inhaltlich gut gruppiere (ggf. mit Oberüberschriften) und wie ich sie sprechend benennen kann.
Schönen Sonntag,
Und wie gesagt: Ich würde Zeilen und Spalten tauschen.
Aus technischer oder organisatorischer Sicht?
sagen wir es so: Ich bin es gewöhnt, dass eine Tabelle mehr Zeilen als Spalten hat.
Text ist meist länger und Bildschirme sind im Querformat, daher eignet sich zum schreiben eine invertierte Tabelle sicherlich besser, ja.
Ich glaube, bei zwei bis drei Sprachen ist die Bildschirmbreite schon recht gut ausgenutzt, wenn man die Sprachen als Spalten nimmt. Ich gehe davon aus, dass es nicht nur um kurze Phrasen wie Anredefloskeln geht, sondern auch mal ganze Textabsätze.
Aber mal objektiv betrachtet ...
Bei Sprachen als Spalte bekomme ich mit einem SELECT-Statement alle Sprachvarianten eines bestimmten Textfragments. Nützt mir das? Nö, ich brauche ja immer nur eine Sprache.
Bei Sprachen als Zeile (Datensatz) bekomme ich mit einem SELECT alle Textfragmente dieser Sprache. Das ist wesentlich nützlicher.
Auch bei in Textform gespeicherten Tabellen (CSV) lässt sich eine ganze Zeile besser herausholen als eine ganze Spalte.
So gesehen ist deine horizontal orientierte Struktur eigentlich sogar günstiger. Nur ungewohnt. 😉
Gibt es ein Programm, dass sich dafür besonders gut eignet / einbinden lässt? Ggf. in Kombination mit GitHub?
Ich habe zwar Excel vorgeschlagen, bin dem gegenüber allerdings selbst dezent skeptisch.
Excel (oder OpenOffice/LibrOffice Calc) ist zum Bearbeiten gar nicht schlecht; wenn du die Tabelle im OpenDocument-Format speicherst (*.ods), kannst du sie sogar direkt mit PHP lesen und verarbeiten. Ich habe diese Bibliothek noch nicht ausprobiert, möchte das aber demnächst mal tun. Zumindest den Quellcode habe ich mir schon mal angeschaut und war fasziniert, wie einfach das "im Prinzip" ist.
So kann ich Tabellen direkt mit der vertrauten Software editieren und trotzdem ohne Zwischenschritt auf einer Webseite anzeigen.
Bis zur praktischen Umsetzung wird es noch etwas dauern. Ich mach zuerst ein reines HTML (JS) in Deutsch. Das kann ich dann später per Copy-Paste in die Datei übertragen. So habe ich bildlicher vor Augen, wo ich welche Variablen brauche, wie ich diese in der Tabelle inhaltlich gut gruppiere (ggf. mit Oberüberschriften) und wie ich sie sprechend benennen kann.
Ein legitimer Ansatz. Aber bedenke: Ein bestimmtes Feature nachträglich einzubauen, das nicht von Anfang an zumindest vorgesehen und im Ansatz berücksichtigt wurde, ist oft mehr Aufwand, als dieses Feature gleich vom Start weg ins Konzept aufzunehmen. Oder anders gesagt: Es ist ärgerlich und schade, wenn man irgendwann später feststellt, dass man sich eine praktische und günstige Lösung verbaut hat, weil man für den Einstieg den vermeintlich schnelleren Weg gewählt hat.
Live long and pros healthy,
Martin
Hallo Martin,
Ich glaube, bei zwei bis drei Sprachen ist die Bildschirmbreite schon recht gut ausgenutzt, wenn man die Sprachen als Spalten nimmt. Ich gehe davon aus, dass es nicht nur um kurze Phrasen wie Anredefloskeln geht, sondern auch mal ganze Textabsätze
Korrekt. Aber mal ganz praktisch gedacht:
Ich werde, sobald der Text in der Haupt-Sprache mal steht, immer von dieser aus weiter übersetzen. D.h. es reicht völlig aus, zwei Spalten nebeneinander (oder Zeilen untereinander) anzuzeigen. Mehr könnte sogar eher stören.
So gesehen ist deine horizontal orientierte Struktur eigentlich sogar günstiger. Nur ungewohnt.
Für mich ist die horizontale Struktur die Gewohnte; es hat sich einfach "richtig" angefühlt. :P Hab ich schon immer so gemacht irgendwie.
Ansonsten ist eine Tabelle ja problemlos invertiert.
Excel (oder OpenOffice/LibrOffice Calc) ist zum Bearbeiten gar nicht schlecht; wenn du die Tabelle im OpenDocument-Format speicherst (*.ods), kannst du sie sogar direkt mit PHP lesen und verarbeiten.
Die Information ist sehr interessant! Aus der Sicht Flexibilität, Anspruch und Übertragbarkeit ist der Ansatz wohl kaum zu übertreffen.
Fraglich ist, ob nicht ein paar mehr Funktionalitäten wünschenswert sind. Insbesondere fällt mir gerade die "letzte Überarbeitung" ein. Es wäre doof, wenn verschiedene Sprachen unterschiedlich aktuell sind und daher andere Informationen anzeigen, ohne dass der Nutzer das weiß.
Oder anders gesagt: Es ist ärgerlich und schade, wenn man irgendwann später feststellt, dass man sich eine praktische und günstige Lösung verbaut hat, weil man für den Einstieg den vermeintlich schnelleren Weg gewählt hat.
;) Darum ja auch dieser Thread.
Aber so wie ich es sehe, brauche ich beim jetzigen Projektststand drei Schritte:
Daran ändert sich nichts, wenn ich vorerst nur die bisherige Sprachversion in HTML vervollständige. Daher finde ich ein vorzeigbares Zwischenergebnis für sinnvoller.
.
BTW könnte ich die Funktion theoretisch direkt in HTML anlegen, mit dem bereits vorhandenen (essentiellen) ein-ausblende-JavaScript:
<label>
<div class="de" hidden>Deutscher Text</div>
<div class="en" hidden>English text</div>
<div class="..." hidden>... ...</div>
</label>
Einerseits hätte ich dann alle Sprachen in einer Datei, jeden Bereich sauber zugeordnet etc. Andererseits fürchte ich, dass es am Ende ein unüberschaubares Monster wird, in dem sich (außer mir, dem Ersteller) niemand mehr zurecht finden kann. Und genau das wäre wiederum Gegenteil dessen, was ich eigentlich erreichen wollte. Dabei sieht es im Codebeispiel hier eigentlich ganz übersichtlich aus.
Impressionen diesbezüglich?
Ammeres
Hallo Ammeres,
Ich werde, sobald der Text in der Haupt-Sprache mal steht, immer von dieser aus weiter übersetzen. D.h. es reicht völlig aus, zwei Spalten nebeneinander (oder Zeilen untereinander) anzuzeigen. Mehr könnte sogar eher stören.
da bin ich wohl anders gepolt. Eine Sprache, die ich selbst überhaupt nicht gut spreche, und die ich daher übersetzen lasse, werde ich auch später gern ausblenden. Die Sprachen, die ich selbst einigermaßen beherrsche und daher selbst übersetze, möchte ich aber immer auch im direkten Vergleich nebeneinander (oder meinetwegen auch untereinander) sehen. Denn in dem Moment, wo mir in Sprache X eine Kleinigkeit auffällt, die vielleicht missverständlich oder nicht korrekt ist, möchte ich dieses Detail auch gleich in den übrigen Sprachen sehen und ggf. nachbessern.
Okay, die Anzahl der Sprachen, die ich beherrsche, ist überschaubar, ich würde sagen: Englisch fließend, Niederländisch ganz okay, Französisch schwache Schulkenntnisse. Spanisch und Italienisch kann ich lesen und zumindest in etwa verstehen, worum es geht.
Excel (oder OpenOffice/LibrOffice Calc) ist zum Bearbeiten gar nicht schlecht; wenn du die Tabelle im OpenDocument-Format speicherst (*.ods), kannst du sie sogar direkt mit PHP lesen und verarbeiten.
Die Information ist sehr interessant! Aus der Sicht Flexibilität, Anspruch und Übertragbarkeit ist der Ansatz wohl kaum zu übertreffen.
Danke für die Blumen. 😀
Fraglich ist, ob nicht ein paar mehr Funktionalitäten wünschenswert sind. Insbesondere fällt mir gerade die "letzte Überarbeitung" ein. Es wäre doof, wenn verschiedene Sprachen unterschiedlich aktuell sind und daher andere Informationen anzeigen, ohne dass der Nutzer das weiß.
Letzte Überarbeitung oder der Zeitpunkt des letzten Speicherns steht in einem Spreadsheet wohl als Feldfunktion zur Verfügung. Aber das bezieht sich dann immer auf das ganze Dokument, nicht auf einzelne Zeilen oder Spalten. Das müsste man dann manuell pflegen - mit dem Risiko, dass man es vergisst.
BTW könnte ich die Funktion theoretisch direkt in HTML anlegen, mit dem bereits vorhandenen (essentiellen) ein-ausblende-JavaScript:
<label> <div class="de" hidden>Deutscher Text</div> <div class="en" hidden>English text</div> <div class="..." hidden>... ...</div> </label>
Damit verlagerst du die Sprachauswahl plötzlich auf die Clientseite.
Einerseits hätte ich dann alle Sprachen in einer Datei, jeden Bereich sauber zugeordnet etc. Andererseits fürchte ich, dass es am Ende ein unüberschaubares Monster wird, in dem sich (außer mir, dem Ersteller) niemand mehr zurecht finden kann. Und genau das wäre wiederum Gegenteil dessen, was ich eigentlich erreichen wollte. Dabei sieht es im Codebeispiel hier eigentlich ganz übersichtlich aus.
Ja, aber es hat ein großes Potential zur Unbeherrschbarkeit. Und noch ein Minus: Bei n Sprachen würdest du knapp die n-fache Datenmenge übertragen, davon ein grßer Anteil unnötig.
Live long and pros healthy,
Martin
Letzte Überarbeitung oder der Zeitpunkt des letzten Speicherns steht in einem Spreadsheet wohl als Feldfunktion zur Verfügung.
Ich kann auch eine Spalte (Zeile) einfügen, bei der bei der jeweiligen Sprache der Zeitpunkt der letzten Aktualisierung eingetragen werden kann, und die dann dem Nutzer anzeigen. Automatisiert wäre jedoch besser.
Damit verlagerst du die Sprachauswahl plötzlich auf die Clientseite.
Nun, da ist sie doch immer. Wenn auch oft unbewusst.
Und noch ein Minus: Bei n Sprachen würdest du knapp die n-fache Datenmenge übertragen, davon ein grßer Anteil unnötig.
Das hätte ich in der heutigen Zeit so gar nicht als Argument gesehen. Immerhin handelt es sich bei HTML um bloße Text-Dateien, und Text allein verschlingt nicht viel. Etwas anderes wäre, wenn ich n-sprachige Meme-Versionen so darstellen würde.
Hingegen wäre der Vorteil, dass dem Nutzer, einmal geladen, jede Sprache im Cache zur Verfügung steht und er selbst bei Sprachwechsel keine Verbindung mehr aufnehmen muss.
Am schwersten wiegt für mich das Potenzial zur Unbeherrschbarkeit. Ein unbeherrschbares Projekt ist ein gescheitertes Projekt ohne Zukunft.
Gibt es bezüglich Mehrsprachigkeit auf diesem Wege best practices oder ähnliches?
Hi,
Letzte Überarbeitung oder der Zeitpunkt des letzten Speicherns steht in einem Spreadsheet wohl als Feldfunktion zur Verfügung.
Ich kann auch eine Spalte (Zeile) einfügen, bei der bei der jeweiligen Sprache der Zeitpunkt der letzten Aktualisierung eingetragen werden kann, und die dann dem Nutzer anzeigen. Automatisiert wäre jedoch besser.
eben, das meine ich.
Damit verlagerst du die Sprachauswahl plötzlich auf die Clientseite.
Nun, da ist sie doch immer. Wenn auch oft unbewusst.
Äh, nein. Auf der Clientseite ist nur der Wunsch "ich hätte gern". Die Untersuchung dieses Wunsches auf Erfüllbarkeit, und die tatsächliche Umsetzung (einschließlich einer Ersatzlösung, wenn's nicht geht) war bis gerade eben noch Sache des Servers.
Und noch ein Minus: Bei n Sprachen würdest du knapp die n-fache Datenmenge übertragen, davon ein grßer Anteil unnötig.
Das hätte ich in der heutigen Zeit so gar nicht als Argument gesehen.
Wenn man bedenkt, wie viele Nutzer inzwischen mit einem Handy (sprich: einem mobilen Volumentarif) surfen, ist das durchaus ein Argument.
Etwas anderes wäre, wenn ich n-sprachige Meme-Versionen so darstellen würde.
Was bitte??
Hingegen wäre der Vorteil, dass dem Nutzer, einmal geladen, jede Sprache im Cache zur Verfügung steht und er selbst bei Sprachwechsel keine Verbindung mehr aufnehmen muss.
Ja. Aber wie realistisch ist das? Wer wechselt andauernd die Sprache? Höchstens der Webentwickler, der alle Sprachversionen sorgfältig testet.
Live long and pros healthy,
Martin
Etwas anderes wäre, wenn ich n-sprachige Meme-Versionen so darstellen würde.
Was bitte??
Naja. Ein Meme ist oft ein Bild oder GIF, meist mit 1-5 Wörtern. Oder anders gesagt, eine gigantische Verschwendung an Daten mit nur geringem Informationsgehalt.
Würde ich das dutzendfach in n Sprachen ungenutzt hochladen, würde ich deinem Argument zustimmen. Aber so hat ein normales Bild in WA knapp 100kb. Sagen wir, ein UTF-8-Zeichen mit dem max. von 4b und 10 Zeichen pro Wort, entspräche das 2.500 Worten. Oder 16,6 deutsche Normseiten (a' 1.500 Zeichen pro Seite). Das ist einiges an Holz.
So als Relation. ;)
(Ich hatte gerade einfach Bock, Google und Taschenrechner zu bemühen. Also nicht zu ernst nehmen. :) )
Und aus der Praxis:
Meine komplette HTML-Datei hat aktuell 400 Zeilen (punktgenau), 2,6k Wörter (inklusive Code-Wörter), 24k Zeichen (ohne Leerzeichen) bzw. 37k Zeichen (mit Leerzeichen) und 38 kb [ist das eigentlich viel oder wenig?]. Großzügig geschätzt kämen pro Sprachversion 30kb dazu. Wenn ich bedenke, wie viel Bilder bei einem kurzen Besuch von Instagram, Facebook, Amazon geladen werden, denke ich nicht, dass das auch nur jemandem auffallen würde - nicht einmal mit LTE.
n'Abend,
Etwas anderes wäre, wenn ich n-sprachige Meme-Versionen so darstellen würde.
Was bitte??
Naja. Ein Meme ist oft ein Bild oder GIF, meist mit 1-5 Wörtern.
also ein Cartoon oder eine Karikatur. Dann sag das doch einfach.
Meine komplette HTML-Datei hat aktuell 400 Zeilen (punktgenau), 2,6k Wörter (inklusive Code-Wörter), 24k Zeichen (ohne Leerzeichen) bzw. 37k Zeichen (mit Leerzeichen) und 38 kb [ist das eigentlich viel oder wenig?].
Kann ich nicht repräsentativ beantworten - aber meine HTML-Dateien sind meist deutlich kleiner. In der Regel so 5..10kB. Und ich mach sogar Präsentationen (wo andere Kollegen Powerpoint nehmen würden) als schlanke HTML-Dokumente und präsentiere sie dann im Browser im Fullscreen-Mode.
Der Unterschied fällt den meisten Zuschauern/Zuhörern gar nicht auf.
Live long and pros healthy,
Martin
Hallo,
Naja. Ein Meme ist oft ein Bild oder GIF, meist mit 1-5 Wörtern.
also ein Cartoon oder eine Karikatur.
Jein, das ist zwar die richtige Richtung, triffts aber doch nicht so ganz: WP über Memes
Gruß
Kalk
@@Der Martin
Naja. Ein Meme ist oft ein Bild oder GIF, meist mit 1-5 Wörtern.
also ein Cartoon oder eine Karikatur.
Nein. GIF steht hier nicht für Icon, Zeichnung o.ä., wofür GIF (oder besser PNG) das angebrachte Grafikformat ist, sondern für animiertes GIF.
Oft ist’s ein Foto. Bekanntes Beispiel:
😷 LLAP
Nein, um Himmels Willen! Dann müsstest du ja die fertige Seite aus vielen Fragmenten zusammenstückeln.
Ganz genau das war auch mein Gedanke, und den fand ich dezent unerfreulich. ;)
Bezieht sich wohl auf mein Beispiel der Datei feld_anred.htm
<p><l>###Anrede###Salutation###Aanhef###</l>
<input [disabled]
type = 'text'
name = 'anred'
title = 'anred'
maxlength = 10
size = 10
value = '[anred]'
placeholder = "Herr Mr. Dhr."
/></p>
Das ist keine eigenständige Seite, sondern ein HTML-Snippet, ein Baustein, der von PHP in eine Seite eingefügt wird. Hätte die Datei auch feld_anred.txt nennen können.
@@Linuchs
<p><l>###Anrede###Salutation###Aanhef###</l>Das ist keine eigenständige Seite, sondern ein HTML-Snippet
Nein, das ist es nicht. <l> ist kein HTML.
😷 LLAP
@@Der Martin
Ermittlung der Sprache: Welche Sprache der Client haben möchte, ermittle ich dabei aus a) dem Accept-Language-Header im HTTP-Request, b) aus einem Cookie (Client hat einmal explizit eine Sprache gewählt und die wird gespeichert)
Wobei der Cookie natürlich Vorrang vor dem HTTP-Header haben muss. (Schriebst du ja später.)
und c) aus einem URL-Parameter
Ob sich die Sprachvarianter per GET-Parameter oder auf andere Art im URL wiederfindet, ist ein Implementierungsdetail.
😷 LLAP