Monday Aug 22, 2011

Agile Localization: More Questions than Answers. Still.

What are the best practices for localization (in the enterprise applications translation sense of the word) operating within the agile software development framework, using scrum for example? I posted a similar question on Quora, and haven't exactly been overwhelmed by the response. Not much change there, then.

The best reference I can find on the interwebs is Tex Texin's (@textexin) document Agile Localization Practices. Recommendations (October 2010). I exchanged some email with Tex about this piece before it was published, so I should disclose I have more than a passing interest in it. I would agree with Tex that the localization industry appears to be reacting to the agile framework adoption rather than help determining it. The evidence from the interwebs is that LSPs have a stock response in the affirmative, “Yes we do agile”, while being very low on 'how-to' specifics or showing any real thought leadership

Here are my own observations on the general seeming lack of 'hard' information.

  • One thing is very clear to me: If you development processes and tools aren't up to the job for agile-based operations, you will find out pretty quickly. Same for translation tools and processes. Whither the role of the crowd and disruptive innovation in agile localization.

    Internationalization (I18n) is a sine qua non for any agile-based localization, not just the basics of character set handling, code conversion, multilingual tables in databases, and country, language, or regional-neutral code that can handle variabilized settings for currencies, dates, times, sort orders and the rest, but translatability. Make sure your product uses technology that is internationalized, but pay attention too to areas of composite messaging, string externalization, the building in of context, and of unique and persistent Ids on strings and content or other devices to aid reuse.

  • Agile has key advantages in the areas of shortening innovation cycles, exposing technical and project risk early, and shortening time-to-market for competitive content. Getting real, working content out there to a global audience in multiple languages, early, means a better global UX too. The idea behind the framework is that all functions are performed together within sprints, rather than preceding or bolting on particular functions to the entire process – usually the latter, waterfall style. Parts of the traditional localization (and UX) process are immediately pressured by this agility.

  • How is terminology developed (for source and target)? Using locked-down, frozen terms in advance of development is hardly agile, yet it's common. Terminology takes time to research and develop in a source language, and getting the language equivalents agreed and onto some kind of usable system isn't an overnight task either. Terminology is also going to change during sprints, in response to customer feedback, like it or not.

    Possible solutions here are to start the agile process with the best terminology available, using possibly crowdsourced validation, and revise terminology as customer feedback comes in, in context from real user. Or allow users to personalize their own user experience. Why try to anticipate the ever-changing mindset of say, teen gamers in Korea when you can accommodate their opinions another way. An term submission and approval workflow and ability to reapply terms to code rather than a spreadsheet of opinion is the way to go here. A terminology-only sprint isn't agile.

  • Testing localized versions should be done in parallel. A build environment that can produce localized product or site versions automatically at regular intervals and publish them to customers for evaluation can be used. In the enterprise applications space, where complexity of functionality, and the need to integrate with other products, databases, and technology stacks, agile translation testing requires automation, coordination, and the setting of clear expectations as to what is in each build is a requirement, and isn't easy. However, a testing-only sprint ins't agile. That's the waterfall we all know and love so much.

  • Communications across all stakeholders in the localization process also needs to be considered. How is that done between development, internal client localization management, outsourced LSP project management, in-country translators, localization QA and linguistic experts working globally, across time zones? Does the daily stand up meeting scale in cyberspace? Video-conferencing? Plasma screens of daily objectives? Web-based reports? Scrum of scrums? Best of luck.

  • Some content is probably better suited to the agile localization process than others, and the range is broad: social media, web sites, mobile apps, games, anything where UX and language decisions are heavily dependent on user opinion or more complex UX-critical deliverables that don't require a ton of technical integration or the provision of dedicated build environments for each language version for sure. Content where terminology and style isn't mission critical works well with repositories full of stodgy content, but that's hardly competitive.

    In some of these areas, the traditional notions of language quality are challenged anyway, and the decisions of the users are the deal-breakers on what works in the market, not professional linguists. Such an approach only works in the enterprise applications space if its moderated carefully. Some middle ground, based on iterative process of getting good enough fast enough would work, but not if you're implementation cycle takes months, and you're a public sector organization behind a firewalls with very strict demands on what can and cannot be said. Tough calls for product owners.

  • Consider, of course, localizing user assistance (PDF, online help, multimedia). Very easy to say DITA, topic-based content is the solution, but how does that really help? What of the information quality? How is that content rendered? How much translatability has been considered? And what of the budget for this? If users don't want documentation, fine, but how do you know? It may be required to help users configure their application and actually use it. And in some markets, translated doc may be a legal requirement. How fast can you write doc or create videos or demos, and localize them to go with the software?

  • As for acceptance criteria and review meetings, well, how is feedback from global users and localization teams accommodated? What is the process for improving translatability and translation tools? How are development processes influences to improve the process next time around? How is the feedback from international customers made to support, to development, to product development? What about real-time feedback from users? Bug databases online? Focus groups? Private Twitter stream or Blackberry IMs with real users? Does your organization have any track record of doing any of this really well, anyway? If not, why would agile be any different?

  • Finally, why assume the source code and content is in English? How would an agile framework work for a Japanese game localized into English (or Korean for example). Do tools and processes work for those scenarios?

