Ankündigung

Einklappen
Keine Ankündigung bisher.

Mehrsprachigkeit mit Hilfe von Files

Einklappen

Neue Werbung 2019

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

  • #16
    Ich mache eine etwas abgewandelte Version von deinem Punkt 3. Ich vergebe Sprachvariablen, die dann auch in meiner Tabelle stehen. Die Ausgabe wird dann eben erst gechached und dann nach Sprachvariablen durchsucht und entsprechend ersetzt. Dadurch habe ich keine Joins, sondern eine einzelne Abfrage am Ende.

    Kommentar


    • #17
      Stimmt - Sprachvariablen (aka "Token") benutzen eigentlich alle. Sogar Gettext: es benutzt den gesamten Ausgangstext als Token. Das Problem, dass ich in der Praxis mit Gettext hatte war, dass sobald sich der Ausgangstext auch nur geringfügig ändert (Bsp. Rechtschreibfehler, Kommasetzung, HTML-Tags) brechen alle Übersetzungen weg weil der Token sich auch ändert. Außerdem hat unser Chef einige feststehende Begriffe gehabt, für die man eigentlich ein Glossar bräuchte. Meist Fachbegriffe, die entweder gar nicht übersetzt werden durften, oder aber eine kundenspezifische Übersetzung hatten. Würde bei Gettext heißen, die ganze Sache wird rekursiv.

      Wenn man im Team arbeitet ist es am bequemsten, der Autor markiert in seinem Entwurf die zu übersetzenden Textstellen, danach erzeugt man aus diesem Ausgangsdokument per Skript ein Skeleton und eine Übersetzungsdatei. Letztere kann man dann in Translation Memory Tools weiter bearbeiten. Das Skeleton lässt sich beim XLIF-Format man mit der Übersetzung verknüpfen. Gute Übersetzungswerkzeuge können dann aus dem Skeleton und der Übersetzung on-the-fly eine Vorschau für den Übersetzer generieren.

      Außerdem hat mich überzeugt, dass die Übersetzungstools automatisch prüfen können, ob alle HTML-Tags aus dem Ausgangstext korrekt in der Übersetzung wieder auftauchen. Tatsächlich finden sie alle doppelten Texte, nicht übersetzten Segmente, Rechtschreibfehler et cetera und mache dem Übersetzer eine praktische ToDo-Liste, die man einfach per Knopfdruck durchgehen und abarbeiten kann. Nicht geschlossene Tags und fehlende Segmente in großen Übersetzungsprojekten von Hand zu suchen ist sehr lästig. Die Kollegen mussten früher entweder mit SQL-Abfragen ran, oder alle Seiten in allen Sprachen von Hand durchklicken. Heute geht das alles automatisch.

      Kommentar


      • #18
        XLIFF scheint mir auch für die Zusammenarbeit mit externen Übersetzern am Besten geeignet zu sein. Die Editoren sind allerdings doch sehr ernüchternd (zumindest die kostenlosen). Den Editor von Sun hab ich noch nicht ausprobiert, da ich gerade keine Lust habe da erstmal ein Build zu machen.

        XML hat immer massig overhead, aber wenn den Übersetzungskatalog aus dem XLIFF aufbaut und danach mittels Cache vorhält, sollte das kein Problem sein.

        In der Desktop-Entwicklung arbeiten wir mit gettext. Im PHP Manual steht zu gettext

        The GNU gettext library works on a per-process, not per-thread basis. This means that in a multi-user setting such as the Apache web server it will only work with a prefork MPM (i.e. one process per user). Worker and other threaded MPMs will not work.
        Hat jemand eine Ahnung wie es da mit IIS und PHP über FastCGI aussieht?

        Kommentar


        • #19
          Tipp:
          Zend_Translate_Adapter_Gettext
          [...]
          Also the Adapter is thread-safe and the PHP gettext extension is currently not thread-safe.

          Kommentar


          • #20
            Zitat von Geryon Beitrag anzeigen
            1. Möglichkeit: SQL Tabelle nach rechts erweitern. Ich find’s komisch, dass das trotz der massiven Nachteile immer noch so oft im Internet angepriesen wird.
            Was ist daran eigentlich so schlecht (alle anderen scheinen hiermit konform zu gehen)?

            Ich finde es eher vorteilhaft, da ich die Sprach-Felder nebeneinander habe und sie so leicher pflegen kann.
            Klar, wenn eine neue Sprache dazukommt, muss die Tabellenstruktur angepasst werden, aber meist beschränkt sich das eh auf Deutsch und Englisch und ist somit eher starr.

            Kommentar


            • #21
              aber meist beschränkt sich das eh auf Deutsch und Englisch und ist somit eher starr.
              Vielleicht bei Deinen Aufträgen.
              --

              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


              --

              Kommentar


              • #22
                Ich denke, genau dies ist der Punkt. Wenn man sich schon die Mühe macht, etwas mehrsprachig zu implementieren, sollte man es denke ich auch skalierbar gestalten.
                Je mehr ich lerne, desto mehr wird mir bewusst, dass ich eigentlich nichts weiß.

                Kommentar


                • #23
                  Zitat von Daniel Beitrag anzeigen
                  Ich denke, genau dies ist der Punkt. Wenn man sich schon die Mühe macht, etwas mehrsprachig zu implementieren, sollte man es denke ich auch skalierbar gestalten.
                  Ist es doch. Neue Spalte einführen und Texte hinterlegen - fertig. Ich hätte dazu mal einen plausiblen Grund, warum man das so gerade nicht machen sollte.

                  Kommentar


                  • #24
                    Hallo!

                    Ich hoff ich hab nichts überlesen, und auch auf die Gefahr das ich die Komplexität "übersehe"... aber warum nicht so das jeder Text eine Namen hat und man dann in der i18n tabelle nach unten geht.. Ein (zusätzlicher) unique ist auf "textname && lang"...

                    Code:
                    txtID | textname          | lang | text
                    ------------------------------------------------------------------------------------
                      1   | txtWelcome        | de   | Herzlich Willkommen!
                      2   | txtWelcome        | en   | Welcome!
                      3   | txtWelcome        | fr   | Bon Jour!
                      4   | txtWelcomUsername | de   | Hallo %1, wir freuen uns das Sie hier sind!
                    etc...
                    Und dann noch ne nette Funktion/Methode (einer Language-Class) die dann den benötigenten Text rausholt - das die Sprach-var verfügbar ist, davnon geh ich aus...

                    echo $Lang->getLangValue("txtWelcome", $currentLang);

                    Sollten dann noch Parameter nötig sein, kann man ja nochweitere Methoden reinbauen die dann im DB-Text zB ein %1 und %2 durch die Parameter ersetzen..

                    echo $Lang->getLangValue_1Param("txtWelcomUsername", $currentLang, "Kingman");
                    Das würde dann in "Hallo %1" durch "Hallo Kingman, wir freuen uns das Sie hier sind!" ersetzen (sorry, grad auf die Schnelle kein besseres Beispiel, man könnte den auch aufteilen..)

                    Dann kann ich ja nach Sortierung auch schöne Übersicht machen und neue Sprache hinzufügen ist sowieso kein Problem... geht mit der Methode nach je Spalte eine Sprache genauso..

                    LG
                    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                    PHP.de Wissenssammlung | Kein Support per PN

                    Kommentar


                    • #25
                      Ich hätte dazu mal einen plausiblen Grund,
                      Z.B. weil man Spaltennamen in SQL nicht dynamisch ansprechen kann. Feldinhalte dagegen ja.
                      --

                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                      --

                      Kommentar


                      • #26
                        Zitat von nikosch Beitrag anzeigen
                        Z.B. weil man Spaltennamen in SQL nicht dynamisch ansprechen kann. Feldinhalte dagegen ja.
                        Das Statement wird in PHP erstellt, wieso sollte ich die Spalte da nicht dynamisch vergeben können?
                        Um mal bei hausls Beispiel zu bleiben:
                        Code:
                        SELECT text FROM tabelle WHERE lang = '$currentLang' AND textname = 'txtWelcome'
                        vs.
                        SELECT text_$currentLang FROM tabelle WHERE textname = 'txtWelcome'
                        Das war jetzt kein überzeugendes Argument.

                        Kommentar


                        • #27
                          Für mich schon.
                          --

                          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                          Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                          --

                          Kommentar


                          • #28
                            Wenn du keine Lust auf eine sachliche Diskussion hast, dann musst du nicht unbedingt antworten.

                            Kommentar


                            • #29
                              Code:
                              SELECT text 
                              FROM   tabelle  t
                              JOIN   users    u
                                ON   t.lang = u.nativeLang
                              WHERE  u.id = '$currentAccount'
                              Code:
                              SELECT t.text 
                              FROM   users    u
                              JOIN   users    uf
                                ON   uf.friendId = u.id /* vereinfacht */
                              JOIN   tabelle  t
                                ON   t.lang = u.nativeLang
                                     OR t.lang = uf.nativeLang
                              WHERE  u.id = '$currentAccount'
                              --

                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                              --

                              Kommentar


                              • #30
                                Ok, $currentAccount kommt aus der Session? Also kann man beim Login genausogut die Sprache in der Session ablegen.

                                Ich führe mal einen meiner Meinung nach weiteren Vorteil auf, wenn alle Sprachen in einer Zeile zusammengefasst sind. Mit einer Abfrage wie IFNULL(text_'.getLanguage().', text_de) AS text kann automatisch ein Fallback auf die Defaultsprache realisiert werden, falls eine Übersetzung fehlt.

                                [EDIT]
                                Deine zweite Abfrage kam später. Was soll diese Bezwecken? Alle Übersetzungen für meine Sprache und die meiner Freunde ermitteln? Wozu soll das gut sein?
                                Konstruierst du jetzt irgendwelche realitätsfremden Abfragen, um deine Aussage zu verteidigen?

                                Kommentar

                                Lädt...
                                X