Some features might be essential for all language editions of a program, but they might require that you implement them using different algorithms for different languages. One obvious example involves features that do lexical analysis—spell-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 dynamic link libraries (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, spell-checkers and grammar-checkers are exceedingly difficult to write. Localized programs that don't include spell-checkers or grammar-checkers should avoid user interface references to them by either disabling or not drawing related menu and dialog items at run time. (See Figure 2-1.) In these cases, it's important to create code that is flexible so that you can easily add, remove, or customize functionality.

Figure 2-1 Microsoft Word for Windows (the Spanish edition) displays the menu items for Spelling, Grammar, Thesaurus, and Hyphenation only if the user has installed the appropriate files. (See the menu on the left.) It omits the menu items if it cannot find the files it needs to execute the commands. (See the menu on the right.)

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 expect the ability to juxtapose Arabic and English text.

Customizing software for a locale can be as straightforward as including localized sample documents with the program executable. One of the best ways to customize a program in a modular fashion, whether for international customers or for special interest groups such as lawyers or students, is by using OLE, which is more flexible than using DLLs. An OLE-enabled program can interact with any other OLE-enabled program, whereas DLLs are useful only to programs that directly call the functions contained in the DLLs.

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 filenames, 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 spell-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.

In contrast, local hardware requirements make it necessary to customize some code—in particular, device drivers. A prime example is Japan, where there are several different hardware standards. (See Chapter 7.) You have to recompile applications for new hardware platforms running Windows NT, such as Reduced Instruction Set Computing (RISC) machines. It's also important to remember that some markets, such as Latin America and the United States, have a large installed base of old hardware (for example, 386 machines). And other markets, such as Japan, still rely on obsolete standards. Windows 95 supports the Windows Intelligent Font Environment (WIFE) layer for the Far East, for example, even though TrueType is now the standard, because many applications produced in Japan continue to use WIFE fonts.