One of the many good things about Oracle APEX is the builtin capability to create multilingual Applications. It gives you a set of tools to translate your Application and provide it in multiple languages at the same time.

One of the Key Components of this Translation Mechanism is the creation of an XLIFF File. This File contains all text strings of your Application (that is all your UI Strings, not your Data) and from which to which language it should be translated.

This File then goes to a Translation Office or to a colleague who speaks the required language. They load this XLIFF File into an XLIFF Editor and translate all the texts in there.

Of course there is a broad range of XLIFF Editors with different features, starting with a very basic Editor to simply translate string by string. At the other end there are Translation Suites with Term Databases and Auto Translation Support and whatnot.

But basically the all work similiar: at first they read the supported XLIFF File, the betters now do an auto translation and then the Files content is shown to the User. That looks something like this:

Picture of an XLIFF Editor (CMS Kite) with a standard APEX XLIFF

Could you work like that and create a correct translation? I doubt it.

All the information about what you are translating is missing. You just see a text string without knowing where it is used. So all you can do is a word by word translation, which sometimes can create rather funny results (ever tried to translated something with Google Translation where you know what the outcome should look like?).

Now imagine your customer wants you to change the text of a Button on Page 3 from “Logout” to “Goodbye”, without changing the other Links and Texts on this Page.
That’s the point where you either stutter “..i..i can’t, i don’t know which of all these Logout-Texts is the button on Page 3…” or you try to change one after the other until you find the right one.

No wonder this is a complicated task, when you take a look into the XLIFF File generated by APEX you see something like this:

<trans-unit id="S-2-787383050723570607-101">
<source>Logout</source>
<target>Logout</target>
</trans-unit>
<trans-unit id="S-2-787383152187570608-101">
<source>Print</source>
<target>Print</target>
</trans-unit>
<trans-unit id="S-2.1-787383050723570607-101">
<source>Logout</source>
<target>Logout</target>
</trans-unit>
<trans-unit id="S-2.1-787383152187570608-101">
<source>Print</source>
<target>Print</target>
</trans-unit>
<trans-unit id="S-2.1-830770714218750168-101">
<source>Feedback</source>
<target>Feedback</target>
</trans-unit>
<trans-unit id="S-4-787382566755570601-101">
<source>Home</source>
<target>Home</target>
</trans-unit>
<trans-unit id="S-4-787382647591570605-101">
<source>Customers</source>
<target>Customers</target>
</trans-unit>

But don’t you panic now. Here comes another ApexLib Tool to the Rescue:

The ApexLib XLIFF Export Tool

The ApexLib XLIFF Export Tool is thought to be used instead of the builtin APEX XLIFF Export.

It creates an XLIFF File in Format 1.2 which contains tons of extra information, like: the Application Structure and the Context (what, where) a Text is used.

Once you load that into your XLIFF Editor it looks like this:

ApexLib XLIFF Export File in CMS Kite

ApexLib XLIFF Export in SDL Trados

Way better, isn’t it?

Now you actually know where the text you are working on is used and what it’s purpose is.

The next time someone wants you to change a Button Label on Page 3 you can say: “Sure, no problem.”

The best thing is: after you translated all those texts you can take this XLIFF File and re-import it into APEX using the standard APEX Translation Upload XLIFF Functionality.

So all you need to change in your translation workflow is the creation of the XLIFF File, the rest stays the same as you are used to right now.

Isn’t that great?

Try an ApexLib XLIFF Export File

Download this file and load it into your XLIFF Editor and see the difference!

Currently i have tested the XLIFF Files in CMS Kite Editor and in SDL Trados Suite (thanks to George for supporting me there), but it should work in any XLIFF 1.2 Compliant Editor.

Join the Beta Program

The ApexLib XLIFF Export Tool is currently in Beta-Test, if you want to join the Beta Program or just want to be notified once the XLIFF Export Tool is officially released, just drop me a note.