Das Szenario
Sie sind Inhaber eines Online-Shops in Polen. Die Mehrheit Ihrer Kunden kommt aus Polen und spricht Polnisch. Sie möchten Ihre Produkte aber auch im Ausland verkaufen und Ihre internationalen Kunden sprechen hauptsächlich Englisch. Sie möchten also, dass Ihr Online-Shop sowohl auf Polnisch verfügbar ist und Englisch . Sie erwarten auch, dass sich Ihre Produkte in Frankreich gut verkaufen werden, also gehen Sie davon aus, dass Sie ein Französisch vorbereiten müssen Version des Shops (und vielleicht Spanisch auch, warum nicht?).
Sie möchten, dass Ihre Benutzer von der polnischen Version wechseln können
zur englischen Version und zurück.
Und natürlich möchten Sie, dass die Produktdetails von Polnisch auf Englisch wechseln.
Wie erstellt man eine mehrsprachige Webanwendung?
In Ihrer Bewerbung gibt es zwei Arten von Texten. Einer ist statisch Daten:Schaltflächenbeschriftungen, Tabellenüberschriften, Grafiken (die oft Text enthalten). Die andere ist die benutzerdefiniert Daten wie Produktname, Produktpreis, Produktbeschreibung usw. Die Daten werden normalerweise aus der Datenbank übernommen.
Die statischen Daten sind das, was Sie als Zeichenfolgenliteral in Ihre Ausgabe schreiben möchten. Die benutzerdefinierten Daten sind Daten, die Sie aus Ihrer Datenbank entnehmen.
Ich werde heute nicht über statische Daten sprechen. Jedes vernünftige Web-Framework wird die Internationalisierung der statischen Daten handhaben. Einzelheiten finden Sie in der Dokumentation Ihres Webanwendungs-Frameworks. Suchen Sie nach Schlüsselwörtern wie „Internationalisierung“, „i18n“, „Lokalisierung“ oder „Übersetzungen“.
Heute werde ich darüber sprechen, welche Datenbankstruktur wir hier bei e-point normalerweise verwenden, um mit mehrsprachigen Daten umzugehen. In der Datenbank Ihres Shops haben Sie wahrscheinlich den product Tabelle, die Informationen über alle im Geschäft verfügbaren Produkte speichert.
Das product Tabelle hat Spalten wie name , description und price . Wenn Sie die Produktinformationen in andere Sprachen übersetzen, müssen Sie nur einige Spalten übersetzen. Hier würden Sie nur den name übersetzen und description , sondern der price ändert sich nicht, wenn Sie die Sprache wechseln.
Wenn wir Unterstützung für mehrere Sprachen hinzufügen, fügen wir eine neue Tabelle mit dem Namen language_version , die alle im Store verfügbaren Sprachversionen speichert. Normalerweise fügen wir eine Spalte namens code hinzu und eine namens is_default (mit einer entsprechenden Einschränkung:nur eine Version kann die Standardeinstellung sein).
Als nächstes teilen wir das product Tabelle in zwei Tabellen:Tabelle product und Tabelle product_lv . Für jedes Produkt gibt es eine Zeile im product Tabelle und mehrere Zeilen in product_lv Tisch; eine Zeile für jede Sprachversion. Die Tabelle product_lv enthält nur zu übersetzende Spalten:name und description . Die sprachunabhängigen Spalten (wie price , weil Sie für denselben Preis verkaufen, egal ob Ihr Kunde Englisch oder Polnisch spricht) bleiben in der Tabelle product .
Dasselbe machen wir für jede Tabelle, die übersetzte Daten enthält. Die übersetzten Daten gehen in table_lv Tabelle, die sprachunabhängigen Daten bleiben in der Haupttabelle.
Vor- und Nachteile
Ein offensichtlicher Nachteil ist, dass alle Vorgänge zum Erstellen, Abrufen, Aktualisieren oder Löschen (CRUD) etwas komplizierter werden. Sie müssen immer eine zusätzliche Sprachversionstabelle hinzufügen, um die richtige Beschreibung zu erhalten.
Der Vorteil dieses Designs besteht darin, dass Sie Ihr Datenbankschema nicht ändern müssen, wenn Sie eine neue Sprachversion hinzufügen. Ich sage nicht, dass das Hinzufügen einer neuen Sprachversion einfach ist. Schließlich müssen Sie ALLE Produktbeschreibungen übersetzen. Dies ist eine organisatorische Herausforderung, aber aus Datenbanksicht ist es ziemlich einfach:viele Beilagen.
Wie entwerfen Sie Ihre mehrsprachigen Datenbanken?
