Sitecore Internationalisierung – Sprachversionen vs. Multisite-Setup

22.10.2015 Miklas Bieberstein

Vor die Aufgabe gestellt, eine Website in mehreren Sprachen auszuliefern, hat man in Sitecore zwei grundlegende Möglichkeiten dies zu realisieren:

1. Sprachversionen

Für diese eher klassische Variante verwendet man die in Sitecore vorgesehene Möglichkeit, die in einem Item gespeicherten Texte eins zu eins zu übersetzen. Hierfür legt man eine neue Version des Items in der entsprechenden Sprache an und trägt die zu übersetzenden Inhalte ein. Dies funktioniert identisch sowohl im Page- als auch im Content-Editor. Voraussetzung dafür ist allerdings, dass die gewünschte Sprache auch im System verfügbar ist. Enthält das Menü für die Sprachauswahl den notwendigen Eintrag nicht, muss die Sprache installiert werden. Dazu begibt man sich vom Sitecore Desktop aus in das Control-Panel, wählt 'Globalization' und anschließend 'Add a New Language'. Es öffnet sich der folgende Dialog:

Abbildung 1: Dialog für die Installation einer weiteren Sprache

In der Liste der vordefinierten Sprachen wird man wahrscheinlich die gewünschte bereits vorfinden. Wenn nicht, lassen sich eigene definieren. Dabei besteht eine Sprachdefinition aus dem eigentlichen Sprachcode und dem Code für das entsprechende Land, die durch einen Bindestrich getrennt werden. Tatsächlich handelt es sich also um die Definition eines Gebietsschemas mit einem sprachlichen und einem geographischen Teil. Die geografischen Codes werden in der ISO 3166, die sprachlichen in der ISO 639 definiert. Die Nomenklatur für die Angabe eines Gebietsschemas wird  ausgiebig in dem RFC 5646 besprochen.

Lokalisierung:
Man muss sich bei der Auslieferung von Inhalten in andere Sprachen darüber im Klaren sein, dass abgesehen von der reinen Übersetzung auch andere Anpassungen an z. B. Datums- und Zahlenformaten vorzunehmen sind. Es wird gerne übersehen, dass die Themen Internationalisierung (I18n) und Lokalisierung (L10n) umfassende Querschnittsbelange sind, deren Umsetzung definitiv nicht trivial ist. Insbesondere bei schon existierenden Projekten, die nachträglich um weitere Sprachen ergänzt werden sollen, kann dies zu unerwarteten Problemen führen. Ein Beispiel aus unserer Sitecore Praxis.
 
Beispiel:
Für einen Kunden wurde eine Website erstellt, die initial nur in Deutsch verfügbar sein sollte. Die Implementierung wurde von der IT vorgenommen, die Inhalte wurden von externen Redakteuren erstellt. Alles gut soweit. Nach erfolgreichem Launch äußerte der Kunde den Wunsch, die Website nun auch in Französisch und Italienisch betreiben zu wollen. Kein Problem – prinzipiell. Was niemand bis dahin bemerkt hatte, war allerdings, dass alle Inhalte in der Sitecore Standardsprache, also Englisch, eingepflegt worden waren. Die gesamte Website war also eigentlich eine englische Version mit deutschen Inhalten. Aufgrund des Umfangs der Website kam eine manuelle Korrektur nicht in Frage. Was also tun? Die Aufgabe bestand darin, für alle Items eine deutsche Version anzulegen, die Inhalte aus der englischen Version in die deutsche zu verschieben und die englische Version anschließend zu löschen. Nach einigen Nachforschungen war klar, dass Sitecore diesen Vorgang von Hause aus nicht unterstützt. Auch die Suche nach entsprechenden Modulen erbrachte nur Teillösungen. Kurzerhand war also die Idee geboren, Sitecore entsprechend zu erweitern und die benötigten Funktionen selbst zu implementieren. Und dabei eine wiederverwendbare Lösung zu implementieren, die Bestandteil des Cocomore Sitecore Werkzeugkastens werden sollte:
 
Abbildung 2: Cocomore Ribbon-Gruppe mit Language Tools

Die Praxis bei der Arbeit mit mehreren Sprachen hat gezeigt, dass vor der Bearbeitung nicht die richtige Sprache ausgewählt zu haben und somit Inhalte in einer falschen Sprachversion eingegeben zu haben, eine häufige Fehlerquelle darstellt. Somit war die Entscheidung für eine Integration in das Sitecore Ribbon doppelt richtig. Die Cocomore 'Language Tools' bieten die Möglichkeit, Inhalte von einer Sprache in eine andere zu kopieren oder zu verschieben. Und das rekursiv ab dem ausgewählten Item! Das war also die Lösung, um unsere englisch-deutsche Website mit ein paar Klicks wieder auf Kurs zu bringen.

Zurück zur Internationalisierung:                                                                                         Wenn also die gewünschte Sprache im System verfügbar ist, gilt es, sich mit den selbst erstellten Templates zu beschäftigen. Erst wenn man mit mehreren Sprachen arbeitet, erkennt man die wirkliche Bedeutung von 'shared' Feldern, deren Inhalte zwischen den Sprachen geteilt werden. Arbeitet man nur in einer Sprache, wird man wahrscheinlich zu viel oder zu wenig geteilte, also sprachunabhängige Felder in seinen Templates haben. Nur merkt man davon nichts. Nun verdient diese Einstellung ein besonderes Augenmerk beim Anlegen neuer Felder. Sind Checkboxen noch unproblematisch, stellt sich bei Grafiken durchaus die Frage, ob alle Sprachen dieselbe Version teilen werden. Wird in der Grafik Text enthalten sein? Im Zweifel muss man sich für eine sprachspezifische Speicherung entscheiden, auch wenn dadurch eventuell nur Redundanz erzeugt wird. Ebenso beachten muss man die Standardwerte und diese gegebenenfalls übersetzen.

