For an ambitious high-growth business, the question of going global in most cases is not “if” but “when”. However, the majority of businesses typically fail to recognize that there’s a lot more to building a truly global product (especially a digital product) than translations. Hence, localization is often an afterthought. Furthermore, adding new languages and entering new markets are often thought of as one-off tasks with clearly defined project endings. But, digital products (software, games, apps, websites, and so on) are never finished, and are continuously improved and updated often. This means that you constantly have new content to translate and localize. Neglecting this often leads to situations where localization becomes a bottleneck that can jeopardize your international expansion, and make it a lot more expensive and painful than necessary. More importantly, user experience becomes disjointed and awkward for international customers because big chunks of content across the entire customer journey are not translated and localized. The only way to prevent this from happening is to ensure that localization is not an afterthought but an integral business process necessary for going global and committing to continuous localization. Alas, continuous localization is quite a challenge. In this guide, we’re going to explore: What continuous localization is. What its origins and the direct tie to software development methodologies are. How to successfully integrate it into your product’s delivery workflow. How this translates to all digital content at your company. Software development methodologies and localization From Waterfall to Continuous localizationWaterfall localizationAgile localizationContinuous localization workflow Waterfall localization Agile localization Continuous localization workflow Continuous localization challengesKeeping up with translation consistency and accuracyPricing and organizing translationsEfficient cross-functional collaborationGetting the workflow right Keeping up with translation consistency and accuracy Pricing and organizing translations Efficient cross-functional collaboration Getting the workflow right How to integrate continuous localization into your product’s continuous delivery workflow1. Merge your localization team with the product team2. Pick the right continuous localization software 1. Merge your localization team with the product team 2. Pick the right continuous localization software Continuously localize all your digital content Final thoughts on continuous localization Software development methodologies and localization Nowadays, localization covers more than just software. The distinction between software and digital content is no longer clear cut. However, it was the rise of the PC and mass market software that created the need for localization. This goes back to the 1980s when the first successful U.S. software companies (such as Microsoft, IBM, and Oracle) started their initial global expansions. In addition to translating text, you also had to account for context and usability, adjusting the date format, the layout, meeting legal requirements, and more. Consequently, the evolution of localization has been heavily influenced by the evolution of software development. While there have been many software development methodologies introduced since the 1980s, the two most common ones are Waterfall and Agile. And in the last decade, Agile has superseded as the leading practice. In addition, the upfront investment in technology to start developing new software has decreased dramatically (because of cloud infrastructure, expensive enterprise software is mostly a thing of the past). The two advancements above have dramatically accelerated the speed at which software is being developed. Historically, software releases happened once a year. Today they happen within weeks and days. The costs of deploying these new releases are basically zero and developers are able to publish updates often. Plus, new software releases typically mean new strings (pieces of text) to translate. Anything that gets in the way of those releases means delays, longer times to market, and ultimately longer waits for new learnings from market feedback, for revenue, and less profits. This is typically where localization started to become a bottleneck. The localization process required the ability to keep up with software development evolutions so that it didn’t halt product releases. Consequently, localization methodologies have gone through their own evolution from Waterfall to Agile, and now to continuous localization. From Waterfall to Continuous localization The translation industry traditionally has used the Waterfall method as the bulk of the work typically included translating documents, books, etc. Once the document is completed, translation work begins. Software, on the other hand, is a completely different story because software is never truly completed. Waterfall localization In most cases, localization is still planned at the very end of the development cycle, continuing the Waterfall practice. Once the cycle had ended, developers would gather a large amount of files in the source language, in different formats, and send them over to translators. On the translator’s end, this also meant significant preparation, doing large batches of translations, rounds of revisions, fixing issues, and then approving the changes. When the translated text was complete, the translators would send back the files (translated strings) to developers and these were manually uploaded into the application for merging and publishing. This approach would inevitably create a headache as: For developers – the process of finding and breaking texts into strings is tedious (especially if you have hundreds of thousands of words in your application). These translation files needed to be converted as developers work with a different set of file formats than translators. Not only does this waste time on both ends, it can also corrupt the files and introduce more room for error. In the case that the product was not developed with i18n (internationalization) in mind, it would require rethinking of the architecture. Manual downloading, uploading, and sending of files to multiple people is just too slow and error prone. Software releases were put on hold while waiting on translators to finish the job. There was little visibility of progress on the translator’s end so projects would often get stretched out. If there were any errors, that meant repeating the process all over again. Put simply, for companies that had adopted the Agile methodology, this meant risking missed deadlines, wasting resources, endless back and forth, long wait times, and opportunity costs. Naturally, it caused pressure for the localization methodology to adapt as well. This also created negative connotations around localization between software developers and product teams. Agile localization As the name implies, Agile localization incorporates localization and translation into an Agile product development cycle so that both processes are operating simultaneously. Translations take place in parallel with Agile sprints and in smaller batches. This means translating just a part of a product or a feature, not the whole product at once. For this methodology to be successful, it requires automation for software teams because string management and file exchange occurs more frequently. The ideal Agile localization workflow looks like this: The new code with new strings is pushed to the code repository. Changes are automatically recognized, and new content that needs to be localized and translated is pushed to the translation management system (TMS). Translators translate and review the content on the translation management system (TMS). Once the translations are done, the content is merged back into the code repository. However, implementing this sounds much easier and more straightforward than the reality. In practice, this created even more friction between software and localization teams. For starters, translators are typically not familiar with the software development environment. So, from their perspective it just means higher frequency, but smaller volumes and out-of-context translation requests with a tighter deadline. In the past, translation management systems (TMS) were built to make life easier for translators (or LSPs), not so much for developers. This means the available automations didn’t fully account for managing software strings (steps 1, 2, and 4), but more so for managing and doing the translation work. As a result, software teams would often have to build custom integrations (in-house localization platforms) that would connect with those translation management systems. However, these would still require maintenance and a lot of attention (and time to build in the first place). Teams that could not afford custom solutions were forced to stick to spreadsheets and semi-automated processes. Unfortunately, this is not a thing of the past. We, at Lokalise, regularly survey the market and typically more than 50% of the prospects that come to us already have their product or their digital assets available in several languages. However, the majority of those same companies don’t use a translation management system or use just spreadsheets to manage the process. This is most often a clear signal that they don’t have a streamlined localization process in place and are stuck. Continuous localization workflow Continuous localization is simply another step further toward making localization automated and seamless. Thus, what Agile localization aims to be. Are you wondering if there is any difference between Agile and continuous localization? There is no official definition of what ‘continuous localization’ is, therefore it depends on who you ask (translators, developers, product managers, etc.). But, there are two key differences you’ll often hear: 1) In Agile, the translation jobs take place in sprints, whereas in continuous localization there is essentially one never-ending (hence, ‘continuous’) sprint (or translation job). Or in other words, it’s a continuous delivery vs a job-based setup which leads to the second point. 2) In Agile, localization is integrated into the Agile process, while in continuous localization, it is fully integrated into the software’s continuous delivery workflow so that engineers don’t have to worry about it once they integrate it. Continuous localization originated from the CI/CD (continuous integration and continuous delivery) approach, which is a subset of the Agile methodology. It also raised this need for this one fully autonomous, uninterrupted translation job. It is when new code is being pushed constantly and the software is ready for release at any time during the development cycle (particularly relevant to video game and mobile app development). In practice, this means even quicker releases that can happen multiple times a day. So, for localization, there are even smaller and more frequent batches of never-ending translation work, and more automation to avoid interruptions. Continuous localization is the perfect Agile localization workflow for Agile software teams that constantly ship a lot of updates and releases. It eliminates the tedious and manual parts of the process and ultimately gets the product to end-users much faster. Continuous localization challenges Similar to Agile localization, implementing continuous localization in your software delivery workflow and making it seamless and efficient is no small feat. It comes with its own set of challenges. Keeping up with translation consistency and accuracy Getting translations right is no easy task, getting them right for a small section of a software product in a short amount of time is even harder. Context, consistency, and accuracy become a real challenge. So it’s important for translators to learn the product and understand the context. Likewise, software teams should understand that planning and understanding the product is crucial for translators to get the translations right. Small, unrelated string translation requests make this a bit more complicated. This can become even more cumbersome if you work with multiple freelance translators or do crowdsourced translations. Each new person will need some time to adapt and learn the product. Pricing and organizing translations It won’t be unusual for translators to work on only around 100 words a few times per week. This can make it challenging for translators to figure out how to charge, i.e. how and when to apply the concept of a minimum fee. Also, translators need to organize their workload in an efficient way so they still have the bandwidth to support clients with larger bulks of content. So, fitting in these smaller (but more frequent) requests can become a challenge. Efficient cross-functional collaboration Software developers are often unaware of the complexities of translation work and vice versa. This is an ever-pressing challenge in localization, but add the speed and pressure of Agile workflows and it becomes even more significant. You’ll need translation partners who are able to translate daily, deliver ASAP, and are familiar with the Agile methodology. Furthermore, it doesn’t end with translators and developers, in software teams you also have product managers, designers, UX writers, and marketers (more on marketers below). Plus, all the stakeholders are pursuing slightly different goals. Thus, the best localization teams are cross-functional, and you need to ensure that all team members get the right information at the right time to meet those market release deadlines. In addition, all members are well-educated on the scope and complexity that goes into planning and executing a localization strategy. As with any system, it’s only as strong and efficient as its weakest link. Getting the workflow right Every product team’s workflow is unique, depending on the specific use cases of your product and technology. Therefore, you’ll need a continuous localization platform (CLP) that is flexible enough for you to integrate localization into your continuous delivery workflow (CI/CD) without much additional investment. How to integrate continuous localization into your product’s continuous delivery workflow 1. Merge your localization team with the product team The aim of continuous localization is to make localization fully automated and seamless so that you are always able to deliver new and updated content to all of your users without any blockages. Nonetheless, someone has to set up the workflows, somebody has to carry out the translations, and somebody has to oversee the process to make sure translations are accurate, and there are no errors or bugs. Thus, they have to ensure things run smoothly. Ideally, this means the localization team becoming a part of the software development team. This becomes even more important at scale when you have hundreds of thousands of strings translated into multiple languages and new updates daily. A typical in-house localization team includes at least 3 software team roles: Localization engineer — responsible for implementing the continuous localization workflow. Localization QA — responsible for the quality of the localized product. Localization manager — someone who oversees the whole process, working with engineers and translators, and is responsible for deadlines. In complex organizations with multiple cross-functional teams working on different products this is even trickier. There should be a clear owner or “localization advocate” in each of the teams, as the workflows might be a bit different. 2. Pick the right continuous localization software Here are the integral features a continuous localization platform (CLP) must have to achieve seamless continuous localization: L10n (localization) process automation – avoid any manual uploads, downloads, and file exchanges. New strings are automatically detected in your code repository and pushed for translation in the TMS. Once the translations are done, translations are automatically merged back into the repository. A single source of truth for translation strings (the TMS) – keep every string, image, or item that requires translation or adaptation in one place. Get an overview of, communicate with all stakeholders and assign tasks all in one place. CAT functionality (translation memories, glossaries, QA checks) – your translators will need translation features to keep up to speed while ensuring quality and consistency. Visual context – provide as much context as possible with UI screenshots by showing translators where and how the translated string will be displayed. Translation version control – the same as with Agile software development, continuous localization means that multiple translators will work on various often unrelated parts of your software. You’ll need a version control system to keep everything in sync. Easy integration into your unique continuous delivery workflow – connect your code repository, like GitHub and Bitbucket, and developer tools, like Jenkins and Docker. Easy integration of designer tools like Figma, Adobe XD, and Sketch – invite designers into the l10n workflow. Start translating and testing your mockups and prototypes before coding to catch potential l10n bugs early on. Continuously localize all your digital content At the beginning of this article, we explained how there isn’t a clear distinction between software and digital content today. Plus, the average company has a lot more digital content in their arsenal nowadays. Making your product available in multiple languages is just the bare minimum. To achieve true global success you also need content to attract and convert people into customers in the first place. And that content will be updated constantly as well. Furthermore, a lead or a customer will interact with your company in multiple ways, not just with your product. They may visit your website, receive an email, a social media update, or read a blog post. They might interact with your live chat and read your documentation. What’s most important here is that to them, you are just one company, one brand, even though your content is owned by different teams. Any disruption in their customer journey is going to negatively reflect on your whole brand, not just one department of your company. Therefore, while the distinction between types of digital content isn’t always clear, there are notable differences: You’ll need to set up various different continuous localization workflows because your content is likely stored on different platforms. For example, your marketing content may be stored on a CMS like WordPress or Contentful while your product (your software) is on GitHub. So, you need to make sure your CLP is able to integrate with your CMS as well as with GitHub. Furthermore your customer support tools (live chat, support tickets, and help center) are likely hosted on platforms like Intercom or Zendesk. Your localization team must become even more cross-functional, inviting marketing, sales, and customer support into localization. Translating software strings is not the same as translating blog posts and marketing content, so you’ll need a clear multilingual brand and writing guidelines along with tools for context. And you’ll most likely have to work with translation partners that understand marketing. Final thoughts on continuous localization Unlocking global growth is one of the key pillars modern companies need to scale; however, localization can become, and most often does become, a serious bottleneck. Proper product localization is time consuming and complex, but the main reason it becomes a bottleneck is that companies fail to recognize that localization should be continuous. Moreover, this applies to product localization as well as to all your content localization. Want to learn how to implement an interconnected continuous localization workflow at your company? Reach out to one of our product specialists at Lokalise. Guides Localization