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]

Thursday May 12, 2011

English as a Source and Target Language: The UX Dimension

I am often bemused by translation (or localization if you're outside the enterprise apps space) discussions on the interwebs that assume the source material for translation is always English and that the target language is always something else. The reality, of course, is different. There is a user-generated content explosion and much of which needs to be translated into English or other languages for global and community support reasons, multinational enterprises create content in languages other than English that may be relevant across their organization in other countries, and therefore needs translation, and so on.

And then we have the age-old debate about US English versus UK English. Some say it doesn't matter that UK English users receive US English content. Claims are made that UK users can 'figure it out' or are already so familiar with US culture that the differences in terminology or spelling between the two country variants  of English (yes, I know there are other variants) are transparently consumed.

I disagree. I think there is an important user experience (UX) dimension here. Admittedly hard to quantify in tangible terms, the use of the local variant in content is important and has an impact on user perception of the product. It can also have wider implications. Users who see themselves coldly described as  "ID  #" in a screen or help system when they should be called "Employee", "Associate", "Partner", or whatever, are hardly likely to warm to a product with hostile language and it certainly does nothing for corporate culture. In other words, the UX is diminished. Does it always have to be that way? No.

Google has done a very good job in providing US and UK users with versions of the Chrome browser that reflect the differences in terminology and spelling. This is done by allowing the user to select the version they want at download time, and then by language, regional detection (the web-based help using en-GB for UK users for example). Check out the following screens. See how "preferences" becomes "options", "hood" becomes "bonnet", "wrench" becomes "spanner", and "customize" becomes "customise". Did Google do this just because they could? Doubt that very much.

Under the Hood

Preferences and Under the Hood in US version.

Under the Bonnet

Options and Under the Bonnet in UK version.

Hood and Wrench

Wrench and Under the Hood in US version error page.

Bonnet and Spanner

Spanner and Under the Bonnet in UK version help system.


Customize in US version UI tooltip.


Customise in UK version UI tooltip.

Nice job.

This is something we need to explore further with enterprise application users. Users should have the language they use in their workplace or at home and not that of another country or region.

If they can't have that, then at least they should be able to change it easily to whatever they do want. That's what user-centered design and UX is all about.

Wednesday Jan 05, 2011

Translation and Localization Resources for UX Designers

Here is a handy list of translation and localization-related resources for user experience professionals. Following some basic guidelines will help you design an easily translatable user experience.

Most of the references here are for web pages or software. Fundamentally, remember your designs will be consumed globally, and never divorce the design process from the development or deployment effort that goes into bringing your designs to life in code. Designers, ask yourself today: Do you know how the text you are using in your designs is delivered to the customer, even in English?

Key areas that UX designers always seen to fall foul of, in the enterprise applications space anyway, are:

  • Terminology that is impossible to translate (jargon, multiple modifiers, gerunds) or is used inconsistently.
  • Poorly written, verbose text (really, just write well in English, no special considerations).
  • String construction (concatenation of parts, assembled dynamically). This seems particularly problematic in search or calendar user interfaces. Days, weeks, months, and years are gender dependent in some languages. Thus, we have the composite messaging and positioning  issue (my favorite):
  • Hard-coded fonts, small font sizes, or character formatting or casing that doesn't work globally.
  • Format that is not separate from content. 
  • Restricted real estate not allowing for text expansion in translation.
  • Forcing formatting with breaks, and hard-coding alphabetical sorting in one language.
  • Graphics that do not work for bi-di languages (because they indicate directionality and can't flip) or contain embedded text. The problems of culturally offensive icons are well known by now in the enterprise applications space, though there are some dangers, such as the use of flags to indicate languages, for example.


Doc and help considerations I can deal with later.

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



« August 2016