APEX bietet die Möglichkeit, Applikationen zu übersetzen und den Anwendern mehrsprachig zur Verfügung zu stellen. Dabei wird einfach eine weitere Sprache für die Applikation im Übersetzungsbereich eingetragen, die Texte der Applikation werden in das Übersetzungsrepository geladen und wahlweise dort oder über den Export und Import einer XLIF-Datei übersetzt, die übersetzte Applikation wird veröffentlich, und schon ist die Applikation zweisprachig.
Aber ist dies wirklich so einfach?
Wie werden Wertelisten für Stammdaten übersetzt, die auf Datenbanktabellen basieren? Wie können für diese Stammdaten Texte in mehreren Sprachen durch Endanwender erfasst werden?
Wie sieht ein geeignetes Vorgehen bei Meldungstexten in Dynamic Actions aus?
Dieser Artikel erläutert den Ansatz, den wir in unseren APEX-Projekten für die Umsetzung gewählt haben, um den Anwendern sowohl die Oberfläche als auch die Stammdaten mehrsprachig zur Verfügung zu stellen, ohne auf ein relationales Datenmodell zu verzichten.
Bevor wir übersetzen können, müssen wir erst die Anwendung erstellen, die übersetzt werden soll. Beim Anlegen dieser Anwendung wird die Sprache der Applikation abgefragt. Dies ist die Sprache, in der die Anwendung entwickelt wird und von der aus in alle anderen benötigten Sprachen übersetzt wird:
Abbildung 1: Quellsprache
Dabei ist zu beachten, dass APEX statische Texte für erstellte Objekte (z. B. Button-Labels) nicht in der Sprache der Anwendung generiert, sondern in der Sprache der Entwicklungsoberfläche zur Zeit der Erstellung!
In der erstellten Applikation können wir anschließend unter „Shared Components Globalization Attributes“ auswählen, wie APEX bestimmt, in welcher Sprache die Anwendung ausgeführt wird:
Abbildung 2: Ermittlung der Ausführungssprache
Für übersetzte Applikationen kann festgelegt werden, dass die aktuelle Sprache
ermittelt wird.
Öffnet man im Application Builder unter „Shared Components“ im Abschnitt „Globalization“ den Link „Application Translations“, zeigt die Zielseite den Ablauf des Übersetzungsvorgangs:
Abbildung 3: Ablauf der Übersetzung
Über den Link im ersten Schritt des Ablaufs öffnet sich die Seite der festgelegten Zielsprachen. Hier wird über den Create-Button eine neue Zielsprache definiert:
Abbildung 4: Definition einer Zielsparche
Jede Zielsprache erfordert eine neue Applikation mit eigener ID. Diese ID darf nicht auf 0 enden!
Bei der Entwicklung einer Anwendung liefert APEX automatisch Texte für die Bedienelemente von Interactive Reports und Interactive Grids sowie für interne Meldungen. Diese Texte stehen in mehreren Sprachen zur Verfügung. Damit sie in unseren Anwendungen genutzt werden können, müssen die entsprechenden Sprachdateien installiert sein.
Auch in den übersetzten Anwendungen werden diese Texte in der gewählten Zielsprache verwendet, wenn diese Zielsprache eine der unterstützten Sprachen ist. Für alle anderen Zielsprachen müssen zusätzlich zur Übersetzung der Anwendung auch diese APEX-Texte übersetzt werden. Hierfür steht im unteren Bereich der „Translate“-Seite der Punkt „Text Messages“ zur Verfügung:
Abbildung 5: Text Messages
Alle gewünschten Messages müssen in allen benötigten Sprachen selbst eingetragen werden. Die eingetragenen Meldungen sind Objekte der Anwendung, nicht des Workspace, d.h. für andere Anwendungen im Workspace müssen die Meldungen wieder eingegeben werden.
Die Listen der Schlüsselwerte für die Meldungstexte sind in der Dokumentation unter „Translating Messages“ zu finden.
Dieser Bereich kann auch für eigene Meldungen verwendet werden. Dabei sollten die eigenen Messages mit einem eigenen Kürzel starten, das sich von den von APEX verwendeten unterscheidet. In PL/SQL kann auf die Einträge zugegriffen werden über apex_lang.message, in JavaScript über apex.lang.
Der Aufruf dieses Punktes zeigt die Liste aller zuvor definierten Zielsprachen und -applikationen. Beim Start des „Seed“- Prozesses werden aus der Quellapplikation alle übersetzbaren Texte ausgelesen und für alle angehakten Anwendungen Einträge im Translation Repository gemacht. Als übersetzter Text wird dabei der ausgelesene Text eingetragen.
Bei Verwendung eines Übersetzungswerkzeugs, das das XLIFF-Format unterstützt, werden nach der Befüllung des Translation Repository für jede Sprache die XLIFF-Dateien heruntergeladen:
Abbildung 6: XLIFF-Export
Bei der Auswahl „Only those elements requiring translation“ ist zu beachten, dass diese Elemente alle Objekte umfassen, für die der Quelltext und der übersetzte Text identisch ist. Wird in der deutschen und in der englischen Anwendung das Label „Name“ für ein Item verwendet, taucht diese Beschriftung immer im XLIFF-File auf.
Im nächsten Schritt werden die extrahierten Texte der Anwendung in die Zielsprachen übersetzt. Dies kann entweder außerhalb in einem Übersetzungstool erfolgen oder durch Bearbeitung der Einträge im Übersetzungsrepository.
Für die manuelle Bearbeitung wird im unteren Bereich der „Translate“-Seite der Link auf das Translation Repository aufgerufen. Dieses listet alle Texte für alle definierten Zielsprachen zusammen mit einem Bearbeitungsbutton in einem Interactive Report auf:
Abbildung 7: Translation Repository
Über den Edit-Link öffnet sich die Bearbeitungsseite:
Abbildung 8: Manuelle Übersetzung
Hier kann für den aktuellen Eintrag die Übersetzung angegeben werden. Kommt der Text mehrfach vor, können gleichzeitig alle Vorkommen mit derselben Übersetzung versehen werden.
Im Upload-Dialog für die XLIFF-Dateien können bis zu 10 Dateien (d.h. Übersetzungen für 10 Sprachen) hochgeladen werden. Nach dem Hochladen wird für jede Datei angegeben, zu welcher Zielanwendung und -sprache sie mittels Apply angewendet wird.
Der Aufruf dieses Punktes zeigt die Liste aller zuvor definierten Zielsprachen und -applikationen. Beim Start des „Publish“- Prozesses werden aus dem aktuellen Stand der Quellapplikation und allen Texten im Translation Repository alle angehakten Anwendungen erstellt.
Wurden seit dem Seed-Prozess an der Quellapplikation Änderungen gemacht, die Texte beinhalten, werden diese Texte unübersetzt in die Zielanwendungen übertragen.
Um die Anwendung mit allen Übersetzungen aus der Entwicklungsumgebung in andere Umgebungen zu übertragen, wird sie mit der aktivierten Einstellung „Export Translations“ exportiert. Nach dem Import in die Zielumgebung sind alle übersetzten Texte im Translation Repository, jedoch noch nicht veröffentlicht. Alle Zielanwendungen müssen mittels „Publish“ in der Zielumgebung zur Verfügung gestellt werden.
Beim Export und Import der Anwendung werden auch alle angelegten Meldungstexte unabhängig von der Sprache mit exportiert und importiert, selbst wenn die Applikation keine Definiton für die Sprache des Meldungstexts enthält.
Wenn für alle Texte, die im Translation Repository vorhanden sind, Übersetzungen eingetragen wurden, sieht die Anwendung in der Zielsprache so aus:
Sowohl die Wertelisten als auch die Display-Only-Items mit statischem Inhalt lassen sich einfach übersetzen, wenn man ein geeignetes Datenmodell verwendet und die benötigten Texte aus der Datenbank ermittelt.
Für Wartbarkeit und Flexibilität werden die Sprachen in einer Tabelle hinterlegt. Jede Sprache wird über ihren Sprachcode identifiziert, dieser entspricht dem von APEX verwendeten Sprachcode (ggf. mit Lokalisierung).
Die Schlüsseltabellen enthalten nur noch die Schlüssel und ggf. sprachunabhängige Sortierungen, für die Texte zu den Schlüsseln verwenden wir Zuordnungstabellen zwischen der Sprachentabellen und der jeweiligen Schlüsseltabelle:
Abbildung 10: Datenmodell
Um die Verwendung in Abfragen zu erleichtern, wird zu jeder Schlüsseltabelle mit Sprachtabelle eine View erstellt, die den Sprachcode, die Spalten der Schlüsseltabelle und die Spalten für die Texte aus der Sprachtabelle:
In APEX legen wir einige Application Items für die Ids der Sprachen an:
Diese Items werden initial beim Start der Anwendung gefüllt.
Ist ein Umschalten der Sprache möglich (abhängig von der Einstellung „Application Language Derived From“), müssen beim Setzen der neuen Sprache zusätzlich die Application Items für die aktuelle Sprache umgestellt werden.
Die Abfragen von LOVs und Regions werden auf die Views umgestellt und mit einer Where-Bedingung versehen, die die Daten auf die Sprache aus dem Application Item A_SPR_ID einschränkt.
Für die Eingabe der Sprachtexte in APEX können wir bei den Schlüsseltabellen ein Interactive Grid zur Verfügung stellen. Dieses hat als Quelle eine Abfrage über die Basistabelle der Schlüsselwerte sowie über die Texte zu den Schlüsselwerten in allen Sprachen:
Die Spalten der Sprachtexte werden auf „Query Only“ gestellt.
Für das Speichern der Daten der Basistabelle wird der Standardprozess des Interactive Grid auf der Basistabelle verwendet, für das Speichern der Sprachtexte wird ein Prozess angelegt, der diese Texte mittels Merge mit ggf. bereits vorhandenen Sprachtexten zum Basisdatensatz zusammenführt.
Bei Tabellen mit mehr Spalten ist es sinnvoll, den Anwendern ein Einzelsatzformular zur Verfügung zu stellen. Das Vorgehen ist dasselbe wie beim Interactive Grid:
Die Quelle der Daten ist eine Abfrage, die zu den Basisdaten die Sprachtexte in allen verwalteten Sprachen ermittelt:
Die items der Sprachtexte werden auf „Query Only“ gestellt. Das Ziel für das Speichern der Basisdaten ist die Tabelle, für die Sprachtexte wird ein Prozess mit Merge-Logik angelegt.
Bei beiden Varianten wird über eine NOT-NULL-Validierung sichergestellt, dass für alle Sprachen die benötigten Texte hinterlegt sind.
Die Mehrsprachigkeit in APEX funktioniert auf Basis von versteckten Schattenapplikationen je gewünschter weiterer Sprache. Diese Applikationen werden definiert, dann wird das Translation Repository mit den zu übersetzenden Texten gefüllt, die Übersetzung durchgeführt und abschließend die Schattenapplikationen mittels „Publish“ erstellt. Die Schattenapplikationen werden nicht automatisch neu erstellt, so dass nach jedem Entwicklungsschritt, auch wenn keine neuen Texte dazugekommen sind, mindestens der „Publish“-Vorgang nochmals durchgeführt werden muss.
Nicht alle Felder, in die Texte eingegeben werden können, werden in das Translation Repository übertragen. Texte für Wertelisten, insbesondere für Listen, die von den Anwendern gepflegt werden, sind von der APEX-Übersetzung nicht betroffen. Für beide Fälle ist es sinnvoll, im Datenmodell die Daten eines Objekts in sprachunabhängige und sprachabhängige Anteile aufzuteilen und entsprechende Tabellen anzulegen. In APEX sind dann geeignete Eingabeseiten einzubauen.
Eine große Herausforderung ist es, bei der Entwicklung immer die Mehrsprachigkeit zu beachten.
In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den
Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.
