A Better Approach to Internationalizing and Localizing Software
Adapting software so that it supports multiple languages and locale formats is not trivial and it is important to your global success. A localized User Interface can have a positive impact on your customers’ satisfaction with your product. The globalization requirements span your software architecture and ongoing development practices. It is important to create ongoing processes so that internationalization (i18n) and localization (L10n) can be easily integrated into your sprints and releases.
Why Software Localization is Valuable
Companies that are looking to grow globally find that fully localized software is one of the key elements to sustained growth. You may gain some initial traction without localization, but if you want to move beyond early adopters and be more competitive, the localization process is an essential step. The localized software is easier to use and helps build long-term customer satisfaction. In addition, companies that invest in i18n and L10n often find they are at a competitive advantage in international markets which helps maintain pricing power.
But before you can effectively localize, you must internationalize your software to enable multilingual capabilities. This includes:
- Adding locale frameworks
- Externalizing strings
- Refactoring string concatenations
- Replacing locale-limiting programmatic functions/methods and patterns
- Database internationalization
- Managing potential 3rd party product issues
Getting Started
Internationalizing your existing application may seem daunting but the effort is typically rewarded with increased revenues. There’s a reason many companies underestimate the effort required to internationalize software. Many good programmers don’t have experience with internationalization and are therefore unfamiliar with best practices. They may regard i18n as a simple string externalization exercise – which of course is not the case. To complicate matters, without tools to keep the development teams on track, it is inevitable that i18n technical debt will creep into new features. Below are some tips and suggestions to help make your internationalization and localization efforts efficient, effective, and successful.
1. Dedicated Team
It’s not uncommon for some companies to start internationalization efforts with only one or two developers. Within a few months, they are pulled from i18n and put onto a “higher priority” project and sometime later replaced with different developers. This inconsistent approach almost always fails. After a year or more and significant resources expended, the project is still not complete, and the opportunity cost only continues to rise.
Creating a dedicated project team is the most important step in ensuring your internationalization effort will be successful. Using third-party contractors to lead the effort, combined with some of your own development resources, is one way to make sure the team persists even when internal resources are diverted. This approach has the advantage of allowing multiple internal developers to participate in the i18n process, rapidly improving the learning and socialization of internationalization techniques.
2. Software Architecture
Before diving into externalizing strings, it is important to first look at the software requirements and architecture. Is Unicode required? String externalization in the user interface is obvious, but are strings also passed through and processed in your software back end? How will you support locale selection within your application’s various programming languages? How will locale be selected and is there a fallback? What changes will need to be made within your database? Are there third-party libraries that need to be considered? Like many programming tasks, getting the approach correct up front will save many hours of wasted time doing rework. Are you choosing to use established methods for locale support or creating your own (we don’t suggest the latter)? Using standard resource file types and conventions will make automation of the translation process much easier.
3. Finding i18n Bugs
One of the more challenging aspects of internationalizing existing software is finding all of the i18n issues. Within thousands or even millions of lines of code, these can be difficult to identify and resolve. Fortunately, there are static analysis tools available, like Lingoport’s Globalyzer, to make the task of finding and fixing i18n bugs faster and easier. It is also important to put in place a method to quickly check new source code as it is being written so that internationalization becomes part of the agile process rather than addressed later in backlogs when it will cost much more in time and hassle. When developers can quickly scan their work from their IDE to find i18n issues, they are much more likely to fix the issues as they are writing the software.
4. Automation
The very nature of agile development involves rapid new feature development. For localization, this means many relatively small localization changes, performed more frequently. Traditional approaches to software localization involve many manual steps to perform a localization update. The process of finding and enumerating new strings from resource files in repositories, sending them out for translation, and returning the translations to the repo, can be tedious and error-prone. When changes are made to the source string, sequencing of the returned translations is almost always an issue. In addition, errors in the source files are multiplied across all of the locales during translation so it is important to validate the formatting prior to sending the files for translation. The good news is that this entire process can be automated so that no one needs to take on the role of “file nanny”, shuttling files back and forth to translation. For example, Lingoport’s Resource Manager handles these tasks using continuous integration along with an automated connection to your localization company or translation management system.
5. Selecting a Translation Partner
Language Service Providers (LSPs), also known as translation agencies, provide professional translation services including software and app localization.
Selecting a translation agency that has experience in and an understanding of software and app localization is key for ensuring your localized product is well received in new language markets.
Here are some things to look out for when evaluating translation agencies:
- Will the localization process be synced with your development process and does it fit seamlessly into your existing workflow?
- Do they offer integrated technology solutions to provide continuous translation and streamlining string hand-offs?
- Are they providing a veteran team of in-country linguists and industry tools to deliver quality translations that meet your deadlines and budget?
- Are they a full-service agency that can be called upon throughout the enterprise with professional translation services that include website, documentation, video and marketing content translation?
- Do they provide an optional Quality Assurance (QA) step that includes efficient, in-context validation of language and formatting to ensure your product looks and functions as intended?
When selecting an LSP, you are outsourcing a set of specialized and time-sensitive tasks that are closely coupled to your creative and development process. Quality should be a priority at each step in the process, from project set up through quality assurance. Working with a localization partner who can navigate both cultural and technological challenges will not only take your product across borders but also help it succeed across language markets.
The unique challenges of software demand dedicated effort to internationalization and localization. The proper tools and partnerships are required to meet your agile development workflow. Lingoport and Acclaro provide the expertise and solutions to help you meet your worldwide market goals.
Acclaro is a strategic partner of Lingoport.
I18n is a vague software requirement. There are some obvious best practices, like the avoidance of embedding strings in your code (obvious, but it still happens), and less obvious issues (i.e. string concatenations, not passing locale into a method, date/time issues, encoding issues, programming patterns that will negatively impact localization and more). 
Globalyzer and Resource Manager come with extensive default detection and filtering for many programming languages (i.e. JavaScript, Java, C# and much more) and resource file types. Globalyzer uses machine learning capabilities to finely tune i18n static analysis to pinpoint issues and eliminate false positive detections. Setting up and performing functions can be as simple as calling Lingobot from within collaboration tools like Slack or even from an IDE.
QA are the gatekeepers of the definition of done, but they need a clear path to measure quality. As developers update interfaces, Lingoport Resource Manager automatically updates changes with pseudo-localizations that can be used to test for language and locale requirements without needing to speak the target languages. Pad characters with target encoding, with a clear beginning and end mark, are added to strings with controllable expansion depending upon target locale requirements. Testers can see quickly if there are problems. 
