Angemessenes mehrsprachiges Schema oder Overkill?

UPDATE 2 : Ich habe dies tatsächlich verwendet und es ist großartig nach ein paar Optimierungen. Hier ist mein Beitrag zum tatsächlichen Design und in Aktion: http://tim.hithlonde.com/2013/lemon-schema-works/

Ich erstelle eine Web-App und möchte, dass sie mehrere Sprachen unterstützt. Diese Struktur besteht aus zwei Komponenten:

1. Verbinden des Gebietsschemas ('Englisch', 'Deutch' usw.) mit Begriffen und Verbinden von Begriffen und Begriffen in einer bestimmten Sprache mit einem Rosettastein.
2. Gruppieren von Begriffen nach Seite. Ich möchte nicht sagen, SELECT term1, term2 usw. über die 30+ Begriffe, die ich möglicherweise auf einer Seite benötige. Ich möchte nach der Seite fragen, mit der sie verbunden sind.

Hier ist meine vorgeschlagene Tabellenstruktur (beachten Sie, dass alle IDs Beziehungen / Indizes enthalten, um sehr effiziente Abfragen durchzuführen):

  * locale
      * id
      * value //English, Deutch, etc//
  * terms
    * id
    * value //In English//
  * page 
    * id
    * value //Think add entry, menu//
  * page_group //group all terms to a page, for easy pulling//
    * id
    * page.id
    * term.id
  * rosetta
    * id
    * locale.id
    * term.id
    * value //french word for amount, description, etc//

Dies ermöglicht Abfragen wie:

SELECT localization.value,
        terms.value
FROM localization
INNER JOIN terms ON terms.id=localization.termid
INNER JOIN page_group ON page_group.termid=localization.termid
INNER JOIN page ON page.id=page_group.pageid
INNER JOIN locale ON locale.id=localization.localeid
WHERE page.value='add_entry' AND locale.id=custlangid
ORDER BY terms.id

Ich muss nur um zwei Artikel bitten; die Sprach-ID, die ich brauche, und die Seite, die ich brauche. Es werden alle Begriffe in der angegebenen Sprache angezeigt, die Teil der Gruppe von Begriffen für diese Seite sind.

Ich denke, das ist eine wirklich gute Struktur, aber ich würde mich über Feedback freuen.

UPDATE : Zur Verdeutlichung sprechen wir nur über die Lokalisierung der UI-Komponenten . (Beschriftungen, Navigation, hilfreicher Text) Alle vom Benutzer eingegebenen Informationen werden in Unicode gespeichert, nicht in diesem Schema.

UPDATE 2 : Ich habe das tatsächlich benutzt und es ist großartig. Hier ist mein Beitrag zum aktuellen Design und in Aktion: http://tim.hithlonde.com/2013/lemon-schema-works/

Wir haben viel getan, und (administrative) Benutzer durften die Übersetzungen live korrigieren. (Vielleicht möchten Sie immer noch eine Caching-Ebene, aber ich bin völlig fertig damit, diese mit einer echten Datenbank und nicht mit Ressourcendateien zu betreiben. Sie haben eine Menge Möglichkeiten, Dinge abzufragen und zu finden, die übersetzt werden müssen usw.). Ich denke, Ihr Schema ist wahrscheinlich in Ordnung, also werde ich nur einige Dinge weitergeben, die wir in der Hoffnung gelernt haben, dass es nützlich ist.

Eine Sache, die Sie ausgelassen haben, sind Sätze mit Einfügepunkten. Im folgenden Beispiel ist die Reihenfolge umgekehrt und die Sprache ist immer noch Englisch. Dies können jedoch sehr leicht zwei verschiedene Sprachen sein. Stellen Sie sich vor, dies sind nur zwei Sprachen, die normalerweise die Dinge in eine andere Reihenfolge bringen.

Hello, <username> you have <x> points!

You've got <x> points to spend, <username>!

In unserem pre-.NET hatten wir eine Routine, die das Einfügen durchführte, damit die Phrasen so aussehen würden:

Hello, {0:username} you have {1:points} points!

You've got {1:points} points to spend, {0:username}!

Dies würde natürlich einfach in Ihrem Code als <%= String.Format(phrase, username, points); %>oder ähnlich verwendet werden

