Vor allem wenn Confluence in großen, internationalen Konzernen eingeführt werden soll, kommt immer wieder die Anforderung Mehrsprachigkeit der Inhalte auf: im Wiki abgelegte Informationen sollen in verschiedenen Sprachen für die Mitarbeiter aus verschiedenen Ländern verfügbar sein. Dazu sind eine Kennzeichnung der Inhaltssprache, Funktionalitäten zum Wechseln zwischen den Inhaltssprachen und Bearbeiten der Sprachvarianten und natürlich eine Auswertung in der Suche erforderlich. Die Unterstützung des Übersetzungsprozess wird hingegen meist nicht benötigt.
Wie kann man diese Anforderung in Confluence realisieren?
Leider bietet Confluence im Standard keinerlei Unterstützung für mehrsprachige Inhalte, auch wenn dieses Feature von vielen Atlassian Kunden gewünscht wird.
Also muss man sich anderweitig über Plugins und Macros behelfen. Dabei sind folgende Lösungsansätze denkbar, von denen ich die beiden ersten nachfolgend detaillierter beschriebe.
- Pflege und Anzeige der Sprachvarianten in einer Wikiseite
- Pflege und Anzeige der Sprachvarianten in separaten Wikiseiten in separaten Bereichen
- Pflege und Anzeige der Sprachvarianten in separaten Wikiseiten im gleichen Bereich
Pflege und Anzeige der Sprachvarianten in einer Wikiseite
In einer Wikiseite werden alle verfügbaren Sprachvarianten eines Inhalts gepflegt und auch in dieser Seite (geeignet voneinander separiert) angezeigt. Vorteil dieses Ansatzes ist die „Nähe“ der Sprachvarianten und die sich daraus ergebende leichtere und flexiblere Nutzbarkeit mehrsprachiger Inhalte. Nachteil der Lösung sind die relativ unübersichtliche Pflege der Sprachvarianten, sowie die Einsprachigkeit der Seitentitel und Links. Das wirkt sich bei der Suche und bei der Navigation in Confluence aus. Außerdem sind Kommentare und Schlagworte sprachlich vermischt.
Dennoch bietet sich dieser Lösungsansatz für die Übersetzung weniger, ausgewählter Inhaltspassagen sehr gut an. In einem Bereich werden beispielsweise alle Inhalte deutschsprachig hinterlegt. Auf der Bereichsstartseite wird aber eine kurze Beschreibung des Bereiches mehrsprachig abgelegt, umso allen Lesern des Bereichs zumindest einen Überblick über den Bereich zu geben.
Dies kann beispielsweise über das ganz frisch veröffentlichte und viel versprechende language Plugin realisiert werden. Es ist frei verfügbar. Beim Bearbeiten des mehrsprachigen Inhalts werden die Sprachvarianten über Macros gekennzeichnet, dem Nutzer wird dann nur eine Sprachvariante entsprechend seiner Confluence Systemsprache angezeigt.
Atlassian beschreibt einen ähnlichen Ansatz über das Visibility Plugin. Wieder werden die Sprachvarianten in einer Seite über Macros gekennzeichnet, die angeben für welche Nutzergruppe der Inhalt angezeigt werden soll. Wenn die Nutzer entsprechend ihrer gewünschten Inhaltssprache den Gruppen zugeordnet sind, werden über das Plugin nur die Inhalte in der richtigen Sprachvariante sichtbar gemacht. Dieser Workarround erfordert aber sehr viel administrativen Aufwand beim Pflegen der Berechtigungen und der Nutzergruppen.
Nachteil bei beiden Ansätzen ist außerdem die fehlende Möglichkeit auf die Inhalte in einer anderen Sprache zuzugreifen. Damit können die Nutzer die Konsistenz und Aktualität von Übersetzungen nur schwer beurteilen.
Dieses Problem löst zum Beispiel das kostenpflichtige Plugin Confluence Content Internationalizer. Wie in den zuvor beschriebenen Ansätzen auch werden die Sprachvarianten über Macros gekennzeichnet, das Plugin zeigt dann bestimmte Sprachvarianten in Tabreitern an.
Diese Lösungsidee kann auch über das frei verfügbare Composition Plugin (Macro „deck“) abgebildet werden. Über relativ komplexe Macrosyntax werden Reiter, die die Sprachvarianten beinhalten, definiert. Diese Reiter zeigen alle Sprachvarianten an und erlauben ein Umschalten zwischen ihnen.
Um die Pflege der einzelnen Sprachvarianten in den Tabreitern zu vereinfachen und um den Nutzer die für passende Sprachvariante vorauszuwählen, haben wir in einem Kundenprojekt ein Plugin entwickelt. Auch hier werden über Macros Sprachvarianten gekennzeichnet, die dann in Tabreitern angezeigt werden. Standardmäßig wird der Tabreiter in der Anwendungssprache des Nutzers vorausgewählt. Auf alle weiteren Tabreiter können die Nutzer zugreifen. Der Screenshot oben stammt aus diesem Plugin.
Pflege und Anzeige der Sprachvarianten in separaten Wikiseiten in separaten Bereichen
Im Gegensatz zum zuvor beschriebenen Ansatz werden die Sprachvarianten nicht in einer Wikiseite zusammengefasst, sondern es wird jede Sprachvariante in einer eigenen Seite in einem separaten Bereich abgelegt. Diese Bereiche fassen dann alle Inhalte einer Inhaltssprache zusammen. Zwischen den Sprachvarianten werden automatisiert Verlinkungen zum Umschalten der Inhaltssprache angezeigt.
Diese Lösung haben wir für einen Kunden entwickelt, bei dem ausgewählte Teams, wie die HR- und IT-Abteilung des Konzerns alle Informationen mehrsprachig zur Verfügung stellen.
Dabei hat sich als vorteilhaft herausgestellt, dass die Sprachvarianten klar getrennt sind, die Seitentitel und die Verlinkungen in der „richtigen“ Sprache erstellt werden können und auch Schlagworte und Kommentare nicht sprachlich gemischt werden.
Allerdings muss insbesondere auf die unterschiedliche Seitenstruktur, die sich in den Bereichen mit eigentlich gleichem Inhalt ergibt, geachtet werden. Außerdem zeigte sich, dass zwei Bereiche, die jeweils deutsch- / englischsprachige Inhalte zusammenfassen, häufig eine gleiche Bereichsbezeichnung haben. Damit ist die Unterscheidbarkeit dieser Bereiche, etwa in der Suchergebnisliste oder beim Erstellen von Verlinkungen nicht mehr gegeben.
Fazit
Abschließend kann man sagen, dass mit Hilfe von Macros und Confluence Erweiterungen eine Mehrsprachigkeit der Inhalte relativ gut nachgebaut werden kann. Allerdings sind diese Lösungen nicht richtig in Confluence intergiert, was sich inbesondere in der Usability und in der relativ komplexen Nutzbarkeit zeigt. Eine echte Mehrsprachigkeit der Inhalte kann eigentlich nur aus Confluence selbst kommen. Das erfordert aber sicherlich umfangreichere Änderungen an den Confluence Datenstrukturen.
Eine gute Usability und leichte Nutzbarkeit sind Schlüsselanforderungen, damit Nutzer die Hürde mehrsprachige Inhalte zu pflegen überwinden. Ich selbst kenne keinen Lösungsansatz für mehrsprachige Inhalte, der für möglichst viele Anwendungsfälle passt und alle Anforderungen erfüllt. Ich würde mich daher sehr über Ihre Erfahrungsberichte zu mehrsprachigen Inhalten in Confluence freuen. Wo sehen Sie Vor- und Nachteile? Gibt es noch weitere Lösungsansätze, die ich hier nicht aufgelistet habe?
Hallo Judith,
sehr guter Artikel. Wir verfolgen bei uns ein ähnliches Konzept. Daher interessant und gut zu sehen, dass andere unabhängig auf ähnliche Lösungen stoßen. 🙂 Es hat sich bei uns (bei Euch wohl auch), dass die Verwendung von Seitentitel als Referenzen bei komplexeren Anforderungen wie diesen eine Limitierung darstellt.
Zudem ist spannend, wie die Übersetzung zum Wiki-Prinzip passt - z.B.
* Was passiert mit der Übersetzung wenn der Artikel in der Original-Sprache erweitert wird?
* Soll die Übersetzung möglichst nah an der Original-Sprache sein, oder verfolgt man mit der Übersetzung auch den Wiki-Ansatz und lässt die Benutzer selbst übersetzen? (crowd-sourcing)
Anmerkungen zur Implementierung:
* Als Alternative sehe ich noch, parallele Bäume innerhalb eines Spaces zu definieren.
* Wenn die Seitentitel für alles Sprachen gleich sind ließe sich das SpaceJump Macro anwenden (Teil des Documentation-Themes). Oder das Space-Jump Macro könnte erweitert werden.
Viele Grüße,
-Stefan
Der Artikel gibt gute Hinweise zur Mehrsprachigkeit von WIKI-Seiten. Vielen Dank dafür.
Auch wir denken darüber nach, confluence für die Publikation unserer mehrsprachigen Dokumentationen zu verwenden. Ich habe jedoch noch keinen praktikablen Weg gefunden, wie man eine deutschsprachiges Handbuch, das ggf. aus einer relativ großen Anzahl von WIKI-Seiten besteht, aus confluence 4.3 zu exportieren, dann die Dateien zu übersetzen und im Anschluss das Ergebnis wieder in confluence zu importieren. Die englische Version der Online-Doku müsste im Anschluss natürlich genau so als Seitenstruktur funktionieren und formatiert sein wie das deutsche Original. Habe ich etwas übersehen?
Das Einzige, was funktioniert, ist die Verwendung einer einzelnen Datei: Inhalt des HTML-Editors der WIKI-Seite kopieren, übersetzen und dann den XHTML-Code in den HTML-Editor einer neuen Seite einfügen. Aber das ist natürlich für einen komplexeren Übersetzungsworkflow nicht akzeptabel. Über Hinweise aller Art würde ich mich freuen.
Uwe
ich bin auch auf der Suche nach der Möglichkeit eine multilinguale Wiki mit Confluence zu erstellen. Bis dato habe ich aber keine öffentliche Wiki mit min. 2 Sprachen finden können.
Könnte vielleicht jemand ein oder zwei Links zur Verfügung stellen.?
Viele Grüße
Dursun