Version: GSB 7Konzeption

Zur Umsetzung der Anforderungen zur Mehrsprachigkeit existieren unterschiedliche Alternativen. Ein in solchen Fällen übliches Standardvorgehen, alle Sprachversionen in einem Dokumenttyp zusammenzufassen, entfällt aus zwei Gründen:

• Es existieren keine mandanten-übergreifend einheitliche Sprachversionen. Neben einsprachigen Webauftritten müssen mit den Dokumenttypen ein Webauftritt beispielsweise in deutsch und englisch während ein anderer Webauftritt in deutsch und spanisch realisiert werden müssen.
• Die Sprachversionen eines Beitrags müssen im Workflow von unterschiedlichen Redakteuren gleichzeitig bearbeitet werden können.

Diese Vorgaben führen dazu, die einzelnen Sprachversionen eines Beitrags in unterschiedlichen Dokumenten verwaltet werden müssen. Somit besteht bei diesem Vorgehen für alle Varianten ein gemeinsamer Nachteil: Die Ressourcenhaltung bzw. die Anzahl der vorhandenen Dokumente steigt mit der Anzahl der eingesetzten Sprachen.

In den folgenden Abschnitten werden auf der Basis der obigen Vorgabe einige interessante Ansätze zur Umsetzung der Mehrsprachigkeit vorgestellt.

Alternative 1

In dieser Variante wird eine Sprache im Wesentlichen durch eine Ordnerhierarchie (Sprachordner) repräsentiert. In jedem "Sprachordner" (z.B. de, en,....) werden die Sitestruktur und die sprachabhängigen Dokumente abgelegt.

Für ein neues Dokument muss jeweils ein gleichnamiges Dokument in den jeweiligen Sprachen in den Sprachordnern ablegt werden.

Bei einer parallel mehrsprachigen Website können sprachunabhängige Dokumente, wie z.B. Navigation in einer separaten Verzeichnisstruktur gespeichert werden.

Vorteile:

• Berechtigungen können auf der Basis von Sprachen vergeben werden, indem z.B. einige Redakteure nur unterhalb des Sprachordners „English“ Rechte besitzen.
• Weitere Sprachen können durch einfaches Hinzufügen von Ordner und Einbinden instantiiert werden.

Nachteile

• Namenskonventionen, die nicht durch das System zugesichert werden (z.B. durch Editoranpassung) bedeuten eine mögliche Fehlerquelle. Dies muss bei der Programmierung der Templates berücksichtigt werden.
• Die Pflege der Site ist für die Redakteure mit Mehraufwand verbunden. Es muss die Ordnerstruktur der einzelnen Sprachvarianten konsistent gehalten werden. Ordner müssen jeweils in allen Sprachen angelegt oder gelöscht werden.
• Eine Konsistenz zwischen den Sprachen kann vom System (ohne Anpassung) nicht sichergestellt werden.

Alternative 2

In der zweiten Alternativen wird die lose bzw. implizite Verbindung der sprachabhängigen Dokumente eines Beitrags, wie sie in der ersten Alternative durch Namenskonventionen vorgegeben wurde, durch eine explizite Überwachung durch das CMS ersetzt. Dies erfolgt durch die Einführung einer Assoziation, welche die einzelnen Sprachversionen des Beitrags miteinander verknüpft.

Bei diesem Ansatz wird zwischen einem Hauptsprachen- und den Nebensprachen-Dokumenten unterschieden. Das Hauptsprachen-Dokument übernimmt die folgenden Aufgaben:

• ist verantwortlich für das Zusammenspiel der Sprachversionen. Beispielsweise werden alle Sprachversionen gelöscht, wenn das Dokument in der Hauptsprache gelöscht wird.
• liefert stets das Dokument Hauptsprache, wenn ein Dokument in einer anderen Sprache noch nicht veröffentlich wurde.
• enthält alle „sprach-unabhängigen“ Metadaten
• enthält alle „sprach-unabhängigen“ strukturellen Links (wie Navigationseinträge usw.).

Ein Nebensprachen-Dokument enthält alle sprachabhängigen inhaltlichen Informationen wie Texte, Bilder oder Downloads.

Vorteile:

• neue Sprachen sind ohne Programmieraufwand durch einen Administrator Mandanten-spezifisch konfigurierbar

Nachteile:

• Es liegen viele Dokumente in einem Ordner und ist daher unübersichtlich. Durch die Kombination mit Alternative 1 können Zugriffsbeschränkungen erzwungen werden, die von der Sprache abhängen.