Apropos: Natürlich muss dann auch noch die gesamte Site in die verschiedenen Sprachen übersetzt werden. Sitecore bietet hierfür die sehr praktische 'Translate' Ansicht, in der die Felder nebeneinander angezeigt werden. So kann man gut überprüfen, dass auch wirklich alles übersetzt worden ist:

Abbildung 3: Aktivierung der Übersetzungs-Ansicht im Sitecore Ribbon

Aber bevor man sich nun voller Eifer an die eigentliche Übersetzung der Website macht, sollte man unbedingt überprüfen, ob diese Variante der Internationalisierung auch wirklich alle Anforderungen des Kunden unterstützt. Eignet sich die direkte Übersetzung der Items gut für Szenarien, in denen es  nur darum geht, z. B. eine Unternehmenswebsite in verschiedenen Sprachen darzustellen, ist ein wirklich internationaler Auftritt einer Marke, mit jeweils marktspezifischen Besonderheiten in den einzelnen Ländern, auf diesem Wege nicht zu realisieren. Als Orientierung bei der Entscheidungsfindung sollte man sich fragen, ob zwischen den einzelnen Sites strukturelle Unterschiede auftreten werden. Unterscheiden sich Navigation und Anzahl der Seiten und verwenden diese vielleicht sogar jeweils spezielle Templates? Dann sollte die Entscheidung klar für die zweite Variante der Internationalisierung in Sitecore fallen.

2. Multisite-Setup

Bei einem Multisite-Setup erhält jede Sprache ihr eigenes Home-Item. Es empfiehlt sich, anstelle des klassischen Sitecore Home-Item Templates, ein eigenes Template zu erstellen, das kein Layout besitzt, sondern die globalen Einstellungen und Inhalte für die jeweilige Site enthält. Hier lassen sich gut Dinge wie Google Analytics Code und andere Konfigurationen zentral unterbringen, ohne das eigentliche Home-Item mit Informationen zu überfrachten. Unterhalb dieses Site-Items kann dann die Struktur der jeweiligen Website angesiedelt werden. Und das natürlich völlig unabhängig von den anderen Sprachen. Hat man bereits eine existierende Website und möchte diese um weitere Sprachen ergänzen, empfiehlt es sich, auf der Basis der existierenden Struktur ein Branching-Template zu erstellen. So hat man eine gute Ausgangsbasis um neue Sprachversionen hinzuzufügen und diese dann strukturell anzupassen und natürlich – zu übersetzen.

Wie findet Sitecore nun die richtige Sprachversion? Das Multisite Setup ist im Grunde von der eigentlichen Internationalisierung unabhängig, bietet aber die perfekten Voraussetzungen, um ein internationales Szenario umzusetzen. Die Identifikation der einzelnen Sites erfolgt dabei auf demselben Wege, wie  die ursprüngliche Website. Hierzu legt man eine Datei mit z. B. dem Namen 'sites.config' im 'App_Config\includes' Verzeichnis an und definiert dort die zusätzlichen Sites. Die eigentliche Sitecore Standard 'website' Definition befindet sich in der web.config Datei. Es gehört zur guten Praxis, diese Datei unangetastet zu lassen und stattdessen mit den zusätzlichen Dateien im 'include' Verzeichnis zu arbeiten. Die sich hier befindenden Konfigurationen werden mit den Einstellungen in der web.config Datei von Sitecore zusammengefügt. Um sich das effektive Ergebnis anzusehen, und so auch zu überprüfen, ob die vorgenommene Konfiguration auch funktionieren wird, existiert eine spezielle Admin-URL:

http://www.example.com/sitecore/admin/showconfig.aspx

In der zuvor angelegten Datei 'sites.config' definiert man nun die neuen Sites:

Wichtig ist das 'patch:before' Attribut. Die Standard Sitecore Website muss als letztes in der Konfiguration erscheinen. Praktisch ist das 'inherits' Attribut. Damit lassen sich globale Belange, wie z. B. Einstellungen für das Caching zentral konfigurieren und an die weiteren Sites vererben.

Mit dem 'rootPath' Attribut schließlich, gibt man den Pfad zum jeweiligen Site-Item an. Erst mit dem 'startItem' Attribut sagt man Sitecore, wo es dann tatsächlich mit dem Inhalt losgeht. Diese Einstellung ist relativ zum 'rootPath'.

Natürlich müssen diese Bindungen auch im IIS konfiguriert sein, damit er die Anfragen richtig an die Sitecore-Instanz weiterleitet. Das wichtigste Attribut ist daher der 'hostName'. Hier sind auch Wildcards zulässig, sodass www.example.de und example.de gefunden werden. Sitecore vergleicht die 'hostName' Attribute der einzelnen Sites mit dem 'Host' Wert des Anfrage-Headers, um das passende Home-Item zu finden. Die Sprachumstellung findet dabei ganz automatisch anhand des 'language' Attributs statt, es ist also keine umständliche Parameterübergabe notwendig.

 

---------------

 

So, das war ein kleiner Ausflug in die Welt der Internationalisierung mit Sitecore anhand von praktischen Erfahrungen aus der wirklichen Welt. Demnächst mehr.