Introduction
This article 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 whitepaper before you begin your next software project, you will be on the right track towards creating a successful world-ready application.
.gif)
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:
Shipping one functional core binary to all platforms and for all different language versions significantly reduces your development hassle and costs.
Conditional compiling becomes unnecessary.
There is no need to maintain separate source codes and development teams.
your language versions can be shipped almost simultaneously, which means your sales force can capture more revenue from these versions.
Software updates are simpler because the same version of patches can be applied to all languages without any additional engineering effort.
Customers' global Information Technology (IT) departments save time and money because they only need to deploy a single service pack instead of many different versions.
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 Windows 2000, Windows XP, and Windows Vista 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 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. 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 and Windows Vista, 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.