So entwerfen Sie ein lokalisierungsfähiges System

Im Zeitalter der Globalisierung sind Unternehmen – einschließlich Softwareentwickler – immer daran interessiert, in neue Märkte zu expandieren. Dies bedeutet oft, ihre Produkte für verschiedene Bereiche zu lokalisieren. In diesem Artikel erläutern wir einige Ansätze zum Entwerfen Ihres Datenmodells für die Lokalisierung – insbesondere für die Verwaltung von Inhalten in mehreren Sprachen.

Was ist Lokalisierung?

Lokalisierung ist der Prozess der Anpassung eines Produkts an verschiedene Märkte. Es ist ein herausragender Faktor, um einen maximalen Marktanteil in Bezug auf den Produktverkauf zu erreichen. Wenn die Lokalisierung korrekt durchgeführt wird, werden die Benutzer das Gefühl haben, dass das Produkt für ihre Sprache, Kultur und ihre Bedürfnisse entwickelt wurde.

An Orten, an denen Englisch keine gemeinsame Muttersprache ist, haben Umfragen gezeigt, dass lokale Sprachen für ein Softwareprodukt sehr bevorzugt werden. Dieser MediaPost-Artikel enthält einige interessante Zahlen zum Bedarf an anderen Sprachen als Englisch im internationalen Vertrieb.

Was können Sie verlieren, wenn Sie nicht lokalisieren?

Betrachten wir ein unglückliches Beispiel für Nicht-Lokalisierung. Zur Bequemlichkeit der Kunden ermöglichte ein E-Commerce-Portal den Kunden, einzelne Käufe in einer Vierergruppe zu bündeln. Leider klingt die Aussprache des Wortes „vier“ im Japanischen wie ihr Wort für „Tod“. Japaner vermeiden normalerweise alle Dinge, die mit dieser Nummer verbunden sind, weil sie als unglücklich angesehen wird. Unnötig zu sagen, dass der Verkauf dieser Produkte auf dem japanischen Markt nicht gut lief.

Um die obige Frage zu beantworten, könnten Sie also eine ganze Menge verlieren, wenn Sie nicht sorgfältig für Ihren Zielmarkt planen.

Inhaltsübersetzung als Lokalisierung

Wenn wir an Lokalisierung denken, ist die Übersetzung von Inhalten oft der allererste Gedanke, der uns in den Sinn kommt. Der zweite Gedanke lautet:„Wir brauchen ein robustes und effizientes Datenbankmodell, um übersetzte Inhalte in mehreren Sprachen zu speichern“.

Angenommen, wir werden gebeten, ein Datenmodell für eine mehrsprachige E-Commerce-Anwendung zu entwerfen. Wir müssten Textfelder wie product_name speichern und die Beschreibung von Produkten in verschiedenen Sprachen. Wir müssten auch Textfelder in anderen Tabellen speichern, z. B. customer Tabelle, in all diesen Sprachen.

Um zu verstehen, wie wir unser Datenmodell im Hinblick auf die Inhaltsübersetzung entwerfen, untersuchen wir verschiedene Ansätze anhand dieser beiden Tabellen. Jeder dieser Ansätze hat Vor- und Nachteile. Die unten gezeigten Ansätze können auf andere Tabellen in Ihrem Datenmodell erweitert werden. Welchen genauen Ansatz Sie wählen, hängt natürlich von Ihren eigenen Anforderungen ab.

Ansatz 1 – Hinzufügen separater Sprachspalten für jedes vorgesehene Feld

Dies ist der einfachste Ansatz in Bezug auf die Entwicklung. Es kann implementiert werden, indem für jedes Feld eine Sprachspalte hinzugefügt wird.

Vorteile

Es ist sehr einfach zu implementieren.
Es ist nicht kompliziert, SQL zu schreiben, um die zugrunde liegenden Daten in einer beliebigen Sprache abzurufen. Angenommen, ich möchte eine Abfrage schreiben, um Produkt- und Kundendetails für eine bestimmte Bestellung in französischer Sprache abzurufen. Der Code würde so aussehen:
```
Select p.product_name_FR, p.description_FR, p.price, 
       c.name_FR, c.address_FR, c.contact_name 
from order_line o, product p, customer c
	Where o.product_id = p.id and o.customer_id = c.id
	And id = ;
```

Nachteile

Es gibt keine Skalierbarkeit:Jedes Mal, wenn eine neue Sprache hinzugefügt wird, müssen Dutzende von zusätzlichen Spalten über Tabellen hinweg hinzugefügt werden.
Es kann zeitaufwändig werden, besonders wenn viele Felder mehrere Sprachen haben müssen.

Am Ende schreiben die Entwickler die unten gezeigte Abfrage, um alle vorhandenen Sprachen zu verwalten. Daher müssen sich alle SQLs in Ihrer Anwendung ändern, wenn eine neue Sprache eingeführt wird. (Hinweis: @in_language bezeichnet die aktuelle Sprache der Anwendung; Dieser Parameter kommt vom Frontend der App, während das Backend Datensätze abruft.)

