Customizing Features | Developing International Software

Glossary

Dynamic-link library (DLL): A module containing functions or resources that other programs or DLLs can utilize. DLLs cannot run by themselves; other programs have to load them.
Kanji: The Japanese name for ideographic characters of Chinese origin.

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.

Figure 2.1 - The Customize Regional Options property sheet for the German (Germany) and Italian (Italy) locales.

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

Glossary

Hard-coding: Putting string or character literals in the main body of code, such as the .C files or the .H files, instead of in external resource files. Basing numeric constants on the assumed length of a string or having any assumptions about language- or culture-specific matters fixed in the code (such as length of strings, formats of dates, and so on).

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.

Figure 2.2 - One of Microsoft's anti-piracy logos.

Keeping Features Accessible

Glossary

Accessibility: The extent to which computers are easy to use and available to a wide range of users, including people with disabilities.

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.