Friday Aug 19, 2011

Translatability Best Practices for Doc and Help

Translatability guidance aimed at user experience (UX) designers who are prototyping doc and help interactions and content. Considering these points will make your content easier to translate. Areas for attention include respecting the demands of XML structured authoring (DITA, DocBook, or other), how to share content, avoiding  translatable attributes, not contributing to the horrors of hard-coded alphabetical sorting orders, steering clear of the PRE element for tables and such like, allowing for graphics text expansion and redraw,  taking care with indexing and keywords, dealing with UPK translation issues, and so on. [Read More]

Wednesday Feb 23, 2011

Oracle User Productivity Kit Translation

Oracle's customers just love the User Productivity Kit (UPK). I hear only great things about it from our international customers at the Oracle Usability Advisory Board meetings too. The UPK is the perfect solution for enterprise applications training needs (I previously "eviewed a fine book about UPK btw).

One question I am often asked is how source content created using the UPK can be translated into another language. I spoke with Peter Maravelias, Principal Product Strategy Manager for UPK about this recently.

UPK is already optimized for easy source-target translation already. There is even a solution for re-recording demos. Here's what you can do to get your source content into another language:

  • Use UPK's ability to automatically translate events and actions. UPK comes with XML templates that allow you to accomplish this in 21 languages with a simple publishing action switch. These templates even deal with the tricky business of using gender-based translations.
Spanish localization template sample

Japanese localization template sample

  • Use the Import and Export localization features to export additional custom content in a format like XLIFF, easily handled by translation tools. You could also export and import in Word format.
  • Rerecord the sound (audio) files that go with the recordings, one per screen. UPK's granular approach to the sound files means that timing isn't an option. Retiming demos isn't required. A tip here with sound files and XLFF-exported custom content is to facilitate translation context by avoiding explicit references to actions going on in the screen recordings. A text based storyboard with screenshots accompanying the sound files should also be provided to the translators. Provide a glossary of terms too.
  • Use the re-record option in UPK to record any demo from a translated application. This will allow all the translated UI labels to be automatically captured. You may be required to resize any action events here due to text expansion issues. Naturally, you will need translated data in the translated application too, so plan for this in advance. However, source-target language skills aren't required for the re-recording.

The UPK Player itself, of course, is also available from Oracle along with content and doc in 21 languages. The Developer and Setup is also translated in a smaller number of languages. Check the Oracle UPK website  for latest details. UPK is a super solution for global enterprise applications training deployments allowing source content to be translated into multiple languages easily. See this post on the UPK blog for more insight too!

I would like to thank Peter for his time in talking with me.

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:

LTR version arrow points to search icon (correct)
How LTR version arrow points away from search icon in bi-di language version and towards an data entry field instead (incorrect)
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!)


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