Microsoft Win32 Internationalization Checklist

Program specs account for international considerations from the outset.

Features important to international markets are included.

Icons and bitmaps are generic, are culturally acceptable, and do not contain text.

Menu and dialog-box designs leave room for text expansion.

Text and messages are devoid of slang and specific cultural references.

Strings are documented using comments to provide context for translators.

Strings or characters that should not be localized are marked.

Shortcut-key combinations are accessible on international keyboards.

International laws affecting feature designs are considered.

Third-party agreements support international design issues.

Consistent English user interface terminology is used in strings.

Code is generic enough to work for several languages.

Code doesn't concatenate strings to form sentences.

Code doesn't use a given string variable in more than one context.

Code doesn't contain hard-coded character constants, numeric constants,screen positions, filenames, or pathnames that presume a particular language.

Buffers are large enough to handle translated words and phrases.

Program allows input of international data.

All language editions can read one another's documents.

Code contains support for locale-specific hardware, if necessary.

Features that don't apply to international markets can be removed easily.

Code takes advantage of international functionality offered by Microsoft Windows.

Code uses international information carried by the system (Win32 NLSAPI).

Code uses system functions for sorting, character typing, and string mapping.

Code uses generic text layout functions provided by the Multilingual API.

Program responds to changes in Control Panel's international settings.

On Microsoft Windows 95, code handles the WM_INPUTLANGCHANGEREQUEST message.

Far East editions support Input Method Editors, vertical text, and line-breaking rules.

All international editions of the program are compiled from one set of source files.

Mechanisms requiring code to be recompiled for different language editions are weeded out.

Localizable items are stored in Windows resource files.

All language editions using double-byte character sets are based on a single executable.

All language editions using Unicode are based on a single executable.

All bidirectional language editions are based on a single executable.

Program executable runs successfully on both Windows 95 and Microsoft Windows NT.

All language editions share a common file format.

Code is generic enough to handle different character sets, not just the Latin 1 code page 1252.

Code properly handles accented characters.

Program handles nonhomogeneous network environments in which machines are running different code pages.

Code uses GetCPInfo() to retrieve lead-byte ranges for Far East code pages.

Code for Far East–language applications parses double-byte characters unless the code is based on Unicode.

Code supports Unicode or conversion between Unicode and the local code page.

Code doesn't assume that all characters are 8-bit or 16-bit.

Code uses generic data types and generic function prototypes.

On Windows 95, code uses the font charset property—it calls EnumFontFamiliesEx and the ChooseFont common dialog function.

Program displays and prints text using the appropriate fonts.

Program meets international testing standards.

Text is translated and meets the standards of native speakers.

Dialog boxes are resized and text is hyphenated appropriately.

Translated dialog boxes, status bars, toolbars, and menus fit on the screen at different resolutions.

Menu and dialog-box accelerators are unique.

User can type accented characters into documents, dialog boxes, and filenames.

User can type accented characters into documents, dialog boxes, and filenames.

User can successfully cut, paste, save, and print accented characters.

Sorting and case conversion are culturally accurate.

Application works correctly on localized editions of Windows.