Apex: Translating Messages Used for Reports

Oracle Application Express is translated into German, Spanish, French, Italian, Japanese, Korean, Brazilian Portuguese, Simplified Chinese, and Traditional Chinese. If your application uses a language that is not among the ten languages into which Oracle Application Express is translated, you need to translate messages displayed by the Application Express reporting engine.

For example, if you develop a Dutch application and want to include report messages (such as pagination) in Dutch you need to translate the strings used in messages displayed in reports.

As example we will replace the word ‘Next‘ displayed in a report navigation with the dutch word ‘Volgende‘. In order to do this we will have to perform the next actions:

1. Go To your application and perform the next actions:

A. Click Shared Components.

B. CLick Edit Globalization Attributes
C. Click Message Translation (right on the page)

2. On the Translate Messages page, click Create.

3. On Create/Edit Text Message, specify the following

A. Name – Enter the name of each report message that needs to be translated.
The name for the ‘Next’ message is ‘PAGINATION.NEXT‘. More info about these names can be found here.

B. Language – Select the language for which the message would be used

C. Text – Enter the text to be returned when the text message is called. We will set the word ‘Volgende‘ here.

4. Click Create.

5. Run your report.

Apex: Using a Date Format Mask at Application Level

Every Apex application contains a lot of report pages with date columns and form pages with date fields. For all these items you can specify a date format mask. Never asked yourself if it is possible to define that format mask only once at a central place in your application?

With PICK_DATE_FORMAT_MASK you can. This is a user defined substitution string at application level. It is the best way to keep the dates consistent throughout your application.

  1. How to create the PICK_DATE_FORMAT_MASK substitution string?

    Creating the PICK_DATE_FORMAT_MASK substitution string is done on the edit application attributes page. So, navigate to “Edit Attributes” (application level) à “Definition” and scroll down to the “Substitutions” region. Enter “PICK_DATE_FORMAT_MASK” in the “Substitution String” column and enter your date format mask (here “DD-MM-YYYY”) in the “Substitution Value” column. Press “Apply Changes”.

  2. How to use your application format mask on a report page?

    Suppose we have a report page presenting table “EMP” with column “HIREDATE”. For that “HIREDATE” column we want to use our application level format mask.

    Go to the “Column Attributes” page of the column “HIREDATE” and go the “Column Formatting” region. For “Number/Date Format” enter “&PICK_DATE_FORMAT_MASK.”. Press “Apply Changes”.

  3. How to use your application format mask on a form page?

    Suppose we have a form page to create or edit a row from table “EMP”, with also the “HIREDATE” column. For that “HIREDATE” column we want to use a date picker with our application level format mask.

    Go to the “Edit Page Item” page of the item on “HIREDATE” (here “P2_HIREDATE”) and go the “Name” region. For “Display As” choose “Date Picker (use application format mask)”. Press “Apply Changes”.

    This is the result when we run the form page:

  4. Other uses of the PICK_DATE_FORMAT_MASK substitution string

    Formatting data while selecting it from the database can be performed by including the PICK_DATE_FORMAT_MASK in a TO_CHAR function:

    TO_CHAR ( hiredate, :PICK_DATE_FORMAT_MASK )

    Converting the text presentation of a date item to a date using the correct format mask can also be done by using the PICK_DATE_FORMAT_MASK in the TO_DATE function:


Integrate Google Maps into your ApEx application

Google Maps, a free service from google that offers dynamic and interactive maps, offers a Google Map API so developers can integrate the service into their website or application.

The first thing you need to do is to register with Google. Then you can go to Google Maps API page and sign up. Save the example code and the key so you can use it later.

Now we implement it into an ApEx page:

Create a new Page with an html region. Go to Edit page and perform the next action:

DisplayAttributes: Put “Cursor Focus” on “Do not focus cursor”.

HTML Header
: Copy your JavaScript into the HTML header, this script will call the map. You can call several classes to customize the controls on your map.

On Load: You will call the JavaScript to start the map when the page loads.

Now you can go to edit the html region and specify the location of the map:

