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

  • nikosch
    antwortet
    Zahlenverdreher. Darf nach 29.395 Beiträgen mal vorkommen. eins elf.

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    [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]

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    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.

    Einen Kommentar schreiben:


  • marcusson
    antwortet
    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.

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    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.

    Einen Kommentar schreiben:


  • Geryon
    antwortet
    @nikosch: warum?

    Einen Kommentar schreiben:


  • nikosch
    antwortet
    Nichts. Nimm 3)

    Einen Kommentar schreiben:

Lädt...
X