Internationalization

Internationalization refers to the translation of all text items on the screen to other languages. Different alphabets can take up more or less room on the screen, so UI designs must be tested to make sure that the content and meaning are not lost.

Text
Content
Bidirectionality

Text

Every written language has its own set of characters known as glyphs. For each language that a UI can display, the typography layout should adapt as languages vary in average word length and height. To determine which font family to use for each language, refer to the typography section.

Avaya currently supports 10 languages: English, French, Spanish, German, Italian, Russian, Portuguese, Simplified Chinese, Japanese, and Korean. Additional languages can be added via a request for each project region.

Word Length

Average word lengths vary between languages, even those that use similar glyphs (e.g. English and German). In the UI, ensure there is enough space to fit longer translations, otherwise text may overlap or be cut off. Generally, shorter text fields are more likely to be expanded in other languages. Below is a table from IBM’s Globalization Guidelines that provides an idea about how much space could be provided.

Characters (In English)	Average Expansion	Can Apply To
<= 10	200 - 300%	Buttons, menus and tabs
11 - 20	180 - 200%	Labels, form fields, chips and tables
21 - 30	160 - 180%	Longer headers
31 - 50	140 - 160%	Short headers, tooltips and notifications
51 - 70	151 - 170%	Short paragraphs
> 70	130%	Longer paragraphs

Small header

Average text expansion of 140-160%.

Button

Average text expansion of 200 - 300%.

Height

Many non-Latin writing systems have taller characters, and often require more vertical space between lines. The user interface should provide enough vertical space to accommodate them.

Alignment

Some writing systems (such as Arabic, Hebrew, Persian and Urdu) are displayed with characters that go from right-to-left. Alignments for these systems must be adjusted accordingly. Visit the bidirectionality section to learn more.

Content

When translating content into other languages, there are a number of items that should be taken into consideration.

Formatting Fields

The formatting of date, time and numbers can vary significantly from region-to-region. For native applications, use the system defaults and preferences so the correct localized content is applied for each language and region. For web applications, leverage existing APIs or follow W3C guidelines.

Field Type	Principles/Examples
Date - Short	The order of day number, month and year can appear as MM/DD/YY, DD/MM/YY, or YY/MM/DD.
Date - Long	The order of day number, month and year can vary. Some examples: Canada: Saturday, July 1, 1967 Mexico: sábado 1 de julio de 1967 Japan: 1967年7月1日土曜日
Time	The order and presentation of hours, minutes and seconds varies in the following ways: 12-hour vs 24-hour clock: The latter is used by most European and Asian countries. AM/PM can also be translated in the local language, and be placed before or after the time. Separators between hours, minutes and seconds: The colon (:) is used the most, though some Asian languages use ideographic characters. Some also require ‘h’, ‘m’ and ’s’ as part of the display. Time zones: Time zones can be displayed with GMT (Greenwich Mean Time) or UTC (Coordinated Universal Time). They can also be displayed using local time zones, though this can vary by region.
Phone Numbers	The presentation of phone numbers varies in the following ways: Separator characters: Different characters such as hyphens (-), periods (.), commas (,) and spaces are used. Groupings: Phone numbers can be parsed differently by country and can be divided into groups of 2 to 6 digits. Total number of digits: The ITU-T standard E.164 states that the maximum number of digits is 15, but this does not include long distance access codes, extensions, passwords and other extra fields.
Currency	Currency formatting varies in the following ways: Currency symbol: This can be either a symbol or combinations of characters (e.g. USD). Symbol placement: The currency symbol can appear before or after the amount. Negative amounts: Negative numbers can be shown either using parentheses, or the negative sign which can appear either before both the currency symbol and amount, after the symbol and before the amount, or after the amount.
Numbers	The presentation of numbers varies in the following ways: Thousands separator: This can be displayed with either a comma, period or space (e.g 1,999 1.999 or 1 999). Decimal separator: This can be displayed with either a comma or period (eg. 1,999.23 or 1.999,23). Negative numbers: The negative sign can appear before or after a number, or the value may be shown in parentheses. Digit groupings left of the decimal: Most cultures use 3 digit groupings (e.g 123,456.00), athough some use 2 digits (e.g. 12,34,56.00). Percent (%) sign: This can be displayed as follows: 77%, 77 %, 77 pct or %77.

Keyboard Shortcuts

Many languages have their own keyboard layouts for their most common characters. Some languages can have several layouts. Any shortcuts you create must consider how these actions can be triggered in each language.

Image showing different text for each modifier key.

Differentiate between Modifier Keys

Most languages use a modifier key such as AltGr (known as the right Alt/option key on a U.S. English keyboard) to enter additional letters, diacritics or symbols. To avoid clashing with shortcuts that use Alt, make sure the application differentiates between these 2 keys. On the web, this can be achieved by checking the .key attribute instead of .keycode.

Image showing a series of partially completed checkboxes, indicating personal preference.

Allow for Personalization

Providing users with a mechanism to override embedded shortcuts with their own is a great way to alleviate conflicts between languages and allows users to select the configuration that is most comfortable for them. Where possible, allow users to define their own shortcuts within an application.

Bidirectionality

Some writing systems (such as Arabic, Hebrew, Persian and Urdu) are displayed with characters that flow from right-to-left (RTL). In these cases, the user interface should be mirrored to reflect the RTL reading pattern.