Archiv

Posts Tagged ‘Übersetzungen’

Mehrsprachigkeit mit Oracle APEX

Juli 6, 2010 4 Kommentare

Oracle APEX bietet out-of-the-box die Möglichkeit, eine Anwendung in mehreren Sprachen zu veröffentlichen. Wie das funktioniert, möchte ich Ihnen in diesem Beitrag näher erläutern.

TIPP!

Bitte beachten Sie auch meinen Post zum Thema

Gefahren und Fallen beim Umgang mit APEX Translations

In diesem Beitrag sind noch weitere nützliche Tipps enthalten, die Ihnen viel Zeit sparen werden.

Szenario

Wir möchten eine Anwendung schreiben, die in 2 Sprachen, Englisch und Deutsch, verfügbar ist. Die Sprache soll sich automatisch ändern, wenn die Browsersprache geändert wird.

Als Standardsprache für die Entwicklung legen wir die englische Sprache fest, da wir uns international positionieren möchten.

Als kleine Zusatzanforderung möchten wir, dass beim Wechsel der Sprache das Datumsformat sich automatisch auf das jeweilige  lokale Format anpasst (für deutsch: DD.MM.YYYY, für englisch: DD/MM/YY).

Vorgehensweise

  1. Festlegen der Standardsprache (in welcher Sprache wird entwickelt?)
  2. Festlegen, auf welche Weise die Sprache gewechselt werden kann
  3. Applikationseinstellungen für das Sprachhandling vornehmen
  4. Applikation in eine andere Sprache übersetzen
  5. Weitere notwendige Aktionen
  6. Formatmaske für Datumsfelder angeben
  7. Tipps und Tricks beim Umgang mit Translation Files

Zu 1: Festlegen der Standardsprache (in welcher Sprache wird entwickelt?)

Am Anfang sollte man sich überlegen, in welcher Sprache die Anwendung realisiert wird (Primary Language). APEX nutzt diese als Basis für alle weiteren Übersetzungen.

Wie wir bereits festgelegt haben, soll die Standardsprache für die Entwicklung englisch sein.

TIPP!

Entwickeln Sie in der Sprache, die für Sie am wichtigsten ist und die als erstes veröffentlicht werden soll. Alle weiteren Übersetzungen können später jederzeit noch hinzugefügt werden.

Die Standardsprache wird automatisch immer dann verwendet, wenn eine Sprache aktiv ist, für die es keine Übersetzung gibt!!!

Bitte beachten Sie auch, dass jede Änderung an den Labels oder Texten in der Standardsprache Änderungen in allen Übersetzungen nach sich zieht!

Zu 2: Festlegen, auf welche Weise die Sprache gewechselt werden kann

Legen sie fest, wie die Sprache innerhalb der Anwendung geändert werden kann. Hierbei sollte man sich überlegen, ob die Sprachanpassung automatisch oder durch benutzereingriff erfolgen soll.

APEX bietet ihnen hierzu folgende Möglichkeiten zur Sprachauswahl:

– Übernahme der Browsersprache

– Einstellen der Sprache über eine Umgebungsvariable namens FSP_LANGUAGE_PREFERENCE

– Einstellen der Sprache über eine selbst definitere Umgebungsvariable

In diesem Beispiel soll sich die Sprache analog zu der im Browser eingestellten Sprache verhalten. D.h. sie soll automatisch wechseln, wenn die Browsersprache geändert wird.

Zu 3: Applikationseinstellungen für das Sprachhandling vornehmen

Zuerst machen wir die globalen Einstellungen für das Sprachhandling in der Applikations-Definition.

  • Über „Shared Components“ -> „Definition“ -> „Globalization“ müssen wir 2 Einstellungen machen.
    • „Application Primary Language“ auswählen

