How to Prepare for and Launch an Agile Software Localization Strategy

ShareShare on Facebook0Share on LinkedIn0Tweet about this on TwitterShare on Google+0

How to Prepare for and Launch an Agile Software Localization Strategy

In any new initiative, planning—while not necessarily the most entertaining part—is vital to success. In fact, perhaps nowhere is it more needed than in software localization, in which lack of preparation into resourcing and workflow can have very costly and time-consuming repercussions.

As Antonia Benney, Senior Solution Architect at Lionbridge, observes, most companies would be surprised to find what resources are readily available in-house. But to implement a software localization strategy, they should have a firm grasp of where to draw from existing expertise, when to outsource, and what can be automated.

In a recent webinar, she applied 21 years of experience in software testing, localization, business development, and technical architecture to finding this balance in the most cost-effective way possible.

Why localize, and where to start?

The decision to take an app global is a smart one for several reasons. Going global can increase sales, revenue, market share, customer loyalty, and crucially, quality of customer experience, on a worldwide scale. Customers want to see software that is available in their own language—period.

It’s therefore important to begin your software localization strategy with a couple of key foundations in mind, the first being design. Developing your software for localization will reduce cost, functional, and capacity issues. Second, if it isn’t already, make localization an integral part of your company’s culture. Becoming part of an agile, global team is key to aligning localization with your business objectives and leveraging team members’ existing experience.

Budgeting for localization

Now, the boring part: Who’s going to pay for this?

In budgeting for a software localization strategy, consider whether corporate or regional teams will foot the expenses. Then, you’ll want to determine the fully-loaded costs for the entire endeavor—including translation, testing, engineering, and project management.

To do this, establish what can be done internally and what needs to be budgeted for externally. Doing what you can with what you have is ideal, but outsourcing to a language service provider (LSP) will at some point be essential. LSPs have their benefits, in terms of output quality and unique market expertise. Keep in mind, though, that more expensive does not always mean better quality, while inexpensive services can lead to low quality and rework.

Internationalization and testing

With budget taken care of, the first—and critical—thing to ensure is that your software is internationalized. Internationalization means getting code-ready: developing your software in such a way that translation is a simple and integrated process. Otherwise, you risk introducing bugs, which can replicate many times if not addressed. You’ll only want to internationalize once; coding is then dealt with and simply a part of software localization best practices going forward.

The next phase of planning is determining your test readiness. Consider issues such as what and how much testing is required, and gaps in your team where a translator is needed. It cannot be overstated, Benney noted: The more you plan, the more money and time you’ll save on the back end. Language testing can be the most expensive part of localization if you’re not prepared.

Executing and testing an agile software localization strategy

Your product is internationalized, and you’re ready to get started. But before getting into localization, there are fundamental building blocks to have in place: for example, glossary and style guides for translators, translation memories (TMs), and an idea of where automation comes into the software localization process.

Benney identified that the goal of automation is to use the smallest amount of human intervention possible—and the simpler the process, the better. With that in mind, she recommended the following process flow:

[Caption:] “Review” and “implement changes” stages are optional.

Determining exactly what happens at each stage differs on a case by case basis, but these are the basic components to tackle up front to make the translation, localization, and test processes as short and sweet as possible.

Other elements to consider are technology, tools, and flexibility. Thousands of software localization vendors are out there clamoring for your business—but again, be sure to weigh up opportunities and costs. Nowadays, it’s easy to start a localization company, but quite another thing to have years of expertise in the field and provide technology that keeps a software localization strategy ahead of the curve.

So how, and when, to test? The best way to approach testing—using methods such as pseudo-localization—is getting as much out of the way as you can before localization starts. But if you have a matrix of multiple languages, browsers, hardware, and third party apps, how do you eliminate the need to test them all? How do you avoid over-testing, which can have diminishing returns? This is where a solution architect or localization testing expert would be helpful.

Ultimately, your goal is a balance of testing coverage, quality, and costs—and therefore, the right balance of internal and external resources. It’s great if you can do everything in-house, Benney said, but if you have to outsource, a hybrid approach is best.

Benney goes into more detail about best practices for preparing a software localization strategy, how to save costs, and what to expect from outsourced providers in her webinar, Software Localization: What You Need to Know to Effectively Go Global. Watch the replay here.

ShareShare on Facebook0Share on LinkedIn0Tweet about this on TwitterShare on Google+0