Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden

Mehrsprachige Inhalte in Confluence

Vor allem wenn Confluence in gro­ßen, inter­na­tio­na­len Konzernen ein­ge­führt wer­den soll, kommt immer wie­der die Anforderung Mehrsprachigkeit der Inhalte auf: im Wiki abge­legte Informationen sol­len in ver­schie­de­nen Sprachen für die Mitarbeiter aus ver­schie­de­nen Ländern ver­füg­bar sein. Dazu sind eine Kennzeichnung der Inhaltssprache, Funktionalitäten zum Wechseln zwi­schen den Inhaltssprachen und Bearbeiten der Sprachvarianten und natür­lich eine Auswertung in der Suche erfor­der­lich. Die Unterstützung des Übersetzungsprozess wird hin­ge­gen meist nicht benötigt.

Wie kann man diese Anforderung in Confluence realisieren?

Leider bie­tet Confluence im Standard kei­ner­lei Unterstützung für mehr­spra­chige Inhalte, auch wenn die­ses Feature von vie­len Atlassian Kunden gewünscht wird.

Also muss man sich ander­wei­tig über Plugins und Macros behel­fen. Dabei sind fol­gende Lösungsansätze denk­bar, von denen ich die bei­den ers­ten nach­fol­gend detail­lier­ter beschriebe.

  1. Pflege und Anzeige der Sprachvarianten in einer Wikiseite
  2. Pflege und Anzeige der Sprachvarianten in sepa­ra­ten Wikiseiten in sepa­ra­ten Bereichen
  3. Pflege und Anzeige der Sprachvarianten in sepa­ra­ten Wikiseiten im glei­chen Bereich

Pflege und Anzeige der Sprachvarianten in einer Wikiseite

In einer Wikiseite wer­den alle ver­füg­ba­ren Sprachvarianten eines Inhalts gepflegt und auch in die­ser Seite (geeig­net von­ein­an­der sepa­riert) ange­zeigt. Vorteil die­ses Ansatzes ist die „Nähe“ der Sprachvarianten und die sich dar­aus erge­bende leich­tere und fle­xi­blere Nutzbarkeit mehr­spra­chi­ger Inhalte. Nachteil der Lösung sind die rela­tiv unüber­sicht­li­che 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 sprach­lich vermischt.

Dennoch bie­tet sich die­ser Lösungsansatz für die Übersetzung weni­ger, aus­ge­wähl­ter Inhaltspassagen sehr gut an. In einem Bereich wer­den bei­spiels­weise alle Inhalte deutsch­spra­chig hin­ter­legt. Auf der Bereichsstartseite wird aber eine kurze Beschreibung des Bereiches mehr­spra­chig abge­legt, umso allen Lesern des Bereichs zumin­dest einen Überblick über den Bereich zu geben.

Dies kann bei­spiels­weise über das ganz frisch ver­öf­fent­lichte und viel ver­spre­chende lan­guage Plugin rea­li­siert wer­den. Es ist frei ver­füg­bar. Beim Bearbeiten des mehr­spra­chi­gen Inhalts wer­den die Sprachvarianten über Macros gekenn­zeich­net, dem Nutzer wird dann nur eine Sprachvariante ent­spre­chend sei­ner Confluence Systemsprache angezeigt.

Atlassian beschreibt einen ähn­li­chen Ansatz über das Visibility Plugin. Wieder wer­den die Sprachvarianten in einer Seite über Macros gekenn­zeich­net, die ange­ben für wel­che Nutzergruppe der Inhalt ange­zeigt wer­den soll. Wenn die Nutzer ent­spre­chend ihrer gewünsch­ten Inhaltssprache den Gruppen zuge­ord­net sind, wer­den über das Plugin nur die Inhalte in der rich­ti­gen Sprachvariante sicht­bar gemacht. Dieser Workarround erfor­dert aber sehr viel admi­nis­tra­ti­ven Aufwand beim Pflegen der Berechtigungen und der Nutzergruppen.

