Agile Localization: Three Strategies for Making It Work
Click here to close
Click here to close
Subscribe here

Agile Localization: Three Strategies for Making It Work

Agile Localization: Three Strategies for Making It Work

Agile Localization: Three Ways to Make It Work

In our “always on” content and development worlds, where the term “digital marketing” is essentially redundant, content shelf life is a fraction of what it only recently was, and “sim-ship” concepts have essentially been replaced by continuous development. To keep up in all your markets, your localization needs to be just as agile as your development.

In this second installment of a two-post series, I’m sharing three practical tips for putting “agile localization” to work. (If you missed the first post on things to consider for agile localization, you can find it here.)

1. Create efficient workflows

To avoid context issues and product knowledge gaps, it’s always best to use the same translator. But capacity and time zone constraints often mean a pool of translators is needed to get all the localization work done. Having multiple translators working on continuous localization iterations means workflow efficiency becomes more important than ever.

Automation has a big role to play here. For example, tasks can be created to analyze source content for problems (such as poor use of variables, bad syntax, or even style guide compliance) before a string is sent to translation. Sending badly written source text to translators simply adds another dimension of wasted effort.

Jobs can automatically be routed to the next available person in the pool of approved translators, and they can be prioritized to have translators start on the most important task as soon as they sit down to work. This eliminates much of the time and complexity associated with multiple handoffs in the traditional localization process.

Some teams have gone even further—cutting dozens of steps by giving translators direct access to their repositories. It’s hard to imagine a more efficient solution than this: the translator gets ultimate context info by seeing the string in the application, they translate it, and they submit it for publishing without the need for further handoffs.

Of course, it pays to invest in training the translators who will have this level of control, since a lot can go wrong quickly. But I’ve seen several of our customers use this approach to create an efficient workflow that allows small iterations to be published in minutes.

In extremely automated workflows, the process is designed to automatically look in the Content Management System (CMS) for each localization job to see if the text has been translated before. If it can’t find anything, it goes to the Translation Memory, then perhaps to a machine translation engine before the job is sent to the translator. They get a notification, log in, translate, and submit, and the job automatically goes into a queue to be reviewed and published. One click later, the new iteration is live on the website or SaaS platform.

Automation does take time to organize and build, so keep in mind what type of return you need to deliver and how long the automation can be used—or in other words, over what time period you plan to depreciate the investment. If you only iterate your software every few months, it makes less sense to automate, but with so many applications moving to subscription models, the world of quarterly updates seems to be nearing an end.

2. Use internationalization best practices, such as pseudo-localization

Internationalization best practices are a must-have in an agile localization model. Manually managing location-specific configurations, such as currency, date, and number conventions, can quickly become cost-prohibitive in a continuous localization model, so investing in internationalization development practices is essential.

For example, most development teams test the English release before it goes to localization, but not all of them pseudo-localize as well. (For non-loc readers: pseudo-localization is a quick way of “fake” translating your release by including in the test build some of the most problematic elements of different languages before translation costs are incurred.)

Pseudo-localization can flush out a lot of problems before translation and eliminate unnecessary bug regression. For example, faulty syntax that breaks the build or omits visible content, long strings that could get truncated, unsupported diacritic marks or special characters, or formatting only found in target languages can be easily detected through pseudo-localization.

Some systems will automatically screen for errors before translation, and some GUIs have dynamic display elements that make a few of these tests unnecessary. But pseudo-localization is still a valuable strategy, and is a relatively easy way for developers (or localizers) to rein in the potential chaos of continuous delivery.

3. Schedule periodic comprehensive testing

Agile localization jobs aren’t usually extensive—by definition they’re often small updates with tweaks and enhancements. As a result, it’s essential to have a comprehensive reality check at regular intervals. These can generally follow the standard best practices of functional and localization testing.

Some errors will be found and (thanks to your investment in automation) fixed quickly, but others may stay hidden for some time. That’s why it’s so important to regularly step back and look at the big picture.

By periodically doing a full contextual linguistic review (such as every couple of months or before major updates), you can capture some of the less obvious errors that may have crept in during agile iterations, and release an update that corrects them as required.

Agile localization in the real world

Of course, there’s one big reason a lot of agile development teams don’t do agile localization—it can be complicated and expensive. When you are gaining speed, you can inadvertently create some new challenges. For example, not catching a source text bug prior to localization can be a big waste, as it can mean more translation.

Consider recycling source content that has already been translated—updates to language versions immediately cost 15-30% more, even if all you need to do is tweak a high fuzzy match. This, plus all the transaction costs mentioned before, can add up. Many teams give up and just wait for the next major release, but this leaves some markets less supported than your home market—which may be giving critical momentum to the competition.

But with the right processes and automation in place, it’s possible to publish localized versions as quickly as the source version without slowing things down or increasing costs from excessive rework.

In reality, both agile and traditional localization will continue to exist side by side for a long time. But, as we saw in the first post in this series, when agile localization is appropriate, you can create real value for your organization by addressing the key elements of cost, cadence, and context, and by implementing the processes described above to build in quality control, automation, and efficiency.

Hopefully the tips I’ve shared in this series will help you achieve agile localization success.