I don't know of any organization providing meaningful agile or scrum training aimed at integrating a full localization process into a product life-cycle. If you know of any, let me know using the comments. Other observations on agile and scrum are welcome too. Lots of questions, not too many answers. “Yes, we can” is a fine declaration, but let's hear some “Here's how we can do it...” statements too!

Saturday May 07, 2011

Notes from the Oracle Usability Advisory Board Globalization Working Group

I am really happy with the outcome of the inaugural globalization (internationalization, localization, and translation) working group sessions at the Oracle Usability Advisory Board Europe in the Oracle office's in Thames Valley Park, near Reading in the UK.

A large number of customers and partners from EMEA were in attendance, and representatives from Oracle Apps-UX and development flew in from the US and Ireland (i.e, me), along with participation from local Oracle teams.

The translation part of the event opened with a great presentation by Bettina Reichart, Director with the Oracle Worldwide Product Translation Group (WPTG). Bettina explained the importance of translatability as part of the product development effort, the WPTG language quality process, about terminology development, and how customers can participate in translated applications assessments.

Customers and partners are always interested to know about internal Oracle processes and how they can interact with them, and I intend offering more of such sessions at future meetings, covering localization, internationalization, and other topics too.

Pseudotranslated Oracle EBS screen (Pseudotranslated environments and testing are central to internationalization in Oracle. We will cover this topic and other Oracle apps processes in more detail at a future OUAB)

The data gathering exercise I designed for board members, asking them to identify their top internationalization, localization and translation issues and how they  impacted usability was a big success too. We discussed the findings and the possible follow ups in a lively, fully attended working group session that seemed to take on a life of its own! We addressed issues such as lack of space for expansion of text, partial translation issues, the importance of localization (in the Oracle enterprise apps space this means support for statutory and reporting requirements for countries and regions - VAT, for example) and questions about terminology and language style. I will follow up with each customer and partner.

But there was more. I was delighted that the board members astutely exposed more complex areas about international versions such as the need to cater for connectivity and bandwidth issues,  and it was so encouraging to hear customers offer insights about the importance of language as a user experience topic, ranging from the more tangible aspects (productivity, and the need for extensibility and customization solutions, for example) to the more intangible aspects about how language it can impact employee loyalty and user perception. I firmly believe that as individual user expectations change we need to explore language aspects more and how we can allowing users to have the language they really want. Vanilla already doesn't cut it.

Finally, it was great to spend some time with my friends in the HCM Localization and information development teams too. And of course, to spend some time in Reading again!

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.


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)!

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



« April 2014