More and more applications today are being used in more than one country and more than one language. For many companies that are looking to move their software products into foreign markets, internationalization (i18n) and localization (l10n) can turn into an ugly and expensive process. The trap that many fall into is thinking that modern operating systems and programming languages will do most of the work for you. Microsoft Windows® comes in multiple languages, and programming languages like Java and C# have built-in support for Unicode and locale-aware functions. The problem is that there are still plenty of ways to get into trouble and create an application that is difficult to internationalize and to translate. Making the necessary changes to the code after the fact is always more expensive than doing it right from the beginning. The good news is that with modern software development environments, i18n is not rocket science. Keeping a few simple rules in mind when designing software will go a long way toward ensuring that deploying software in multiple locales and markets is as painless as possible.
When designing for international software, there are three primary areas to keep in mind: data, locale, and user interface (UI). When thinking about each in the context of software design, the most important question to keep asking is, “What happens when this runs in a non-English environment?” A basic familiarity with the possible issues that can arise across languages and a few simple rules should enable any modern software architect to put together a system that can run across any language, anywhere. Continue reading
