Apex: XLIFF Translator, the editor (step 3.2)

The difficulty with editing the XLIFF- file is that you do not know with which item/object the translation text corresponds in your application.

As explained in a previous blog, we discovered a way to link a translation item to a specific apex object type. This information is stored in the flows-table wwv_flow_translatable_cols$.

Therefore we decided to build a GUI-editor on top of that XLIFF-file.

In a first step, we loaded the XML-file as such in an XMLTYPE column, linked with a specific source and target language. By using SQL/XML features and X-Path expressions we extract the data and transform it to a relational structure.

Since all the data-to-be-translated is now seeded in our internal translation table, it is easy to build an user-friendly Apex page on it.

As you can see, we provide extra filtering options including the Apex object type. The screenshot shows only the labels of the tabs in our application.

There is also a small accounting on the work already done: we have already translated 3 of 4 tabs; for the complete XLIFF file, we translated already 175 of 400 items.

We extended the utility also with the notion of a ‘dictionary’. By default we have already preloaded a small dictionary with typical words that we see in every application: create, save, delete, search, home, admin, …

As user, you can extend this glossary with values (business terms) that are often used in your application.

In our example, we can decide to add the translation for “Photos”, “Foto’s” to our dictionary, by clicking on the right-most arrow:

Once added a check-mark appears between the two icons. A small help text on top of the page explains the different icons.

This mechanism can accelerate the translation work to a high degree: you can extend gradually your own dictionary and apply on a regular base those new words to the items that are not translated yet. We also provide a separate tab-page in the application where you can maintain the content of your dictionary.

In a next blog, we will explain how you can extract the relational data back to the initial XML-structure once the translation work is done.

Apex: XLIFF Translator, Step 3.1

As posted last week, we started developing our own utility to help us in step 3 of the translation process of an Oracle Application Express application.

The global idea is to create an Apex-frontend on top of an XLIFF-file.

XLIFF is an acronym and stands for “XML Localization Interchange File Format“. You can read all about is on following url.

We decided to take a pragmatic approach. We started with the XML-file as it is being exported by Apex into the XML translation file.

The following examples show some lines of the generated XML:

You notice that each translatable element has a source and target element, encapsulated in the tag, identified by an id-attribute.

So it should be quite easy to upload that file in an XMLTYPE-column and transform the xml-structure to a relational table by using one of the XML features of the Oracle Db.

Following SELECT gives a part of the query we used: t.xliff refers to the column storing the complete XLIFF-file in our custom table with the name apex_translation_files:

SELECT extractValue(value(xx), '/trans-unit/@id') id,
extractValue(value(xx), '/trans-unit/source') source,
extractValue(value(xx), '/trans-unit/target') target
FROM apex_translation_files t,
TABLE(XMLSequence(Extract(t.xliff, '/xliff/file/body/trans-unit'))) xx

In the XML-excerpt, you can also see that the same source-value can appear multiple times, but that there is a small difference in the value of the id-attribute.

It is clear that this id should have a specific meaning for the translation process, but we couldn’t find any documentation on this topic.

The id-value has 4-data fragments, separated by a ‘-‘: e.g. S-2-11453021424239212-144

The first element is always a “S”.
The third element contains typical an unique identifier of a record.
The fourth element is obviously the APP_ID of an apex application.

The second element intrigued me. It was a reduced set of possible values; that must be some typology of the text-to-be-translated.

We dived into the flows_020200 schema and noticed two important tables related to the translation process:

  • wwv_flow_translatable_text$: this table contains all data coming from step 2 in the translation process “Seed the Translable Text” and we discovered that the 3th element of our id-attribute corresponds with the translate_from_id -column

  • wwv_flow_translatable_cols$: this table contains all apex-elements that can be translated. The id-column of this table corresponds with the second element of the id-attribute in the xliff-file.

Putting all those elements together, we were able to built the first step in our utility: Upload and Seed the original XLIFF-file…

… and our previous XML excerpt presented in a relational way gives following result, where the value of the id-attribute “S-2-xyz” is referring to “the Navigation Bar Icon text” or “Icon Image Alt”

(will be continued …)