SELECT CASE @in_language 
              WHEN ‘FR’ THEN p.product_name_FR
              WHEN ‘DE’ THEN p.product_name_DE
              DEFAULT THEN p.product_name_EN,
           p.price,
          CASE @in_language 
              WHEN ‘FR’ THEN c.name_FR
              WHEN ‘DE’ THEN c.name_DE
              DEFAULT THEN c.name_EN,
          c.contact_name
FROM order_line o, product p, customer c
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND id = ;

Ansatz 2 – Erstellen einer separaten Tabelle für übersetzten Text

Bei diesem Ansatz wird eine separate Tabelle verwendet, um übersetzten Text zu speichern; im Beispiel unten haben wir diese Tabelle translation . Es enthält eine Spalte für jede Sprache. Werte, die aus Feldwerten in alle anwendbaren Sprachen übersetzt wurden, werden als Datensätze gespeichert. Anstatt den tatsächlich übersetzten Text in zugrunde liegenden Tabellen zu speichern, speichern wir seinen Verweis auf die translation Tisch. Diese Implementierung ermöglicht es uns, ein gemeinsames Repository für übersetzten Text zu erstellen, ohne zu viele Änderungen am vorhandenen Datenmodell vorzunehmen.

Vorteile

Es ist ein guter Ansatz, wenn die Lokalisierung auf einem bestehenden Datenmodell implementiert werden soll.
Eine einzelne zusätzliche Spalte in der translation Tabelle ist die einzige Änderung, die erforderlich ist, wenn eine neue Sprache eingeführt wird.
Wenn der Originaltext in allen Tabellen gleich ist, gibt es keinen redundanten übersetzten Text. Beispiel:Angenommen, ein Kundenname und ein Produktname sind identisch. In diesem Fall wird nur ein Datensatz in die Übersetzungstabelle eingefügt und derselbe Datensatz wird in beiden customer und product Tabellen.

Nachteile

Es erfordert immer noch eine Änderung im Datenmodell.
Die Tabelle kann unnötige NULL-Werte enthalten. Wenn 1.000 Felder für nur eine unterstützte Sprache benötigt werden, erstellen Sie am Ende 1.000 Datensätze – und viele NULL-Werte.

Die Komplexität des Schreibens von SQL nimmt mit zunehmender Anzahl von Joins zu. Und wenn es viele Datensätze in der translation Tabelle, die Abrufzeiten sind langsamer.

Lassen Sie uns erneut eine SQL-Anweisung für das Sprachverwaltungsproblem schreiben:

SELECT CASE @in_language 
              WHEN ‘FR’ THEN tp.text_FR
              WHEN ‘DE’ THEN tp.text_DE
              DEFAULT THEN p.product_name_EN,
           p.price,
          CASE @in_language 
              WHEN ‘FR’ THEN tc.text_FR
              WHEN ‘DE’ THEN tc.text_DE
              DEFAULT THEN c.name_EN,
          c.contact_name
FROM order_line o, product p, customer c, translation tp, translation tc
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND p.name_translation_id = tp.id
	AND c.name_translation_id = tc.id
	AND id = ;

Eine Variante des Übersetzungstabellenansatzes

Um beim Abrufen von übersetztem Text eine bessere Leistung zu erzielen, können wir die translation Tabelle in mehrere Tabellen. Wir können die Datensätze basierend auf der Domäne gruppieren, d. h. eine Tabelle für customer , ein weiteres für product usw.

Ansatz 3 – Eine Übersetzungstabelle mit Zeilen für jede Sprache

Diese Implementierung ist dem zweiten Ansatz ziemlich ähnlich, aber sie speichert die Werte für übersetzten Text in Zeilen und nicht in Spalten. Hier die translation Die Tabellen-ID bleibt für einen Feldwert in jeder übersetzten Sprache gleich. Ein zusammengesetzter Primärschlüssel {id , language_id } wird in der Übersetzungstabelle gespeichert und speichert dieselbe translation_id für jedes Feld gegen mehrere language_id .

Vorteile

Diese Implementierung ermöglicht es Entwicklern, ganz einfach SQLs zum Datenabruf zu schreiben.
Es ist auch einfach, OEM für dieses Modell zu schreiben.
Es sind keine Datenmodelländerungen erforderlich, wenn Sie eine neue Sprache hinzufügen; Fügen Sie einfach die Datensätze für die neue Sprache ein.
Es gibt keinen unnötigen Speicherverbrauch, wenn eine Gruppe von Feldern nicht auf eine Sprache anwendbar ist.

Die Komplexität von Datenabruf-SQLs wird reduziert. Sehen Sie sich das folgende Beispiel an:

SELECT tp.text,
        p.price,
       tc.text,
        c.contact_name
FROM order_line o, product p, customer c, translation tp, 
     translation tc, language l
	WHERE o.product_id = p.id AND o.customer_id = c.id
	AND p.name_translation_id = tp.id
	AND c.name_translation_id = tc.id
             AND tp.language_id = l.id
             AND tc.language_id = l.id
             AND l.name = @in_language
	AND id = ;

