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. 


Wednesday Feb 02, 2011

Text Expansion Awareness for UX Designers: Points to Consider

Awareness of translated text expansion dynamics is important for enterprise applications UX designers (I am assuming all source text for translation is in English, though apps development can takes place in other natural languages too). This consideration goes beyond the standard 'character multiplication' rule and must take into account the avoidance of other layout tricks that a designer might be tempted to try. Follow these guidelines.

  • For general text expansion, remember the simple rule that the shorter the word is in the English, the longer it will need to be in English. See the examples provided by Richard Ishida of the W3C  and you'll get the idea.

    So, forget the 30 percent or one inch (excuse me?) minimum expansion rule of the old Forms days. Unfortunately, remembering convoluted text expansion rules, based as a percentage of the US English character count can be tough going. Try these:

    Up to 10 characters: 100 to 200%
    11 to 20 characters: 80 to 100%
    21 to 30 characters: 60 to 80%
    31 to 50 characters: 40 to 60%
    51 to 70 characters: 31 to 40%
    Over 70 characters: 30%

    (Source: IBM)

    So, it might be easier to remember at the prototyping and design stage a simpler rule that if your English text is less than 5 characters then allow it to double in length (an increase of 100 percent) during translation, if it's more than 20 characters then allow for a 30 percent increase, and if it's in between those two ranges then assume a 75 percent increase. (Bear in mind that ADF can apply truncation rules on some components in English too).

    Note that iIf your text is stored in a database, developers must make sure the table column widths can accommodate the expansion of your text when translated based on byte size for the translated character and not numbers of characters. Use Unicode. One character does not equal one byte in the multilingual enterprise apps world).

  • Rely on a graceful transformation of translated text. Let all pages to resize dynamically so the text wraps and flow naturally. ADF pages supports this already. Think websites.
  • Don't hard-code alignments. Use Start and End properties on components and not Left or Right.
  • Don't force alignments of components on the page by using texts of a certain length as spacers. Use proper label positioning and anchoring in ADF components or other technologies. Remember that an increase in text length means an increase in vertical space too when pages are resized. So don't hard-code vertical heights for any text areas.
  • Don't force wrapping by using tricks such as /n or /t characters or HTML BR tags or forced page breaks. Once the text is translated the alignment will be destroyed. The position of the breaking character or tag would need to be moved anyway, or even removed.

    Don't be tempted to manually create text or printed reports this way either. They cannot be translated successfully, and are very difficult to maintain in English. Use XML, HTML, RTF and so on. Check out what Oracle BI Publisher offers.

  • When creating tables, use table components. Don't use manually created tables that reply on word length to maintain column and row alignment. For example, don't use codeblock elements in HTML; use the proper table elements instead. Once translated, the alignment of manually formatted tabular data is destroyed.
  • Finally, if there is a space restriction, then don't use made-up acronyms, abbreviations or some form of daft text speak to save space. Besides being incomprehensible in English, they may need full translations of the shortened words, even if they can be figured out. Use approved or industry standard acronyms according to the UX style rules, not as a space-saving device.

Restricted Real Estate on Mobile Devices

On mobile devices real estate is limited. Using shortened text is fine once it is comprehensible. Users in the mobile space prefer brevity too, "as they are on the go, performing two to three-minute tasks, with no time to read lengthy texts. Using fragments and lightning up on unnecessary articles and getting straight to the point with imperative forms of verbs makes sense both on real estate and user experience grounds.

Wednesday Jan 19, 2011

Designing Global Graphics in Enterprise Apps: Points to Consider

Continuing my series on translatability for UX professionals in the enterprise applications space, let's look at graphics.

The essence of designing a global graphic is simple: aim to create an image file that requires no subsequent intervention by developers or translators to make it suitable for any other language versions. Use these guidelines:

  • Design an image file that has no translatable text on it (including single letter such as B for Bold or whatever). The file should be used for every language version's UI without any further work on it.
  • Avoid graphics that might present cultural issues in the translated version. Use generic icons. Be wary of designs that use body parts such as hands or feet, pictures of people, relies or a visual pun. Avoid flags for languages.

    There are lots of possibilities of things to avoid here, usually recommended by people who don't work in the enterprise applications space but on global web sites. If you're using crucifixes and pictures of pigs in an enterprise app UI, you're probably going wrong anyway. Common sense please!

  • Use web-safe colors, but don't worry too much about overblown cultural issues about colors in the enterprise applications space. It's not like anyone will log a bug saying white and not black is the color of mourning in Asia, ignoring the coffin icons you've used for the Exit menu option (who ever does that?). Colors generally are only problematic when associated with objects, and not in their own right.
  • If using arrows or pointer image files in the UI, then make sure you create equivalent files with reversed directions so that they will work with bi-di  language versions of the applications. Although browsers can mirror HTML UIs based on DIR (directional element) or locale preference settings, they cannot flip binary objects such as image files.

    So, create an right-to-left (RTL) equivalent for any left-to-right (LTR) directional image, give it an "rtl" (for right-to-left) filename suffix and work with your developers to implement code to use the RTL image when the detected user's language is Hebrew, Arabic, and so on. And it test to ensure that it works. Here's an example:

    bidi_US_ltr.png
LTR version arrow points to search icon (correct)
bidi_rtl_wrong.png
How LTR version arrow points away from search icon in bi-di language version and towards an data entry field instead (incorrect)
bidi_rtl_right.png
How RTL version arrow points to search icon in bi-di language version (correct)

Use these guidelines for graphics that might require translator intervention (usually these are in user assistance components):

  • If there is translatable text on a graphic, then make sure the image has enough space to allow the text length to expand. Don't use abbreviations or acronyms on the image as a way to save space.
  • Supply image file format, font, color, line weight, and screen resolution information to the translation team so the translated image will have the same rendering and look and feel as they source image.
  • Create the image files in tools that support Unicode fonts so they will work for all languages.
  • For conceptual images, diagrams, and so on in user assistance deliverables, use an editable source file format that can be easily redrawn if necessary during translation, for example Microsoft Visio VSD format.
  • If using Adobe PhotoShop, supply the translation team with the PSD layers along with the final output format for comparison (PNG, JPG, or whatever).
  • If you've sample data shown in a spreadsheet or database table then provide the source files so the data can be localized easily too.
  • Avoid placing screen shots in documents. Use a tool like Oracle's User Productivity Kit  to easily recapture translated screens and to automatically translate UI widget names and actions. 

You might investigate the possibilities offered by SVG and XLIFF in the hope of making savings for graphics translation. Investing effort in transforming files to SVG, XLIFF, or any other XML format is not worth it relative to the cost of doing graphics the old way in my opinion (say where the cost is probably less than 5% of total translation cost). Defining and enforcing translatable elements in SVG is a pain and if a graphic requires redrawing after translation, then SVG is not worth it. Suck it up.

Do you have any other guidelines for designers working in the enterprise applications space? Find the comments.

(Incidentally, after I wrote this, I looked up my article in Multilingual Computing and Technology Volume 9, Issue 5 called Creating Easily Localizable Graphics  published in August, 1998. Still seems quite sensible!)

About

Oracle applications global user experience (UX): Culture, localization, internationalization, language, personalization, more. For globally-savvy UX people, so that it all fits together for Oracle's worldwide customers.

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

Ultan Ó Broin. Director, Global Applications User Experience, Oracle Corporation. On Twitter: @localization

Links

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today