Read an Excerpt
Designing a World-Ready Program
Identifying World-Ready Requirements in Specifications
Planning for Globalization
Designing an International User Interface That’s Localizable
Researching Legal Issues
Keeping Features Accessible
Organizing a Product Team
Setting Up a World-Ready Development Environment
Eliminating Compile Dependencies
Making Life Easier for Translators
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:
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.
All 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 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.
Identifying World-Ready Requirements in Specifications
The design process will generally begin with your specification, in which you identify all criteria that will help bring about world-readiness. The general categories to consider when writing your specification include globalization, customizing features, designing a user interface (UI) that’s localizable, legal issues, and accessibility of features. Each of these areas is discussed in more detail throughout the remaining sections of this chapter.
More specifically, your team’s specification should address factors affecting your ship dates, such as staffing requirements and the scheduling of milestones for coding, translation, and testing. In addition, the members of your team who are writing the program specification need to know and specify in advance which languages and locales the final product is targeting and to what extent each language edition will actually be translated.
Also, when describing the appearance and functionality of new features, the team should be sure to address internationalization issues in the specification. Some examples include whether certain features will be removed or customized for different editions, and whether a feature’s behavior must be locale-aware. For instance, what happens if a user enters Cyrillic (Russian) characters? Is it necessary to adjust certain dialog boxes for the Japanese edition? Program designers need to consider such details. If they are not familiar with foreign languages or with the needs of international users, they need to talk to people who are.
If you work for a large company, send copies of your draft specification to marketing representatives and language specialists at international subsidiaries. If you work for a small company, share the specification with overseas partners or consultants. Your partners should be able to point out any glaring errors or oversights and give you feedback on the relevance of proposed new features and designs to their markets. They might forward customer reports, market-research results, and reviews of competitive products from the local press. They should also provide you with locale-specific information your product might need, such as typical postal codes, business letter formats, punctuation rules, and so on. (Country-specific formats for addresses, currency, date, time, and other information can be found in the appendixes of this book and on the accompanying CD.) Familiarity with the specification will in turn help your international partners make plans for marketing the product once it is released.
Good planning will help you ship your product quickly. Early feedback on the specification from your team, key customers, usability tests, and market experts will help you determine the best way to implement your features at a much lower cost than the cost of making changes at the last minute. Large-scale, last-minute changes in your product design will cause a chain-reaction delay in the ship date of your executable, Help files, tutorials, documentation, and marketing collateral—all of which might then need to be retranslated and retested. You never want to ship an inadequate product, but major last-minute changes are expensive; you can avoid them by working from a solid, world-ready specification.
Some of the areas just mentioned that you’ll need to consider when developing a world-ready specification—for instance, specifying which languages and locales the final product is targeting—overlap with tasks associated with globalization. This makes sense since focusing on globalization issues, once again, is an integral part of writing any specification that’s world-ready, as discussed in the next section.
Planning for Globalization
Although Part II, "Globalization," discusses globalization in detail, it’s important to have an initial understanding of what globalization covers as you prepare your specification. Making sure that all language versions of your software have the same built-in capability to support all targeted languages and locales is called "globalization." It is essentially a process that involves the following general tasks:
Identifying the languages and locales that must be supported.
Designing features that support targeted markets, languages, and locales.
Writing code that functions equally well in any of the supported locales.
These tasks are all centered on the concept of locale-awareness, which, as you’ve seen, should be an integral part of your specification. (See "Identifying World-Ready Requirements in Specifications" earlier in this chapter.) Nevertheless, the scope of globalization features is even broader than issues regarding locale-awareness. A second area of globalization involves encoding data for internal processing and sharing it with other applications. Like all aspects of coding, there are many ways to do this, each having strengths and weaknesses. However, Chapter 3, "Unicode," explains why Unicode is the best encoding method to use when dealing with world-ready applications.
A third major area of globalization concerns the input, output, and display of data to the user. You will recall that IMEs refer to the modules that handle the input of ideographic characters. In order to ensure correct input of data, IMEs are used for languages such as Chinese, Japanese, and Korean. Character-shaping engines handle the display of complex scripts such as those in Arabic, Thai, and Indic languages, among others. Since the input, output, and display of data are all processes linked closely with font technologies, you should carefully consider the best approach for using fonts.
You should also determine how to manage Multilingual User Interface (MUI) technology, the fourth major area of globalization. For example, how will you display items like menus, dialog boxes, and system messages in the user’s preferred language? In order to help you better understand the four globalization issues highlighted here, Part II, "Globalization," is exclusively dedicated to this topic.
The process of writing a specification that’s oriented toward world-readiness will, among other things, force you to think about what features will need customizing. Of course, a well-designed, world-ready core product minimizes the need for customizing features for different language editions. As you write your product specification, however, you might find that certain features important to your domestic market don’t make sense for other markets, or that some markets require functionality that isn’t necessary for your domestic market. For example, the East Asian versions of Windows XP automatically add the necessary IMEs at installation, whereas the English version does not, but instead allows the user to install them later if needed.
Some features might be essential for all language editions of a program, but they might require that different code be executed for different languages. One obvious example involves features that do lexical analysis—spelling checkers and grammar checkers, for example. Spelling rules and common words change from language to language. Therefore, most Windows-based software products ship spelling engines as separate DLLs and spelling dictionaries as separate compressed files. For some languages, such as Italian, spelling rules are simple and consistent. For others, such as Japanese, spelling checkers and grammar checkers are exceedingly difficult to write.
Another example of feature design that is locale-specific involves the Regional And Language Options component of Control Panel in Windows XP. While the Sorting tab appears in the Customize Regional Options property sheet of some language versions, in others it is absent, depending on the particular language’s rules regarding word sorting. For instance, some regions like English (United States) or Italian (Italy) have only one way to sort words in some prearranged order. Other regions like German (Germany), Spanish (Spain), or Simplified Chinese (PRC) have more than one way. Thus the Customize Regional Options property sheet displays the Sorting tab only when the region’s locale has more than one sort order, such as in the German locale, which has two different sort orders (Dictionary and Phone Book). (See Figure 2-1.) Since Italian has only one way to sort, the property sheet for the Italian locale does not include the Sorting tab.
Figure 2-1 The Customize Regional Options property sheet for the German (Germany) and Italian (Italy) locales. (Image unavailable)
In cases such as those just discussed, it is important to create code that is flexible, so that you can easily add, remove, or customize functionality. This is especially true since your product will face tough competition in well-established markets. In Germany, for example, word processing programs with poor hyphenation engines tend to sell poorly, and in Japan, people will buy only the text processing programs that make it easy for them to enter kanji characters. Arabic speakers might expect the ability to juxtapose Arabic and English text.
Features that access large amounts of language-specific data can use text files to simplify customization. Windows Setup, for example, reads from text files the list of shipped components along with their localized file names, file sizes, and floppy disk locations. Localizing the Setup program for Windows, then, is only a matter of translating the program’s user interface and tailoring the text files. The core setup code works for all language editions. Many spelling checkers use a similar mechanism. The code that searches for spelling errors and suggests corrections remains constant, but special dictionaries—such as medical, legal, and scientific dictionaries—are provided in separate data files.
Designing an International User Interface That’s Localizable
By now you have seen that creating world-ready applications produces versatile applications that can be used in many different locales, thus giving you access to more markets and increased revenue. Another reason for creating world-ready applications is to keep localization and development costs down, with localizability of the UI being one of the best ways to accomplish this goal. Though both globalization and localizability are part of world-readiness (which, along with localization, forms the basis of creating internationalized software), it’s important to understand the distinction between the two.
Take, for example, the executable Wordpad.exe. Making sure users can edit any supported script using different keyboard layouts and IMEs—or displaying calendar information that’s specific to a particular language when users insert the date in WordPad—is part of globalization. The product does not need to be translated into a given language for users to leverage these functionalities and for testers to test these features.
Now, suppose you want to translate WordPad into a given language. Making sure that all resources that need to be translated are separated from your source code, and that dialog boxes are designed in a way that can accommodate text expansion, are both localizability considerations. Since globalization deals mostly with the application’s functionality and not its user interface, defects pertaining to it are easy to detect early in the design process before any translation even starts. However, these defects require you to address potentially major changes in design or extensive coding changes. Localizability issues, on the other hand, are harder to detect. The software first needs to be either code-reviewed or be translated into either a pilot language or a pseudo-language. (See Chapter 12, "Testing Localizability with Pseudo-Localization.") Also, sometimes issues only affect a given language, so you will need some extensive language-specific testing to unveil certain problems or bugs. On a positive note, localizability defects are usually relatively easy to fix, assuming that it’s not too late into the design process to make such changes. Things can backfire, however, if you wait too long to address bugs, since you will then need to correct them in every language version you ship.
When designing for localizability, remember that it is human nature to take for granted that which is comfortable and familiar to us. For example, linguistically speaking, many grammar rules of our native language, which we learned intuitively when we were young, tend to reside in our unconscious mind. We usually activate or use these rules also somewhat unconsciously, rather than with our conscious, analytical mind. Similarly, it can be tempting or easy to assume that, for example, the idiomatic expression that something "costs an arm and a leg" will be similar in other languages. However, in Spanish, the same expression is that something "cuesta un ojo de la cara," or literally, that something "costs an eye from the face." In similar fashion, with languages in applications, it can be easy for developers to lose sight of how these languages will function in another language market, unless they consciously analyze the issues beforehand. Many developers create coding tricks that they feel are clever in the earnest attempt to save work and money, yet which often overlook the broader context.
Some of these programmers’ tricks include the following:
Hard-coding strings in their code, to avoid having to create a resource handling service.
Saving storage space by using text strings that are concatenations of phrases. For example, developers might use the text string "The [flood gate/control rods/exit door] cannot be [closed/open/reset]"—which doesn’t account for changes in verb form resulting from nouns of differing gender and number—instead of having to create nine different sentences.
Overlapping controls of the dialog box (such as hiding one button behind another), thus saving display space in the dialog box.
Although these strategies can be viewed as clever in that they can save some work for the developer, in the long run these myopic practices will increase costs when you localize your applications. This is because every code change that could have been avoided with good localizability practices is multiplied by the number of language markets for which you are preparing your applications. For example, if you’re going into 24 markets, the cost of every localizability issue not addressed in the core code costs you up to 24 times its original cost to fix, because you might have to fix it in every language version. Chapter 7, "Software Localizability Guidelines," discusses the many areas you need to think about when creating a localizable user interface.
Researching Legal Issues
Another component of customizing for international markets entails investigating pertinent legal issues. As you get feedback on your product specification, solicit advice from people familiar with the law in local markets. Certain kinds of features might affect the international distribution of your product. For example, some countries have export and import laws that govern the sale of products that contain encryption algorithms, such as those used for file compression or copy protection. Software that connects with telephones can be more difficult to sell in Europe, where some governments closely regulate the use of phone lines. Software and documentation that is marketed in France must be in French, and software marketed in Brazil must support hardware that is developed locally.
In Germany, competition law severely restricts a company’s ability to claim that its product is better than another company’s product. This directly affects advertising and packaging, but it can also affect sample files, documentation, Help files, or features that assist users in transitioning from a competitor’s product to your product. Productivity features, such as those that keep track of how long a user has been editing a document, might conflict with labor laws.
Another important legal consideration is, of course, software piracy. Microsoft works with the Business Software Alliance (BSA), located in Washington, DC, to protect its products overseas. (Figure 2-2 on the following page shows one of Microsoft’s logos used in literature to stop piracy.) The BSA conducts educational campaigns and lobbies governments for tougher piracy laws. The efforts of the BSA have proven more effective in preventing piracy than adding copy-protection code or hardware devices to products. Although counterfeiting is illegal in many countries, some countries still allow local companies to market clones of software products. Before you enter a new software market, research these issues. Keep in mind that entering new markets requires diplomacy. Microsoft’s well-publicized efforts to establish Windows in mainland China is a good case study for any company seeking to expand its operations. Microsoft was not aware of the politically sensitive issues of developing products offshore for import into the People’s Republic of China when it began developing and marketing the Simplified Chinese edition of Windows. As a result, the company unwittingly angered the Chinese government. For this reason, Microsoft worked very closely with the Chinese government and local developers to ensure the full success of Windows XP.
Figure 2-2 One of Microsoft’s anti-piracy logos. (Image unavailable)
Keeping Features Accessible
The purpose of making your software world-ready is to make it easy for as many people around the world as possible to use it. Designing for accessibility has the same purpose—and many features that place software within reach of people with visual, aural, cognitive, or mobility impairments also help prepare it for localization. For example, dialog boxes with a simple design and minimal text are easier to translate and easier for some people with visual impairments to read. Addressing accessibility issues in your product specification will result in a product with a larger potential worldwide market. Just as with world-readiness, designing your product to be accessible from the start saves you from having to redesign it later—and possibly from having to release special editions.
Detailed guidelines for designing accessible applications for Microsoft Windows are published in the subtopic titled "Accessibility" in "User Interface Design and Development," available in the Microsoft Developer Network Library.
Organizing a Product Team
Identifying world-ready requirements in your specifications and customizing features for the global market are two essential steps toward designing a world-ready program. Of course, having people who will implement your plans is obviously another vital component. Putting together an efficient product team is a challenge that can make a significant difference to your bottom line. If your entire team—including developers, designers, testers, translators, marketers, and managers—is committed to all language editions of your product, and if management holds them responsible for all language editions, you won’t have to hire a lot of extra people.
The golden rules for product team managers are as follows:
Educate all product team members on internationalization issues.
Hold all team members responsible for the international functionality of their features.
Develop at least one localized or pseudo-localized edition in parallel with the domestic edition. (See Chapter 12.)
Managers might argue that holding all team members accountable for all international products will cause them to lose focus, but in reality such a policy will save time and effort in the long run. Developers who are responsible for only the domestic edition of a product have no incentive to design global code, and might not even know how to do it. Later, when problems are uncovered during software translation and testing, those developers will have to spend time fixing errors that would have been easy to avoid; instead of working on the next version of the product, they will be busy redesigning old code. If your team creates a program so domestically centered that bitmaps must be changed or features redesigned, you will sacrifice consistency among language editions. If you choose to minimize the time spent fixing internationalization problems, you will release poor-quality products. Fixing and adjusting an existing product takes time, during which your company pays salaries and loses sales.
Microsoft used to have separate teams working on each product—one for domestic software and one or more for international software—and each one reported to separate managers and had different objectives. The domestic teams wanted to finish their English products as quickly as possible, with a minimum of interference. The international teams wanted to release localized editions as quickly as possible, and constantly needed domestic teams to make changes that would lower localization costs. This arrangement created an "us vs. them" mentality, because each team invariably had different priorities and felt the other was making its job harder.
Eventually Microsoft merged the domestic and international teams, but managers still assigned responsibility for international editions to "international developers." Just as before, these developers had to contend with algorithms that were not designed for multiple languages, and they had to decipher code that other people wrote.
This old approach, with its sense of being disconnected, contrasts with the current approach, with its emphasis on being a cohesive unit. The results are clear. For the Windows XP project, the German language edition of the system was shipped the same day as the English edition. In addition, many language editions—including Chinese, Japanese, Korean, and several European languages—shipped within 21 days of the English release. This was an improvement of more than a year over the release delta between English and Japanese Windows 3.1. These goals were achieved because, after Windows 3.1, Microsoft moved all the development for Windows to Microsoft’s headquarters in Redmond, Washington. The teams working on features related to East Asian languages, complex scripts, and multilingual versions worked alongside the rest of the Windows XP team and reported to the same managers. The Windows XP team was thus able to meet strict milestones for delivering localized editions of their operating systems.
Although some teams are still tempted to follow the old approach, it has proven to be a very inefficient way to create international products. Developers find it much easier and more rewarding to be the experts on a subset of features than to be jacks-of-all-trades trying to maintain a working knowledge of an entire product code base. And if you hire one or two people to monitor all international functionality, you are basically paying some developers to clean up after other developers who will continue to make the same mistakes. Why pay someone to fix design problems and bugs that educated developers can prevent in the software’s planning stages?
As you delegate more responsibility for world-readiness to each member of your development team, remember that changes aren’t likely to occur immediately. It takes time to instill global thinking into your company culture. A good example of the need for perseverance can be seen in the development of Microsoft Word. In the earlier versions, there were many different localized code bases. However, persistence has paid off. With team members sharing the responsibility for world-readiness, all localized versions of Word XP are now created from one code base. (See Figure 2-3.)
Figure 2-3 The gradual convergence of localized versions of Word into a single, world-ready binary.1 (Image unavailable)
In addition to promoting a company culture of world-readiness that trickles down to each individual, you will also need to consider the needs of some key people—your translators. (For more information, see "Making Life Easier for Translators" later in this chapter.) Quick release of localized software requires that translators begin work early. If you plan to hire translators from abroad, remember that it takes time to obtain work visas for noncitizens. Microsoft employed in-house translators and third-party contractors to translate German, East Asian, Arabic, and Hebrew editions of Windows XP in Redmond. All other European editions of the operating system were translated, tested, and manufactured at Microsoft’s subsidiary in Ireland. The subsidiary also hired third-party contractors in Europe. If you do hire a third-party localization company, make sure that translators have direct access to members of your product team, or you will lose some of the efficiency and other benefits gained with early translation.
Much of the expense and lost productivity resulting from any inefficient approaches described in this section drain a project’s resources subtly over time, and might be apparent only to people who prepare budgets and earnings reports. If you are having a difficult time convincing your company to change its approach to internationalizing software, arm yourself with schedules, bug lists, and sales statistics from past products. Back up that ammunition with market research and testimonials from product team members. Finally, show people this book.
Setting Up a World-Ready Development Environment
Along with assembling your product team, you will need to provide a development environment that is conducive to world-readiness. A key prerequisite to creating a world-ready core code base for your program is that all language editions share the same core source files. Maintaining separate source files for different language editions of the same product is error-prone, a waste of time and disk space, and unnecessary for code that has been made world-ready.
When you have shipped or are close to shipping your domestic product, you might decide to make a copy of your current source files and set up a separate development project for the next product revision. In such a case, you will need to pass bug fixes to the new project and incorporate updated code or features into the old project for international editions that have not yet shipped. When the schedules for your international releases overlap with the schedule for the next product revision, you might be torn between your desire to take advantage of improvements and your desire to ship to international markets on schedule. Obviously, you have to use your best judgment in these situations.
Just as all language editions should share a single set of source files, all language editions should share a single bug database or bug-tracking system. Many defects will be common to all language editions, but bugs that first appear only in non-native editions can reveal design flaws with regard to world-readiness. Those responsible for testing certain features in native editions should also be responsible for testing the same features in the international editions, or with non-native settings and parameters. It’s a good idea to have dedicated test scripts for localized products and help from native speakers to test certain features, but the most successful philosophy is that of one product, one team.
As you start a new project, be sure to select tools—such as editors and compilers—that will help rather than hinder world-readiness. If you plan to write customized build tools or design your own resource-handling mechanisms (instead of using Microsoft Win32 resource files), first consider what effect they will have on your international editions. If you must write your own build tools, make them world-ready the way you would your main executable.
Eliminating Compile Dependencies
A major incentive for creating world-ready core code is not having to recompile source files to create localized editions of your program. If you eliminate compile dependencies by avoiding hard-coded strings or constants and by not putting localizable resources in header files, your localization process will go much faster. (See "Designing an International User Interface That’s Localizable" earlier in this chapter.)
Very large programs take hours to compile, even with powerful processors. Building debug and nondebug executables from scratch for each language takes significantly longer (unless you buy a number of expensive machines) and requires large amounts of disk space. If you share common code, you have to compile your main executable only once. To create localized editions, you first separate items like strings and graphics from your source code, and then you compile only these localized resource files and link them to the executable or to a separate DLL. (See Chapter 7 for more details on resource separation. Also, see the chapters within Part III, "Localizability," for other localizability issues in general.) It’s even possible to eliminate compilation entirely by using localization tools that allow translators to edit executables directly.
To handle those parts of the code that will change from one language edition to another, you can create a directory structure that separates your core code from each language version of your localized resources. Each set of resources can be placed in a single directory. Translators need access only to the directory containing the native-language files and the localized files for which they are responsible. A multilingual build process can incorporate resource files from the appropriate language directory and place resulting files in that particular language’s Build directory. (See Figure 2-4.)
Figure 2-4 Sample directory structure. (Image unavailable)
All files needing language customization are located in the Resources directory. Developers update files in the Native directory and use batch files to propagate the changes to other language directories. (The Neutral directory separates all your resources that do not need translating from those that do.)
This "no-compile" strategy has a number of obvious benefits. Separating code from localizable resources helps you write world-ready code. Also, significantly reduced compile times allow for faster turnaround in the development, testing, and translation cycle. Testers, for example, have to test only one executable. Translators, especially third-party consultants, don’t need to have access to source code—with only an executable, resource files, and a build script, they can compile a localized program to check their work.
Without this "no-compile" strategy, you might need more than one core executable—one for all single-byte, left-to-right languages; one for multibyte languages; one for single-byte, bidirectional languages and several for languages based on complex scripts. Multibyte, right-to-left, and complex-script languages require special input and layout handling. A single code base for Windows XP was used to produce more than 24 different language editions, all of which use a no-compile approach.
Even though source files for Windows contain #ifdef statements to distinguish code bases, #ifdefs are never used to handle cases specific to individual languages. The best place to put #ifdef statements is in header files. Don’t use code with #ifdef statements to fix bugs that occur only in the nondomestic language editions, since this practice makes international concerns too easy to ignore. With the increasing importance of multilingual documents, it’s harder to label bugs as being "international only." Often the code surrounding #ifdefs is poorly designed and the #ifdef is simply a hack. You can be sure that developers who use #ifdefs and hacks to fix international-related problems will forget to update the code inside the #ifdefs when they update the surrounding code.
You can easily replace language-specific #ifdef statements with run-time if and switch statements. The following fragment from a hypothetical program’s startup code uses #ifdefs to omit features for certain language editions:
Setting up a proper development environment, as just discussed, can go a long way toward ensuring world-readiness. Developers can have a significant impact on the translator’s job, a particularly important task since translation is not cheap—most translators charge by the word. Developers can help maximize the accuracy of translation and minimize the amount of support translators need in a number of ways.
First of all, clarify the context of strings that should be translated, preferably by providing comments in resource files or separate text files. Does the English word "integral" refer to the mathematical operator, or is it an adjective meaning "important"? Does a particular string appear on a dialog box, menu, or button, or in a message? If a string should not be translated, try to put it in a separate resource file where the translator won’t even see it, or use a standard way of naming identifiers. For example, you could prefix identifiers for debug messages that shouldn’t be translated with "IDS_DBG" or with an underline, as in "_IDS."
When composing messages or other translatable strings, watch out for slang, sloppy grammar, and ambiguous words or statements. Translators will have a hard time understanding poorly worded messages, and so will international users. Have a linguist or a professional writer edit messages for clarity before you send them for final translation. This will increase the accuracy of translation as well as improve the quality of your native-language product. If translators know which strings to translate and how to translate them, they will be able to work much faster. Their work will be more difficult if terminology is inconsistent within a single application or among different applications, and if adequate tools for editing and updating resources are not available.
Indeed, there are many localization tools that can expedite translation. Some, for example, allow both you and the translator to create translation glossaries that you can share with other software projects and use for automatically translating resource files. (Microsoft supplies translation glossaries at http://www.microsoft.com/globaldev.) Machine translation software is also becoming commercially available. Automatically translated text still requires editing, but editing often takes less time than translating from scratch.
Giving translators a localization kit will allow them to work more independently because they can compile and check their work as they do it. Passing files back and forth among development, translation, and testing departments is simple when all parties are on the same computer network, but is more difficult when the translators are third-party contractors who work in different countries. Express-mailing floppies, CD-ROMs, or portable hard drives is one option, as is exchanging files via the Internet.
Just as localization should begin early in the product cycle, so should testing of localized programs. It’s very tempting to concentrate all testing efforts on the domestic product in order to get it shipped quickly. Early testing of all editions, however, ensures that development is paying attention to international issues because it often uncovers serious bugs in the core code.
When deciding whether to fix a bug, determine how much time fixing it will require and how crucial the fix is to the finished product. Does the bug make the program unusable? If not, will it seriously affect sales in any important target markets? Maintain common standards for all language editions of your product. Never postpone fixing bugs found in your domestic software product that will affect international users.
At the end of the product cycle, when the domestic product is close to shipping, it is tempting to postpone fixing bugs that arise only in localized software until after the domestic product ships, out of fear of "destabilizing" the domestic edition. But every time you delay fixing an international-related bug, you are postponing all of your international releases. If your domestic product will ship in a few days, postponing a few bugs exclusive to localized editions is not a big deal. However, many experienced developers have worked on projects that were in ship mode for weeks, months, or even years. Under these circumstances, allowing international bugs to pile up is dangerous and leaves unresolved a significant number of changes that you will have to merge with the sources for the next product release.
If you plan to ship a single international executable, you really cannot postpone fixing bugs related to world-readiness. Developers of localized editions might need a few extra weeks after the domestic edition ships to make changes to resource files, Help files, or sample documents; but once your single executable is done, it should be done for all languages. Of course, this won’t always happen, but striving for this ideal will definitely benefit the ship dates of your localized editions.
Planning and designing a software project that is world-ready will require foresight and an ability to see the big global picture. As you plan and take steps to create a single-binary, world-ready product, educate your team about internationalization issues and hold all team members responsible for the internationalization of the product. Make sure you get international input on the product design early in the process, preferably during the specification stage. Pay attention to legal issues that might affect your ability to sell your product internationally.
Create a versatile user interface and code design that make customization easy, as some features will be necessary for some locales but not for others. As part of the globalization process, design your code to handle international issues pertaining to data input, output, display, and encoding. Be aware of accessibility issues, many of which overlap with world-readiness issues.
In addition, use one set of source-code files to create all language editions of your product. Eliminate from your design any compile dependencies such as #ifdef statements, hard-coded strings or constants, and localizable resources in header files. Never use #ifdef statements to handle cases specific to individual languages. Also, steer clear of coding assumptions that are based on a single language (for example, that words are always separated by spaces, that characters are always Latin, or that the text stream is always left-to-right).
Help translators work more efficiently by:
Making your code easier to localize (localizability).
Using comments to document strings.
Allowing translators to compile and check their work.
Finally, test international functionality early in the development cycle, and do not wait until after the domestic product is completed to fix international-related bugs. By closely following the practices discussed in this chapter, your software project—just like a carefully planned, ideal community—will reap the rewards.