What is Continuous Localization？
Table of Contents
Continuous localization allows developers and localizers to work on the same product simultaneously, thus shortening the process duration and reducing the time-to-market. It is often the ideal localization process for software companies.
The waterfall model: A software bottleneck
In the 1980s and 1990s, a relatively fixed software development process emerged. It allowed better collaboration on the development of large programs.
Developers would work on code for weeks or months, and when they were done with a specific batch, they would send it to the quality assurance (QA) team for testing. After testing, the final product is sent to the operations team for deployment.
This development model is known as the classical “waterfall model.” The production process is sequential, leading to stable and complete products. But, this model has a long development cycle.
As you undoubtedly know, a slower time to reach the market can be costly, both in market shares and customer testing. Silicon Valley’s motto is “fail fast, fail often” for a good reason. The sooner you can get your product into customers’ hands, the sooner you get crucial feedback you can leverage to iterate.
The agile model: The rise of continuous development
An “agile model” was developed early in the 21st century to avoid these problems. In this model, requirements are broken down into small parts that can be individually developed and tested. As a result, the interval between software releases significantly decreased, allowing developers to continuously adjust based on user feedback.
With the rise of the Internet and the increasing competition among similar products, the concept of DevOps emerged. Operations are integrated into the agile development process to achieve rapid iteration while capturing the target market’s preferences.
You need continuous development, integration, testing, deployment, and monitoring to achieve it. You also need to ensure that new versions are always ready for release. In essence, rigorous processes are involved, and modern tools are required.
One pressing issue is the primitive user interface (UI) translation, which is an integral part of a product. According to a survey, 18.5% of teams transfer multilingual strings in Excel, and 48.1% transfer texts even without tools.
At present, UI content is updated continuously. If the content is manually imported and exported, and localized in more than 10 languages, the product manager or the operations team of a product would have no time for tasks other than receiving and sending files.
When an employee is assigned to integrate development teams and translation agencies while doing it manually, this employee will be tied up with communication, confirmation, and coordination, sparing little time for overall quality, time, and risk control.
Localization is often planned at the end of a development cycle. Hence, very little time is available to evaluate the quality of localization.
Poor localization has a substantial negative impact on user experience. Without overall planning, localization may not yield the desired results and even lead to severe consequences if politically sensitive issues are involved. As a result, localization can become a development bottleneck.
The bottleneck solution: Continuous localization
Let’s look at the following workflow:
- The new or updated codes (including resource files like UI) are pushed to content sources (e.g., code repository).
- Resource files that must be updated are automatically identified and pushed to the translation management system (TMS).
- Translators log in to the TMS.
- Translated resource files are pushed to the original content source and merged with the original resource files.
As you can see, files are automatically converted and transferred so that their localization is always in continuous production and delivery state.
This continuous process was dubbed “continuous localization.” It is designed to bridge development and translation environments constantly while freeing people from transactional tasks through automation. It also enables development and translation to run in parallel rather than sequentially.
Nevertheless, continuous localization still poses several challenges. However, they can be adequately tackled with the support of a professional language service provider (LSP) and an appropriate TMS.
Challenge 1: Bidirectional connection
A TMS is not tailored for the localization of the UI. In the localization world, UI is only a tiny part of the content that needs to be translated.
Other components, including documents, tables, books, and multimedia, have their own complexity.
Handling all these components has made TMSs cumbersome. Moreover, a TMS needs to be connected with computer-assisted translation (CAT) tools because translators do the actual translation.
A poor connection may cause interruption and affect the reliability of TMSs. Thus, early in the 21st century, when offline resource files were typically transferred online, a TMS was rarely connected to a content source.
A TMS may be connected to some middleware. However, as third-party software, middleware has several disadvantages, such as instability and a slow update process. The only way to resolve this is to connect the TMS directly to content sources.
Modern TMSs that support continuous localization (e.g., Lokalise and Starling) can be seamlessly connected to most content sources. Changes to the content sources can be automatically converted into content that needs to be translated into the TMS. The interface and operations are highly translator-friendly.
Challenge 2: Short expressions
Usually, UI strings are short and snappy and can convey complete information only in a specific environment. This presents considerable difficulty to translators.
Hence, the development team must provide as many instructions as possible to translators and answer the queries from translators in time.
Meanwhile, translators must download and familiarize themselves with the product by logging in to the interface and performing operations. It helps translators learn the context from combinations of out-of-context words and vague descriptions to create accurate translations.
Existing TMSs (e.g., Starling) support automated pushing of multimedia content, such as images, audio, and video, thereby enabling translators to understand the context in which the content to be translated is used and improving productivity and accuracy.
Challenge 3: Talent shortage
For translators, translating UI strings is a slow and time-consuming process. In addition, UI strings may be created daily rather than occasionally. UI translation is a job with too low an input/output ratio.
Thus, it would be hard for LSPs to attract and retain talented translators. This poses a severe challenge to LSPs. As much as possible, UI string translation must be handled by dedicated translators to ensure consistency and avoid misrepresenting the features.
However, LSPs face the challenge of distributing appropriate workloads to translators because the workload is ever-changing. To solve this issue, LSPs can try to predict the workload through negotiation with customers and then assign UI strings and documents with high content to translators to maintain their daily output.
With the help of AI, LSPs can also match the specialization of translators with the document fields and assign translation projects based on data instead of personal judgment or experience.
Challenge 4: Multi-party collaboration
A short UI string, which may be created by a product manager or the result of a discussion between UX writers and designers, must be sent by your localization colleagues to your LSP’s PM, who will then assign the string to translators.
Sometimes, the string is translated into English (a neutral language) first and then assigned to translators for different languages. At each link in the chain, queries may be raised and answered, and errors may be pointed out.
How the translation is perceived varies based on work position. Thus, if any variation is observed, more time should be spent on communication and collaboration.
Most CAT/TMS tools today support communication at the production side, for example, between PM and translators or between translators and reviewers. These tools allow communication either through live chat or by adding comments.
Some TMS tools also support communication between translation teams and the demand side. For example, Lokalise allows translation teams to communicate with designers when connected to Figma through API.
Continuous localization demo
Next, let’s try it out and see how continuous localization works by connecting Lokalise to GitHub.
Search for an app on GitHub with the following conditions:
android language:java pushed:>2022-01-01 in:description game
Search for Android games in Java that were updated this year.
Vector-Pinball is the one that we want. Click Fork on GitHub to copy the source code to our local repository. Then we can modify it at will.
First, check if it can run properly:
It is a pinball game. Its resource files show that it is available in multiple languages except for Chinese.
It is a pinball game. Its resource files show it is available in multiple languages except for Chinese.
Let’s localize it in Chinese and implement the continuous localization workflow in simulated scenarios. To do this, we need some tools that can:
- Be connected to the code repository (GitHub), identify resource file updates in real time, and pull the updates.
- Be connected to CAT tools and pushes updates to CAT tools. It is okay if the tools have already integrated CAT modules.
- Return the CAT translations to the code repository.
Lokalise is a cloud-based tool with the above features and offers a free 14-day trial. After sign-up, create a project first:
Then, select the content source to be connected:
Connect to the code of Vector-Pinball (the original English fields have been copied to the new folder “values-zh” before this step):
Select the files to pull:
After pulling, enter the Editor page:
The Editor pages of various tools are similar, so we will not elaborate on how we work on this page.
Let’s imagine a scenario where strings are updated. Can tools like Lokalise detect and automatically pull the updates?
The answer is Yes. We only need to connect Lokalise to GitHub. To be specific, enable Webhooks on GitHub and enter the URL of the Lokalise project:
Next, let’s try to update fields by editing the source code on GitHub. We can add a field by adding content to Line 72 and update it by adding Line 74. The code changes from:
Shoot ramp for jackpot %1$s complete
Shoot ramp for jackpot, come on!! %1$s complete %1$s complete, that's good
In Lokalise, the page corresponding to the original code is shown below:
When the code is updated, the page changes accordingly:
The above example shows that any changes to the resource files will be synchronized to the Lokalise project in real-time, requiring no manual operation.
When the translation is completed, the translated content is submitted to the corresponding folder indicating the target language in the code repository. The localization is achieved.
- Despite being easily overlooked, continuous localization improves productivity and efficiency with updated workflow.
- It is especially effective when handling many target languages since its workflow won’t become more complex when adding language pairs.
- “Continuous localization” originated from software development, but it doesn’t mean it only applies in development scenarios.
- The key to continuous localization lies in automation. More specifically, we use tools to identify, push, check, return, publish, and notify us about the content, thus facilitating us in working and allowing us to play a more prominent role.
- In line with the digitalization trend, the handling of all kinds of information carriers (such as code, documents, images, and multimedia) is being updated. There are suitable continuous localization approaches for these carriers.