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

  • Mehrsprachigkeit mit Hilfe von Files

    Hallo,

    ich bin gerade am grübeln darüber, wie ich das Datenbankkonzept für Mehrsprachigkeit umsetze.

    Ich habe im Internet verschiedene Ansätze gefunden. Jedoch scheint keiner auf meine Anforderungen zu passen.

    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.

    2. Möglichkeit: Mehrere Sprachen in der gleichen Tabelle untereinander in Zeilen Speichern. Spätestens wenn ich mit Nested Sets arbeite bekomme ich hier ein mega Chaos. Es fängt aber schon bei den IDs und auto_increment an.

    3. Möglichkeit: Alle sprachabhängigen Inhalte in eine extra Tabelle auslagern. Diese Methode ist schon ganz gut aber erfordert Joins und erzeugt zusätzliche Datenbanklast. Beispiel: Nested Sets Befehle werden an dieser Stelle sehr komplex

    4. Möglichkeit: Alle Sprachinhalte in ein und dieselbe Zelle Stecken und die verschiedenen Abschnitte im Text mit speziellen Trennzeichen unterteilen. Das ist zwar eine Möglichkeit aber die einzelnen Zellen würden extrem Aufgebläht. Zum Beispiel bei der Speicherung von Artikeln. Außerdem wäre die Software zum Bearbeiten solcher Zellen relativ kompliziert (Bearbeiten von Artikeln)

    Meine Idee: Ich speichere die Sprachabhängigen Inhalte einfach nicht in der Datenbank. Sondern ich speichere diese Inhalte in Dateien. Alles was ich nun tun muss, ist meine Datenbankklasse zu erweitern. Dort gibt es eine Methode getRows($sql). Diese Methode müsste nun nur noch prüfen, ob es zu den ausgelesenen Spalten zusätzliche Werte in Dateien gibt. Diese würden dann in der derzeit eingestellten Sprache nachgeladen werden.

    Vorteile: Keine Datenbanklast, Spontanes umschalten auf alternative Sprache wenn angeforderte Sprache nicht vorhanden ist, kann ohne großen Aufwand nachgerüstet werden, SQL-Kommandos bleiben absolut leserlich

    Nachteile: Sicherung umständlicher, Benutzung der Inhalte durch mehrere System unter Umständen schwierig, Nachteil der fehlenden Volltextsuche – müsste über mehrsprachige Keywords ausgeglichen werden

    Was haltet ihr von dieser Möglichkeit?


  • #2
    Nichts. Nimm 3)
    --

    „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


    • #3
      @nikosch: warum?

      Kommentar


      • #4
        Zitat von Geryon
        @nikosch: warum?
        Wenn ich hier mal stellvertretend einspringen darf:

        Die - teils massiven - Nachteile der anderen Methoden und auch deines eigenen Vorschlags hast du doch schon erkannt.

        3. Möglichkeit: Alle sprachabhängigen Inhalte in eine extra Tabelle auslagern. Diese Methode ist schon ganz gut aber erfordert Joins und erzeugt zusätzliche Datenbanklast.
        Wenn dir das Sorgen macht - implementiere Caching.

        Beispiel: Nested Sets Befehle werden an dieser Stelle sehr komplex
        Keine Arme, keine Kekse.

        Du kannst kein System mit erhöhter Komplexität in den Anforderungen bauen, ohne dass auch die Komplexität der Umsetzung an einigen Stellen steigen wird.

        Kommentar


        • #5
          Also ich mache es so wie du beschreibst, allerdings etwas weniger kompliziert.
          1) Es gibt ein Standardformat: OASIS XLIFF, welches diese Aufgabe löst
          2) da es XML ist, kann man das mit Simple-XML direkt laden und an eine Template-Engine oder Ersetzungsroutine geben
          3) weil es dokumentbasiert ist, kann man es mit mit einer Standardsuchmaschine bequem durchsuchen und die Datei-Id mit der passenden URL verknüpfen
          4) Da XLIFF ein Standard ist, kannst du es offline mit allen gängigen Translation Memory Tools (wie dem kostenlosen Omega-T oder dem XLIFF Editor) bearbeiten - sogar mit Anbindung von externen Übersetzungshilfen und Online-Wörterbüchern
          5) Die Synchronisation von Dateien löst man in der Regel indem man diese an einen gemeinsamen Speicherort auslagert. Häufig benutzte Dateien kann man on-demand in einen lokalen File-Cache auslagern, wenn man mehrere Front-End-Server hat.

          XLIFF kann beides: es hat ein einfaches Key-Value-Format, dass man sehr leicht bearbeiten kann, verfügt aber auch über weitergehende Funktionen wie kontextabhängige Alternativübersetzungen, Gruppierung von Textpassagen und Freigabemechanismen, über anzugeben wann eine in Überarbeitung befindliche Übersetzung publiziert werden darf. Die vorhandenen Tools können (je nach Preisklasse) Simultanübersetzungen von mehreren Übersetzern gleichzeitig, in Datenbanken gespeicherte Projekte, einen Glossar, Rechtschreibkontrolle, automatische Übersetzung über Anbindung externe Dienste a la Google-Translate. Und da es natürlich alles Textdateien sind, kann man sie notfalls immer bequem über Versionsverwaltungssysteme einchecken und auf mehreren Entwicklerrechnern konkurrierend bearbeiten. Wenn es sein muss auch auf einem Server direkt über die Kommandozeile.

          Mir persönlich gefällt diese Lösung und ich setze sie auch schon seit langer Zeit recht erfolgreich so ein.

          Kommentar


          • #6
            Alles was Dateien können, können auch Datenbanken. Und was Du an DB-Performance einsparst, bezahlst Du in Filesystemoperationen.
            Wenn es Dir zu viele Joins werden, dann benutze halt eine 2. i18n Tabelle. Selbst wenn Du die komplett ausliest, hast Du nicht mehr ausgegeben (Speicher!), als wenn Du ein File komplett einlesen musst. Aber Datenbanken sind eben von Natur aus als Feldbasierte Speicher ausgelegt, plain text Dateien nicht. Zudem hast DU die Datenverwaltung zentral an einem Ort.
            --

            „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


            • #7
              [OT]
              Zitat von nikosch Beitrag anzeigen
              dann benutze halt eine 2. i81n Tabelle.
              Entweder meinst du i18n - oder du willst im wahrsten Sinne des Wortes Bullshit-Bingo spielen, und jeder darf sich seine Zahlen selber ausdenken ...
              [/OT]

              Kommentar


              • #8
                Zahlenverdreher. Darf nach 29.395 Beiträgen mal vorkommen. eins elf.
                --

                „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


                • #9
                  danke für die Antworten...

                  @marcusson: den Ansatz werde ich mir mal näher ansehen. Klingt auf jeden fall interessant.

                  Kommentar


                  • #10
                    Schau es dir mal an: ist wirklich einfach zu realisieren.

                    OASIS FAQ: http://www.oasis-open.org/committees/xliff/faq.php
                    Code-Beispiel: http://yana.codeplex.com/SourceContr...iew/7562#11330
                    Youtube-Video: http://www.youtube.com/watch?v=A6dFZVE5lvw

                    Ab Minute 2:00 demonstriere ich die Verwendung des XLIFF-Editor.
                    Da hat man dann eine grafische Oberfläche, die man kostenlos verteilen darf.

                    Privat benutze ich Omega-T (Open-Source) für meine Handbücher.
                    Im professionellen Umfeld war ich mit Swordfish Translation Editor recht zufrieden.

                    Geladen wird die Datei mit simplexml_load_file() und danach kannst du über XPath "//trans-unit[@id=$foo]/target" Übersetzungen oder über "//group[@id=$bar]/trans-unit" Gruppen von Übersetzungen laden. Alles mit Bordmitteln, ohne zusätzliche Extensions.

                    Kommentar


                    • #11
                      Mal 'ne Frage. Über welche Größenordnung reden wir hier eigentlich. Meine Anwendungen benötigen ca. 240 Übersetzungen, die ich ganz lazy und nur nach Sprache differenziert komplett als Datei mit einem Array (12kb) einbinde. Wenn ich das hier lese, komme ich mir recht gedankenlos vor. Obwohl das ganze eigentlich prima klappt und der Performance nicht schadet.
                      Es ist schon alles gesagt. Nur noch nicht von allen.

                      Kommentar


                      • #12
                        Hmm

                        message.xlf
                        32kB / 25,6kB / 14,9kB

                        xml uncompressed / xml compressed (whitespace) / Nutzdaten

                        Also irgendwie finde ich, dass der XML-Overhead (Markup und XML-Zugriff) dieses Format nicht sehr elegant erscheinen lässt.
                        --

                        „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


                        • #13
                          Also ich benutze für mein Projekt das Zend Framework.

                          Die Anforderungen sind ebenfalls Multilang-Unterstützung.

                          Hierfür habe ich mich für den GetText Adapter entschieden.
                          (http://framework.zend.com/manual/1.1...dapter.gettext)

                          Nach dem zu urteilen was ich bei meiner Suche nach einer Lösung über google fand, ist nikosch´s Methode die beste im Hinblick auf die Performance, bzw. die, welche für große Projekte am meisten angefragt wurde.

                          Wobei natürlich immer die Frage ist von welcher Größenordnung wir reden... bei meinem Projekt habe ich mit 5000 Übersetzungen gerechnet.

                          Wobei ich aber auch zugeben muss, dass bei meiner Entscheidungsfindung es eine Rolle gespielt hat, dass es noch (immer) keinen offiziellen Zend_Translate_SQL Adapter gibt.

                          Es soll wohl einen inoffiziellen geben, leider ist die Seite aber nicht mehr erreichbar
                          (http://cloetensbrecht.be/zend_translate_mysql.html).

                          Denn dann hätte mich ein Benchmark schon sehr interessiert.
                          __________________________________________________ ________________________________

                          Marcussons Vorschlag kann ich so nicht zustimmen.

                          Ein XLIFF Adapter ist ebenfalls im Zend Framework enthalten.

                          Jedoch wird bereits in der Beschreibung darauf hingewiesen, dass diese Variante langsamer ist als die GetText Variante.
                          Zend_Translate_Adapter_Xliff

                          [...] but the parsing is not as fast as with gettext files.
                          Most medium companies use this adapter. The files are human readable and system-independent.
                          (http://framework.zend.com/manual/1.1....adapter.xliff)

                          Kommentar


                          • #14
                            Ich habe ca. 250 kbyte Texte und mit den XML-Dateien keine Probleme. Ich mache allerdings mehrere Dateien daraus, das macht sich einfacher beim Übersetzen.
                            Overhead oder Speicherprobleme habe ich keine. Durch die Netzwerklatenz und die ganzen Layer zwischen Anwendung und Datenbank würde ich auch nicht behaupten wollen, dass eine Datenbank noch schneller wäre.
                            Aber wenn es jemanden wirklich stört mit XPath zu arbeiten, kann man die Texte in ein Array umwandeln und cachen. Das würde man mit Datenbankabfragen auch bloß nicht anders machen.

                            Der Grund für mich persönlich war der, dass man keine eigenen Übersetzungstools schreiben möchte (ich jedenfalls nicht). Wenn man also nicht unbedingt im Web editieren MUSS ist ein Standardformat, dass mit allen gängigen Übersetzungsprogrammen gelesen werden kann keine schlechte Wahl.

                            Zumal sobald jemand auch nur ein kleines bisschen nach Features fragt kommt man mit dem selbst gebastelten Übersetzungsprogrammen schnell in Bedrängnis. Und da vorhandene Tools das ja alles schon können, bezahlt das auch niemand gern.
                            Zumindest Import- und Exportskripte müsste man sowieso schreiben, denn einem Übersetzungsbüro kann man wohl kaum einen Dump der Datenbank schicken.
                            Spätestens dann würde man sowieso wieder XLIFF nehmen - sofern man nicht unbedingt Excel exportieren will. Nichts gegen Microsoft aber ... Excel ist nicht unbedingt ein gutes Übersetzungsprogramm.

                            Ich finde diese neuen Austauschformate sind eine schöne Technologie: ich kann das XLIFF hier in einen SVN-Branch einchecken, die Übersetzer checken das aus, öffnen es in ihrem Standardtool und ich kann es nach dem Commit sofort im Demosystem angucken. Dann kann ich im XLIFF-Editor direkt (sogar automatisch) auf Fehler suchen lassen, die Texte durchgehen und abhaken: Übersetzung angenommen / abgelehnt.
                            Viel Smoother kann der Workflow gar nicht mehr laufen.

                            Mir ist aufgefallen: Man sollte darauf achten ein Übersetzungsbüro zu wählen, dass auch Erfahrung mit Übersetzung von Software hat. Einige machen hauptsächlich Print und sind überrascht, wenn man ihnen was anderes als Microsoft Word schickt.
                            Wir mussten denen ernsthaft sagen: "Klicken Sie im Menü 'Datei' auf 'Öffnen'", weil die Datei nicht per Doppelklick mit dem Übersetzungstool verknüpft war.

                            Kommentar


                            • #15
                              Klingt interessant. Ich habe mich persönlich ebenfalls für Gettext entschieden, auch wenn ich es für ein hervorragendes Tool halte (richtig konfiguriert bekommen das selbst DAUs hin), denke ich auch länger schon über dein Einsatz von der Industrie verbreiteten Tools nach.

                              Und ich denke, dass man z.B. mit Zend_Cache die Perfomance so weit erhöhen kann, dass man sich letztendlich für das bessere Format entscheiden kann.

                              Ein Datenbank-Adapter für Zend_Translate zu schreiben sollte wirklich einfach sein, wenn man vorhandenes Zend_Translate_Adapter nutzt.

                              Kommentar

                              Lädt...
                              X