Ankündigung

Einklappen
Keine Ankündigung bisher.

best practice bei Sprachvar. in JS

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • best practice bei Sprachvar. in JS

    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

  • #2
    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).
    [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
    | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

    Kommentar


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

      Kommentar


      • #4
        4. Ansatz: Sprachdateien wie in Ansatz 2, aber eben gruppiert und dann eingebunden etwa so (JS):
        PHP-Code:
        importLanguageFile('sprache''gruppierung'
        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.

        Kommentar


        • #5
          Zitat von cycap Beitrag anzeigen
          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
          Wieso sollte damit Browsercaching unmöglich werden? Die Datei ändert sich doch damit nicht bei jedem Aufruf.

          Kommentar


          • #6
            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

            Kommentar


            • #7
              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..

              Kommentar


              • #8
                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.

                Kommentar


                • #9
                  Im idealfall ist das dann bestandteil deines build/deploy-prozesses
                  [URL="http://www.robo47.net"]robo47.net[/URL] - Blog, Codeschnipsel und mehr
                  | :arrow: [URL="http://www.robo47.net/blog/192-Caching-Libraries-and-Opcode-Caches-in-php-An-Overview"]Caching-Klassen und Opcode Caches in php[/URL] | :arrow: [URL="http://www.robo47.net/components"]Robo47 Components - PHP Library extending Zend Framework[/URL]

                  Kommentar


                  • #10
                    Ich habe viele Module die fast ausschließlich mit Javascript funktionieren und da werden ja auch Texte benötigt
                    Schön und gut, aber wieso kann das nicht PHP-seitig vorbelegt werden? Im Zweifel machst Du ein Var-Setting im Dokumentenkopf?
                    [COLOR="#F5F5FF"]--[/COLOR]
                    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                    [COLOR="#F5F5FF"]
                    --[/COLOR]

                    Kommentar


                    • #11
                      Zitat von nikosch Beitrag anzeigen
                      Schön und gut, aber wieso kann das nicht PHP-seitig vorbelegt werden? Im Zweifel machst Du ein Var-Setting im Dokumentenkopf?
                      Ich versteh gerade nicht was du meinst.

                      Kommentar


                      • #12
                        Er meint wahrscheinlich:
                        PHP-Code:
                        <script type="text/javascript">

                        var heading = <?php echo $heading_from_php;?>;

                        </script>
                        Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

                        Kommentar


                        • #13
                          Genau. Oder eben die Buttons, Hilfs-Spans etc. schon php-seitig mit den richtigen Labels ausgeben.
                          [COLOR="#F5F5FF"]--[/COLOR]
                          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                          [COLOR="#F5F5FF"]
                          --[/COLOR]

                          Kommentar


                          • #14
                            Ob ich Ansatz 2 nun direkt im HTML oder per File mache, das macht doch keinen Unterschied?

                            Und
                            schon php-seitig mit den richtigen Labels ausgeben
                            wäre ja Ansatz 1 oder nicht?

                            Kommentar


                            • #15
                              Inline-<script>-Elemente im Dokument sind aber auch kontra Caching, und gerade darauf liegt ja mit der Hauptaugenmerk der Fragestellung.
                              [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                              Kommentar

                              Lädt...
                              X