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

Language-Pool mit Confluence

Problembeschreibung

Bei der Entwicklung von meh­re­ren Plugins kann es vor­kom­men, dass Texte mehr­fach über­setzt wer­den müs­sen, wodurch somit Redundanzen ent­ste­hen. Der Ursprung liegt dann bei Atlassian Confluence, wel­ches das Sharen von i18n-keys über die ver­schie­de­nen Plugins hin­weg nicht ermöglicht.

Beispielhaft soll dies am fol­gen­dem Szenario erläu­tert werden:

Angenommen man hat ein Plugin X ent­wi­ckelt und in ihm den i18n-key manager.user.email defi­niert. Zusätzlich exis­tiert ein Plugin Y, dass Plugin X um wei­tere Funktionalität ergänzt und eine neue vm anlegt, die eben auch den i18n-key manager.user.email ver­wen­den soll. Nun gibt es das Plugin-Konzept von Confluence nicht her auf die in den pro­per­ties defi­nier­ten Texte von Plugin X zuzu­grei­fen. Dies bedeu­tet, dass der Key auch im Plugin Y hin­ter­legt wer­den muss. Folglich ergibt sich ein erhöh­ter Pflegeaufwand.

Info!
Die harte Trennung von Atlassian Confluence ist ein­leuch­tend, da die Plugins unter­ein­an­der aut­ark funk­tio­nie­ren sol­len. Es gibt aber auch Fälle, in denen dies hin­der­lich ist.

Problemlösung

Info!
Die fol­gende Erklärung zielt auf die Nutzung eines ein­zel­nen Plugins ab. Es ist natür­lich auch mög­lich für die ein­zel­nen Sprachen sepa­rate Plugins (wie Confluence Standard) zu führen.

Damit Redundanzen besei­tigt wer­den kön­nen, müs­sen die i18n-keys zen­tral abge­legt wer­den. Dazu kann man einen bestimm­ten Plugintyp von Confluence – das Sprachplugin – nutzen.

Achtung!
Das Sprachplugin kann meh­rere Sprachen reprä­sen­tie­ren. Wichtig ist, dass die in der atlassian-plugin.xml kon­fi­gu­rier­ten Sprachen (Kombination aus lan­guage und coun­try) nur ein­mal im System auftreten.

Diese Erkenntnis ist wich­tig, da für die Lösung des oben genann­ten Problems, es not­wen­dig ist, die Standard Sprachplugins von Confluence zu deinstal­lie­ren und die darin ent­hal­te­nen pro­perty Dateien in das neue SprachPlugin zu überführen.

Außerdem muss die atlassian-plugin.xml des Sprachplugins, wie folgt ange­passt werden.

<language name="German" key="de_DE" language="de" country="DE">

   <resource name="de_DE.png" type="download"
      location="templates/languages/de_DE/de_DE.png">
      <property key="content-type" value="image/png"/>
   </resource>
 </language>

<language name="Spain" key="es_ES" language="es" country="ES">
   <resource name="es_ES.png" type="download"
       location="templates/languages/es_ES/es_ES.png">

       <property key="content-type" value="image/png"/>
   </resource>
</language>

<resource name="i18n" name="i18n_my_plugin" type="i18n" location="/my_plugin"/>

<!-- Important entry, because you have to add the default
          i18n files to this new plugin -->

<resource name="i18n" name="i18n_default" type="i18n"
     location="/ConfluenceActionSupport"/>

Vielseitige Lösung

Diese Lösungsansatz besei­tigt nicht nur Redundanzen, son­dern bie­tet auch in Kombination mit Maven, eine Möglichkeit meh­rere Varianten einer Pluginlösung tex­tu­ell abzugrenzen.

Beispielhaft soll dies am fol­gen­dem Szenario erläu­tert werden:
Man stelle sich die Situation vor, es exis­tiert ein Plugin X, wel­ches durch einen ein­ge­bau­ten Schalter unter­schied­li­che Workflows abdeckt. Möchte man nun inner­halb die­ses Plugins in Abhängigkeit des aktu­el­len Modus andere Texte ver­wen­den, müs­sen die Keys dupli­ziert oder die vm-Dateien ange­passt werden.

Für die­sen Fall kann man mit­tels Maven trick­sen. Wichtig hier­bei ist eine ein­deu­tige Namenskonvention für die Unterteilung der pro­per­ties vor­zu­neh­men. Beispielsweise kann man die pro­per­ties wie folgt nament­lich abgrenzen:

  • my_plugin.properties
  • my_plugin_typex.properties
  • my_plugin_typey.properties
  • my_plugin_de_DE.properties
  • my_plugin_typex_de_DE.properties
  • my_plugin_typey_de_DE.properties

Ist das gesche­hen, defi­niert man in der atlassian-plugin.xml des LanguagePool-Plugins fol­gende Zeilen:

<resource name="i18n" name="i18n_my_plugin_general" type="i18n"
     location="/my_plugin"/>

<resource name="i18n" name="i18n_my_plugin_specific" type="i18n"
     location="/my_plugin_${TYPE}"/>

Letztlich müs­sen im Eclipse zwei neue Maven Run-Configurations erstellt wer­den, die das ent­spre­chende Goal (Bsp.: package, install oder atlassian-pdk:install) ver­wen­det und im Environment-Tab die Variable TYPE auf typex oder auf typey setzt.

26. Februar 2010
||

Related Posts

Pin It on Pinterest