Nachteil bei bei­den Ansätzen ist außer­dem die feh­lende Möglichkeit auf die Inhalte in einer ande­ren Sprache zuzu­grei­fen. Damit kön­nen die Nutzer die Konsistenz und Aktualität von Übersetzungen nur schwer beurteilen.

Dieses Problem löst zum Beispiel das kos­ten­pflich­tige Plugin Confluence Content Internationalizer. Wie in den zuvor beschrie­be­nen Ansätzen auch wer­den die Sprachvarianten über Macros gekenn­zeich­net, das Plugin zeigt dann bestimmte Sprachvarianten in Tabreitern an.

Diese Lösungsidee kann auch über das frei ver­füg­bare Composition Plugin (Macro „deck“) abge­bil­det wer­den. Über rela­tiv kom­plexe Macrosyntax wer­den Reiter, die die Sprachvarianten beinhal­ten, defi­niert. Diese Reiter zei­gen alle Sprachvarianten an und erlau­ben ein Umschalten zwi­schen ihnen.

Um die Pflege der ein­zel­nen Sprachvarianten in den Tabreitern zu ver­ein­fa­chen und um den Nutzer die für pas­sende Sprachvariante vor­aus­zu­wäh­len, haben wir in einem Kundenprojekt ein Plugin ent­wi­ckelt. Auch hier wer­den über Macros Sprachvarianten gekenn­zeich­net, die dann in Tabreitern ange­zeigt wer­den. Standardmäßig wird der Tabreiter in der Anwendungssprache des Nutzers vor­ausge­wählt.  Auf alle wei­te­ren Tabreiter kön­nen die Nutzer zugrei­fen. Der Screenshot oben stammt aus die­sem Plugin.

Pflege und Anzeige der Sprachvarianten in sepa­ra­ten Wikiseiten in sepa­ra­ten Bereichen

Im Gegensatz zum zuvor beschrie­be­nen Ansatz wer­den die Sprachvarianten nicht in einer Wikiseite zusam­men­ge­fasst, son­dern es wird jede Sprachvariante in einer eige­nen Seite in einem sepa­ra­ten Bereich abge­legt. Diese Bereiche fas­sen dann alle Inhalte einer Inhaltssprache zusam­men. Zwischen den Sprachvarianten wer­den auto­ma­ti­siert Verlinkungen zum Umschalten der Inhaltssprache angezeigt.

Diese Lösung haben wir für einen Kunden ent­wi­ckelt, bei dem aus­ge­wählte Teams, wie die HR- und IT-Abteilung des Konzerns alle Informationen mehr­spra­chig zur Verfügung stellen.

Dabei hat sich als vor­teil­haft her­aus­ge­stellt, dass die Sprachvarianten klar getrennt sind, die Seitentitel und die Verlinkungen in der „rich­ti­gen“ Sprache erstellt wer­den kön­nen und auch Schlagworte und Kommentare nicht sprach­lich gemischt werden.

Allerdings muss  ins­be­son­dere auf die unter­schied­li­che Seitenstruktur, die sich in den Bereichen mit eigent­lich glei­chem Inhalt ergibt, geach­tet wer­den. Außerdem zeigte sich, dass zwei Bereiche, die jeweils deutsch- / eng­lisch­spra­chige Inhalte zusam­men­fas­sen, häu­fig eine glei­che Bereichsbezeichnung haben. Damit ist die Unterscheidbarkeit die­ser 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 rela­tiv gut nach­ge­baut wer­den kann. Allerdings sind diese Lösungen nicht rich­tig in Confluence inter­giert, was sich inbe­son­dere in der Usability und in der rela­tiv kom­ple­xen Nutzbarkeit zeigt. Eine echte Mehrsprachigkeit der Inhalte kann eigent­lich nur aus Confluence selbst kom­men. Das erfor­dert aber sicher­lich umfang­rei­chere Änderungen an den Confluence Datenstrukturen.

