Wednesday Sep 07, 2011

What's in a Name: Global Considerations for Apps

Enjoyed this article about the assumptions made by programmers (and therefore developed applications) about names:

Falsehoods Programmers Believe About Names

"My system will never have to deal with names from China.
Or Japan.
Or Korea.
Or Ireland, the United Kingdom, the United States, Spain, Mexico, Brazil, Peru, Russia, Sweden, Botswana, South Africa, Trinidad, Haiti, France, or the Klingon Empire, all of which have 'weird' naming schemes in common use."

Head-wrecking stuff. Actually, it's a little unfair to blame it all on programmers, they aren't the only ones to fall into this trap, and if they have not been educated in the ways of internationalization, there's little point in blaming them. However, there are serious UX implications of these kinds of assumptions. You can read more about this impact on users in the usableapps entry Cross-Cultural Factors Should Be Considered in Enterprise Software UX Design.

"Names may require prefixes to delineate male or female employees, but sometimes there is no place to put these prefixes in the form fields. And some recent immigrants to Europe do not use last names (for example, those from Myanmar, Afghanistan, and Pakistan)."

Oracle Fusion Applications offers superb support for global names and how the user wants to see them. That's another post.

Bottom line:

  • Don't allow developers to design your apps, leave that to user experience professionals.
  • Internationalize code so that it is neutral of any one name format and can be localized for regional requirements.
  • Investigate your target market and what regional conventions means for the UX and design accordingly.
For more great information on the global challenges of handling names, and how you might deal with them on the UI and database side, see the W3C's Internationalization article Personal Names Around the World.

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!

Friday Apr 01, 2011

Context for All

Interesting post over on the Content Rules blog, discussing the issue of context (or lack of, really) for translators, and how it relates to granularity of content. It's great to see this issue raised and I think we need to be a lot more hardcore about examining the claims about how intractable the problem of lack of context for translation can be.

For me, the problem with this context debate is that it is decontextualized (ho, ho) from the total content lifecycle and the tools and process side of things. For one thing, has anyone considered what context an application developer or technical writer has when reusing content (whether burst DocBook objects in a CMS or DITA conrefs)? Is it any worse/better than what translation teams have? Surely, if content developers have context from their CMS (or development environment) then isn't the issue why translators aren't accessing the CMS/environment and working in there too? Why ever remove content from a database just so to translate it? What is very clear to me is that context can be easily and automatically derived from the development environment and included within a translatable file format, if you so design it. Here's a simple Oracle-related example:


Information quality helps a lot here too. A term should only have one meaning in that context. So, derived context, information quality, and repository-based operations can solve the problem. Sure, a badly written little piece of text copied and pasted into Notepad and sent around the world via e-mail is going to lead to trouble. Duh.

What translation teams should not be pushing for however, is dumbed-down text devoid of any real style or necessary references just to make translation easier. Contextual information is a critical UX. Bland, generic content is not - that stuff damages the UX in all languages. Nor should content developers have to "write in" context in the form of translation notes for translation teams. That is a waste of development time and resources. Derive the context automatically, instead.

Regardless of how this context is provided, the most frustrating part of this context debate is the lack of insight displayed by advocates about the application lifecycle. Context has been positioned by internationalization and translation teams as something exclusively required on translatability grounds. It's not. In fact, context is a critical part of any UX-effective customization or extensibility efforts.

Less than a quarter of enterprise application deployments stay 'vanilla'. The rest are customized: modified for customer needs, and with extra bits of functionality added on that need to look the same as the rest. Without context for developers and functional users, such customization/extensibility efforts can be very tough indeed in UX terms. In fact, 'translation context' columns in databases are usually repurposed description columns intended for development, implementor and customization team notes. That internationalization and translation teams never leveraged a wider argument in support of improved context doesn't surprise me.

I believe the context for all requirement is one that can be met. But it will be by UX people, and not translation teams.


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