i18n in Magnolia 5

Die Internationalisierung (Übersetzung statischer Texte) wird in Magnolia 5 etwas anders gehandhabt als in den vorhergehenden Versionen. In diesem Beitrag möchte ich auf die Unterschiede eingehen und einige Details vorstellen.

Verwendung von i18n
Internationalisierung wird in Magnolia hauptsächlich in folgenden Bereichen benötigt:

  • Übersetzung von Bezeichnungen und Beschreibungen in Dialogen (bzw. allgemein im Admincentral)
  • Statische (d.h. nicht als Inhalt verwaltete) Texte in Templates

Neuerungen

Basename entfällt
In den Versionen vor Magnolia 5 musste zu jedem Label-Key auch ein „basename“ angegeben werden. Damit wurde der „Scope“ des Keys festgelegt. Innerhalb eines „basename-scopes“ mussten die Keys eindeutig sein.
Der „basename“ wurde oft verwendet, um die Übersetzungen auf Modul-Ebene voreinander abzukapseln, d.h. um gleichnamige Keys in verschiedenen Modulen möglich zu machen.

Neu ist die Verwendung des Basenames als deprecated gekennzeichnet. Zumindest in der jetzt aktuellen Version 5.2. steht aber noch die gesamte bisherige Funktionalität des basenames zur Verfügung und wird auch von Magnolia selbst in einigen Teilen verwendet (z.B. in STK Dialogen).

Durch das Wegfallen des Basenames können keine „Scopes“ mehr geschaffen werden. Um „Key-Kollisionen“ zu vermeiden, braucht es eine entsprechende Naming-Konvention für die Keys (z.B. der Modul-Name als Prefix). Das lässt sich einfach bewerkstelligen und wurde vermutlich bereits zu „basename“-Zeiten in den meisten Projekten eingehalten. Wahrscheinlich war das auch der Grund, weshalb Magnolia den Basename abgeschafft hat.

Die Property-Files mit den Übersetzungen müssen dementsprechend auch nicht mehr in einem dem Basename entsprechenden Ordner abgelegt werden. Neu werden alle auf „.properties“ endende Dateien im Ordner „mgnl-i18n“ als Übersetzungen geladen. Man kann pro Sprache auch mehrere Files anlegen, was eine bessere Strukturierung erlaubt als früher, wo pro Sprache nur eine Datei möglich war.

Nachteil der neuen Strategie: wird ein Key mehr als einmal definiert, wird er entsprechend der Lade-Reihenfolge von der letzten Definition überschrieben. Gleichzeitig kann das aber für gewisse Fälle auch ein gewolltes Verhalten sein.

Key-Erzeugung
In den Versionen vor Magnolia 5 musste bei den Dialog-Definitionen immer explizit ein Key für die übersetzbaren Texte (üblicherweise „label“ und „description“) hinterlegt werden. Andernfalls wurde nichts angezeigt.

Neu wird in solchen Fällen ein Key erzeugt. Dieser wird jedoch nicht in der Dialog-Definition abgelegt sondern „on-the-fly“ generiert. Technisch wurde das so gelöst, dass die Dialog-Definitionen „dekoriert“ werden, d.h. es wird ein dynamischer Proxy erstellt, welcher die entsprechenden Methodenaufrufe (typischerweise „getLabel“ und „getDescription“) modifiziert (interception). Falls die ursprüngliche Methode „null“ zurückliefert, wird ein Key erzeugt. Der Proxy übernimmt auch gleich die Übersetzung des Keys, so dass ein Aufruf der modifizierten Methoden direkt den übersetzten Text liefert, falls ein solcher vorhanden ist. Andernfalls wird der Key angezeigt.

Die „i18n-Dekoration“ der Dialog-Definitionen wird in den Presenter-Klassen (z.B. BaseDialogPresenter) mittels eines „i18nizer“s vorgenommen.
Durch diesen Mechanismus gibt es jetzt in den Dialogen garantiert keine leeren Bezeichnungen mehr. Es fällt auch sofort auf, wenn ein Label bzw. dessen Übersetzung fehlt.

Wer nun die ganze Arbeit den neuen Key-Generatoren überlassen möchte, muss berücksichtigen, dass die Key-Erzeugung unter Umständen nicht wie gewünscht funktioniert:
Falls Dialoge erweitert werden und sowohl der Basis-Dialog wie auch der erweiterte Dialog keine Keys definieren, werden die Keys des Basis-Dialogs zweimal generiert: einmal für den Basis-Dialog und einmal für die Erweiterung, aber jeweils unterschiedlich. Beispiel:

baseDialog.tabMain.label
extendedDialog.tabMain.label

Das „extendedDialog.tabMain.label“ ist eigentlich nicht notwendig und wird in den aller meisten Fällen dieselbe Übersetzung enthalten wie im Basis-Dialog.

Fazit

Insgesamt ist die Internationalisierung in Magnolia 5 einfacher und flexibler geworden. Die Key-Generierung zeigt auch auf technischer Seite neue Möglichkeiten zur Verwaltung und Organisation von Keys.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>