Motif and Common Desktop Environment: Style Guide Migration Version

Motif and CDE 2.1 Style Guide

Bidirectional Language Support

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.

Basic Rule for Bidirectional Applications

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.

National Language Use

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.

Dynamic Language Selection

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.

Orientation

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 < and >) must still move the cursor according to the direction of the arrow engraved on the key top. (This is also true for combinations of < and > 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.

Guidelines for Right-to-Left Screens and Windows

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".

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 Field Differences

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.

Text Cursor Appearance

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.

Text Cursor Position in Insert Mode

In general, the text cursor has the same appearance in insert mode as described for left-to-right text. However, in insert mode you must place the vertical bar representing the cursor on the proper side of the cursor position.