Problem Summary

The Text Message-based translation model introduced in Oracle APEX 26 is modern and recommended, however the handling of translation keys (the STATIC_ID provided in the &{STATIC_ID}. format) within the Label field is currently not developer-friendly:

• There is no visibility or validation that indicates whether a STATIC_ID is already used elsewhere. As a result, developers may unintentionally reuse an existing key without realizing it, even in cases where separate translations would be required. This lack of feedback makes it harder to intentionally create distinct translations for different UI components.
• The translatable text and its translations are only accessible through multiple navigation steps (Shared Components → Text Messages → Translations), which significantly slows down development and increases the risk of mistakes.
• The STATIC_ID entered in the Label field using the &{STATIC_ID} format does not automatically create the corresponding Text Message record, causing the translation workflow to break until the developer manually creates it in Shared Components. As a result, even in the primary language, a non-user-friendly placeholder text appears initially, interrupting the developer’s page design workflow.

This behavior leads to unnecessary navigation, maintenance difficulties, and translation inconsistencies.

Proposed Solution

I propose two possible solutions: a simpler (easier to implement) option and a more comprehensive (ideal) option.

1. Simpler Solution

Make the STATIC_ID displayed under the Label field clickable

The Label field currently displays the recognized STATIC_ID (even when it does not yet exist in the translation table). This value should become a clickable link that:

• automatically creates the corresponding row in apex_application_translations (for the default language),
• opens the appropriate Text Message record:

Shared Components → Text Messages → [STATIC_ID]

Additionally, in Shared Components → Text Messages, each row could include a link that navigates back to the UI elements where the STATIC_ID is used.

This would significantly reduce navigation and speed up the translation workflow.

2. Ideal Solution

Introduce a dedicated UI panel for defining the translation key and multilingual text

Instead of manually typing the &{xxx}. reference into the Label field, provide a structured interface where:

• the developer can specify the STATIC_ID for the Label, with uniqueness validation (including a warning if the value is already used elsewhere),
• the developer can enter translations for all languages defined in Text Messages.

Based on this input, APEX would automatically:

• create or update the corresponding Text Message record (populate apex_application_translations),
• set the Label field to the correct &{STATIC_ID}. format.

This solution would make the translation workflow consistent and significantly reduce the chance of errors.

Expected Benefits

• Ensures uniqueness of translation keys, preventing accidental duplication.
• Faster and more intuitive development workflow, with less navigation required.
• Easier maintenance of translation structures, thanks to unified STATIC_ID management.
• Improved developer experience, as the translation workflow becomes accessible directly from the component editor.
• Stronger integration between the Text Message-based translation model and the Page Designer.