10 Challenges in Agile Localization (and How to Address Them)
Click here to close
Click here to close
Subscribe here

10 Challenges in Agile Localization (and How to Address Them)

In our fast-paced society, new products and features are expected to become available instantly. Our customers demand and deserve it. Gone are the days when 1-2-year cycles are acceptable. And because of this, many software companies have changed their development cycle from traditional waterfall to an agile development process.

Let’s unpack this concept a little bit and explore the ways to enable this transition to agile.

Agile versus traditional

Agile—in both software development and in localization—is the development and release of smaller pieces of functionality in short cycles, usually a week. When that software is sold globally, those strings are handed off to localization at the same time, and they need to be localized and handed back within 48 hours or less to be in sync with the release cycles.

Where traditional software localization is optimized to handle bigger batches of strings connected through menus or dialogs, agile localization accommodates random handoffs of single or multiple unrelated strings at any time. Little to no planning information is available and worse, if it’s a new project, no historic data can be used to plan for resource availability.

To successfully take your localization program agile, here are 10 things you’ll want to consider.

Different processes are required

If you want different results, then you need a different workflow. This can only be achieved by restructuring your localization program from scratch. Instead of working in long, planned localization and QA cycles, teams need to pick up strings sporadically and localize these very quickly. To accommodate the ad-hoc nature of this work, the end-to-end workflow, including reviews and test phases, needs to be highly automated (to reduce human error and speed up work).

A core example: the handoff and handback process of deliverables. In a highly automated, no-touch process, no human interaction is required. As soon as strings are checked in by the author, these get submitted to the Localization Services Provider and the localization process is kicked off. When the translator has completed the work, the localized strings get submitted back into the production system and are automatically included in the next build. During post-processing, the target strings are run through a QA process, including, for example, spell checks, source-target formatting comparisons and string length checks.

And further, to be agile, the localization process itself needs to react to continuously changing requirements and challenges.

Process issues are inevitable

Especially for agile localization, workflows and processes need to work like a well-oiled machine. But new processes cannot be planned and set up without a risk of issues due to unknowns. Defects that appear during implementation and later in production need to be addressed immediately with Root Cause Analysis (RCA) and fixes that prevent the problems from recurring, ideally through automation of the underlying process.

Issues can also be avoided by continuously monitoring performance data—but this requires proper data capturing and intelligent data analysis.

Linguistic flaws are more acceptable

Flaws are a bit more common in agile workflows; in fact, choosing speed as a priority can introduce them. And linguistic flaws seem to be OK: end-users are tolerant of an error here or there because they value speed over perfection. After all, this is content that might otherwise never get translated, so customers are thrilled to get it. In an agile process, you just fix them in the next iteration.

You can combat linguistic flaws through linguistic testing and quality automations, of course, but you just might not have time for it.

Context is critical

Due to the short cycles and disconnected deliverables, proper context information is usually either unavailable or outdated. You just can’t get it in time. This not only makes it hard for translators to determine the right translation, but also causes trouble with keeping translations consistent.

Product builds, in source and target language, can provide a reference for translators to review strings in context if time allows. A translator can work with actual builds, emulators or even screen shots to get the context they need.

Recycling and translation automation speed up work

To keep the translation effort to a minimum and guarantee the highest consistency, strings need to be recycled as much as possible, or pre-translated through machine translation (MT).

How does it work? Before the strings are received by the translator, they are either recycled against a translation memory, or if there are no matches, get machine translated. The pre-processed (target) strings are then post-edited or, in case the recycling or MT is not useful, translated from scratch.

For maximum success, you’ll need well-maintained translation memories and trained MT engines.

Terminology is key

For consistency reasons, terminology definition and translation become even more important in the agile loc process. Developers need to provide new terms and their definitions right after implementation in the code. The new terminology has to be translated before software localization begins. Then, translators must be provided these terms and translations as reference. To easily access terms within the translation environment, most CAT tools provide modules or add-ins for termbase hosting and management.

Planning your terminology process is key to successful agile localization—and to fewer linguistic flaws to fix in the next iteration.

(We blogged about this recently: 8 Features of Terminology Management Systems We Really Love)

Localization testing might not be complete

Continuous product updates free end-users from major updates and provide them a constant flow of new or improved functionality as well as bug fixes. But often the quality of the updates suffers due to the inability to perform thorough testing before release.

To combat this, linguistic testing can be performed by the end-user. On websites, users can often provide feedback as comments at the bottom, and sometimes businesses facilitate direct user community involvement, enabling readers to modify the translated content themselves. For software, the quality can be evaluated through A/B testing. This is when two versions of the same product are given to different users, and their feedback and experience determine which of the two is more effective.

Localization must be integrated

In agile software development, localization cannot be an afterthought. The localization and product development teams should not be in silos. Localization teams must play an integral role in the software development process—the most agile development groups treat the localization staff as if they were part of their own team.

This requires the localization team to engage proactively upstream, including educating developers on globalization best practices such as internationalization. Any internationalization or localizability issue not only replicates into all languages; it interrupts a well-automated localization process.

Automations and humans working together

In the age of machine learning and artificial intelligence, workflows will increasingly be controlled by decision-making engines.

The translation management system Memsource, for example, provides the AI-powered Non-translatables feature. It recognizes content that does not need to be translated, reducing translation spend and speeding up the process. Yet, all this automation does not eliminate human assistance. People will still be involved as AI and the use of automation increase, but their roles will certainly change. (To take a closer look at the interplay between humans and machines, check out this slideshare.)

Implication of supply chain

Agile workflows require a much more flexible supply chain—work comes in sporadically, volumes vary and it must be turned around immediately. You must build a flexible team of available resources—freelancers—who can reply to job requests as they come in. The process of assigning jobs can also be automated: you would send out a request for translation and the first available resource can claim and complete that job. You can even look at harnessing resources that are always on and large in number—the crowd. But beware that it can be very hard to control quality when you work with this resource model.

As for any service, resourcing must be adjusted to specific client needs. What is their priority: rapid turnaround, linguistic quality or price? This will be the deciding factor in your resourcing strategy.


In this digital age, brands go global as soon as they are online. Customers around the world demand faster and faster updates—in their own languages—and luckily there is a model to enable that. When you make the switch from waterfall localization to agile localization, a keen awareness of challenges and pitfalls will help you set your program up correctly from the start.