The other half of localization: Internationalization
Internationalization is the other half of localization, and the two are like yin and yang, requiring different but intermingled tasks and knowledge. For internationalization I’m referring to developing software, sites and applications so that they are capable of dynamically supporting any language or locale preference needed for their marketing and use. That’s a bit of a difficult abstraction, and after all these years of me doing it, I’m pretty sure my mother still doesn’t really understand.
Think of it this way: software doesn’t just work in another language because you localize the U/I. If you want to globalize, you actually have to make source code so that it can support multiple languages without creating a new product. Software also doesn’t just display an interface. It deals with all kinds of data input, data manipulation, storage/retrieval, comparisons, calculations, reporting and more. To support all that, the fundamental logic and processing of how software presents information needs to be adapted so it’s pretty flexible on issues like language, sorting, date/time presentation, numerical formatting, parsing addresses, phone numbers and more. Generally, for software localization to work at all, internationalization needs to be in place, and becomes an ongoing requirement for all new product development activities once a company takes on localization.
Trouble is, internationalization can be very expensive in money and time if you haven’t built it into your product in the first place, or it can be hard to maintain as your team pushes for new product features. It’s difficult to quantify, test and verify internationalization issues and often there is only limited verification after localization is well under way. It’s no wonder global releases are often late, way over budget or worse, not really tested and just pushed out to market.
Tracking down and measuring internationalization issues
A challenge with internationalizing existing applications is tracking down and measuring internationalization issues when they are buried in hundreds of thousand to millions of lines of code. Most people take a testing route, but it is extremely difficult to test potential use cases and their conceivable permutations. Additionally, by nature testing happens at a more costly time in the development process. Engineers usually have moved on to new features or other development efforts and tracking down and fixing bugs slows down releases.
We use static analysis with our Globalyzer software to pinpoint internationalization issues right in the code either during the development process or at staged intervals like a nightly build. Another advantage is instead of cataloging a bug, you are creating lists of exact issues exactly where they are in the application. Think of this as a very strong to-do list, guiding the developer through internationalization. This is not to say that testing isn’t needed, but it should be a last verification step, and not necessarily an investigative and scoping tool as it has often been used for internationalization.
Static analysis
With medical products, using static analysis as a process is especially gaining acceptance. With a particular emphasis on quality control, and consequences for bugs, examining code at the source level for constructs, bugs and security is becoming a regular part of product verification. We know of one medical products client that started working with Globalyzer directly because of a dangerous issue regarding locale support that they missed in testing. It is very hard to recreate every possible user scenario for multiple locales, including misuse, so static analysis becomes a strong way to mitigate that risk.
Conclusion
Medical products offer a case where lives are potentially at stake, but given how global customers, revenues and organizations play such a strong role in so many companies, tools that quantify, monitor and help remedy internationalization issues efficiently should be important to every development team.
About the Author
Adam Asnes is President and CEO at Lingoport and enjoys investigating how globalization technology affects businesses expanding their worldwide reach. Adam is a sought after speaker at industry events and a columnist on globalization technology as it affects businesses expanding their worldwide reach. He often writes articles for localization, internationalization and globalization industry publications and enjoys cycling and Colorado’s Rocky Mountains.
About Lingoport
Lingoport helps globally focused technology companies accelerate and improve how software is built for world markets. Lingoport’s suite of products is the market leader for companies looking to remove surprises in coding software for the world by automatically checking, measuring and fixing source code for internationalization (i18n) defects. Combined with comprehensive outsourcing services, Lingoport offerings enable our clients to make world-ready software development a priority for their worldwide customers.
Contact Lingoport by phone at +1 303 444 8020, by email at info@lingoport.com, or find and follow Lingoport on Twitter at https://twitter.com/Lingoport, on LinkedIn at https://www.linkedin.com/company/lingoport, on Facebook at https://www.facebook.com/Lingoport, and our i18n blog at https://i18nblog.com/.
This article was authored by Lingoport CEO Adam Asnes and originally published in Net-Translators’ June 2012 eNewsletter.
