Continuous localization: a few words of trouble!
Over the last few years, many translation and localization industry experts have pointed out that the average size of translation projects is getting smaller. We asked Welocalize’s VP Development, Doug Knoll, and he confirmed the trend: the average size of translation jobs they receive from their top 20 clients today is 63 (weighted) words. It takes just a few words to eat up hours of project management and reduce the profitability margin of projects.
This article tries to bridge the gap between software developers and translation experts by providing an overview of the peculiarities related to continuous localization — the art of making small repeating projects an automated and cost-effective effort. It’s aimed at both software developers and translation specialists.
The quantitative information mentioned comes from the surveys that István Lengyel, BeLazy’s founder, carried out together with Patricia Paladini Adell, who is the Globalization Director at CA Technologies, a Broadcom company.
Bridging the gap between translation and development
Ask a translation expert and they will most likely say that continuous localization means smaller and more frequent translation jobs. So that’s the reality today, but what’s the underlying reason? Why are translation jobs smaller today than, say, ten years ago and why the proportion of small jobs is likely to increase further? Understanding the changes affecting the translation industry requires learning about transformation in the technology arena.
The last decade has seen significant changes in the way software is made. Agile software development superseded waterfall practices after 2010. The biggest cloud providers – Amazon, Microsoft and Google – set up an effective strategy to lure even companies that didn’t show interest in shared system hosting (what the cloud originally was back then) into using their services. Cloud infrastructure has enabled the shortening of the software release cycle, as developers can get started quickly with basically any technology without a big upfront investment. Furthermore, cloud platforms provide good support for continuous integration / continuous delivery.
For most companies, expensive enterprise software is a thing of the past – in a way, the IT landscape got much more democratic.
What is Continuous Integration / Continuous Delivery?
Continuous delivery, which was first described in an identically named book in 2010, is a very powerful concept. Continuous delivery played a big role in agile’s success. Agile took over other software development methodologies in popularity because of the benefits offered by short release cycles, which can be most efficiently achieved applying continuous integration/continuous delivery practices, especially in the cloud.
According to an article on the Stackify blog, “Continuous Integration is about automating build and test processes to make sure the resulting software is in a good state, ideally every time a developer changes code. …The goal of Continuous Delivery is to make sure the software is always ready to go to production, even if the team decides not to do it for business reasons. Finally, Continuous Deployment is a process that automatically deploys the results of Continuous Delivery into the final production environment, usually every time a developer changes code. Companies using Continuous Deployment can push hundreds or even thousands of releases into production every day. It’s the method to quickly release software. Quick software releases mean faster time-to-market, which usually means that revenue comes earlier.”
While there are CI/CD solutions in the market like Jenkins, TeamCity or GitLab, it’s a developer’s (to be precise, DevOps’) task to prepare systems for automation.
When we think of localization in a continuous delivery set up, we refer to it as continuous localization. It’s one additional step in the continuous delivery workflow — the strings need to be localized. Developers should be responsible for internationalization, which means making sure that the strings in the application can be exported for translation and merged back again. Internationalization also means adjusting time and date formats, different input methods for non-alphabetic languages, making sure that expansion or contraction after translation don’t affect layout or even the assignment of hotkeys to functions. However, from the perspective of continuous localization, string export and import is the most important aspect. So internationalization requires a system that collects these strings and delivers them to the localization managers but there’s no standard method.
About 60% of the companies that we interviewed have built their own platform instead of using a publicly available (commercial or open source) solution.
Logically, it makes little sense receiving strings in automated fashion and then having to start sending emails manually to every person involved in the translation process: companies doing continuous localization are using some sort of translation management system (TMS) in an attempt to automate the entire translation process. In our survey, the proportion of those using a TMS was 84%.
How continuous is continuous depends very much on how the developers handle internationalization: with the right degree of automation and the “shift left” approach, i.e. detecting and remediating internationalization errors before they get to the translator, localization can become really efficient. Implementing this process correctly requires following standards and training cross-functional teams, and for this reason there are different levels of maturity in continuous localization.
The frequency of string updates is also differing. As software develops, new messages are added to the application’s interface (and way more messages relate to error handling than actual functionality), and some companies send content for translation very frequently: once or even more times a day, or when a certain amount of translatable content accumulates (e.g. 200 words). Other companies do localization once per development sprint, which can be once every two weeks. The timing may or may not correspond with the end of the sprint. If it does, it’s likely that the localized strings will only update later, for example at the next release. If it does not, some functionality that was not carefully planned and added may be released without localization. There are companies that do the bulk before the end of the sprint and a small update at the end of it.
Faster and more frequent iterations
Traditionally, localization was planned for the end of the development cycle. It included preparation, translation, review and in-context review, fixing the issues found, and approving the fixes. But the nature of agile development is changing the localization process. Those translation jobs that lasted around half a year and which were the norm for big projects such as new versions of Microsoft Office are becoming less frequent. Continuous localization projects still follow the steps in the traditional cycle, but they happen faster, with less volume and in iterations.
It is also worth mentioning that continuous localization is an approach that can work with any computer system. Take for instance e-commerce companies or content publishers which typically send small updates that don’t relate to software strings but to content stored in content management systems.
Agile localization vs. continuous localization
It was back in 2012 when we first started hearing the concept of “agile localization” within the translation industry. Now, in retrospect, we understand that the only difference between agile and traditional localization is mainly related to frequency. Everybody thinks agile localization is when a translation company receives work from a customer regularly. But that’s simply not enough. To live up to the expectations, agile localization would also need to mean that some members of the localization team are also members of the agile team, which often isn’t the case.
Today, we believe that the correct term for what agile localization originally stood for is, in fact, continuous localization. Why? Because continuous localization as a concept is closely related to the software development practices of continuous delivery.
Continuous localization has to be driven by the customer (the translation buyer) because it involves changing their processes. Without the active support of the customer and its teams, it is not very likely that a translation company itself can implement such kind of solution. But how can this be achieved? The first step to continuous localization is for the product and development teams to understand the importance of localization.
