cycap

Hallo zusammen,

ich würde gerne Meinungen zu Sprachvariablen in Javascript bekommen. Ich habe viele Module die fast ausschließlich mit Javascript funktionieren und da werden ja auch Texte benötigt, vor allem Beschriftugen aller Art (für Buttons, Spaltenüberschriften, QuickTips, etc.).

Nun frage ich mich wie ich diese Texte möglichst auch multiligual gestalten kann.

Ich habe mir dazu schon einige Gedanken gemacht:

Ansatz 1: Ich schreibe in die JS-Files direkt Sprachvariablen als ##VAR## und lasse die Datei bei jeder Anfrage durch den gleichen Übersetzer laufen der auch mein HTML übersetzt. Vorteil: Es werden nur Texte aus der DB geholt die auch benötigt werden. Nachteil: Browsercaching wird nahezu unmöglich

Ansatz 2: Eine PHP-Datei via <script> einbinden und vorgaukeln es wäre Javascript. Diese schreibt dann sämtliche Sprachvariablen und dessen Übersetzungen in JS-Arrays. Vorteil: Alle Files bis auf die Variablen selbst können ganz normal vom Browser gecached werden. Nachteil: Es müssen immer ALLE Sprachvariablen zur Verfügung gestellt werden

Ansatz 3: Es gibt eine Master-Pseudo-JS-Datei die Sprachvariablen wie in Ansatz 1 enthält. Ein Script auf dem Server generiert und speichert dann die übersetzten Varianten. Vom Browser werden dann direkt die übersetzten Dateien angefordert. Vorteil: Übersetzungen müssen nur einmalig beim generieren geholt werden, danach nicht mehr. Nachteil: Beim ändern des Inhalts einer Sprachvariable muss jedes mal der Generator angeworfen werden

Was meint ihr dazu?

Gruß
Cy

Mister Ad

robo47

Also ich würde zu 2) tendieren und wenn die eine Sprachdatei viel zu groß ist, kann man es ja eventuell modular aufteilen und es gibt ein basis-modul das immer geladen wird und dann laden Seiten/Module ihre Übersetzungen extra bei bedarf (darf halt nicht zu viel werden dass am ende 30 sprachdateien auf einer Seite geladen werden).

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

cycap

Da stellt sich natürlich die Frage wie sich "viel zu groß" definiert... aber die Gruppierung an sich ist wohl kein schlechter Ansatz.

xm22

4. Ansatz: Sprachdateien wie in Ansatz 2, aber eben gruppiert und dann eingebunden etwa so (JS):
Sprache ist dann de oder de_DE oder was auch immer (Könnte auch global festgelegt werden), gruppierung ist so was wie Benutzerdaten, Forum und enthält jeweils dafür spezifische Strings. Die Sprachdateien könnten mittels dynamisch geladener Script-Tagsw nachgeladen werden.

erc

Wieso sollte damit Browsercaching unmöglich werden? Die Datei ändert sich doch damit nicht bei jedem Aufruf.

cycap

Es gibt ja in dem Sinne keine Datei, sondern nur Content. Sicher gibts da Möglichkeiten über Header usw. allerdings müsste man dann auch wissen wann Änderungen stattgefunden haben um dem Browser mitteilen zu können das die imaginäre "Datei" sich geändert hat. Ich hab ja nie behauptet es sei unmöglich

xm22

Da gibt es den Ansatz (der sich für mich bewehrt hat), an die Dateien einen Parameter (z. B. ?v=xxx) zu hängen, der bei einer Änderung einfach inkrementiert wird..

cycap

Wenn ich dann aber eine Sprachvariable ändere, dann muss ich ja alle JS-Files neu holen lassen, da ich ja nicht weiss in welcher Datei welche Variable gebraucht wird, also optimal ist die Lösung auch nicht.

robo47

Im idealfall ist das dann bestandteil deines build/deploy-prozesses

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

nikosch

Schön und gut, aber wieso kann das nicht PHP-seitig vorbelegt werden? Im Zweifel machst Du ein Var-Setting im Dokumentenkopf?

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--