By Ultan O'Broin-Oracle on Nov 21, 2013
Ever heard the acronym "MLS" used in the context of Oracle E-Business Suite, Fusion or Cloud Service applications, and wondered what it meant? It stands for Multilingual Support. The Fusion Applications Developer Relations blog has the architecture details and is worth a read.
The business significance of MLS, along with the applications' translations known as National Language Support (or NLS) versions, and the localizations support required for doing business in different countries and regions, is that Oracle customers can run applications in different ways to suit their business requirements.
MLS architecture provides for such requirements common in the business world as when a multi-national customer needs the same application to support a wide variety of national languages, countries or regions globally, or where a customer needs an application user interface in one national language (the language of business, English for example) but to needs enter, store, view, and publish data in other national languages. The applications can be patched easily and safely (see how the tables separate logic from translatable strings) too. You can read more about the subject in my blog on the Oracle E-Business Suite features and capabilities for global user experience.
Those "Ω'+++ '+++ '+Ø" characters you can see in the table in the developer relations blog are, in fact, the ends of what we call pseudo-translated strings. This technique of automatically padding, or adding extra, or special characters to source strings ones is used in development environments to simulate what happens when an application is translated and deployed globally.
Pseudo-translated strings simulate text expansion (strings usually get longer than the source U.S. English ones by varying lengths) and that nothing gets truncated or misplaced in the UI, are a check for multi-byte (now Unicode) character set support, bi-directionality (or Bi-Di) enablement (for Arabic and Hebrew languages, for example), and are used to detect hard-coded source strings that cannot be accessed by the translation tool (in other words, will be left in English).
The pseudo-translated version of the application must be tested in a suitable environment with realistic data by development teams and tools. If something breaks in the environment during this functional testing then it can be fixed before translation, rather than finding out the hard way, after implementation. Oracle applications uses pseudo-translation simulations for Latin character-based languages, Asian-based characters, and for Bi-Di ones too.
You can find out the basics of making internationalized and easily translatable enterprise applications that meet the needs of local workers and global businesses, and about using best practices such as pseudo-translation and more, in my SlideShare presentation delivered at the Action Week for Global Information Sharing at the Localisation Research Centre in Ireland, a few years ago.