More InformationDesign Specifications and Guidelines - Special Design Considerations
To successfully compete in international markets, your software must easily accommodate differences in language, culture, and hardware. This section summarizes some of the key design considerations regarding the localization of software.
More Information
For more information about the technical details for localizing your application, see the Microsoft Global Software Development site at http://www.microsoft.com/globaldev/. Another useful reference is the online book, Developing International Software, by Nadine Kano, available on the MSDN Online Web site at http://msdn.microsoft.com/library/.
The process of making a software product linguistically and culturally appropriate for use in a different country or region and its language is called localization. Like any part of the interface, include international considerations early in the design and development process. This helps cut costs and speeds up the localization process. In addition to adapting screen information and documentation for international use, remember that your Help files, scenarios, templates, models, and sample files should also be a part of your localization planning. For example, a scenario or example involving gourmet dog food or styles of birdbaths would be inappropriate in many countries.
Even if you don't plan to localize your application into other languages, you still need to consider how your application will operate with other language configurations. For example, if you use U.S. English names and locations for standard system directories, your application may not install or run.
Language is not the only relevant factor to consider when you localize an interface. Several countries can share a common language but have different conventions for expressing information. In addition, some countries can share a language but use a different keyboard convention.
A subtler factor to consider when preparing software for international markets is cultural differences. For example, users in the U.S. may recognize a rounded mailbox with a flag on the side as an icon for a mail program, but this image may not be recognized by users in other countries. Sounds and their associated meanings may also vary from country to country.
Similarly, consider the implications on brand and trademark decisions. An untranslated, trademarked U.S. term can sound like a vulgar or otherwise undesirable term in another language, and certain colors or color combinations may produce undesirable associations in some countries.
A major aspect of localizing an interface is translating the text used by the software in its title bars, menus and other controls, messages, and some registry entries. To make localization easier, store interface text as resources in your application's resource file rather than including it in the source code of the application. Remember also to translate the menu commands that your application stores in the system registry for its file types.
Translation does not always result in one-to-one correspondence. A single word in English can have multiple translations in another language. Adjectives and articles sometimes change spelling according to the gender of the nouns they modify. Therefore, be careful when re-using a text string in multiple places. Similarly, several English words may have only a single meaning in another language. This is particularly important to remember when you create keywords for your application's Help index.
When text is translated, it is often expanded. For more information, see the "Layout" section later in this chapter.
When you are careful and consistent in your use of terminology, users can learn to use your application more quickly, and it can more easily be translated into other languages. For example, "traveling" and "travelling" are both correct in English, but to ensure ease of translation, use only one variation. This is particularly important if you use automatic translation tools, because the utility may not handle the variation. The first spelling offered in a dictionary is usually preferable to alternate spellings.
Similarly, where possible, use consistent phrasing for text that appears repeatedly in your application, such as messages. This not only makes localization easier, it avoids confusing users who may interpret different words as having a different intended meaning.
Avoid words that can have several meanings in different contexts. These can require extra translation work. For example, time can mean time of day or duration; map can be a noun or a verb.
Similarly, avoid technical jargon. For example, phrases like the following can be difficult to translate:
Strip the leading character and remove the last quote character.
Unable to fork daemon.
Receives discarded.
Unable to close all users.
When you name a new feature, also avoid idioms, colloquialisms, or metaphors, which may be meaningless in other cultures.
| Correct | Incorrect | |
| Your design is finished in minutes. | Now how's that for instant design! | |
| These simple steps complete the task. | That's all there is to it. | |
Do not assign a new or broader meaning to an existing term. Doing so may add extra effort during the translation process. Also, avoid joining words to create new words.
Phrasing that includes compound nouns also makes translation more complex. For example, the phrase "Last member query interval" can mean:
Last interval for the query "member"
Interval for the query "last member"
Interval for the last query "member"
Query interval for the "last member"
Use articles or personal pronouns with product or feature names only if they help clearly identify the product or feature. For example, in the phrase "Remove Remote Storage program files only," it is not clear whether "remove" is part of the program name or if the Remote Storage program files are to be removed. In this case, "Remove the Remote Storage program files" is much clearer.
Translation from English to other languages can affect the size of your application in a variety of ways:
To handle expansion of your interface text, avoid sizing text to your content. You must allow for 30 percent or more space than you use in your English version, as shown in Figure 15.3.
Figure 15.3 Text expansion space
Depending on the language and the wording, you might even need to provide twice as much space. For example, in German, the word "move" becomes "verschieben" and the word "prompt" becomes "Eingabeafforderung." Accordingly, if the amount of space available in the interface is strictly limited, as in a status bar, restrict the length of the English text to half of the available space.
When possible, avoid sizing text to the actual content. For message boxes or explanatory text, include an extra blank line, as shown in Figure 15.4.
Figure 15.4 Allow for text expansion for explanatory text
For text labels for text boxes, leave extra space so that the label text can expand, as shown in Figure 15.5. This avoids the need to resize and adjust the layout for localization, saving time and money. It also reduces potential layout errors.
Figure 15.5 Allow for text expansion of text box labels
For some controls, such as option button labels, provide space not only for horizontal expansion, but also for an extra line, as shown in Figure 15.6.
Figure 15.6 Example of vertical expansion spacing
For resizable controls that contain text within a frame, make sure you allow enough space for the control itself to be resized without requiring that the window be resized. For example, drop-down lists don't include a horizontal scroll bar, so important information may be hidden when the text is localized. Allow enough space to widen the list to avoid truncated text, as shown in Figure 15.7.
Figure 15.7 Sizing to avoid truncation (click to enlarge image)
When the label for a text box is already long, consider placing the label above the text box rather than in front of it, as shown in Figure 15.8. Then you won't have to reduce the width of the text box. Consider this also when you place a button adjacent to the text box.
Figure 15.8 Label above text box
Instead of using long phrases for text box labels, split the information into descriptive text, then use a word or short phrase for the label, as shown in Figure 15.9.
Figure 15.9 Splitting long labels into descriptive text and the label
Avoid using text that is dynamically linked from a string table, as shown in Figure 15.10. Many controls, such as buttons, are sized based on their labels. Control labels that use dynamically linked strings can make it difficult to lay out the controls properly when they are localized.
Figure 15.10 Avoid dynamically linked text labels
Similarly, avoid dynamic, or run-time, concatenation of different strings to form new strings — for example, composing messages by combining frequently used strings. An exception is the construction of file names and names of paths.
Avoid having your software rely on the position of text in a control or window, because translation may require movement of the text. Similarly, word forms, length, order, or number are likely to be different from language to language.
As a result, avoid placing controls within a sentence, as shown in Figure 15.11. This can require you to lay out the position of the controls differently for different languages. In the following example, you would have to relocate the combo box directly after the option button. Placing the control at the end of the text label for the option button provides a better alternative.
Figure 15.11 Example of control placement
Also avoid placing text or other controls on top of other controls, as shown in Figure 15.12. Overlapped or hidden controls can result in access key or sizing problems.
Figure 15.12 Avoid hidden or overlapping controls
In Hebrew and Arabic countries, information is written right to left. When you localize for these countries, your design needs to support reversing your U.S. presentation.
Some languages include diacritical marks that distinguish particular characters. Fonts associated with these characters can require additional spacing.
It is best to review proposed graphics early in your design cycle to make sure they are applicable for international versions. Although graphics communicate more universally than text, graphical aspects of your software — especially for icons and toolbar button images — may need to be revised to address an international audience. Images, idioms, metaphors, or symbols with a strong meaning in one culture may not have any meaning in another. For example, many symbols for U.S. holidays and seasons are not shared around the world. Similarly, for example, the concept of a "wizard" may not include the concept of magic in many languages; therefore, a toolbar image of a magic wand that represents access to a wizard interface may not be an obvious reference. A "dog-eared" book won't work in some languages because they use a different animal or might not associate this idea with animals at all. Some symbols can even be offensive in some cultures. For example, the open palm commonly used at U.S. crosswalk signals is offensive in some countries.
Therefore, wherever possible, use neutral images and avoid including text. Localizing graphics can be time-consuming. Even if you can create custom designs for each language, having different images for different languages can confuse users who work with more than one language version.
International keyboards also differ from those used in the U.S. Avoid using punctuation character keys as shortcut keys, because they are not always found on international keyboards or easily produced by the user. Remember too, that what seems like an effective shortcut because of its mnemonic association (for example, CTRL+B for Bold) can warrant a change to fit a particular language. Similarly, macros or other utilities that invoke menus or commands based on access keys are not likely to work in an international version, because the command names on which the access keys are based differ.
Keys do not always occupy the same positions on all international keyboards. Even when they do, the interpretation of the unmodified keystroke can be different. For example, on U.S. keyboards, pressing SHIFT+8 results in an asterisk character. However, on French keyboards, it generates the number 8. Use the following guidelines when you work with key combinations:
@ £ $ { } [ ] \ ~ | ^ ` < >
Some international countries require support for different character sets (sometimes referred to as code pages). The system provides a standard interface for supporting multiple character sets and sort tables. Use these interfaces wherever possible for sorting and case conversion. In addition, consider the following guidelines:
More Information
The SystemParametersInfo function allows you to determine the current keyboard configuration. For more information about this function, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.
Different countries often use substantially different formats for dates, time, money, measurements, and telephone numbers. This collection of language-related user preferences for a specific area is referred to as a locale. Designing your software to accommodate international audiences requires supporting these different formats.
Windows provides a standard way to find out what the default format is for a given locale. It also allows users to use different formats within a locale. Your software can also allow users to change formats, but you should change only those that affect your application or document type, not those that affect system defaults. The following table lists the most common format categories.
More Information
For more information about the functions that provide access to the current locale formats, see the Microsoft Platform SDK on the MSDN Online Web site at http://msdn.microsoft.com/ui/guide/sdk.asp.
| Formats for International Software | ||
|---|---|---|
| Category | Format considerations | |
| Date | Order, separator, long or short format, leading zero | |
| Time | Separator and cycle (12-hour vs. 24-hour), leading zero | |
| Physical quantity | Metric vs. U.S. measurement system | |
| Currency | Symbol and format (for example, trailing vs. preceding symbol) | |
| Separators | List, decimal, thousandths | |
| Telephone numbers | Separator for area codes and exchanges | |
| Calendar | Calendar used, starting day of the week | |
| Addresses | Order, postal code format | |
| Paper sizes | U.S. vs. European paper and envelope size | |
Access keys for control labels in double-byte languages (Japanese, Chinese, and Korean) follow conventions different from those of other languages. Instead of identifying an access key with an underline character, display the character in parentheses at the end of the text. Typically, you would use a Roman character, which is generally accessible even on foreign keyboards.
Avoid confusing international users by leaving in references to features that do not exist in their language version. Adapt the interface appropriately for features that do not apply. For example, some language versions may not include a grammar checker or support for bar codes on envelopes. Remove references to features such as menus, dialog boxes, and Help files from the installation program.
Take into account differences in international names and addresses. For example, middle names are not used in some countries. Many countries do not have an equivalent for states in the U.S.
Avoid hard-coding file names in a binary file. File names may need to be translated. Also, use the system interface to locate common system directories, such as Program Files.
Political unrest, disputes over national borders, and other geopolitical issues can also affect your application. For example, your product might be banned in a country that views its national borders differently than you present them. If your interface deals with maps, country names, international or political organizations and leaders, or any other politically sensitive subjects, consult an expert on geopolitical issues for advice.
Fundamentals of Designing User Interaction
Design Specifications and Guidelines