1. Static Analysis for Internationalization
and Localization
This article was authored by Lingoport CEO Adam Asnes and originally published in Net-Translators’ June
2012 eNewsletter.
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 user
interface. 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 thousands 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.
© Lingoport Page 1 Static Analysis for i18n and L10n

2. 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.
For more resources on internationalization please visit Lingoport.com or dive into Lingoport’s wiki at
wiki.lingoport.com.
Related Reading
 Internationalization Management Tips: Ten Mistakes to Avoid
© Lingoport Page 2 Static Analysis for i18n and L10n