Was dem Übersetzer ein bisschen geholfen hat. Aber .NET String.FOrmat unterstützt leider keine Kommentare innerhalb des Formatstrings.

Wie Sie sagen, möchten Sie dies in Ihrem PHP nicht mit Gebietsschema-Bewusstsein oder Meta-Phrasen behandeln.

Was wir also hatten, war eine Masterphrasentabelle:

Phraseid, Englisch, ergänzende Informationen

und eine lokalisierte Tabelle:

Phraseid, Localeid, Übersetzung

Sie haben bei INNER JOINS auch angenommen, dass die lokalisierten Versionen vorhanden sind. Wir haben sie in der Regel weggelassen, bis sie übersetzt wurden, sodass Ihre Abfrage zunächst nichts zurückgibt (nicht einmal die Standardeinstellung).

Wenn keine Übersetzung vorhanden war, wurde unsere standardmäßig auf Englisch gesetzt und dann auf Code-bereitgestellt zurückgegriffen (falls die Datenbank nicht über die ID verfügte, und aus dem Code ging auch hervor, welche Phrasen-ID "TXT_LNG_WRNNG_INV_LOW" tatsächlich zu erhalten versuchte ) - Das Äquivalent dieser Abfrage ist das, was wir verwendet haben:

SELECT COALESCE(localized.translation, phrase.english, @fallback)
FROM DUAL
LEFT JOIN phrase
    ON phrase.phraseid = @phraseid
LEFT JOIN localized
    ON localized.phraseid = phrase.phraseid
    AND localized.localeid = @localeid

Offensichtlich können Sie alle Dinge auf einmal mit Ihrem Seitensystem erhalten.

Wir neigten dazu, Dinge nicht mit der Seite zu verknüpfen, da sie häufig zwischen Seiten wiederverwendet wurden (und nicht nur in Seitenfragmenten oder Steuerelementen), aber das ist sicherlich in Ordnung.

Bei unseren Windows-nativen Apps haben wir Reflection und eine Zuordnungsdatei vom Steuerelement zum Übersetzungs-Tag verwendet, sodass für die Übersetzung keine Neukompilierung erforderlich war (in Apps vor.NET mussten wir die Steuerelemente mit dem Tag oder einem anderen speziellen Element kennzeichnen Eigenschaften). Dies ist in PHP oder ASP.NET MVC wahrscheinlich etwas problematischer, in ASP.NET jedoch möglich, wo es ein vollständiges serverseitiges Seitenmodell gibt.

Zum Testen können Sie natürlich sehr leicht nach fehlenden Übersetzungen suchen. Um Orte zu finden, die markiert werden müssen, übersetzen Sie das gesamte Phrasenwörterbuch mit Schweinelatein oder Klingonisch oder ersetzen Sie jedes Nicht-Leerzeichen durch? - Die Engländer sollten auffallen und Sie wissen lassen, dass sich nackter Klartext in Ihr HTML eingeschlichen hat.

In der Regel werden Übersetzungen von externen Fachfirmen durchgeführt. Daher wäre es mühsam, den übersetzten Inhalt in einer Datenbank zu verwalten. Sie sind besser dran, in "Bundles" oder Eigenschaftendateien über eine von Ihrer Plattform angebotene Sprachfunktion zu verwalten. Um dies zu erreichen, platzieren Sie in der Datenbank einfach eine Mnemonik für die Zeichenfolge. Basierend auf der gewünschten Sprache würden Sie dann im Bundle nachschlagen. z.B.

Data:
Employee_Status = empl_status.active

language Bundles:
Employee.us:  
  empl_status.active=Active

Employee.es
  empl_status.active=<spanish translation goes here>

To get the localized content:
    String status = getLocalizedContent("Employee","empl_status.active", "us");
    String status = getLocalizedContent("Employee","empl_status.active", "es");
    String status = getLocalizedContent("Employee","empl_status.active");

Erstellen Sie einfach 3 Tabellen

1.) Sprachmeister (LangId, LangName)

2.) Ressourcenmaster (ResourceMasterId, TableId, ColumnId, ColumnName)

3.) Ressourcendetails (ResourceMasterId, LangId, Wert)

zusammengesetzter Schlüssel (ResourceMasterId, LangId) für Ressourcendetails