Friday Aug 19, 2011
Thursday May 12, 2011
By Ultan O'Broin-Oracle on May 12, 2011
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.
Preferences and Under the Hood in US version.
Options and Under the Bonnet in UK version.
Wrench and Under the Hood in US version error page.
Spanner and Under the Bonnet in UK version help system.
Customize in US version UI tooltip.
Customise in UK version UI tooltip.
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
By Ultan O'Broin-Oracle on Jan 05, 2011
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.
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
- Iconic #WearableTech: Gucci Translate Anyone?
- “Hello. Is it .ME You’re Looking For?” Storytelling for Coders
- Oracle PaaS4SaaS UX Enablement is Global
- Hamburger is the New Discovery: Chinese Mobile App UI Trends
- The Minimum You Need to Know about Internationalization
- Oracle ADF and Simplified UI Apps: I18n Feng Shui on Display
- Translation and UX Trends in the Enterprise: Your Reason to Attend Oracle Apps UX Events
- Shout-out for Oracle Cloud and Fusion Apps Multilingual Support: Pseudo-translation Explained
- Translating Fusion Apps Customizations: Composers mean Usable Apps in Any Language
- Oracle Fusion Applications Simplified UI Translated (NLS) Versions Release 7