X

An Oracle blog about translation

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!

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.