Menu

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:

One for language-code ‘nl’ (= dutch) => APP_ID = 145

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.

If you want to deploy your multilingual application, choose the same APP_ID’s for production environment, like you used in development environment.Suppose that during the import process into the production environment, you choose another APP_ID for the primary application, than step “c)” in the given example is not true anymore. You will notice, however, that the mappings with the two other translated applications (145 and 146) are not created. Even if you create these two mappings manually afterwards and if you seed, export and upload the xliff-files like explained in steps “d)” and “e)”, your application will not be translated…

Hi Jan,that’s an important thing to keep in mind, as well as the fact that, according to the online help, you can’t pick an application ID ending with a zero digit, i guess that Apex is doing some trickery using mod(app_ID,10), who knows. I never investigated or asked the rationale behind the application ID number that Apex spawns when you create a new application, but i presume they are not simply random numbers. At any rate, on one hand it must be said that generally speaking, Apex is very flexible with the handling of this numbers, except for this case, although i have never been a fan of design models where application numbers “mean” something, like 10 is development, 100 is test, 1000 is production or stuff like that. I prefer to have distinct boxes where applications have the same number, but i do understand it’s not always possible. For instance, all my production sites are hosted at http://www.shellprompt.net and in more than one occasion it happened i couldn’t keep my original application number because it was already taken. Rather than keeping two distinct numbers, i got the new one from the production environment and i used it in development too, changing the existing one. On the other hand, Apex could have used the application alias to do the mapping, giving some more flexibility in terms of numbers, but that’s not what we currently have.In the end, they (the Apex team) had to figure out a mechanism that would fit most cases, so either they didn’t worry about the conflicting IDs problem or they thought there were other options available anyway.Thanks for the comment and come back from time to time!Flavio———————-Annals of Oracle’s improbable errors.

Hi, I find your explanation very usefull. I wonder if you could write the sqlplus code to achieve tasks c),d), e) in production (Seed and export the translation text,upload xliff and publish), lets say to automate the translation process in a script. Thank you in advance. Gissel