Does software localization have to be so complex!?
When you are creating software for the global market, localization can seem like a lot of work. Your development (dev) teams are already putting all their best efforts into keeping up with your release cycles…
Won’t adding localization into the mix require a huge added effort?
You imagine copying and pasting hundreds of English strings into documents, sending them to the translators, then doing exactly the same when the translations return.
You worry “Is my customer going to see this button translated differently because something weird has happened during the translation process?”
Wouldn’t it be great if software localization felt like “business as usual”?
In this article, Victoria Milton, a Senior Project Manager at Rubric, explains how you can improve your localization process to make it almost effortless for your dev teams.
The unnecessarily difficult approach to software localization
Many dev teams think that software localization only happens after all the English content has been created. They start thinking about translation once the entire release has been created, when time is already extremely tight.
They strip out all the strings to be translated, zip them up or copy them into a document, and send them to be translated. After all the translations are done, they then do all this work again in reverse, manually copying the translated strings back into the code.
Many translation providers will only be able to handle this way of working.
This is a terrible option for software localization!
As a dev team, you know that automation and low-touch processes are vital for an efficient software development workflow.
Does copy-and-pasting all your strings out by hand sound like a very efficient workflow?
There is a much better approach to localizing software…
What if localization was just business as usual for dev teams?
At Rubric, we are fanatical about process optimization. We understand the needs of a dev team and we have always incorporated automation and software-development approaches into our localization processes.
Victoria Milton explains how we often directly handle our clients’ source files and data interchange files (for example
JSON, XML, or even working directly with the databases of their
headless CMS):
The client makes a branch of their main development branch for us and tells us “This is the branch we need to translate.” We do everything from that point onwards.
We use our automation tools to pull the English and existing translated files down directly from their Git or Bitbucket repository, whatever they’re using. They don’t have to isolate strings or Zip anything.
We then follow a process that may be familiar to you as a dev:
Our automation tools process the software files to prepare them for translation.
We translate the required strings into your chosen languages.
We post-process them according to the pre-arranged requirements for the target files (naming, encodings, line endings, etc).
We compare them against previous deliveries to ensure only the correct parts of the files have been changed.
We push them straight back up to the repository branch.
Victoria says:
All the client has to do is merge the branch into their main repository branch. The way that it gets merged in is exactly the same way that all their other features get merged in.
And that’s it! That’s all they have to do. Basically, the localization branches are part of their business as usual. It’s not fully zero-touch but it demystifies the entire process.
Other ways to streamline software localization
When you think of localization as just another strand of your development, many doors open for further process optimization.
You will start to notice so many ways that you can incrementally improve your localization workflow.
Victoria gives an example of how we streamlined the Quality Assurance (QA) step even further with one client:
With that client, when we push up our changes it triggers an automatic product build. That then sends us a file to install the software so we can do testing.
The devs tell us “This is the new feature we’ve added this week, this is how you need to test it.” We pull that down, get the build, then we go away and test it. For any linguistic QA fixes after that, we just push them back up again.
Making your software localization match your dev cycle
Over the years, one of our key learnings is that you need to match your localization work to your dev cycles.
Whatever project management methodologies you use and whatever release cycles you have in place, the localization step should fit into your cadences. With our clients, we often help them to adjust their process to better accommodate the localization.
If you use a waterfall methodology
Despite the rise of agile, the waterfall methodology is still popular in some software companies and can be highly effective for some products. It’s possible to integrate localization into a waterfall approach in an efficient way.
Victoria explains how this works:
We can respond to whatever teams need. For example, one of our clients was using the waterfall model. The teams developed everything in English. Then, 2 weeks before their code freeze, there was a flurry of activity while we translated and tested everything. As well as the code, we also translated all the help files and the tutorial videos.
If you are using the waterfall method, leaving enough time for all the extra steps associated with localization is vital (such as extra QA).
For example, if you are translating the help files, remember that these will include references to products. To ensure the Help matches the product, those references should be translated and signed off before the help files are translated, which requires extra time.
When you leave enough time for localization a waterfall approach can be very effective. But, be aware of what can happen if you don’t leave enough of a time buffer.
Victoria explains that this particular client often didn’t leave enough time for those extra steps:
In that case, there was too much of a time crunch for the client. Their internal teams had to do crazy hours and burn themselves into the ground in order to get ready for each new release. They sometimes had to delay their release dates because features weren’t ready, which wasn’t ideal when marketing campaigns and sales teams had planned around release dates.
If you use an agile methodology
We are big fans of the agile methodology.
We have found that clients who adopt an agile approach to localization can make impressive gains in efficiency, product quality, and ease of use.
Victoria describes one example of the significant difference that an agile approach has brought to the same client:
That same development team has now moved to an agile sprint model on a yearly release cycle. This was a change across their entire organization — it wasn’t done because of the localization — but we helped them to switch the localization to agile as well. They now work in 13-week sprints. They have it all planned and the marketing team hook into that same sprint planning.
We use a rolling model with them as we’re translating 2 main products. So, we alternate between those products each week. They know that, whatever new strings have been added, those strings will be translated in 2 weeks’ time.
By the time we then get to the release, we’ve been testing all those new features for an entire year!
When you approach localization in the right way, your translation provider can even help you to achieve a more agile way of working.
And your project manager will be just as excited as you are about the gains that your process improvements have made!
Learn more tricks to improve your localization workflow
There are so many more improvements you can make when you start thinking of localization in the same way as your other development processes.