This chapter describes those features of the interface that may require clarification or different guidelines when applied to various cultural environments.
This chapter first describes general guidelines for international design, including icon, symbol, and pointer design; data formats; multibyte character sets; screen text; and modularized software. Finally, the chapter presents guidelines for bidirectional language support.
The following sections discuss using general Motif guidelines in an international environment.
The guidelines stated for capitalization in this manual are for the English language developer. When an application is developed in another language or translated to another language, the rules of that language must be followed. For example, in the German language all nouns are capitalized, no matter what their position in a phrase or sentence.
The space for a translated column head may need to be increased. You can create the additional space by increasing the number of rows in the heading.
The translation of a label may cause a field to be misaligned. Fields must be realigned after translation.
Labels sometimes reflect a localized or culturally sensitive format. Allow the translator to edit the descriptive text.
Allow a user to press the unaccented uppercase or lowercase character to access accented first letters when using first-letter cursor navigation.
For a description of first-letter cursor navigation, see “First-Letter Cursor Navigation” in Chapter 5.
Using Alt (A – Z) for shortcut keys can be awkward on non-United States keyboards since only a left-hand Alt key or a right-hand Alt key may be available for this function.
Each country has a different way of sorting and may have several ways of sorting within the country, such as in a telephone book or a dictionary. The Sort menu may have to allow selection of these criteria based on the requirements of the country or application. In addition, when lists are ordered alphabetically, as in spin boxes, the list must be reordered after translation.
You may not always be able to design a graphical symbol (like an icon or a pointer) that adequately represents the same object or function in different countries. Cultural differences impact even seemingly universal symbols. For example, sending and receiving electronic mail is a common function, but representing that function with a picture of a mail box may be inappropriate because the appearance of mail boxes varies among countries.
When used correctly, graphical symbols offer the following advantages:
They are language independent and do not need to be translated.
They can replace computer terms that have no national-language equivalent.
They may have more impact when used with warning text than ordinary text.
Use the following guidelines when designing icons, symbols, or pointer shapes:
Use an already existing international icon, if possible.
Avoid using human body parts.
If you include alphabetic characters, use uppercase letters.
Avoid symbolically written material oriented for left-to-right text.
Avoid using stars and crosses.
Do not use humor or regional metaphors.
Make your icons, symbols, and pointer shapes represent basic, concrete concepts. The less abstract the icon, the less explanatory documentation is needed.
Check your icons and symbols for conflicts with existing icons or symbols for that function.
Do not incorporate text in icons because the text will need to be translated. Translated text often expands and might no longer fit the icon.
Test and retest your symbols and icons in context with real users.
Different countries require data to be represented in different ways. Besides the language differences, other data (such as currency) varies from country to country. The following list describes these data formats and includes an example of each:
Thousands separators
The comma, period, space, and apostrophe are examples of valid separators for units of thousands.
1,234,567
1.234.567
1 234 567
1'234'567
Decimal separators
The comma, period, and center dot are examples of valid separators for decimal fractions.
5,234
5.234
5•324Grouping separators
Grouping may not be restricted to thousands separators.
400,001.00
40,0001,00Positive and negative values
The symbols + (plus) and - (minus) can appear before or after the number. You can enclose negative numbers in parentheses in certain applications, such as spreadsheets.
234+
+234
234-
-234
(234)Currency
The comma, period, and colon are examples of valid separators for currency. There can be one or no space between the currency symbol and the amount.
Kr. 3,50
Sch3.50
FIM 3:50
3F50
350 Pts
ESC3.50Date format
Most countries use the Gregorian calendar but the dates may be formatted differently. Separators might be different or might not be used. The hyphen, comma, period, space, and slash are all valid separators for the day, month, and year. In numeric date formats, the month and day fields might be reversed and, in some cases, the year field might come first.
4/8/96 or 8/4/96 for August 4, 1996
961029 or 962910 for October 29, 1996Time format
The colon, period, and space are valid separators for hours, minutes, and seconds. You can sometimes use the letter h to separate hours and minutes. Also, you may use either 12- or 24-hour notation. For 12-hour notation, a.m. or p.m. might appear after the time, separated by a space. You can also indicate the time zone for a given time.
1307
13:07
01 07
01h07
1.07 p.m
13:07:31.30 IST (Indian Standard Time)Telephone numbers
Telephone numbers can contain blanks, commas, hyphens, periods, and brackets as valid separators. You can display telephone numbers in local, national, and international formats. Local formats vary. National formats might have an area code in parentheses. The international format does not use parentheses, but adds a + (plus) at the beginning of the number to indicate the country code.
(038) 473589 +44
(038) 473589
617.555.2199
(617) 555-2199
1 (617) 555-2199
(1) 617 555 2199
911
1-800-ORDERMEProper names and addresses
Addresses can vary from two to six lines long and can include any character used in the locale's character set. The post code (zip code) can be in various positions in the address and can include alphabetic characters and separators as well as numbers.
Herr Dipl. Ing. Schmidt
Stolbergerstrasse 90
D-200 Hamburg 55
GER
Madame Dupont Claudette
17, Rue Louis Guerin
F-69626 Lyon-Villuerbanne
France
In some languages, users cannot type characters from the keyboard into a text control. Instead, the user must apply multiple key combinations to form the symbols that appear in the text-entry field. For these languages, you must provide a preedit area. The text is typed into the preedit area until the user indicates the text is complete; the text is then converted and sent to the text control.
You must address the following issues when providing a preedit area:
Locating the preedit area
Displaying the status
Converting the preedit characters to final characters
The location of the preedit area depends on a variety of software considerations. Ideally, preedit should occur in place in the text control being edited. The following list describes three preedit locating methods:
| On-the-spot | The input from the preedit area goes to the text control. This method is preferred because it is more direct for the user; however, the on-the-spot input method can be difficult to implement. | |
| Over-the-spot | The preedit spot is above, but separate from, the text control. | |
| Off-the-spot | A single preedit area is used for multiple text controls. The input from the preedit area goes to the text control that currently has the focus. |
With the on-the-spot method, the text control may contain both unconverted and final characters. You should show the portions of the text that have been converted by using a visual cue, such as a different font, color, or highlight.
When the preedit text is converted into the final characters, there might not be enough information to unambiguously convert the text. If there is not enough information, the conversion either:
Prompts for more preedit text
Presents a list of possible choices
Fails
ASCII and extended ASCII character sets are single-byte character sets (SBCSs). That is, there are no more than 256 unique characters in an SBCS. The English language uses an SBCS. Some languages, like Japanese or Chinese, have a larger set of unique characters that constitute more than what a single byte can represent. These character sets are called multibyte character sets (MBCSs). The following sections address multibyte character set guidelines.
When a user types a valid mnemonic, the cursor moves to the choice that the mnemonic is assigned to and the choice is automatically activated. This saves keystrokes for choices that are usually activated explicitly.
All the guidelines for mnemonics in an SBCS language apply to an MBCS language except for how the mnemonics appear. If all the letters in a choice are already assigned, or the choice consists of MBCS characters, you may choose another letter or a keyboard character, such as the comma (,). You should assign the same mnemonic to choices that appear many times throughout an application.
Applications translated from SBCS languages to MBCS languages can keep the SBCS mnemonics. Place the mnemonics in parentheses following the word.
For controls that specify choices be shown in a specific sort order, such as alphabetic order, the sort order may actually depend on the application. For example, in Japanese Kanji it may be better to sort by Japanese phonetic order or some other appropriate order, depending on the information in the field.
Well-written screen text makes an application easier for users to understand. It also makes translation easier. Use the following guidelines when writing screen text for translation:
Write brief and simple sentences. They are easier to understand and translate.
Write affirmative sentences. They are easier to understand than negative statements. For example, write ‘Do you want to continue?’ rather than ‘Don't you want to continue?’
Use active voice. It is easier for both users and translators to understand. For example, use ‘Press the Help button ’ rather than ‘The Help button should be pressed.’
Use prepositions to clarify the relationships of nouns. Avoid stringing three or more nouns together.
Use simple vocabulary. Avoid jargon unless it is part of your audience's working vocabulary.
Allow space for translation. Text translated from English is likely to expand thirty to fifty percent or more in some languages.
Designing software in modules makes translation easier. A modular application requires fewer files; therefore, fewer files must be translated. Use the following guidelines when designing software:
Create separate modules for text, code, and input and output components that need to be changed to accommodate different markets. Also, place elements that need to be translated in separate files.
Separate all user interface text from the code that presents it.
Use standard registered data formats, such as ISO and IEEE.
Use standard processing algorithms for all processing, storage, and interchange.
Use the internationalization tools on your system to create a different set of language-dependent text files for each market you are designing for.
The Hebrew and Arabic languages are written from right to left. The English language is written from left to right. Consequently, bidirectionality is a necessity in any system intended for Arabic or Hebrew users.
You can design for most right-to-left languages in the same way. This chapter uses “Arabic and Hebrew” as a generic designator for the national language that a bidirectional application uses. Whenever special considerations apply to either Arabic or Hebrew only, they are mentioned explicitly.
The basic rule for bidirectional applications is that you must display all pieces of data in the orientation that is correct for the user. Also, data input must be supported in the orientation that is natural for users.
Arabic and Hebrew applications generally must use the national language for titles, instructions, headings, prompts, and other window controls, with the following exceptions:
English acronyms or terms are not commonly translated, for example, DOS, EXE, CICS.
Key names must be identical to the keyboard, for example, F1, Alt, Ctrl, Enter.
Key combinations must be displayed in English, for example, Alt F2.
An application may allow dynamic language selection. When the user chooses a new language, the headings, messages, and commands should adhere to the new language. For right-to-left languages, the application interface should reflect these bidirectional language guidelines. When the application contains a mixture of right-to-left and left-to-right language elements, the left-to-right elements follow the unmodified guidelines provided in this book and the Style Guide Reference; the right-to-left elements follow the bidirectional language guidelines in this chapter.
If the application is multilingual, mention the language being used in the product information window. If the application allows dynamic language selection, mention the initial language in the product information window.
Use a right-to-left screen orientation for Arabic and Hebrew applications. Thus the right side of a window is the ‘begin’ side, and the left side is the ‘end’ side. Most references in the guidelines for left-to-right languages are true for Arabic and Hebrew, with the understanding that the meaning of ‘right’ and ‘left’ are interchanged. (Note that in some cases, the meaning ‘right’ and ‘left ’ must not be changed for Arabic and Hebrew.)
While bidirectional language interfaces seem to have exchanged the meaning of the words ‘right’ and ‘left,’ the physical right and left are still the same. Thus the following have the same effect for Arabic and Hebrew as for English:
Cursor movement keys (including Left Arrow and Right Arrow) must still move the cursor according to the direction of the arrow engraved on the key top. (This is also true for combinations of Left Arrow and Right Arrow with Shift, Ctrl, or Alt.)
Also, Ctrl PageUp must always scroll to the left and Ctrl PageDown to the right.
Right and left buttons of a pointing device are not transposed.
Right and left movement of a pointing device is not transposed.
Graphics may be unaffected by the window orientation: for example, a map must still have the East on the right and the West on the left.
The appearance of an Arabic or Hebrew window is the mirror image of a corresponding English window, except that the position of the window menu button and the maximize and minimize buttons in the title bar does not change.
Orientation applies at multiple levels. An application has a general orientation for its windows. A window also has an orientation. If the window orientation is right to left, its elements are logically ordered from right to left and from top to bottom.
In a bidirectional environment, the user chooses the orientation of the screen and windows according to use, standards, or preferences.
Use the following guidelines for right-to-left screens and windows:
Tile, cascade, or superimpose windows with the older primary window on the right and the newer secondary window on the left.
Order minimized (iconified) windows from right to left, beginning from the right side of the screen.
For a right-to-left window, prioritize the positioning of associated secondary windows (like help windows) as follows: to the left of, to the right of, above, or below the application window.
Note that an Arabic or Hebrew application can include some left-to-right windows.
You can also use a left-to-right window on a right-to-left screen and vice versa. This means that English left-to-right applications can be used on a right-to-left screen and Arabic and Hebrew (right-to-left) applications can be used on a left-to-right screen.
Within the same window, text and graphics may have differing orientations. For example, a geographic map may have left-to-right graphics (as for an English application), but the Arabic and Hebrew captions may have right to left graphics.
Text-entry fields are a special case: for each field, an orientation is defined, which by default is right to left within right-to-left windows. However, you should define fields that are to receive numeric data or English text as left to right. Within a text-entry field, the keying or cursor direction may be right to left or left to right, according to the data entered: Arabic or Hebrew text, or English and numbers.
For more information, see “Right-to-Left Text-Entry Fields”.
In a bidirectional application, each field has an orientation that is defined by the application. By default, text-entry fields assume the same orientation as the encompassing window. According to the expected contents of the field, the application must define text entry as right to left (Arabic or Hebrew textual data) or left to right (numeric data or English textual data).
Right-to-left text-entry fields differ from left-to-right text-entry fields in the following ways:
Text is right-aligned in the text-entry field.
At initial entry, the cursor is located at the rightmost position.
For each entry, the cursor movement is initiated as right to left: in replace mode, the text cursor moves left to the next entry position; in insert mode, the cursor and all characters to the left of the cursor are shifted one position to the left.
If scrolling is available in the text-entry field, the rightmost field positions are initially visible. When the cursor moves to the left, the information scrolls to show more characters on the left side. In summary, the beginning of the information is on the right side, its end on the left side.
When the user must type text in an orientation opposite to the field orientation, such as typing numbers within a right-to-left field, use special bidirectional functions such as Push and End Push.
During a push operation, the cursor does not move (like a calculator interface). The cursor stands on the character at the boundary between the surrounding right-to-left text (for example, a street name) and the Push segment (for example, a house number).
When the user presses End Push to end the operation, the cursor skips beyond the Push segment. The user can then continue entering right-to-left text.
You must make it clear when the cursor is located at a Push boundary. The Push boundary is where the latest character typed in a push operation appears, assuming that arrow keys were not used to move the cursor. Typing text at the Push boundary does not always have the same calculator-interface effect as typing elsewhere, thus you should provide some visual feedback to help the user differentiate between the two.
Although Asian languages use both vertically and horizontally written text, vertical text is the more natural of the two. In vertical text, a line is a string of characters written from top to bottom, and each new line starts to the left of the previous line. Figure 11-1 shows an example of vertically written text.
Chinese, Japanese, and other vertically written Asian languages represent words as characters or combinations of characters. Unlike English, these characters should be equally spaced from each other. Similar to a grid, each character should be aligned on a vertical line called a center line.
In vertically written text, the preedit string must be displayed vertically. You can do this with the on-the-spot method (see “Locating the Preedit Area”). On-the-spot character entry eases the implementation of an input method server for vertical writing.
The basic rule for vertical language applications is that you must display all pieces of data in the orientation that is correct for the user. Also, data input must be supported in the orientation that is natural for users.
Chinese and Japanese applications generally must use the national language for titles, instructions, headings, prompts, and other window controls, with the following exceptions:
English acronyms or terms are not commonly translated, for example, DOS, EXE, CICS.
Key names must be identical to the keyboard; for example, F1, Alt, Ctrl, Enter.
Key combinations must be displayed in English, for example, Alt F2.
An application may allow dynamic language selection. When the user chooses a new language, the headings, messages, and commands should adhere to the new language. For vertical languages, the application interface should reflect these vertical language guidelines. When the application contains a mixture of vertical and left-to-right language elements, the left-to-right elements follow the unmodified guidelines provided in the Style Guide Reference; the vertical language elements follow these vertical language guidelines.
If the application is multilingual, mention the language being used in the product information window. If the application allows dynamic language selection, mention the initial language in the product information window.
Use a vertical screen orientation for Chinese and Japanese applications. Thus the top of a window is the “begin” side, and the bottom is the “end” side. Lines of text begin with the rightmost line and continue leftward. Most references in the guidelines for left-to-right languages are true for Chinese and Japanese, with the understanding that the meaning of “top” and “right” (and “bottom” and “left”) are interchanged for client areas, preedit areas, and some labels, text-display fields, and text-entry fields.
While vertical language interfaces seem to have exchanged the meaning of the words “top,” “bottom,” “left,” and “right,” the physical right and left are still the same. Thus the following have the same effect for Chinese and Japanese as for English:
Cursor movement keys (including Left Arrow and Right Arrow) must still move the cursor according to the direction of the arrow engraved on the key top. (This is also true for combinations of Left Arrow and Right Arrow with Shift, Ctrl, or Alt.)
Also, Ctrl PageUp must always scroll to the left and Ctrl PageDown to the right.
Right and left buttons of a pointing device are not transposed.
Right and left movement of a pointing device is not transposed.
Graphics may be unaffected by the window orientation: for example, a map must still have the East on the right and the West on the left.
Pull-down menus, pop-up menus, push buttons, and most dialog boxes still conform to left-to right language guidelines.
The appearance of a Chinese or Japanese window is the same as a corresponding English window, except that the orientation of the text in a client area is vertical instead of left-to-right.
In a vertical language environment, the user chooses the orientation of the screen and windows according to use, standards, or preferences.
Use the following guidelines for vertical screens and windows:
When including English text in vertically written text, display the English text rotated clockwise by 90 degrees.
You can use a left-to-right window on a vertical screen and vice versa. This means that English left-to-right applications can be used on a vertical screen and Chinese and Japanese (vertical) applications can be used on a left-to-right screen.
The format of text data to be exchanged between clients is the same as in horizontally written text. Since the text buffer representation of characters is the same in both horizontal and vertical writing, you can treat the text data in the same way in both writing styles.
Expand text selections vertically. Vertical motion of the pointer is interpreted as column expansion, and horizontal motion of the pointer is interpreted as line expansion.
Within the same window, text and graphics may have differing orientations. For example, a geographic map may have left-to-right graphics (as for an English application), but the Chinese and Japanese captions may have vertical graphics.
Text-entry fields are a special case: for each field, an orientation is defined, which by default is vertical within vertical windows. However, you should define fields that are to receive numeric data or English text as left to right. Within a text-entry field, the keying or cursor direction may be vertical or left to right, according to the data entered: Chinese or Japanese text, or English text and numbers.
For more information, see “Vertical Text-Entry Fields”.
In a vertical application, each field has an orientation that is defined by the application. By default, text-entry fields assume the same orientation as the client area's text field. According to the expected contents of the field, the application must define text entry as vertical (Chinese or Japanese textual data) or left to right (numeric data or English textual data).
Vertical text-entry fields differ from left-to-right text-entry fields in the following ways:
Text is top-aligned in the text-entry field.
At initial entry, the cursor is located at the topmost position.
For each entry, the cursor movement is initiated as top to bottom: in replace mode, the text cursor moves down to the next entry position; in insert mode, the cursor and all characters under the cursor are shifted one position down.
If scrolling is available in the text-entry field, the topmost field positions are initially visible. When the cursor moves down, the information scrolls to show more characters below. In summary, the beginning of the information is on the top, its end on the bottom.
In most Asian language applications, the user must enter English letters to generate an equivalent Asian character. For example, in Chinese, the user enters a character by keying in a phonetic “word” (called PinYin) that is based on the English alphabet. Since many characters can match a phonetic approximation, it is essential to display all of the matching characters in the application's status area or preedit area. The user should be able to locate the correct character and select it quickly.