Chapter 2: Designing a World-Ready Program
People who plan ideal cities spend months and sometimes years researching, documenting, and revising their proposals. It doesn't make sense to spend years planning most commercial software projects, but the complex process of planning a community illustrates some important principles. City planners study other cities and talk to the people who live in them to determine how they should design a new community. They do this before they even dig the first hole to lay a foundation for a building or a street. After all, a city has to attract residents, or building it will be a big waste of money. And business districts and neighborhoods must have room to grow. Any city budget director will tell you that having to tear down an existing high-rise or apartment complex to make room for a hospital, library, or police station is expensive.
A decision to release your program in different language editions-or at least to have it handle many different scripts (Latin and other scripts)-affects decisions that your team makes regarding coding and user interface (UI) design during the product cycle. A good underlying program design will work for all language editions of a product. Even if you have never designed or created world-ready software, you can probably foresee some of the issues that might arise if you examine an existing program. As with any project, large or small, the golden rule for creating world-ready software is to plan ahead. Few tasks in software development are more arduous, time-consuming, and expensive than rewriting existing code and redesigning existing features so that they will work for other languages. With a good plan, you can create a single-binary application that will accommodate multiple languages instead of just one. Some advantages of creating a single, world-ready binary include the following:
Only a few years ago, creating a single, world-ready binary was considered a costly and almost impossible task to achieve. But with the unprecedented international support that Microsoft Windows 2000 and Microsoft Windows XP offer, the process has become much easier and more cost-efficient. As a result, with a little extra effort, you can reach a much larger market than was possible earlier, with fewer competitors. In addition, since most corporations are multinational, they would rather distribute and support one set of software executables for their worldwide operations than be forced to maintain a mishmash of binaries.
Indeed, the Windows XP team has learned from experience to use the single-binary approach. For example, the Chinese, Japanese, and Korean editions of Microsoft Windows NT 4 had slightly different application programming interfaces (APIs) for Input Method Editors (IMEs), the modules that handle the input of ideographic characters. (See Chapter 5, "Text Input, Output, and Display.") The differences made it hard for developers to create single executables that would work on all East Asian language editions of Windows NT 4. Windows XP, in contrast, has a single unified IME API for not only the East Asian editions but for all the language versions of the operating system. Developers who wrote applications for East Asian and other non-Latin versions of Microsoft Windows prior to the release of Windows 2000 (the first release of a single binary for Windows) were no doubt pleased with this improvement.
This chapter describes the issues you need to consider when writing specifications, when customizing features, as well as when designing the user interface and code for a single-binary, world-ready program. It also describes strategies for setting up a project team and a development environment, and gives tips regarding testing and translation issues. By familiarizing yourself with the concepts presented in this chapter before you begin your next software project, you will be on the right track towards creating a successful world-ready application.