Eine gute Usability und leichte Nutzbarkeit sind Schlüsselanforderungen, damit Nutzer die Hürde mehr­spra­chige Inhalte zu pfle­gen über­win­den. Ich selbst kenne kei­nen Lösungsansatz für mehr­spra­chige Inhalte, der für mög­lichst viele Anwendungsfälle passt und alle Anforderungen erfüllt. Ich würde mich daher sehr über Ihre Erfahrungsberichte zu mehr­spra­chi­gen Inhalten in Confluence freuen. Wo sehen Sie Vor- und Nachteile? Gibt es noch wei­tere Lösungsansätze, die ich hier nicht auf­ge­lis­tet habe?

Related Posts

Hallo Judith,

sehr guter Artikel. Wir ver­fol­gen bei uns ein ähn­li­ches Konzept. Daher inter­es­sant und gut zu sehen, dass andere unab­hän­gig auf ähn­li­che Lösungen sto­ßen. 🙂 Es hat sich bei uns (bei Euch wohl auch), dass die Verwendung von Seitentitel als Referenzen bei kom­ple­xe­ren Anforderungen wie die­sen eine Limitierung darstellt.

Zudem ist span­nend, wie die Übersetzung zum Wiki-Prinzip passt - z.B.
* Was pas­siert mit der Übersetzung wenn der Artikel in der Original-Sprache erwei­tert wird?
* Soll die Übersetzung mög­lichst nah an der Original-Sprache sein, oder ver­folgt man mit der Übersetzung auch den Wiki-Ansatz und lässt die Benutzer selbst über­set­zen? (crowd-sourcing)

Anmerkungen zur Implementierung:
* Als Alternative sehe ich noch, par­al­lele Bäume inner­halb eines Spaces zu definieren.
* Wenn die Seitentitel für alles Sprachen gleich sind ließe sich das SpaceJump Macro anwen­den (Teil des Documentation-Themes). Oder das Space-Jump Macro könnte erwei­tert werden.

Viele Grüße,
-Stefan

Der Artikel gibt gute Hinweise zur Mehrsprachigkeit von WIKI-Seiten. Vielen Dank dafür.
Auch wir den­ken dar­über nach, con­fluence für die Publikation unse­rer mehr­spra­chi­gen Dokumentationen zu ver­wen­den. Ich habe jedoch noch kei­nen prak­ti­ka­blen Weg gefun­den, wie man eine deutsch­spra­chi­ges Handbuch, das ggf. aus einer rela­tiv gro­ßen Anzahl von WIKI-Seiten besteht, aus con­fluence 4.3 zu expor­tie­ren, dann die Dateien zu über­set­zen und im Anschluss das Ergebnis wie­der in con­fluence zu impor­tie­ren. Die eng­li­sche Version der Online-Doku müsste im Anschluss natür­lich genau so als Seitenstruktur funk­tio­nie­ren und for­ma­tiert sein wie das deut­sche Original. Habe ich etwas übersehen?

Das Einzige, was funk­tio­niert, ist die Verwendung einer ein­zel­nen Datei: Inhalt des HTML-Editors der WIKI-Seite kopie­ren, über­set­zen und dann den XHTML-Code in den HTML-Editor einer neuen Seite ein­fü­gen. Aber das ist natür­lich für einen kom­ple­xe­ren Übersetzungsworkflow nicht akzep­ta­bel. Über Hinweise aller Art würde ich mich freuen.
Uwe

ich bin auch auf der Suche nach der Möglichkeit eine mul­ti­l­in­guale Wiki mit Confluence zu erstel­len. Bis dato habe ich aber keine öffent­li­che Wiki mit min. 2 Sprachen fin­den können.

Könnte viel­leicht jemand ein oder zwei Links zur Verfügung stellen.?

Viele Grüße
Dursun

Comments are closed.

Pin It on Pinterest