Nachteile

Eine relativ hohe Anzahl von Joins ist erforderlich, um übersetzte Daten abzurufen.
Mit der Zeit kann möglicherweise eine große Anzahl von Datensätzen in der translation Tisch. Da es nur eine Übersetzungstabelle gibt, wird der gesamte übersetzte Text darin abgelegt. Wenn Sie Millionen von zu übersetzenden Feldern haben und Ihre Anwendung eine große Anzahl von Sprachen unterstützt, wäre das Abfragen einer Tabelle nach einer Übersetzung eine zeitaufwändige Aktivität. Sie können die Übersetzungstabelle jedoch entweder nach Sprachen oder Fachgebieten aufteilen, wie wir am Ende des zweiten Ansatzes aufgezeigt haben.

Was wäre, wenn wir die Ansätze 2 und 3 kombinieren?

Konkret kombinieren wir die Variante von Ansatz 2 – Aufteilen der translation table – mit der Idee, Zeilen in einer Tabelle zu verwenden. Wir können den Nachteil, große Datensätze in der translation Tabelle, indem Sie mehrere Tabellen basierend auf einer Domäne erstellen, wie wir es in der Variante von Ansatz 2 getan haben. Wenn die domänenbasierte Übersetzungstabelle eine beträchtliche Anzahl von Datensätzen enthält, könnten wir die Tabellen basierend auf einzelnen Feldern weiter aufteilen.

Ansatz Nr. 4 – Erstellen von Entitätsebenen für übersetzte Felder und nicht übersetzte Felder

In dieser Lösung werden Entitätstabellen, die ein oder mehrere übersetzte Felder enthalten, in zwei Schichten aufgeteilt:eine für übersetzte Felder und eine für nicht übersetzte Felder. Auf diese Weise erstellen wir für jede eine separate Ebene.

Vorteile

Es besteht keine Notwendigkeit, Übersetzungstabellen zusammenzuführen, wenn nur nicht übersetzte Felder betroffen sind. Daher erzielen nicht übersetzte Felder eine bessere Leistung.
Eine relativ geringere Anzahl von Joins ist erforderlich, um übersetzte Texte abzurufen.
Es ist einfach, OEM zu schreiben.
SQLs zum Abrufen von übersetztem Text sind einfach.
Dies ist ein bewährter Ansatz zur Integration mehrerer Sprachen in Entitäten.

Um diesen Punkt zu demonstrieren, ist hier eine Beispielabfrage, die übersetzten Text abruft:

SELECT pt.product_name, pt.description, p.price
FROM order_line o, product p, product_translation pt, language l
	WHERE o.product_id = p.id AND 
	AND p.id = pt.product_non_trans_id
	AND pt.language_id = l.id
               AND l.name = @in_language
	AND id = ;

Lokalisierung – Mehr als die Übersetzung von Inhalten

Bei der Lokalisierung werden Ihre Anwendungsinhalte nicht nur in eine andere Sprache übersetzt. Es gibt auch kulturelle und funktionale Parameter, die beachtet werden müssen. Beispielsweise wird ein Datumswert in Nordamerika als „MM/TT/JJJJ“ formatiert, aber in den meisten asiatischen Ländern wird er als „TT/MM/JJJJ“ geschrieben.

Ein weiteres Beispiel hat mit der Anzeige von Namen im Anwendungskopf zu tun. In den USA ist es akzeptabel oder sogar bevorzugt, jemanden beim Vornamen anzusprechen; In dieser Kultur wird der Vorname des Kunden in der Kopfzeile angezeigt, sobald sich der Kunde anmeldet. In Japan ist es jedoch umgekehrt:Jemanden beim Vornamen anzusprechen, ist unhöflich oder sogar eher beleidigend. Die Lokalisierung würde dies berücksichtigen und die Verwendung von Vornamen für das japanische Publikum der Anwendung vermeiden.

Lokalisierungsparameter müssen möglicherweise am Backend der Anwendung gespeichert werden. Dies ist sehr häufig der Fall, wenn Sie eine Programmlogik rund um die Lokalisierung entwerfen müssen. Wir können wahrscheinlich alle diese Parameter in kulturelle und funktionale Kategorien kategorisieren und das Datenmodell um sie herum aufbauen.

Noch ein Gedanke zur Lokalisierung

Lokalisierung ist notwendig, wenn eine globale Marke in lokale Märkte vordringt. Um eine Anwendung zu lokalisieren, betrachten Sie das Gesamtbild. Lokalisierung ist mehr als nur technisch perfekte Leistung. Es bedeutet auch, lokale Kulturen, Verhaltensweisen und sogar Denk- und Lebensweisen zu beherrschen.

Was kann noch getan werden, um eine Anwendung lokal anpassbar zu machen? Teilen Sie uns Ihre Gedanken in den Kommentaren mit.