Agile Localization: Myth or Reality?

Agile localization: myth or reality?

I think many of those who are working in translation industry already got used to small chunks of work that need to be translated within short turnaround time. And buzzword “Agile” emerged as one of popular tendencies. What does it mean in terms of localization?

What is Agile?

Agile is development practice and methodology that focuses on frequent delivery of working software, continues changes, tight collaboration between team members. In agile, there are two-week sprints, after each sprint there is software release. Usually team members hold short stand-up meetings every day during which they discuss work progress, new and existing features, define what piece of work each person is responsible of. As a result, they achieve tighter communication between team members, better understanding of requirements and final goal, and more flexible development process.

The difference between traditional waterfall and agile model is that in the first case all software requirements are strictly defined before development starts and it is hard to change them in the process. And in agile, requirements are changing very frequently and they are adapted regularly to appropriate circumstances.

How localization can become part of agile development?

In terms of localization, agile is more challenging than traditional waterfall process when development took a few months or even year. After finalization of release stings were collected, externalized and sent for translation. Translators had enough time to familiarize with the source and references, software, app, game or web-site they’re working on.

In the case of agile, localization starts after each sprint and often during the sprint (when new approved and updated strings are sent automatically for translation). So it is important to build dedicated team of translators and editors who are trained to use appropriate style and terminology, familiar with the product. Oftentimes those people are responsible for linguistic testing before the release.

In agile development projects, the localization project manager shall take part in stand-ups so he or she can pay attention of team to localization plans, work closely with developers, product managers and copywriters on issues that arise.

Localization teams should be trained in agile so they know its main principles and act accordingly for better collaboration with other team members and achieving more efficient results.

Moreover, localization process and tools need to be able to handle rapid iteration and support removal of obsolete content, frequent updating of refactored code.

Agile localization benefits and challenges

In my mind, no matter which parts of localization you’re involved in – management, development, translation – agile should be perceived as opportunity, not as threat. It allows to have a better localization process for managers; to have more constant and predictable flow of work, to work closely with developers and copywriters for translators and editors; to have more efficient collaboration and faster fixing of localization issues for developers.

When set up correctly, agile localization process can bring substantial benefits: new strings and updates are pushed automatically and you don’t need to worry about duplicated strings, reviewing of matches and manual extraction of strings. Translators can automatically receive notifications if there is a need to translate new strings or they can visit your “translation center” from time to time to check for updates. But in order to maximize benefits, your team has to invest time and efforts to set up processes and tools appropriately in the early stage.

Early sprints can be used for collecting key terms, creating definitions and translations of terminology, recommending improvements to the source text and the overall style of authoring. Special attention should be paid to controlled authoring (usage of controlled language) because language consistency increases reuse opportunities and therefore reduces localization cost.

Also, best practice is to create translation memory, localization kits, and references so you can identify obsolete strings quickly, and have materials to rely on for quick updates and validation.

Because software is changing frequently, UI and help materials should be updated accordingly and translated into multiple languages. In this case, it is important to have dedicated translation team (of in-house translators, freelancers or agency) so they can work on translation immediately after new strings are ready so software, app or game is simultaneously shipped multilingual.

A good practice during agile localization is to perform linguistic testing after translation of new resources is ready. It can help to find translation mistakes prior to release and to catch some functional bugs and bring them to developers’ attention.

In my opinion, there are many “shades” of the so-called agile localization and it is hard to find pure implementation of agile methodology during localization.

But nevertheless, agile opens many opportunities for all localization players. It just requires many efforts to gain more productivity and efficiency.

Image source: Microsoft