Write to us. Creating a software product that can be sold in multiple markets is complex. Software localization plays a critical role in that endeavor but inadvertently sabotages it at the same time. This happens because localization is essentially a waterfall Trojan horse in a predominantly Agile development process. This mismatch may not be problematic in early stages, but it eventually drives localization costs through the roof; it delays releases and increases complexity for everyone involved. More importantly, inefficient localization processes also prevent businesses from scaling up at the pace they need. Many companies tackle this problem by changing translation vendors, buying new technology or reorganizing their teams, but none of that solves the issue. The wiser approach would be to address the cause – instead of symptoms – and redesign the localization process to become Agile too. In this article we’ll discuss how continuous localization (CL) models increase agility and also present some key elements that enable future scalability. Localization and Agile As a fellow consultant likes to say, translation must be part of the primary process and not a separate thing with rules and mind of its own. This article follows the same thought – in our case, the primary process is software development. This dictates that localization should closely follow the Agile principles too, in order to match the speed, flexibility, and collaboration with which that software gets created. As we mentioned, switching to CL does not necessarily require buying new tech or changing translation vendors, but it DOES always involve developing new pieces of the internal pipeline. True scalability is possible only if systems do most of the work, not humans. So that’s where companies should start if scalability is the goal. Unfortunately, translation professionals cannot automate localization on their own – help from other departments is needed. CL is a matter of business, technology, and process as much as translation, so most CL practitioners have approached exactly it like that – they added a product person and at least one software engineer to work alongside the localization professionals they already have. Although not cheap, having a dedicated product person and software engineer is a key prerequisite for any automation. Picture this new team as a Localization Ops team, mirroring what DevOps teams do for the development process. It is important to note that CL teams rarely need more people as the business grows, since automation handles most of the tasks. For example, in CL programs there is no need for localization project managers – people are there only to build automation, improve processes and manage exceptions in the assignment logic. Contrast that with traditional localization teams, which demand more hiring whenever 2-3 new languages or products are added to their workload. That is what makes CL programs radically more scalable and future-proof. Besides automation-building ability, having product people in the team ensures that localization has a seat at the metaphorical business table, thus securing a more strategic approach to this matter. This has traditionally been difficult to achieve if the localization team sat “far away” from product and engineering. Tech backbone Besides the people, the core prerequisite of any CL system is the automated extraction of new content/strings and merging of translations back into the product. This includes handling of updates, automated assignment of translation tasks and, ideally, automated screenshot generation. These tech components are crucial because, with multiple teams working at the same time on multiple products with multiple translators, it is impossible to keep track of everything and supply context information manually. Traditional localization teams need development freezes in such situations, which then creates more problems for the business than it solves. CL programs never requires freezes, another advantage. The next key part of CL is the automation of error corrections. Just like there will always be imperfections or bugs in new features, caused by the speed of work, translation errors will also get published to production. Unless people’s lives depend on your product, however, this should not be viewed as a negative thing as long as there is a mechanism for quickly detecting and fixing errors. Such a mechanism can be created by decoupling translated strings from the source code and storing translations in the cloud instead. In that case, whenever a translator corrects an error in the translation tool, the system can publish it to production automatically that very night. If it’s an urgent issue, the localization team can even publish the fix immediately, without having to wait for engineers. Think of this as “CMS-ization” of software strings – fixing a translation error in the UI should be as quick as editing content in WordPress and publishing it live. It’s another step towards better scalability. Side benefit of such decomposed cloud setups is that they effectively serve as a backup and versioning system for translations. Translation tools typically don’t have this capability. Interestingly enough, the decomposed approach can also be applied to fix errors in the source language quickly – something that would otherwise take inexcusably long time. User feedback is king The last important CL part is better user feedback collection. Contrary to the conventional wisdom, the most relevant indicator of localization quality is not the review done by another translator – it is the end users’ experience while using the product in real life situations. This approach also happens to be more scalable and objective than expert reviews. Options to measure localized user experience are many: · Track user engagement across the key parts of localized products. If ~57% of users click on a business-critical button in five languages but only 13% in the sixth, the latter language may have serious quality issues. · Use A/B testing for some pages, to measure which language style suits the target market better (before spending money on localizing all content). · Add feedback forms within the product to report translation errors. People do leave feedback, especially for products built by their companies. · Send out occasional surveys to users with non-default locales, to ask about their experience. All these methods can use existing analytics tools in the company, thus keeping the costs down and saving time. They conveniently go hand in hand with what the rest of the product team is already using, without introducing added complexity. It should be noted that this approach may not guarantee spotless quality (especially relevant for B2C products, where the bar is higher than in B2B), but it is enough to cover the basics. Human quality review can be done on top of this, but keep in mind that is a non-scalable, expensive, and inherently subjective process. For companies that do decide to invest into this, the general recommendation is to automate the processes, prefer transcreation wherever possible, and focus on reviews done in the product UI (not in the translation tool). New models of collaboration Supply chain in localization is what essentially makes it so waterfall – it is impossible for translation companies to calculate pricing and deadlines without locking the scope of work beforehand. Consequently, translation companies are unable to jump on the CL wagon because it is not just their way of work that must change – it is their subcontractors’ and subcontractor freelancers’ too. This chain is what blocks true scalability. This translation provider paralysis has forced CL practitioners to reimagine the localization process on their own. They automated project management and started collecting quality indicators internally. Many of them started finding, contracting, and paying freelance translators too, embracing simple-to-use marketplace and fintech solutions. Without translation companies and their many subcontractors in the loop, the communication between content creators and translators tends to improve. Clarification questions can be asked directly via chat apps and translation tool comments, replies can be delivered promptly, and a continuous collaboration can be fostered. This why the quality of CL programs is never poor despite its neck-breaking pace – stable localization teams that know each other and communicate often produce fewest errors from the first attempt. However, managing translators internally might limit the long-term scalability of localization programs – the very thing we were trying to avoid. Every company can manage 20 freelance translators, but what about 200? Luckily, that is where translation companies can help – by positioning themselves as language expert providers for CL programs and not as classical service providers. Think of them as talent management partners, specialized in finding, testing, and managing translator pools for medium- and large-size programs (without handling any communication or financials). That little bit of competitive edge In the modern, highly competitive world, every little thing that can push the business forward is important. Continuous localization adds a whole new superpower to that global competitiveness and enables future scalability too. And sometimes, with all things being equal, some company might be the first one to cross the finish line just because of that little extra speed and agility. Sign up here for our newsletter on globalization and localization matters.