Mehrsprachige Anwendungen bedeuten – unabhängig von der verwendeten Technologie – immer einen nicht unerheblichen Aufwand, zusätzlich zur eigentlichen Entwicklung der Applikation.

Das vorweg genommen, kommt die gute Nachricht: Oracle APEX ist von Haus aus auf Mehrsprachigkeit ausgerichtet und bringt alle nötigen Werkzeuge dazu mit.
Auf der öffentlichen Test- und Demo-Plattform apex.oracle.com sieht man, dass diese in 10 verschiedenen Sprachen angeboten wird. Mit dem Zusatzwissen, dass APEX in APEX geschrieben wird, ist klar: Übersetzungen sind möglich, auch für grosse Anwendungen (der Application Builder besteht aus knapp 1200 Seiten).

Wir wollen uns hier nicht mit dem Übersetzungsprozess von Oracle APEX beschäftigen, dies ist einerseits im Application Builder Users Guide, aber auch in einem sehr ausführlichen Blogpost und einer Artikelreihe (Teil 1, Teil 2) der deutschsprachigen APEX Community genauestens beschrieben.

Mit Oracle APEX 4.1 wurde der Translations Bereich nochmals überarbeitet und komfortabler gestaltet, wie Joel Kallmann (Product Manager Oracle APEX) in seinem Blogposting beschreibt.

Nun gibt es aber nie nur eine einzige Möglichkeit ein Problem zu lösen, und so mag mancher einen eigenen Weg zur Übersetzung seiner Applikation beschreiten wollen. Dieses Blogposting versucht einen Überblick über Vor- und Nachteile verschiedener Übersetzungs-Lösungen zu geben.

1. Der eingebaute APEX Übersetzungsmechanisums

Natürlich die erste Wahl, aber was sind nun die Vor- und Nachteile vom APEX Übersetzungssystem?

Vorteile:

• Vom Hersteller eingebaut und auch selbst verwendet (Übersetzung der APEX Entwicklungsumgebung)
• deckt alle relevanten Oberflächentexte ab (das sind mit Stand APEX 4.1 insgesamt 394 unterschiedliche Entitäten/Textarten).

Nachteile:

• Aufwändiger Prozess: Code – Seed – XLIFF – Apply – Publish
• XLIFF-Dateien fehlt der Kontext, Übersetzer weiß nicht wo der zu übersetzende Text verwendet wird
• Seed ist etwas übereifrig und zwingt zum neuerlichen Übersetzen eines Textes, sobald im Originaltext auch nur ein Buchstabe verändert wurde
• Übersetzungen sind nur am Entwicklungssystem möglich, danach ist ein neuerliches Deploy der Anwendung auf andere Systeme nötig

 

2. Übersetzung mit Substitutions-Items

Will man die Oberflächentexte in einer eigenen Tabelle in der Datenbank verwalten, dann stösst man oft auf diese Variante. Dazu wird pro angezeigtem Feld bzw. Text (Regions-Überschrift, Hinweistext…) ein verstecktes Item erstellt, das mit dem entsprechenden Text aus einer Datenbank-Tabelle befüllt wird. Dieses versteckte Feld (z.B. P3_USERNAME_TEXT) wird mit der „&.“-Methode im eigentlichen Feld substituiert, soll heißen in der Einstellung „Label“ des Feldes P3_USERNAME wird &P3_USERNAME_TEXT. eingesetzt.

Natürlich muss davor das Feld P3_USERNAME_TEXT entsprechend befüllt werden. Dies kann über einen Prozess oder über die Element-Quelle geschehen.

Vorteile:

• Text können einfach in der Datenbank gepflegt werden
• Auch zur Laufzeit ist eine Änderung der Texte und damit der Oberflächenbeschriftung möglich

Nachteile:

