This article was originally posted on the Locale blog
The localization process should happen automatically, without relying on someone starting the translation process. But how can localization keep up with product development?
Continuous localization is every developer’s dream process; to have localization completed seamlessly as they work.
The goal is to get to 100% of translation completion with the minimum amount of effort, offering major cost and efficiency benefits.
This post explains what the process is and looks at a number of practical examples that use GitHub as the platform for hosting your code.
What is continuous localization?
Continuous integration automates the building and testing process for software releases. It’s been popularised over the last decade as companies develop agile development processes and have shorter release cycles.
Continuous localization has the same philosophy, embedding localization into your workflow.
This is a break from the traditional waterfall method where localization occurs when a project is finished. The traditional approach can cause code to break and prevents internationalization errors being found until it’s too late.
So, how do you build a process to get everything translated with the minimum of effort?
4 approaches for working with git branches
1. Translate when changes are merged into the master branch
You wait until changes are merged into the production-ready master branch before starting localization.
This means localization doesn’t impact the development process. However, you may have to wait until translations are complete to release a new version.
2. Translate when changes are committed to the develop branch
Only completed features are translated. The staging server looks at the individual branches, meaning you can check previews of a feature in different languages.
This is generally the preferred option.
3. Translate each feature branch
Each feature branch is self-contained, with all the related code, content, and translations. This means translations can be done before they are merged into the master or develop branches.
However, you might end up translating branches that aren’t used. Also, doing lots of small batches of translations at different times could be more expensive.
4. Creating a separate branch just for localization
Creating a new branch means localization can wait until a new release is ready. That gives you lots of control over the translation process.
However, this will slow the release process. Even if the localization process triggers automatically, you have to remember to rebase the localization branch.
Timing your translation
Text can be sent for translation when you reach a certain word limit or as you get to the end of a sprint.
You need a partner that can cope with small translation requests and turn them around at a pace that’s fast enough to keep up with your process.
Continuous localization can’t depend on your team writing instructions for every batch of translation. It’s important your partner has a termbase that provides the context to translate content in a consistent and accurate way.
Choosing your approach to continuous localization
Continuous localization requires a translation management system.
Your developers need to be responsible for internationalization, making sure text strings can be extracted for translation and merged back in effectively. Think about how your translation partners will provide feedback too.
When deciding what approach to take to continuous localization, you have to strike the right balance in terms of complexity, cost, and desired outcomes.
Translators need to be qualified and responsive. The iterative process means you’re probably going to ask for a higher volume of translations, potentially increasing cost. You have to invest time into setting up a robust process.
Think about how often you iterate on your software and the impacts on user experience. Continuous localization helps companies that are comfortable working in an agile manner save time and effort.
