It’s a fact: the shift of software and content development from lengthy waterfall release cycles to continuous release models has been accelerating, and it’s becoming increasingly vital that enterprises quickly publish updates to all supported languages.
Your localization processes need to keep up. That means taking a new approach to localization that’s just as agile as the software development itself.
In the first of this two-post series, I’ll look at how an “agile localization” strategy can help you handle localization in the increasingly agile world of digital content. A world in which speed to market matters. A lot.
Making localization agile
Traditional localization is time-consuming. From choosing what to localize, to packaging it with context and support instructions, to coordinating resources and file handoffs, to translation, QA and re-integration, the localization process typically takes days.
While all of these steps are necessary, many of them can be automated to cut down on time and manual processing. Automation, as well as smaller handoffs and frequent iterations, are the fundamental building blocks of an agile workflow. Using an agile localization approach can lead to less overall waste. And it’s far more responsive to market changes and evolving end-user needs. This means you can release effective content more quickly across all your markets.
It can be done, and mature localization programs are doing it. I’ve even seen full localization cycles, including updates to CMS and TMS, completed in minutes.
A caveat, though: automating the localization process to that extent and translating every iteration isn’t right for everyone. One characteristic of continuous development and agile loc is that the process trades perfection for expediency. Since agile strives to develop working software in smaller, iterative chunks, it results in frequent changes and rework. Rework can be driven by errors or constant small refinements based on user feedback. The most important concept is delivering software that works, and this can turn the transitional localization model on its head.
Agile also encourages teams to take some risks—to not be afraid to make mistakes. Mistakes are practically inevitable as you push the speed of content to market. As Reid Hoffman, the co-founder of LinkedIn, said: “If you are not embarrassed by the first version of your product, you’ve launched too late.”
You may have heard me say: If you're not embarrassed by the first version of your product, you've launched too latehttps://t.co/r4JyKzzyWO— Reid Hoffman (@reidhoffman) 29. března 2017
Hence a core idea is to reduce the consequences of mistakes by making them easier and faster than ever to fix. This works best when the defects don’t have a big impact on the business.
To make small updates and more easily fix mistakes, it’s imperative to reduce the overhead of each transaction—but that can drown your team in a sea of version control issues and chaotic releases. There are two basic approaches to solving this: one is to automate as many steps as possible, and the other is to eliminate them altogether. By doing this, you’ll make agile localization work, and you’ll get software updates or new digital content out to market in record time.
Three things to consider
Making localization agile is about shifting to a continuous localization mindset. And that means rethinking three key components of your content operations: localization costs, cadence, and context.
First, agile localization means cost models and cost management need to change.
Every task has transaction overhead, and the most valuable human resources, such as the translator, have fundamental constraints to consider. When starting a translation, a translator must take some time to focus on the task at hand, understand the context of the job, and go through their own internal checklist to ensure they translate the content correctly. There are some fundamental economies of scale to this, largely based on the time it takes for these steps to occur. It may take a while to get up to speed, but once they're familiarized, they're on a roll.
A quick way to manage these constraints is to lower the time required to “get focused” on a translation task, by bundling small, similar jobs together, and by providing the translators with a lot of context about the product.
Using the same (or a small team) of translators is another option, since once they are familiar with the product, they will quickly get oriented. Consider having translators work through what they can during scheduled blocks of translation time. This makes translation costs more predictable and reduces incremental transaction spend, such as the time required to track and manage each transaction. Then you can either pay overtime for larger tasks or defer lower-priority tasks to the next scheduled time.
An alternative is to use a pool of qualified, responsive translators. This is a more scalable and responsive strategy, as you can better manage peaks and valleys in volumes, but the resources may not be as familiar with your product. To combat this, invest more in providing them with meaningful context materials up-front to ensure that quality and brand requirements are met.
In addition, transaction time is a critical element of the cost equation. Transaction time is the sum of all the task's steps: from defining the job and getting it to the translator to receiving the finished translation. One of the simplest ways to reduce this is to translate where the content lives, since that involves nearly zero transaction cost. This eliminates a lot of the steps in the translation process, but when moving files around is necessary, automation helps.
It’s worth keeping in mind, though, that while automation can make localization incredibly responsive, it can also back you into a process corner that can tie your hands for years. Automation can cost a lot to set up, and can be difficult and expensive to change, so visualizing a truly agile automation process means keeping the workflow as adaptable and flexible as the content itself. While there is really no such thing as a truly future-proof process or technology, being flexible towards a wide range of options is essential.
Your cost model should be closely aligned with your iteration cadence. Consider how often you release content updates and how you’re going to schedule and pay for the content to be localized. The answers to these questions can result in very different business models.
Many agile development teams work in two-week “sprint” cycles, which can drive a natural, regular cadence for translation. But in some teams, small code changes go into production several times a day. In the content world, updates in response to market changes might need to happen as soon as humanly possible. In each case, the cost of failure (or in this case, delays) should be part of the equation.
How often you need to run localization cycles to keep up with these iterations depends on several factors:
- The impact of changes on the user experience
- The incremental costs of the iteration (transaction cost)
- The orientation time a translator needs
- The incremental cost of delay
If the user benefit is low and transaction costs are high, it doesn’t make sense to continuously localize lots of small iterations. Periodically aggregating iterations for localization can be the most efficient way to go.
On the other hand, if you can automatically extract content for translation, or translate directly in a CMS, it’s relatively easy to manage frequent updates with minimal effort.
Ultimately, ROI doesn’t just come from faster time-to-market. It compares the costs of automation against the human labor needed to collect and publish content, plus factors in the time to fix inevitable mistakes. Spending thousands to automate a task to save just a few hours obviously doesn’t make sense. But thinking just in terms of ROI can backfire when automation unlocks new capabilities that were not even possible before. In our rapidly-evolving technological world, this can make or break your business more quickly than ever.
To get localization right, translators need context—a good understanding of the product, the market, and the customer base that helps them understand (and translate) the content in a way that makes sense.
If they do enough similar work such that their “preloaded” background knowledge enables them to do small jobs correctly, less time is needed for orientation. If the job is entirely new to them, it will take more time.
To complete lots of small tasks quickly, translators either need all the necessary context to be readily available when they start, or they need to already have extensive knowledge about the product. This reduces orientation and linguistic review time, and it’s one of the main reasons scheduling translation blocks can be really valuable.
When you’ve defined your cost model, iteration cadence, and context process, you’re ready to start making localization agile—and getting your content to end-users fast, in all your markets.
In the second post in this series, I share some tips for getting agile localization right. In the meantime, find out how Microsoft Office, one of the most mature localization models in the whole industry, has shifted to the continuous localization model of today.