Oracle APEX · · 3 Min.

Mehrsprachige Apps mit Text Messages

Wie APEX 26.1 Übersetzungen aus Seitendefinitionen löst und den Austausch mit Übersetzungsteams vereinfacht.

Veröffentlicht am 22.09.2026 · Verfasst von Dominik Radojevic

Mehrsprachige APEX-Anwendungen scheitern selten an der Auswahl einer Sprache. Schwieriger ist die Pflege: Texte liegen in Seitenelementen, Templates, Validierungen, Dynamic Actions und eigenen JavaScript-Dateien verteilt. Oracle APEX 26.1 führt deshalb einen stärker nachrichtenbasierten Übersetzungsworkflow ein. Übersetzbare Anwendungstexte können als Text Messages verwaltet, exportiert und wieder importiert werden.

Einordnung: Text Messages ersetzen nicht die fachliche Übersetzung. Sie schaffen einen zentralen Austauschpunkt, an dem Entwickler, Übersetzungsteam und Qualitätssicherung mit denselben Schlüsseln arbeiten können.

1. Texte zentralisieren

Der erste Schritt besteht darin, sichtbare Texte aus der Seitendefinition in wiederverwendbare Text Messages zu überführen. Jede Nachricht erhält einen stabilen Namen und den Ausgangstext. Seiten, Regionen und Prozesse referenzieren anschließend die Nachricht, statt unterschiedliche Kopien desselben Satzes zu enthalten.

Wählen Sie die Namen so, dass ihre Verwendung erkennbar bleibt, etwa nach Bereich und Zweck. Ein Schlüssel wie ORDER.STATUS.OPEN ist langfristig hilfreicher als ein generischer Name wie TEXT_17. Platzhalter sollten dokumentiert werden, damit Übersetzer wissen, welche Werte zur Laufzeit eingesetzt werden.

2. XLIFF und CSV für den Übersetzungsprozess

APEX 26.1 unterstützt den Export und Import von Text Messages in etablierten Austauschformaten wie XLIFF und CSV. XLIFF passt gut zu professionellen Übersetzungswerkzeugen, während CSV für kleinere Teams oder eine kontrollierte Tabellenprüfung praktisch sein kann.

Definieren Sie vor dem Export einen klaren Prozess: Ausgangssprache einfrieren, Schlüssel nicht während der Übersetzung umbenennen, Platzhalter testen und importierte Dateien zunächst in einer Testanwendung prüfen. Ein Übersetzungsexport sollte wie ein Artefakt behandelt werden – mit Version, Sprache, Änderungsdatum und verantwortlicher Person.

3. APEX_LANG für automatisierte Abläufe

Die APEX_LANG-API kann den Workflow programmatisch ergänzen. Damit lassen sich Text Messages automatisiert exportieren oder importieren, beispielsweise als Teil eines Release-Prozesses. Das ist interessant, wenn Anwendungen regelmäßig zwischen Entwicklungs-, Test- und Produktionsumgebung transportiert werden.

Automatisierung braucht Schutzmaßnahmen: Prüfen Sie Dateiformat, Zielsprache und Anwendungskontext vor dem Import. Überschreiben Sie keine produktiven Übersetzungen ohne Freigabe und protokollieren Sie, welche Version importiert wurde. Ein Rollback sollte über die vorherige geprüfte Exportdatei möglich bleiben.

4. Qualitätssicherung für Übersetzungen

  1. Alle unterstützten Sprachen und ihre Fallback-Regeln festlegen.
  2. Schlüssel, Platzhalter und maximale Textlängen dokumentieren.
  3. Übersetzungen über XLIFF oder CSV austauschen und Änderungen versionieren.
  4. Import in einer Testumgebung durchführen und Navigation, Fehlermeldungen, Dialoge und E-Mails prüfen.
  5. Mobile Layouts und lange Übersetzungen separat testen, bevor die neue Sprachversion veröffentlicht wird.
Praxisregel: Übersetzungen sind Teil des Release-Artefakts. Wenn Text Messages, Anwendungsexport und Datenbankänderungen gemeinsam versioniert und getestet werden, sinkt das Risiko, dass eine Seite nach dem Deployment teilweise in der falschen Sprache erscheint.

Fazit

APEX 26.1 macht die Pflege mehrsprachiger Anwendungen strukturierter. Text Messages zentralisieren die Inhalte, XLIFF und CSV erleichtern die Zusammenarbeit mit Übersetzungsteams und APEX_LANG öffnet den Weg zu reproduzierbaren Import- und Exportprozessen. Der wichtigste Erfolgsfaktor bleibt ein stabiler Schlüsselbestand mit klarer Qualitätskontrolle.

Weiterführend: Oracle: Übersetzungen mit Text Messages, die APEX-26.1-Release-Notes und die APEX_LANG-API-Referenz.