Source: In source we place the div-tags where the map will show and its width and height.

Finally run your page:

Customize your map:

More info about how to customize your map with other default locations and buttons can be found here.

An example with a customized map can be found here.

Apex: Deploy Your Multilingual application in a production environment.
One of the great pro’s of Apex is the ease to put an application from a development or test environment into a production environment. You take an application export at the one site, and you do an import at the other site.

When you have to deal with a multilingual application, there are some extra steps to be aware of.

Everything related to translating an Apex-application can be found at “Shared Components: Globalization / Translate Application”. There you see the 6 different steps that are necessary to translate your application in another language.

A first thing to know is that an application has always a primary language. This language is defined via the “Edit Globalization Attributes” on the Attributes pages for the application.

In our case we mapped this primary language application (with code ‘en’ and APP_ID = 144) to two other languages:

  1. One for language-code ‘nl’ (= dutch) => APP_ID = 145
  2. One for language-code ‘fr’ (= french) => APP_ID = 146

The strange thing here, is that you have to assign your self an application id for the “translated application”, Apex does not propose anything. Of course the APP_ID is unique, so the chosen APP_ID may NOT exist yet in your apex environment.

This means that after step 1, you end up with 3 different applications within your workspace. But in the application builder you only see the primary, master application (144). The two other ones are not visible as stand-alone applications.

Suppose you have finished all the other necessary steps, you have tested the applications in the 3 different languages, and you want to deploy those three applications in your production environments. How do you proceed from here?
In our example we deploy from development to production.

a) In development: Take an export of the primary application (144)

b) In development: Seed and export the translation text of your application into a translation file (.xlf).

So, the xliff file and the application export file (step 1) should be based on the same metadata. You may not change translation-sensitive stuff anymore in you application once you have generated the xml-file. Otherwise you need to restart the translation process.

In our case we have a xml file for the dutch and one for the french translations. During the development process you should have translated those two files where for every source element, you entered a translation in the target element. Those translated xlf-files you need further on.

c) In production: Import the application (144)

You will notice, that, though you only imported application 144, the mappings with the two other ‘translated’ applications (145 and 146) are automatically created.

d) In production: Seed and export the translation text.

This is the same as in step b), but now in the production environment.
You really need to do this step. If not, the next step will not work !
I assume that apex need to prepare his internal metadata, necessary for the further translation process.
So again, you will have two xliff-files, but you don’t use them further on !

e) In production: Do step 4 of the standard translation process (via Shared Components) and apply the xliff files you have created and translated in step b). Publish this uploaded translations and your application is now available in three different languages.

Apex: How to Disable a Text Area ?

Every application contains pages where the data should be displayed in read-only mode.

For a normal text item, you can declare a field as “Display as Text Item (does not save state)” and the value is shown as HTML
(see Text 1).

For a multi-line text area there is not a similar option.You can leave it as such by defining it as “Textarea (auto-height)”
(see Text 2).

This can be confusing because the enduser can edit the field and have the impression that he may change the content.

Another possibility is to set on the Element-level for that textarea-field the HTML Form Element Attributes to “disabled“.

The disadvantage of this solution is that the scrollbar disappears; so, when you are dealing with a large textextract, you may not see the complete content (see Text3).

Javascript can help us to resolve this problem. By defining the two following steps, you can scroll within the textarea, but you may not change the text
(see Text 4):

  1. Include following lines of code on the page HTML header:

  2. Add a call to this javascript function in the Region Footer of the region where the textarea belongs to, specifying the item you want to disable

Apex: Caveat PK column name length

It is highly encouraged in Apex to use system generated, single primary key columns whenever possible.

When choosing multi-column, composed primary keys, you quickly get in trouble when dealing with the standard MRU Processes. This is limited to handling tables with at most a 2 column primary key.

So, it is a good practice to work with auto-generated, sequence-based PK’s, on 1 column.

There is one caveat that you should be aware of.

Within Oracle, the maximum length of a column name is 30 characters.
However, when you plan to build tabular forms on your tables, the length of the primary key column name may not exceed 22 characters.