Sitecore Internationalisierung – Sprachversionen vs. Multisite-Setup
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:
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.
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:
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:
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.