Mehrsprachige Systeme sind heute der normal Fall. Welche Lösungen aus Applikationssicht gibt es? Die unterschiedlichen Lösungsansätze im Vergleich unter Berücksichtigung der Randbedingung der regional unterschiedlichen Konfiguration der Systeme.

Die meisten Online Shops möchten nicht nur eine Region mit einer einzelnen Sprache ansprechen. Im ideal Fall sind die Grenzkosten für eine weitere Region konstant, es macht daher Sinn den Markt auch auf andere Regionen auszudehnen.

Für die Implementierung von unterschiedlichen Sprachen in ein System gibt es unterschiedlich Methoden. In einem System gibt es immer zwei Arten von Texten.

1. Fixe Texte: Diese Texte sind fix in der Webseite eingebunden. Dies können Beschriftungen für Buttons sein oder Fehlermeldungen. Diese Texte sind typischerweise in einer Konfigurationsdatei gespeichert und müssen nur einmal für alle System übersetzt werden.
2. Dynamische Texte: Diese Texte sind dynamsiche angelegt und verändern sich zum Teil auch über die Zeit. Dies sind meist Texte wie zum Beispiel Produktnamen, Produktbeschreibungen oder einfache Texte wie dieser Artikel. Diese Daten werden überlicherweise in einer Datenbank gespeichert. Diese Texte sind in keinem System gleich und müssen immer übersetzt werden.

Der übliche Ansatz, um den ersten Typ von Texten zu übersetzten, ist die Verwendung von Konfigurationsdateien, die für jede Sprache die Übersetzung beinhaltet und über einen eindeutigen String identifiziert werden kann. Zum Teil wird auch gleich der Englische Text als eindeutigen String verwendet, dadurch muss dann nur noch die Übersetzung angelegt werden.

Bei gewissen Systemen werden auch sogenannte Inline Übersetzungstools angeboten, die das Übersetzen direkt in der Webseite ermöglichen. Das kann die Arbeit bei komplexeren System wesentlich vereinfachen und damit beschleunigen.

Bei der zweiten Art von Texten, den dynamischen Texten, ist die Situation nicht ganz so eindeutig. Es gibt einige unterschiedliche Ansätze wie dies gelöst werden kann.

1. Es wird für jede Spalte, die übersetzt werden soll, eine weitere Spalte für jede Übersetzung angelegt. Wenn eine neue Sprache hinzugefügt wird, muss eine weitere Spalte eingefügt werden mit der entsprechenden Sprache. Weiter werden alle Texte dezentral gespeichert. (Dazu mehr weiter unten.)
2. Eine leichte Abänderung des ersten Ansatzes ermöglicht, dass das eigentlich Datenbankmodell nicht angepasst werden muss, wenn eine neue Sprache hinzukommt. Dabei wird zu jedem Eintrag gespeichert in welcher Sprache das der Eintrag gespeichert worden ist. Dazu wird eine Spalte mit der Sprach ID hinzugefügt.
3. Nun kann der zweite Ansatz noch verbessert werden, in dem alle Sprachabhängigen Felder in eine separate Tabelle ausgelagert werden. Dadurch werden zum Beispiel die Preise (die sind bei allen Sprachen gleich) eines Produktes nicht redundant gespeichert, was beim Lösungsansatz zwei ein Problem ist.
4. Die bisherigen Ansätze haben noch ein Problem: Wenn die Person, welche für die Übersetzung verantwortlich ist, alle Texte auf einen Schlag haben möchte, müssen dies alle einzeln aus den Tabellen zusamengesucht werden. Man könnte nun eine Tabelle anlegen die alle Übersetzungen beinhaltet. Bei den Feldern in welchen die Texte drin standen, werden nur noch die IDs auf die Übersetzung in der neuen Tabelle gespeichert. In der neuen Tabelle existiert, dann für jede ID eine Übersetzung. Damit sind alle Texte die übersetzt werden müssen in einer eigenen Tabelle, wodurch sie ganze einfach ausgelesen werden können.
5. Ein komplett anderer Ansatz wäre das verwenden von einem Multistore System, mit welchen sich die einzelnen Felder für jede Ansicht einzeln lokalisieren lassen. Dabei wird eigentlich immer eine Kopie des Inhalts angelegt (wie im Ansatz 2) allerdings wird gespeichert welche Felder lokalisiert wurden und welche nicht. Leider ist es mit einer solchen Lösung nicht möglich alle Übersetzung zentral aufzurufen, sie müssen alle zusamengesucht werden.