Thursday Nov 21, 2013

Shout-out for Oracle Cloud and Fusion Apps Multilingual Support: Pseudo-translation Explained

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. 

Sunday Feb 12, 2012

Oracle E-Business Suite: Features and Capabilities for Global UX

There is excellent global user experience afforded to users of Oracle E-Business Suite Release 12, all based on solid internationalization (i18n) and out of the box multilingual support (MLS). The engineering and features were covered by Maher Al-Nubani, Director of Internationalization Development in his webcast about Oracle E-Business Suite Internationalization and Multilingual Features.

Maher covered such areas as single global instance deployment, Unicode, BiDi, regional preferences (locale), MLS architecture basics, international calendar and first day of the week support, currencies, and  multilingual reporting. Check out the presentation slides (PDF) for full details.

Bidirectional Support in EBS
Here's a few features and capabilities, amongst others, that I think are particularly well-grounded in meeting the user experience needs of Oracle applications customers who deploy globally.  These are the kind of usability areas that the Oracle Usability Advisory Board (OUAB) members address through the Globalization UX working group. EBS implementors, take note.

  • Lightweight MLS support: New in EBS 12.1.3, by using OAM, multinational companies can activate languages without applying NLS (translation) patches. This means the user interface (UI) remains in English but setup, data and reporting is in the customer's language.  This is a customer requirement often missed. Combined with localizations functionality, an English UI with language data entry and printing is a powerful and effective solution that enables enterprises to work globally while using and sharing information according to local conventions. Full translations can be later easily added if required, for extra flexibility and evolution of the user experience.
  • Complete Excel data exchange: Business users just love Microsoft Excel! And, in EBS 12.1.3, customers can export data using comma or tab separated values (commas, of course, can be other kind of delimiters in other countries/locales). Plus, a choice of Unicode UTF-8 or UTF-16 export options means users can safely use Microsoft Excel to handle their data's character set encodings.
  • Cultural calendars: EBS 12.1.1 added support for the Arabic Hijrah and Thai Solar calendars. EBS 12.1.2 allows users to specify their first day of the week (it's Sunday, and not Monday for some). These UI features allow users to work in accordance with their local customs and conventions, but without impacting business logic or data.
  • BI Publisher global reporting: BIP's excellent internationalization foundation enables customers to communicate with other parts of their organization, suppliers, vendors, and other agencies easily. Without any dependency on installed languages or the DB character set, customers can create a report template for their language, country or region, and translate it easily themselves using XLIFF. For apps customers, reporting in the local language using customized templates and flexibility in how they work is a very big deal.
  • More Unicode support: Been there for a while now through Unicode (UTF8) introduced in Release 11i, EBS 12.1 uses the AL32UTF8 encoding, based on the latest Unicode standard to support more characters and languages. AL32UTF8 is is the default Unicode database character set for EBS 12.1 installations for multiple languages. AL32UTF8 is the default in Oracle Fusion Applications Release 11g R2, by the way.
  • Additional language translations: EBS 12.1  is now translated into 34 languages, adding Indonesian, Lithuanian, Ukrainian, and Vietnamese. The myth that  every enterprise apps user speaks English has long been exposed as just that, a myth. It is also important to realize that not only do local users demand UIs in their own language, but the domain specific aspects of enterprise apps means that it is easier for them to understand and use translated versions, even when they do speak conversational English. Better productivity and user satisfaction in the workplace is the result.

Great features and support for our global customers! Refer to the resources at the end of Maher's presentation for availability, implementation details and more information. Watch out for some news about OUAB activities globally soon, too.

Friday Aug 26, 2011

Internationalizing Designs and Usability Testing for Enterprise Apps: Points to Consider

User experience is global, and usability research and testing must involve real applications users doing realistic tasks in all of Oracle's target markets worldwide. However, creating designs and prototypes for every language that Oracle translates its applications into (30 plus) is neither feasible nor required. Here's some guidance about creating lo-fi designs, prototypes and testing scenarios that will work well internationally, make the target audience comfortable, while obtaining relevant feedback on materials.

The Reality...

Optimally, the user experience shown in designs, prototypes and described in testing tasks should be in the natural language and use the regional preferences of users in the target market. Users should always be allowed to work in the language of their choice, entering and printing and viewing data, and seeing their local data, time, currency separators, sort orders, and so on of their region. The reality of the modern global enterprise allows us some more leeway however, and this can work in favor of more scalable UX processes too.

How to Adapt Designs, Prototypes and Test Tasks for International Audiences

  • Remove any obvious US functionality from the UI or required test tasks. For example, social security numbers, address formats, data pickers that launch US-format calendars, or popups on editable fields suggesting US date formats as examples.

Social Security Numbers are not used globally, so tailor your experience to the market

  • If localization functionality is being shown, then change the UI and tasks to reflect the reporting or other legal requirements of the country or region. For example, VAT in the EU instead of sales tax, what the various statutory requirements for employee leave and holidays are and so on. Consult with local sales consultants and localization developers to tailor the UIs.

Find out what requirements, laws and regulations are in operation for the workplace in the target market and reflect that.

  • Take care when showing personal or employment data in designs or prototypes intended the EU especially, avoiding invalid tasks that might cause privacy issues in Germany for example. Remember social media-type interactions and integrations too in this regard.
  • Adjust any functionality and testing tasks to reflect what users might do locally. For example, if searching for information using a mobile app, German users may prefer to search a German website (.DE domain) for local information, using translated keywords and so on.

Use international features to reflect the user activity of the target market.

  • Find our what are the most common formats and variables used by the organization as it works, and adjust any test tasks to reflect those. For example, rather than a list of currencies to scroll through, why not present the local users most used currencies at the top of a currency list of values.

Use the commonly used data and activities of the target market.

Other observations about taking international user experience considerations into account are detailed in the usableapps blog Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

Decide About Translating Designs, Prototypes, and Testing Materials

  • Whether the design or prototypes needs translation depends on the user profile and the work involved, so review that information carefully. In some countries (for example, Japan, Korea, China, France, and others) using an untranslated UI for testing is not advisable, and certainly for public sector users a translated version should be used too.
  • Do not fall for the old argument that “they all speak English” when testing in European countries. Although conversational English is widespread amongst users of enterprise apps in Europe, the domain expertise required by some enterprise applications is more easily acquired and functionality understood in the native language of the user. Any public sector testing will hinge on being able to provide translated designs and test scenarios.
  • In other cases, such as testing with users in US-based multinationals, an English language UI may suffice if it uses the regional settings of the local users and the tasks involved in any testing reflect what local users do when working.
  • Depending on the market and user profile and other information you may also need to translate any test instructions, questionnaires, surveys and other materials, as well as translating any quantitative data or other observations gathered. Test sessions may also require you to use an interpreter to guide users through tasks, so pilot these sessions so the interpreter and usability engineer knows what's involved, and the right cultural approach can be taken when coaxing information out of test subjects or helping them along.
  • Use professional translation services and interpreters who preferably have domain expertise in the test area. Do not rely on Google Translate. Working with local in-country domain experts who speak the language of the user is the way to go. Leverage the language assets and expertise of the corporate translation team, or already subcontracted translation companies working on applications.
  • Create designs in formats that can be easily translated. HTML is ideal, and PhotoShop layers or Visio (VSD) files can also be translatable.
  • If you cannot translate the UI, then be prepared to explain how to users how application will be translated, and also explain how the language shown in applications can be changed further. If in the UK, for example, be prepared to deal with the issue of US spellings used instead of the UK variants by emphasizing regional support, localizations, and how the language can be changed to reflect the enterprise requirements using personalization or other extensibility tools to maximize the usability of the application.
Be ready to explain translation, personalization, and other language change mechanisms.
Personalization is particularly important in the mobile apps space (as evidenced by the Apple iOS5 personalization feature, coming).

Using Regional Settings

  • Always use local regional or common formats in user preferences. In enterprise applications, multilingual support (MLS) is critical: this functionality allows users to enter and view data in their own language and use local settings while running the UI in another language; a situation often encountered in multinational companies. Change the US defaults for dates, times, currency symbols, decimal separators, and so on to reflect what is used in the target market.

Use the regional settings of the target market. Common formats help testing efforts scale.

  • Construct test tasks that require users to enter or use data using those settings, not the US equivalents. There is nothing more infuriating to non-US user than being told to enter a date of 03/03/03.
  • If you must compromise on these regional settings, for reasons of scale for example, then choose a common format instead over the US one. For dates for example, a common format of dd-MMM-yyyy will avoid confusion internationally.
  • Even something as simple as changing the sign in name in your application to a friendly local format can make testers feel more comfortable.

Do you have any other guidance on successful internationalization of designs, prototypes or usability testing? Any observations or tips to share? Let me know, using the comments.


Oracle Applications Cloud global user experience (UX): Culture, localization, internationalization, language, personalization, more. A globally-savvy UX making it all fit together for Oracle's worldwide partners and customers.

Audience: Enterprise applications translation and localization topics for the user experience professional (designers, engineers, developers, researchers)!

Ultan Ó Broin. Senior Director, Oracle Applications User Experience, Oracle EMEA. Twitter: @localization



« July 2016