• Die Entwicklung wird aufwändiger. Pro angezeigtem Feld muss ein zweites Feld erstellt und im ersten referenziert werden. Zusätzlich müssen noch die entsprechenden Einträge in der Datenbank-Tabelle erstellt und ausgelesen werden.
• Aus Sicht von APEX wächst die Anzahl der zu verwalteten Items im Session-State stark an.
• Zusätzliche Lese- und Substitutions-Operationen beim Seitenaufbau
• Für Feldbeschriftungen gerade noch geeignet, sollen aber auch Hilfetexte, Regionsbeschriftungen usw. unterstützt werden, dann steigt der Aufwand und die Anzahl Felder entsprechend weiter an.
• Oracle APEX hat ein Limit von 100 Feldern pro Seite, dies inkludiert auch die versteckten Felder. Für diese Art der Übersetzung wird dies also auf 50 echte Felder halbiert

 

3. AJAX Übersetzung auf Client-Seite

Alle Texte werden in der Datenbank in einer Tabelle gespeichert und können dort gepflegt werden. Mit einer Dynamic Action wird unmittelbar nach dem Seitenaufbau ein AJAX-Call an die Datenbank abgesetzt und alle Texte in der User-Sprache gelesen. Diese Texte werden mit einer weiteren Dynamic Action auf der Oberfläche ausgetauscht.

Vorteile:

• Keine besondere Rücksicht beim Entwickeln der Applikation nehmen
• Text können jederzeit in der Datenbank bearbeitet werden, damit ist auch eine Änderung der Oberflächentexte zur Runtime möglich

Nachteile:

• Die Applikation wird zuerst in der Haupt-Sprache angezeigt und dann erst angepasst. Bei einer langsameren Verbindung sieht der Benutzer diesen Wechsel der Texte und ggf. ein „Flackern“ der Seite.
• Seiten-, Regions-, Report- und alle anderen verwendeten Templates müssen entsprechend angepasst werden, damit die Dynamic Action die zu tauschenden Texte finden kann
• Bei vielen Elementen und Texten auf einer Seite kann das Austauschen der Texte langsam werden und den Client-Prozessor beanspruchen.

 

4. Manipulation des APEX-Label-Array

Im Package APEX_APPLICATION gibt es eine ganze Reihe von nützlichen Funktionen und globalen Variablen. Einige wenige davon sind dokumentiert und zur Verwendung freigegeben.

Unter den nicht erwähnten globalen Variablen befinden sich g_item_name und g_item_prompt, zwei Arrays die alle auf der Seite befindlichen Felder bzw. deren Labels enthalten.
Mit einem PL/SQL-Prozess beim Seitenaufbaus könnte man nun das g_item_prompt Array manipulieren und die Labels gegen übersetzte Labels austauschen.

Hinweis: diese Methode wurde nicht getestet und ich rate auch dringend davon ab APEX Strukturen zu manipulieren!

Vorteile:

• Feldbeschriftungen werden beim Seitenaufbau ausgetauscht und sofort richtig angezeigt
• Texte können so auch im laufenden Betrieb verändert werden

Nachteile:

• Es handelt sich dabei lediglich um Feldbeschriftungen. Alle anderen Texte werden dadurch nicht abgedeckt.
• Manipulation nicht öffentlicher APEX Strukturen kann unerwartete Nebeneffekte haben.
• Diese Strukturen können sich auch in zukünftigen APEX Versionen nach belieben ändern

 

Fazit

Keine der Alternativen ist perfekt, auch nicht das APEX System selbst. Allerdings kann keine der Alternativen zum APEX System auch nur annähernd komplette Übersetzungen anbieten. Meist ist die Übersetzung auf Feld- und Regionsnamen beschränkt und bedeutet zusätzlichen Rechenaufwand beim Seitenaufbau.

Im Sinne eines qualitätsgesicherten Entwicklungs- und Ausroll-Prozesses passt das System von APEX aber sehr gut in den Ablauf. Nicht umsonst wird APEX selbst seit Jahren in 10 Sprachen angeboten, die bei jeder Release überarbeitet (Anpassung an Änderungen) werden müssen.

Aus unserer Erfahrung – wir haben schon einige Kunden durch APEX Übersetzungsprozesse begleitet und beraten – ist das eingebaute APEX System auf alle Fälle allen anderen Varianten vorzuziehen. Mit maßgeschneiderten Anpassungen kann man den Ablauf optimieren und an die Umgebung und Entwicklungsprozesse anpassen.

Im nächsten Blogposting zeigen wir Möglichkeiten das APEX Übersetzungssystem zu verbessern und die Arbeit damit komfortabler zu gestalten.