Translations in Application Express 4.1 Early Adopter 2

With Application Express 4.1 Early Adopter 2 recently announced, one of the enhancements that needs clarification are those affecting translations. The purpose of this post isn't necessarily to explain how the translation process works in Application Express but, instead, to explain the improvements. These aren't earth-shattering enhancements, but they're intended to improve the process and information for the developer.

It does begin with a revision to the translation home. Here, a developer should be able to quickly see what translations are defined for the current application and if any of them require synchronization. A translated version requires synchronization when the primary application has been changed, but the translated version hasn't been published, to pick up this change. Anyone who has worked with translations in the past has gone through the pain of debugging a translated version of their application, only later to realize that it's out of sync with the primary application.

When it comes to seeding and publishing, these operations can now be performed on the same page and in bulk. If you have multiple languages mapped for your application, you can quickly seed and publish them all from the same page.

And the same type of improvement has been made to the XLIFF file upload and apply translation process. You can now upload up to 10 XLIFF files at a time and also apply these files to different translations in one operation.

Lastly, and most importantly, is the ability to include the application translations in an application export. Prior to Application Express 4.1, if you ever needed to move your application to a different workspace or different application ID, there was no practical way to bring along your translations. You basically hit the end of the road. Now, as an option to application export, you have the choice to include all of your translations in the application export file.

While these enhancements aren't perfect, they are at least an improvement over the previous interface and process. I must give credit to a few people for pushing for these changes.

• David Bliss from the Oracle Store team has cringed every time he has to perform the translations in Application Express 4.0 for the Oracle Store. The Oracle Store is translated into a multitude of languages and the process he must follow is very cumbersome. He offered to even write the necessary changes in Application Express Application Builder for us if we didn't have time. David provided a very detailed recommendation and extensive feedback on how this should be improved. There is nothing like getting feedback from an end-customer who frequently lives and breathes through this process.
  
  
• Francis Mignault from Insum has been asking for years for a way to move translations from one instance to another, and to different applications. I praise his persistence. He also helped to rationalize the numerous ways to accomplish the same tasks.
  
  
• And lastly, credit must be given to Roel Hartman and Peter Raganitsch - for Peter's presentation at Oracle Gebruikersclub Holland and Roel's blog post about it. When someone says about translations in APEX "In short: it works, but takes a lot of work and maintenance is not so simple. So if you can stay away from multi-lingual applications, you should.", that is not to be perceived as a compliment. And justifiably so.