Struggling to keep up with your planned product cycles when you translate your software?
If so, you’re not alone. Adding translation can easily throw off dev cycles if you aren’t careful. In the days leading up to their release deadlines, many content and dev teams in global companies end up rushing to keep up as they try to incorporate late translations and inefficient quality assurance (QA) processes.
Your dev teams work hard over days, weeks, and months to develop the next set of features for your software.
As the deadline approaches, your content creators produce all the necessary associated content for the new release. Sales pages, blog content, social media posts, videos… it’s a lot of work but they are still keeping to the planned schedule.
Your UI people make sure that all the in-software content is optimized.
You send all this content to your localization provider…
And then everything stops.
Delays mount up.
You know that you need to localize your product and associated content for your international markets. But, you’re left wondering… is translation really worth it?
How can you avoid the frequent delays that are caused by the localization process?
Why localization can throw off software dev cycles
Various factors can throw off a product dev cycle. Scope creep, expansion of functionality, neglecting quality control, over-optimistic schedules… the list goes on.
These issues can affect any software team working with any type of project management framework.
But, when you’re creating software for global markets, you have to contend with more challenges than other companies.
Localization often throws off dev cycles because it takes longer than people expect.
Companies often wrongly assume that localization is just a straightforward linguistic step at the end of their content creation processes. They think that it only involves turning words from one language into another.
In reality, there can be a lot of associated engineering steps involved with software localization. There are also extra QA steps that can take longer if they aren’t managed correctly.
The right type of software localization can reduce or even remove these unnecessary engineering steps from your team’s workload. But, you need to choose the right type of localization!
Using the right tool for the right job: types of localization
Despite what some translation providers imply, there is no one-size-fits-all for localization.
Software localization has a variety of unique features compared to, say, technical document translation. Also, your company will have a different set of requirements to another software company.
If you are working on a model of continuous delivery, for example, you need your localization process to also work on that model. You and your teams can’t be waiting for the localization step to catch up on every cycle!
Many localization providers will put all translation projects through exactly the same internal processes. This is often a cause of those delays because the processes are likely not optimized for software localization.
As the “Law of the Instrument” says “If all you have is a hammer, everything looks like a nail.”
You don’t want your company to end up “as a nail” for your localization provider when your needs and your content could be better suited to another type of localization.
For example, some translation providers may advise you never to release a product that has been translated with Machine Translation.
It’s true that Machine Translation cannot match the accuracy of human translation and it would be a very bad idea to use it exclusively. However, selective use of Machine Translation can be an appropriate tool for software companies in some situations.
How Machine Translation can aid continuous localization
One exciting use case of Machine Translation is continuous localization.
This allows you to ensure that your translated content is always up to date to reflect the latest changes in your files, even if you are updating those files every week.
Victoria Milton, a Senior Project Manager at Rubric, explains how we use Machine Translation in tandem with human translation with one of our technology clients. We work with that client on a continuous delivery model with a cadence of 5 days.
“They are a big team with around 20 devs working on the project. They can’t all pause work whilst we’re translating. We have 5 days to translate their content manually. But, when we get to the end of each week, we do another pull-down of the files from their repositories to check for anything new that’s been added over the course of that week.
“We then machine translate those new changes and push them back up to the client’s repositories. So, at the end of each week, they have a hybrid of the old human translations, the new human translations, and machine translations of anything brand new.”
This way of working selectively with Machine Translation is also much easier for developers.
The devs don’t have to worry whether the software has been properly translated. This way, they know that the latest translations are always going to be reflected in their software files at the start of each week.
“This way of working makes it easy for our client to merge those translated files back in the following week. Otherwise, some of the strings would conflict and it would be very time-consuming for them to decide “We’re going to take Rubric’s version of this string but keep the developer’s version of this string.”
“And that’s all automated on the Rubric side. We’ve built that Machine Translation capability into our normal translation platform.”
The benefit of continuous localization
For some companies, continuous localization will be unnecessary.
If you are working with longer release cycles and you have built enough runway into your cycle to accommodate localization, another process might make more sense.
However, if you are working with continuous delivery, adding Machine Translation can reduce delays or even remove them completely.
“Machine Translation has a bad reputation for not being accurate. But, there are use cases for it. Our way of working with this client is one example where they don’t have time for the software to be human-translated. We just need something temporary so that their international customers don’t see content in English.”
“We pick up those machine-translated strings in the next round of translation and these will get pushed out to users in the next iterative update. So, the machine translations might only be visible to end-users for a matter of days or weeks depending on the release cycle.”
What’s the right type of localization for you?
You might be wondering if a continuous localization cycle is right for your software company.
The best way to find out what approach could work for you is to talk over your needs with a content strategist.
You can book a free Global Content Strategy call with one of our strategists and find out more about our approach and how it applies to businesses like yours on our software localization page.