Successfully launching software for a global market requires internationalization. Without that, adapting your software for other languages and locales is impractical and expensive.
Since failing to prepare your software to support multiple countries isn’t a real option, when should you start and how do you manage the cost? The answer is that the earlier you include internationalization in the development process, the less it costs.
What is Internationalization
Internationalization, or i18n, is the process of building the framework in software, apps, and websites to support markets around the world. That includes multiple languages, date and time formatting, address formatting, number formatting, currency conversion, user interface elements, data sorting, and other changes to support different locales and cultures.
In a sense, i18n makes code modular so elements that need to change for a specific country or region are easy to swap. For language translations, that relies on string localization, which treats each text part like a LEGO brick that can be quickly replaced.
Internationalization lays the groundwork for localization (l10n), or the process of translating languages and converting other elements to conform to a locale’s requirements. Since developers work with a single code base instead of spinning off a separate version for each language, the amount of time spent writing code is significantly reduced, the number of bugs is reduced, and the overall development cost is much lower.
Procrastination Doesn’t Pay Off
In most cases, the longer a company waits to start internationalization, the more expensive the process becomes. If you’re planning on serving multiple markets, the most economical time to internationalize your software is when you start developing it. Including i18n at the beginning of the process saves your developers from needing to write new code later — or rewrite existing code — to support internationalization and localization.
Incorporating i18n into code later poses some challenges for developers that may lead to redirecting resources, or release delays.
- Working with existing code: Jumping into i18n after software has already shipped means there’s a lot more code to review for updates. Developers will likely have to write new code, too.
- Complexity: As software grows, the code becomes more complex. For developers, that means more time and money spent finding where i18n changes need to happen. It also means there’s a higher likelihood of missing something.
- Bugs: As the software code becomes more complex, there are more opportunities for i18n-related bugs. If those bugs aren’t caught, developers need to spend more time later addressing them instead of focusing on new features.
Companies can make their coding more efficient by using tools to automatically scan for i18n-related bugs as they’re writing code. Lingoport’s Globalyzer does that by integrating with developer’s IDE so they can check for issues while writing and reviewing code. Globalyzer also scans code repositories during pull requests. It can find issues in four categories:
- Embedded and Concatenated strings
- Locale-sensitive methods
- General patterns
- Static file references
The price for failing to catch and fix i18n-related bugs early is surprisingly high. Finding them during initial development doesn’t cost any more to fix than other coding flaws. Finding those bugs during the functional testing phase, however, costs 10 times as much to fix. If internationalization bugs make it all the way to release, the cost to address them is more than 600 times higher.
Supporting i18n later isn’t an insurmountable goal. Some companies develop their software for the one market they serve, or they acquire a business with software that hasn’t been internationalized or localized. In those situations, Globalyzer can make adapting software for expansion into additional markets easier, too, since it automatically scans code for internationalization issues. That’s a big time saver for developer teams since they may be working with thousands — or even millions — of lines of code.
The i18n Circle of Life
Software gets new features and revisions over time. Those features come with new code, which needs to be written with internationalization in mind, too. Since localization relies on internationalization, i18n-related bugs carry over into problems and potential delays for translators and the rest of the l10n team.
Repetitive and tedious tasks are opportunities to automate workflows to save time and money. The ongoing internationalization and localization process is a perfect example of where this pays off. Developers using Globalyzer in their IDE, for example, are able to verify their code is i18n ready without the need to stop working on their other development sprint goals.
The localization team can do their job in step with developers since bugs that would otherwise cause them delays can be addressed before they become problems. That cuts down on costs and lost time, as well.
Localyzer and Localyzer QA round out the automation puzzle by managing the elements that need to be adapted for different locals. With them, content can be translated, reviewed, and added to the code base without impacting the developer team, which also helps keep budgets in line.
Managing the costs involved with i18n makes expansion into new markets more approachable for companies. That starts with writing software with i18n in mind and creating a continuous development workflow that allows coding and localizing to happen at the same time. It also involves using the right tools in the IDE to reduce the internationalization workload for developers. With all the pieces in place, companies can stay on top of i18n costs during initial development, and as their software evolves over time.
Resources to Learn More
With a solid internationalization plan in place, companies are better positioned to prepare their software for new markets faster and at a lower cost. The payoff is software that feels native for every user, customer loyalty, and a better chance for more sales.