What is continuous localization?
Continuous localization is the process of localizing ever-changing pieces of content while working in parallel with agile development cycles.
In this modern age, market pressures require flexible and frequent content updates. To ensure fast release times, localization processes must match the fast-paced rhythm of the development cycle, which is the core goal of continuous localization.
Continuous localization requires a seamless synchronization of Translation Management Systems (TMS) with other parts of the production process. It reduces reliance on manual localization practices (e.g., file exchange through email) and automates substantial segments of the workflow.
Why should you implement continuous localization?
Maximum efficiency at the lowest cost and in the shortest possible time is one of the chief priorities of any workflow—and continuous localization is no exception. By modernizing your localization efforts, you can improve your operation in several ways:
By aligning your localization and development cycles, your teams can improve their ability to communicate effectively throughout the entire production process. As such, their adaptability increases, and your entire operation’s efficiency and flexibility improves.
Continuous localization eliminates the need for a developer or software engineer to manually handle resource files, send them for translation, and manually put them back in the code.
Repetitive manual inputs can be error-prone, as such, automating these steps will increase your accuracy, leaving your developers free to focus on their core skills——development.
Moreover, developers only need to work with one source language, while the rest can be dealt with automatically, i.e., translations automatically merge in their code repositories.
Requirements
Although there are many requirements for continuous localization, a two-way synchronization between a TMS and a version control system (VCS) is the main one. Below is a list of requirements that are needed to achieve continuous localization.
- Translation Management System that has an API/CLI tool
- Version Control System
- Localization Server
The right tools for the right job
Choosing the right tools is the first and most critical step to effectively implement continuous localization. Considering the variety of translation management tools available, we strongly encourage you to take your time and research the ones that will fit your operation best. Here is a quick sample of the many options available:
Source: Nimdzi
In our case, the bulk of our operations are located in China. For that reason, we chose to rely on ByteDance’s software Starling. It’s a powerful application that provides automatic translation and localization services and is mainly used to internationalize and localize websites and mobile applications.
We’d encourage you to try it, but feel free to pick an alternative if it is not the right fit for your business. To complement Starling, we selected Serge, which runs on our localization server. If you’d like to learn more about Serge, you can skip ahead to the “Serge Background” section. We discuss the key features of the app and provide some useful links.
Starling in action
In the following sections, we are going to have a simple walkthrough on how you could leverage Starling and Serge to implement continuous localization. But first let’s see the main application scenarios for Starling.
Main application scenarios
Product localization: Provide one-stop service for project management, translation content management, and copy issuance for Web, Mini Program, and other product forms.
Document translation: Based on Word, Excel, Feishu Doc, PPT, PDF, and other file formats, provide document translation online services, including project management and translation editor capabilities.
Video translations: For common video/subtitle files, you can initiate translation orders and manage video resources. AI automatically transcribes videos, adds proofread subtitles, video suppression, and subtitle export. The whole process supports multimedia localization.
Compatible file formats
Starling supports various kinds of file formats. Below is a table showing the file compatibility via the starling CMS and starling CLI.
| Supports .zip for packaging various file formats |
Connecting to Starling
To connect to Starling, we need to use their SDK, which is introduced below.
Starling Web SDK
Starling provides a web SDK to help fetch translated strings and replace the texts on your website in real-time with said strings. As you can imagine, internationalizing web applications can be completed quickly.
It may also help development teams identify UI issues brought about by internationalization. By improving detection rates, Starling improves your patch efficiency.
The SDK defaults to the i18next framework as the base, and is supported by the community for function extension, to achieve internationalization in multiple scenarios. It is framework friendly and works with React, Vue, and Angular. Moreover, it works with nodes too.
For us to connect to Starling Web SDK, we need to first install @volcengine/i18n
| Shell npm install @volcengine/i18n |
Next, we need to create an i18n.js file and initialize reactI18n
| JavaScript import reactI18n from ‘@volcengine/i18n’ reactI18n.init({ lng: ‘zh’, backend: { namespace: 3174, operatorId: 2222222, apiKey: ‘704dbe7057f510ec8e4sedf71dc34d4f’, projectId: 4168, }, react: { useSuspense: true, } }) export default reactI18n |
Finally, we are going to import it to index.js
| JavaScript import React, { Suspense } from ‘react’; import ReactDOM from ‘react-dom’; import App from ‘./App’; import ‘./i18n’; ReactDOM.render( <Suspense fallback=”Loading…”> <App /> </Suspense>, document.getElementById(‘root’) ); |
Usage.
| JavaScript import { useTranslation } from ‘@volcengine/i18n’; function Page() { const { t, i18n } = useTranslation(); return( … <Button> { t(‘hero_button_text’)} </Button> … ) } export default Page |
Pass the ‘hero_button_text’translation key inside the t(…) function and wrap it in calibrates. Do that to all the texts that will need a translation.
Translation key—used to obtain a translated copy that matches the corresponding language of the source copy. It is recommended to name translation keys according to the purpose of the string and what value it might hold. For example: t(…) replaces the key with the translation/source string. i18n.changeLanguage(lang) changes the language. |
Going forward, you will have to code a language switcher in order for the user to select their preferred language and pass the lang argument in the changeLanguage method to switch between languages.
Dropdown Language Selector
After using the format mentioned above, your resulting website should look like this.
| Starling recommends naming translation keys in this format: Function Module_Function Name. For example, productname_profile_5. Hence, our naming convention. |
The translation keys would appear in the CMS, as shown below.
Serge Background
Serge (String Extraction and Resource Generation) is a uniquely flexible and robust open-source solution for continuous localization. Serge eliminates the tedious tasks that you would otherwise need to code, e.g., file parsing.
Serge provides the following benefits:
- Extensible to any TMS.
- No TMS lock-in—you may use different TMSs while maintaining the same automation workflow.
- Security—TMSs will never have access to your code repository.
- Advanced functionalities, such as file parsing and formatting.
Serge runs against configuration files that provide all the required information to Serge, which include:
- How to interact with version control systems.
- Which external Translation Management System to pull translation files from.
- Where to store the local checkout and translation files.
- What files to process.
- How to parse various files.
Feel free to download Serge here and get started with the installation according to the documentation.
Localization server
We will use a localization server that will continuously run serge, and during testing, you can run an endless loop. In the production environment, you will need to run it as a daemon so that it starts automatically after the system reboot. Please refer to the documentation for more details.
Starling CLI
Starling command-line tool enables file exchange where they can be downloaded and uploaded to Starling CMS via the command line.
To set up the starling CLI, we need to install @volcengine/starling-cli-public
| Plain Text $ npm install -g @volcengine/starling-cli-public |
| Before using the Starling Client CLI, you should pre-generate the configuration file and run the CLI tool. By default, the Starling Client CLI looks for a configuration file named starling.yml in the current directory. |
This command uploads files according to starling.yml configurations, which is the configuration file.
| JSON $ starling client upload |
This command downloads files according to the configuration file.
| JSON $ starling client download |
| JSON “ak”: “Access Key” “sk”: “Secret Key” “basePath”: “/project-base-path” “projectId”: “ProjectId” “download”: { “namespaceId”: “NamespaceId”, “taskId”: “TaskId” } “files”: [ { “source”: “/locale/zh/folder/*.xml”, “translation”: “/locale/%locale%/folder/%original_file_name%” } ] |
Configuring the TMS plugin in Serge
You will have to write your own TMS plugin in serge/lib/Serge/Sync/Plugin/TranslationService folder and reference its filename in the configuration file.
| Plain Text ts { plugin command } |
In the above configuration file snippet, the TMS plugin name is command hence our plugin in the above path would be command.pm—a Perl module.
In our case, command.pm runs starling client upload and starling client download command which uploads or downloads files via the command-line.
So far, we have covered every component we need to build continuous localization into the whole workflow, and now is when we put them all together。
Continuous localization workflow
Simplified representation of Continuous localization workflow
After much research, we decided to adopt this continuous localization workflow. Firstly, the development team pushes the website/app source code to the remote repository (for example, GitHub).
At this point, the localization server should already be live and running Serge in the background. As such, it will update the repository continuously. Hence, if there are any changes, they will be reflected on the server.
Repository resource files with only the source language. Before translation.
On the server, Serge performs a localization cycle that eventually pushes the files to the Starling CMS using the TMS plugin in an existing translation task outlined in the starling.yml configuration file, where it is then assigned to translators.
After the translations are published by the localization team to the test environment, grayscale, or full-release environment, they become exposed to being consumed by the starling Web SDK. At the same time, Serge runs starling client download to fetch the translation files, which will be committed and pushed back into the remote repository. At this point, we have fully transformed our localization process into a continuous automated workflow.
Repository resource files with the source language and translations. After translation.
| As long as the translated strings are published, the source code doesn’t necessarily need the translated files because it fetches the translation data using the SDK from starling CMS. |
Your resulting website should now have published translations like the one below. Making any changes to the strings and pushing them to your remote repository should automatically push the new/updated strings to your TMS.
Source language
Translated copy
Key Takeaways
It is vital to take the time to research the different available continuous localization tools to find the most suitable one for your business. The right choice can improve your workflow, while the wrong one may lead you to an unproductive dead end.
Using Serge as a continuous localization solution does most of the complicated tasks so that you don’t need to reinvent the wheel and it allows you to tailor your whole process according to your requirements.
Finally, integrating localization with your development cycle may be challenging and costly, but in the long run, it will improve your operation’s efficiency, saving you time and money.
FAQ
What is a Version Control System?
A Version Control System tracks changes in a file or set of files majorly used in software development projects. Some version control system examples are git, CVS, SVN, and Mercurial.
What is a Translation Management System?
A Translation Management System is software that manages language assets and automates localization processes and workflows for better translator and translation project manager efficiency. Translation Management technology has seen improvements over the past years; some are even open-sourced.