Wählen Sie hier die Standardsprache, die wir zuvor als Primary Language festgelegt haben, aus (in unserem Beispiel „English (en)“.

    • “Application Language Derived From” auswählen.

Wählen Sie hier „Browser (use browser language preference)“ aus.

    • Optional geben wir hier schon mal das Standard-Datumsformat für die englische Sprache an (DD/MM/RRRR)
Define global language

Define global language

Zu 4: Applikation in eine andere Sprache übersetzen

Nun wollen wir die eigentliche Übersetzungsarbeit durchführen. Dazu gehen Sie bitte, wie folgt, vor.

  • Über „Shared Components“ -> „Translate Application“ (in der Region „Globalization“) gelangen Sie in das Translation Menü. Dieses Menü muss nun, mehr oder weniger, von oben nach unten durchgearbeitet werden.
  • Klicken Sie auf “1. Map your primary language application to a translated application” und dann auf “Create”.

Hier wird nun zuerst einmal die Sprache erzeugt, die veröffentlicht werden soll. Wir machen nun die notwendigen Eingaben und setzen folgende Werte:

    • Translation Application: 1501
    • Language Code: German (Germany) (de)
    • Comments: <Irgendein Kommentar>

TIPP!

In dem Feld “Translation Application” wird eine eindeutige ID erwartet, die man jedoch selbst vergeben muss. Wenn man viele Applications auf einer Instanz erzeugt hat, wird das etwas schwierig mit der Eindeutigkeit. Deshalb meine Empfehlung: Überlegen Sie sich eine Regel, wie Sie IDs für Übersetzungen verwenden. Sie können z.B., wie in unserem Beispiel, die ID der Primary Language (in unserem Falle 150) nehmen und eine Stelle anhängen und diese dann einfach für jede Übersetzung um 1 erhöhen (1501 deutsch, 1502 italienisch, 1503 spanisch, usw.)

  • Über die Breadcrumb Region gehen wir zurück zum Translation Menü und erzeugen das Translation-File.
    • Klicken auf „Seed and export the translation text of your application into a translation file.”
    • Sprache auswählen und Texte erzeugen

Hier werden nur die von uns angelegten Sprachen angezeigt. In unserem Beispiel existiert nur die „1501 de“. Diese wählen wir aus und klicken auf „Seed Translatable Text“.

Wir gelangen nun in den XLIFF Export. Hier können wir entscheiden, ob wir die Übersetzungen für die gesamte Anwendung oder nur für bestimmte Seiten erzeugen wollen. Zudem kann ausgewählt werden, ob alle Übersetzungstexte oder nur die, die eine Übersetzung benötigen, exportiert werden sollen.

Wir wollen nun die gesamte Anwendung übersetzen und auch nur die Texte, die eine Übersetzung benötigen.

Wir wählen hier nun die Application aus, markieren die Option „Only those elements requiring translation“ und klicken auf „Export XLF File for Application“, um das Übersetzungsfile zu erzeugen.

Es wurde nun eine Datei mit allen notwendigen Übersetzungen erzeugt (f150_1501_en_de.xlf). Dies ist nun die Basis, auf der wir die Texte übersetzen müssen. In unserem kleinen Beispiel können wir die Texte nun direkt in dem erzeugten File ändern (Bitte nur jeweils die „Target“-Texte ändern!!!). Bei einer richtigen Anwendung kann das allerdings ziemlich viel Aufwand werden.

Hinweis!

Unter Punkt 7 finden Sie noch einige Tipps und Tricks für das Übersetzen der Texte und den Umgang mit den Translation-Files.

  • Haben wir die Texte im Translation-File übersetzt, müssen wir die Übersetzung noch veröffentlichen.
    • In der Breadcrumb Region klicken wir auf „Translate Application“ und dann auf „4. Apply your translation file and publish“.
    • Auf der Seite „XLIFF Translation Files“ klicken wir nun auf „Upload XLIFF“ um das Translation File hochzuladen. Wir machen folgende Eingaben:

Title: 1501_de

Description: <irgendeine Beschreibung für das Import File>

XLIFF File: <auswählen der Datei mit unseren Übersetzungen, in unserem Fall f150_1501_en_de.xlf>

    • Nachdem wir auf „Upload…“ geklickt haben, wird uns die importierte Datei angezeigt. Klicken Sie nun auf den Title der Datei und wählen im folgenden Dialog die Sprache aus, für die die Übersetzung bestimmt ist („apply to“ – in unserem Fall „1501 de“).
    • Klicken Sie nun auf „Apply XLIFF Translation File“, prüfen Sie im folgenden Dialog, dass bei „Create Application“ die richtige Applikation angezeigt wird (ggf. korrigieren) und dann oben rechts auf „Publish Application“, um die Sprache schließlich zu veröffentlichen.

Hinweis!

APEX erzeugt für jede veröffentlichte Sprache eine eigene Applikation. Im Hinblick auf die Performance ist das sicherlich eine sehr gute Lösung. Jedoch werden Sie früher oder später sehen, dass dies auch einige Nachteile hat. Wenn wir nämlich nun PLSQL-Code verändern, der nichts mit irgendwelchen Übersetzungs-relevanten Texten zu tun hat, müssen wir trotzdem alle Übersetzungen erneut veröffentlichen, da APEX teilweise auch funktionalen Code dupliziert und für jede Übersetzungs-Applikation explizit vorhält. Mehr dazu finden Sie unter „Gefahren und Fallstricke beim Umgang mit APEX Translations“.

Zu 5: Weitere notwendige Aktionen

Übersetzen von internen APEX Messages

Wenn Sie die Anwendung nun aufrufen und Ihren Browser auf z.B. „German (de)“ umstellen, werden Sie feststellen, dass einige Labels noch in englischer Sprache dargestellt werden. Z.B. werden in einer Reportmaske mit Seitennavigation die „Next“/“Previous“ Labels noch in Englisch dargestellt.

Grund hierfür sind die APEX internen Messages, die nicht out-of-the-box in das Translation-File exportiert werden. Eine Aufstellung aller internen Messages finden Sie unter folgendem Link in Kapitel „Table 16-3 Internal Messages Requiring Translation“.

http://download.oracle.com/docs/cd/E10513_01/doc/appdev.310/e10499/global.htm#BABFHCJA

http://apex.oracle.com/i/doc/global_mess_reports.htm

Um diese internen Messages zu übersetzen, gehen Sie bitte wie folgt vor.

  • „Shared Components“ -> unter „Globalization“ auf „Text Messages“ und dann auf „Create“ klicken.
  • Geben Sie bei Name den gewünschten Substitution String aus der Tabelle „Internal Messages Requiring Translation“ (zuvor erklärt) ein.
  • Wählen Sie die Sprache aus, die als Hauptsprache bei der Application angegeben wurde (bei uns „Englisch“).
  • Geben Sie den Übersetzungstext ein (in englisch).

Hier können auch Platzhalter eingegeben werden. Um z.B. den Info-Text in der Navigations-Popupliste (X_Y_of_Z: row(s) 1 – 10 of 12) zu ändern, geben Sie bei Name „WWV_RENDER_REPORT3.X_Y_OF_Z“ und bei Text z.B. „Zeile(n) %0 – %1 von insgesamt %2“ ein.

Beachte!

Diesen Vorgang müssen Sie für alle benötigten internen Messages durchführen.

  • Nun, wie unter Punkt 4 beschrieben, die übersetzten Applikationen neu erzeugen (der Punkt „Map your Primary Language Application to…“ kann weggelassen werden, da die Anwendung bereits gemapt ist). Wenn die gerade angelegten Texte in der Hauptsprache erzeugt wurde, werden diese Texte ebenfalls mit in die jeweiligen XLF-Files eingetragen. Nach dem Übersetzen und „publishen“ müssten auch hier nun die Übersetzungen angezeigt werden.

TIPP!

Sollten diese internen Messages nun nicht im Translation-File auftauchen, lesen Sie bitte den Beitrag Interne Messages und dynamische Übersetzungen werden nicht in das XLF-File exportiert.

HINWEIS!

Alle Übersetzungstexte für interne Messages können auch hier komplett erstellt werden. Jedoch ist der Weg über die Translation-Files der bessere, wenn die Übersetzungsarbeit von einem Übersetzer durchgeführt wird.

Übersetzen von statischen Wertelisten

Wenn Sie statische Wertelisten verwenden die nicht über eine LOV implementiert, sondern mit „STATIC:…“ einfach bei dem entsprechenden Item eingegeben wurden, so werden diese Inhalte nicht übersetzt.

Hierfür sollten Sie auf jeden Fall eine statische LOV erzeugen und ausschließlich diese verwenden (auch im Sinne von Wiederverwendbarkeit sinnvoll!). Statische LOV-Werte werden beim erzeugen der Translation-Files (siehe oben) mit exportiert und können dann zusammen mit den anderen Texten übersetzt werden.

Übersetzen von dynamischen Wertelisten

Ein weiteres Problem besteht darin, LOV-Werte, die dynamisch aus der Datenbank ermittelt werden, zur Laufzeit zu übersetzen. APEX stellt dafür eine PLSQL-API zur Verfügung (APEX_LANG).

Wie das funktioniert, möchte ich Ihnen hier kurz zeigen.

Gegeben sei eine Wertelist, die verfügbare Sprachen darstellt und auswählbar macht. Diese Sprachen sind in einer Datenbanktabelle mit dem Namen „LANGUAGE“ eingetragen (In unserem Beispiel sind nur 2 Einträge in der Tabelle für „German“ und „English“).

Gehen Sie bitte wie folgt vor.

  • Übersetzungstexte für alle Werte der Tabelle LANGUAGE erzeugen.
    • Über „Shared Components“ -> „Translate Application“ (Globalization) -> “Optionally identify any data that needs to be dynamically translated …” -> “Create” einen neuen Text in der gewünschten Übersetzungssprache erzeugen.

Language: “German (Germany) (de)” auswählen

Translate From Text: “German” (das ist der Key bzw. der Text, der in der Tabelle vorhanden ist und übersetzt werden muss).

Translate To Text: „German“ (das ist der Text, der angezeigt werden soll).

Bild zu dynamic translation messages

    • “Create” klicken, um den Text anzulegen.
    • Das Gleiche machen wir nun mit allen Sprachen, die in der Tabelle vorhanden sind und übersetzt werden müssen.

Hinweis!

Ich habe hier als Übersetzungstexte die englischen Texte eingegeben, um das Szenario aufzuzeigen. Wenn Sie hier direkt die richtigen Übersetzungstexte eingeben, sparen Sie sich die spätere Übersetzung.

Beachte!

Wenn Sie diese dynamischen Texte in der Hauptsprache (in unserem Fall „Englisch“) eingeben, werden diese Texte, im Gegensatz zu den anderen Text-Messages, nicht in das XLIFF-File exportiert! Deshalb sollten Sie darauf achten, direkt die richtige Sprache auszuwählen.

  • Erzeugen einer LOV zur Selektion dieser Sprachen.

Beim Erzeugen der LOV müssen wir die Apex Language API (APEX_LANG) benutzen, um auf die Übersetzungstexte zuzugreifen. Das Statement für die LOV sieht dementsprechend wie folgt aus.

  • Nun müssen wir die LOV dem Item zuweisen, welches diese Werteliste beinhalten soll.
  • Nun, wie unter Punkt 4 beschrieben, die übersetzten Applikationen neu erzeugen. Wenn die gerade angelegten dynamischen Werte in der Hauptsprache erzeugt wurden, werden diese ebenfalls mit in die jeweiligen XLF-Files eingetragen. Nach dem Übersetzen und „publishen“ müssten auch hier nun die Übersetzungen richtig angezeigt werden.

HINWEIS!

Alle Übersetzungstexte für interne Messages können auch hier komplett erstellt werden. Jedoch ist der Weg über die Translation-Files der bessere, wenn die Übersetzungsarbeit von einem Übersetzer durchgeführt wird.

  • Weitere Informationen zum Umgang mit der APEX_LANG-API hierzu finden Sie unter

http://download.oracle.com/docs/cd/E10513_01/doc/appdev.310/e10499/global.htm#insertedID0

Übersetzen sonstiger dynamischer Inhalte

Nun kann sich auch noch die Notwendigkeit ergeben, Werte aus anderen Tabellen, die in Reports oder Formularen benötigt werden, zu übersetzen. Hierfür stellt APEX noch eine andere Funktion der APEX_LANG-API zur Verfügung.

APEX_LANG.MESSAGE

Das Handling hierfür ist fast identisch zu dem vorherigen Punkt („Übersetzen von dynamischen Wertelisten“). Der Unterschied besteht hauptsächlich darin, dass der Übersetzungstext in APEX an einer anderen Stelle eingetragen wird.

Zum Erstellen des Übersetzungstextes klicken Sie bitte unter „Shared Components“ -> „Text Messages“ (Globalization) -> und klicken auf „Create“. Bei Namen bitte den Text bzw. Key eintragen (der Text aus der Tabelle, der übersetzt werden soll), wählen die Sprache aus und tragen den Übersetzungstext ein. Fertig!

Nun können Sie innerhalb Ihres Codings (im Prinzip überall, wo Sie PLSQL-Code verwenden), mit der APEX_LANG-API auf diesen Text zugreifen.

Beispiel: (Dieses Statement würde die Städtenamen aus der Tabelle PERSONEN übersetzen, wenn zuvor die Städte als Übersetzungstexte angegeben worden sind)

SELECT APEX_LANG.MESSAGE(city) FROM PERSONEN;

Weitere Informationen zur APEX_LANG-API  finden Sie unter

http://download.oracle.com/docs/cd/E10513_01/doc/appdev.310/e10499/global.htm#insertedID0

ACHTUNG BUG in Version 3.2.1!!!

Wenn man zuvor eine Translation zu einer Sprache mit einer anderen ID erstellt und dann gelöscht hatte (z.B. zuvor die „151 de“), dann bleiben Fragmente in der Tabelle WWV_FLOW_TRANSLATABLE_TEXT$ die verhindern, dass eine deutsche Übersetzung mit einer anderen ID (jetzt 1501) erstellt werden kann. Als workaround geht folgendes:

  1. Die Translation, die Probleme macht, löschen.
  2. Gesamte Applikation exportieren
  3. Gesamte Applikation löschen
  4. Applikation importieren.

Nun kann die Translation wieder normal angelegt und damit gearbeitet werden.

Zu 6: Formatmaske für Datumsfelder definieren

Wie Sie Formatmasken in APEX definieren können, finden Sie hier.

Datumsformate applikationsweit defnieren

Einen Beitrag zum Thema „Localization“ für Datums- und Zeitformate kommt bald. Sollten Sie Informationen dazu benötigen, können Sie mich gerne kontaktieren.

Zu 7: Tipps und Tricks zum Umgang mit Translation Files

In diesem Beitrag wurde nun erklärt, wie man mit APEX eine Anwendung mehrsprachig auslegen kann. Nun stellen sich allerdings noch folgende Fragen.

  1. Wer übersetzt denn nun eigentlich die ganzen Texte?
  2. In welcher Form stelle ich dem Übersetzer die Texte zur Verfügung?

Naja, die Antwort auf die 1. Frage ist recht einfach – die Übersetzer!

Im Unternehmen haben wir vielleicht Leute die gut genug englisch sprechen, um die englische Übersetzung zu machen. Aber was ist mit den anderen Sprachen? Hierfür benötige ich natürlich einen oder vielleicht sogar mehrere Übersetzer.

Und schon sind wir bei der 2. Frage. In welcher Form kann ich den Übersetzern meine Texte zur Verfügung stellen?

Das Problem

Die Translation Files (XLF-Files) sind so unübersichtlich, dass ein Übersetzer mir dieses wahrscheinlich nach spätestens 5 Minuten um die Ohren schlagen würde.

Also was tun?

  • Nicht benötigte Labels und Texte von den Translations ausschließen

APEX bietet eine Möglichkeit, ein paar unnötige Übersetzungen zu unterdrücken. Das macht auch durchaus Sinn, da eh schon genügend Texte als Übersetzungen erkannt und vorgeschlagen werden, die gar keine Übersetzung benötigen.

    • Unnötige Region Labels unterdrücken

Bei den Region-Attributes gibt es die Möglichkeit, die Option „exclude title from translation“ anzuklicken. In diesem Fall wird der Region-Title nicht als Übersetzung eingetragen. Diese Option macht Sinn für Hilfs-Regions, die nicht angezeigt werden.

    • Templates von den Translations ausschließen

Bei den Templates gibt es die Möglichkeit, ein Template komplett auszuschließen. Sie sollten also prüfen, ob statische Texte in Ihren Templates enthalten sind. Wenn nicht, markieren Sie die entsprechenden Templates als „non-translatable“ (wie folgende Abbildung zeigt).

Bild zu Define option Template Translatable

Define option Template Translatable

  • Nur die Texte in das Translation File exportieren, die eine Übersetzung benötigen

Sie können beim erzeugen des XLF-Files die Option „Only those elements requiring translation“ auswählen. Dadurch werden schon mal eine nicht benötigte Texte ausgeschlossen.

  • Übersetzungstexte über APEX Dialog bearbeiten

APEX bietet einen Dialog, um Übersetzungstexte direkt im APEX Builder zu bearbeiten. Hinweis!

Beim späteren Erzeugen des Translation Files (XLF) werden die Änderungen erkannt und dort eingetragen.

Bild zu Manually edit translations

Manually edit translations

  • XLF-File in eigene Tabelle laden und Maske bauen

In meinem letzten Projekt haben wir ein JAVA-Programm geschrieben,  um das komplette XLF-File in eine eigene Datenbanktabelle zu schreiben. Für diese Tabelle haben wir einen einfachen änderbaren Report entwickelt, mit dem wir die Übersetzungstexte ganz einfach bearbeiten konnten. Ein zweites kleines JAVA-Programm hat die übersetzten Texte aus der Tabelle gelesen und ein neues APEX-konformes XLF-File erzeugt. Dieses konnten wir dann importieren, um damit die benötigen übersetzten Applications zu erzeugen.

Bei Interesse stellen wir Ihnen diese JAVA Programme gerne zur Verfügung (natürlich kostenlos – auch gerne mit Source-Code, damit Sie diese Programme für sich anpassen können).

  • Übersetzungstexte aus Repository auslesen

Zu diesem Punkt habe ich einen eigenen Post geschrieben.

Übersetzungstexte aus dem APEX Repository auslesen

Advertisements

Gefahren und Fallen beim Umgang mit APEX Translations

In der Hoffnung, Ihre Arbeit etwas zu erleichtern und Zeit zu sparen möchte ich Ihnen hier einige Hinweise, Tipps und Tricks mitgeben.

Themen

  • Änderungen an der Anwendung werden mir nicht angezeigt.
  • Interne Messages und dynamische Übersetzungen werden nicht in das XLIFF-File exportiert.
  • Umlaute werden im XLIFF-File als Sonderzeichen dargestellt.

Änderungen an der Anwendung werden mir nicht angezeigt.

Es gibt eine Tücke beim Umgang mit dem APEX Übersetzungsmechanismus, der mir persönlich immer wieder Probleme bereitet.

Ich habe eine Änderung durchgeführt, führe die Anwendung aus bzw. teste meine Änderung, aber meine Änderungen sind nicht zu sehen bzw. wirken sich nicht aus.

Beispiel:

Änderung des SELECT-Statements für einen Report

oder irgendeine Eigenschaft eines Items verändert.

Ursache

Wenn ich eine Übersetzung erzeuge, wird von APEX intern eine neue Application erzeugt. D.h. wenn ich die Anwendung mit der Primary Language (bei mir „English“) ausführe, wird die Primary Application ausgeführt (bei mir z.B. Application-ID „150“. Wechsle ich die Sprache nun auf „Deutsch“ (bei mir ID „1501“), dann wird nicht mehr die Application 150, sondern die 1501 ausgeführt. Da APEX nun auch gewisse Codestellen innerhalb der übersetzten Application speichert, werden diese nicht direkt mit aktualisiert. D.h. meine Änderung ist nur innerhalb der Primary Application verfügbar. Alle Übersetzungen müssen neu durchgeführt werden, damit dort auch die Änderungen aktiv werden.

TIPP!

Wenn Sie Änderungen an der Anwendung machen, stellen Sie in dem Browser, in dem Sie testen, die Sprache der Primary Language ein oder wählen Sie im Browser eine Sprache, zu der es definitiv keine Übersetzung gibt. In diesem Falle wird immer die Primary Application verwendet.

Testen Sie dann Ihre Änderungen und wenn alles funktioniert, führen Sie alle Übersetzungen nochmal aus. Danach sollte alles funktionieren.

Interne Messages und dynamische Übersetzungen werden nicht in das XLF-File exportiert

Eine der Hauptursachen, dass interne Messages oder dynamische Übersetzungen im XLF-File nicht eingetragen sind, ist eine falsche Definition der Sprache. Die Sprache, die bei der Application-Definition (Globalization) eingetragen ist, muss mit der bei dem Übersetzungstext angegebenen absolut übereinstimmen.

Wenn Sie z.B. in der Definition „English (United States) (en-us)“ und beim Erzeugen „English (en)“ angeben, funktioniert es nicht.

Prüfen Sie also, dass überall die gleiche Sprache angegeben wurde und korrigieren es ggf..

Deutsche Umlaute werden in der Anwendung als Sonderzeichen dargestellt

Das übliche Problem bei deutschsprachigen Anwendungen: Umlaute werden als Sonderzeichen dargestellt. Was tun?

Generell gilt für HTML-Anwendungen, HTML-Encodings mit der Notation „&auml;“, „&uuml;“, etc. zu verwenden, damit auch wirklich unter allen Umständen und in allen Browsern die richtigen Zeichen dargestellt werden.

In Oracle APEX 4.0 gibt es jetzt aber dummerweise ein kleines Problem damit.

Ich lade das XLIFF-File hoch (über „Shared Components“ -> „Translate“ -> „Apply XLIFF translation…”), klicke auf das File, um es anzuwenden und zu veröffentlichen und nun kommt folgender Fehler:

ORA-31011: XML parsing failed ORA-19202: Error occurred in XML processing LPX-00118: Warning: undefined entity "uuml" Error at line 63

LÖSUNG!

Oracle hat Probleme mit der einfachen „&“-Notation. Damit alles richtig funktioniert, müssen wir das „&“ ebenfalls encoden.

Beispiel: Wir möchten den Text „Löschen“ encoden.

Falsch: L&ouml;schen

Richtig: L&amp;ouml;schen      (wir müssen das „&“ ebenfalls encoden)

Wenn Sie alle Umlaute im XLIFF-File so encoden, sollte das Importieren und Veröffentlichen funktionieren und die Umlaute in Ihrer Anwendung korrekt dargestellt werden.