Wednesday, January 29, 2025

Translate an Oracle APEX application: essential considerations

It's almost an year since I assumed responsibility for maintaining a multi-language Oracle APEX application that was originally developed in APEX 3.2. My earlier exposure to APEX's translation capabilities was limited to surface-level exploration: clicking through the interface to create a basic two-language application. However, maintaining a production multilingual application revealed layers of complexity and considerations that weren't apparent in those initial experiments.

I will not explain how to translate an APEX application - many comprehensive guides for APEX application translation are available online; I will only highlight some important aspects.

1. The primary language version serves as the master APEX application; every translation is, in fact, a distinct APEX application, a smaller copy of the "master";  these copies are not visible in the APEX Builder but they can be queried through the apex_applications view.

2. every change in the master application must be "seed", and the translated applications must be published to reflect the changes

Improvement in APEX 24.2: When translations are not synchronized with the master application, a warning message appears on the export page

 

3. When deploying a multilingual APEX application to a new environment, we must include both the master application and all its translation copies in the installation process. The complete deployment package must contain the master application (primary language version) and all associated translation copies

Changes in Export application page: Pre-APEX 23.x: the export page has a list element containing all application to export, including master application and all translated copies. This allowed developers to directly select and export one by one the multi-language application. Starting with APEX 23.x, the export page does not display the list of application anymore; we can export only the "master" application. 

We have 2 possibilities to export the translated copies:

a) In the Export page, the tab Components has a switch to enable Export translations. When it is ON, the result of export is a single file, containing the "master" application and all the translated applications.

b) We can export individual translated applications from the App Builder menu. In this way, we will have one export file for each copy.


 

4. Every label, every title, every message, every text can be translated. All translations are centrally stored in the APEX translation repository, creating a single source of truth for multilingual content. One particularly powerful feature is the ability to access the translation repository directly from database objects through the APEX_LANG API. This integration extends translation capabilities beyond the APEX interface into our PL/SQL code (packages, procedures, functions, triggers). What I found useful was the CREATE_MESSAGE procedure: I could define some new translatable text programmatically, without accessing the APEX Builder interface, and integrate it directly within database packages.

 

That's all for now.


 

No comments:

Post a Comment

Oracle APEX Build Options: the what and the hows

In my department, we frequently have multiple teams working simultaneously on 2-3 features within the same APEX application, with each featu...