To launch a successful, agile software localisation strategy, planning is essential. It may not be the most compelling part of your strategy, but, as Benjamin Franklin once said, “If you fail to plan, you are planning to fail!”. It’s as true today as it was in the 1700s.
By not planning ahead, you run the risk of spending much more than you would like (or can even afford), in terms of money and time; both valuable assets for any company.
To implement a software localisation strategy, first look within your organization for existing resources and to learn from existing expertise. If that’s not available, outsourcing is the best option.
Localisation often carries the stigma of adding more work and more expense. In the short-term this is true, but the added hours and costs in the beginning of the process will be insignificant compared to the long-term gains.
Whether you are launching your software globally because your competitor has already done so, or you’ve identified that a global app would increase sales, market share, customer loyalty, revenue and customer experience, it’s clear that your customers want that software in their native language.
And only when it’s in their own language will they want your software. “If you build it, they will come”, or so the saying goes.
When you start your software strategy, it’s key to design for localisation from the start. Doing so will reduce cost, functional and capacity issues. If your company isn’t already integrating localisation into its culture, it is imperative to begin the initiative.
Becoming part of an agile, global team is key to aligning localisation with your business objectives and leveraging team members’ existing experience.
Let’s talk money
When it comes to expanding your business, cost should be a major consideration. . Leveraging in-house expertise will alleviate costs, and for anything that’s being outsourced a formal budget should be created.
Elements to be considered and budgeted for:
- Project management
- Language service provider (LSP)
LSPs offer multiple benefits and are essential to localise successfully. They have the market experience and output quality is high, but it is important to remember that, as with any service, more expensive doesn’t always mean better quality. Inexpensive services, however, can lead to low quality and rework so it is vital that you spend time finding the right LSP.
Internationalisation at code level
Develop your software in such a way that translation is a simple and integrated process. If your software isn’t coded with internationalisation in mind you risk introducing bugs, which take time and money to fix.
Test readiness review
In order to be ready for formal testing, you must determine your test readiness. A strategy for determining test type and function must be mapped out for your test coverage map. It’s better to plan for more, as you’ll save time and money on the back end, especially where language testing is involved. Planning resources and test beds are essential at this point.
Executing an agile software localisation strategy
At this point in the strategy, it’s important to have a glossary and style guides for translators, translation memories (TMs) and an idea of where automation comes into the software localisation process.
In terms of what your process flow should look like, Lionbridge suggests:
Export Function > Translation Process > Review (optional) > Implement Changes (optional) > Import > Testing > Release > Repeat
Other important elements to consider are technology, tools and flexibility. While there are many localisation vendors offering to help globalise your software, take the time to select the right one. When selecting a provider it’s important to weight expertise vs cost. While selecting a new company that offers while less expensive options, they might not have the experience or technology that keeps a software localisation strategy ahead of the curve.
A solution architect or localisation testing expert would be beneficial at this point. They’ll be able to help you with figuring out what to test (browsers, languages, third party apps) and help to avoid over-testing.
Yes, over-testing can be a bad thing. It’s great if you’ve got limitless resources, but for the majority of businesses you need to find a happy medium. Make sure your code, localisation, and app support is working as it should, but don’t spend all your hours (and money) looking at your project through a microscope.
Find the right balance of testing coverage, quality, and costs. If you’ve got the in-house expertise, that’s all the better. Otherwise, a hybrid approach if in-house and outsourcing is best.
Originally published on Minutehack.com