Chapter 11. International Builds

Philosophy: Change before you have to.

Jack Welch, former Chairman and CEO of General Electric

Most people would agree that it is more efficient to plan ahead and build something once rather than having to rip it apart later and retrofit it. Every line of core code that needs re-engineering (or "remedial engineering") later on is a wasted expense, a potential bug, and a lost opportunity.

If you ask most developers, the majority of them would probably agree that inheriting someone else's code is never fun. It is rather painful at best. It is usually easier to develop the code from scratch than to figure out how someone else solved a coding problem and which routines they chose to do it with. After all, we all know that software development is an "art form," and each developer has his own style, albeit some being more "beautiful" than others.

Along these lines, building code for different languages tends to be an afterthought and abstract artwork. It is usually done by "localization engineers" and not necessarily by the developers who wrote the code. The U.S. market tends to be the primary one for most software companies. But don't get me wrong here. I realize that more than 50 percent of Microsoft's annual revenue is from international sales and has been for almost as long as the company has been around. This is my point: If your product is successful, there will be international demand for it. So plan carefully and as early as you can for "internationalizing" your product.

When localizing, there is a lot more to consider than just translating your text strings into another language. I have gathered some ideas and concepts that you should keep in mind when building your product for international releases. This chapter is by no means meant to be a comprehensive look at how to write internationally compliant code. For that type of detail, I will refer you to International Software, by Dr. International (Microsoft Press, 2002). What I cover in this chapter are the basics of building the international releases of your product for the Windows platform more specifically, Windows 2000 and later releases. The reason for focusing on Windows 2000 and later is because this is the first operating system that shipped a Multilingual User Interface (MUI) add-on that significantly changed the way code was localized at Microsoft. All operating systems post-Windows 2000 (XP and 2003) also have this add-on feature.

As with the previous chapters, let's start with some definitions and concepts and then end with recommendations of how we do it at Microsoft.