Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

Internationalization

...

and Localization

Internationalization (i18n) is the process of designing a software application applications so that it can potentially be adapted to various languages and regions without engineering changes. Localization (l10n) is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text.

Here are a number of guidelines for designing content with international audiences in mind:

Color

Be aware of the cultural significance of colors. For example, the color red is associated with warning and danger in Western cultures, while it symbolizes luck and happiness in some Asian cultures, like China and Japan.

Flags

Avoid using flags to represent languages. Language and country are different concepts. Flags are symbols that represent countries or nations while languages represent a shared method of communication between people. For example, Spanish is spoken in 29 countries and Spain is only one of them. Countries like Canada have more than 1 official language. Which language do you think the maple flag represents?

When designing a language selector, use plain text despite its lack of visual appeal. Only use flags to represent countries, not languages.

Right to Left

In certain languages like Arabic and Hebrew, text is read from right-to-left (RTL) necessitating your entire design to be flipped. A modular design approach will come in handy while accommodating RTL languages. For example, the application is designed to flip neatly for Hebrew and other RTL languages as shown below:

...

When localizing, the elements below should not be horizontally mirrored in RTL languages:

  • Main layout sections

  • Images, except when they correspond to direction (example: arrows)

  • Graphs (x– and y–axes are always shown in the same orientation in all languages)

  • Clocks

  • Video controls and timeline indicators

...

Date and Time

Date and Time should always be stored in UTC to allow it to be converted and displayed in multiple time zones. LUX components and guidelines follow the conventions detailed below by default:

  • Basic date format: dd/mm/yyyy. For example 03/08/2017.

  • For the current day and the day before that, the default is Today and Yesterday.

  • Basic time format: 00:00 PM/AM. For example 05:55 AM.

  • The combined date and time should be connected using either a comma or the word ‘at’, where relevant. For example:

    • 03/08/2017, 00:55 AM and Yesterday, 12:55 PM.

    • 03/08/2017 at 00:55 AM and Yesterday at 12:55 PM.

All applications built for Verint should allow the above defaults to be automatically changed based on the users specified browser locale (or by a manual setting, if the application allows it). Details of conventions for specific countries and regions are available here.

Many frameworks and libraries (such as Moment.js) offer full and constantly-updated internalization features for easy localization of dates and times.

Decimals

Despite being the conventional standard (and the LUX default), Great Britain and the United States are two of the few places in the world that use a period to indicate the decimal place. Many other countries use a comma instead. Likewise, while the UK and US often use a comma to separate groups of thousands, many other countries use a period instead, and some countries separate groups of thousands with a thin space.

Region

Format

Most English-speaking countries

1,275.28

Many European countries

1.275,28

Canada and some European countries

1 275,28

As with Date and Time above, all applications built for Verint should allow the decimal character defaults to be automatically changed based on the users specified browser locale (or by a manual setting, if an application allows it). Details of conventions for specific countries and regions are available here.

Large Numbers

In LUX, large numbers may be represented using K for thousands and M for millions, which is the common practice in most countries.

The number

May be represented as

1,380

1.38K

2,040,296

2.04M

Text Expansion

Always design with text expansion in minmind. When English text gets translated to into another language, the translated text can be as much as three times longer. Leave blank space around condensed UI components, such as buttons and tabs.3x longer. Make UI components expandable whenever possible. Do not assign a fixed - width or height to your UI component unless you have a good reason to.

For longer text, wrapping is a good solution. Be aware of the potential vertical expansion since translated text will take require more lines. Truncation with hover text can be a compromise. Be aware that this brings the risk of making the UI less effective.

...

The general rule for text expansion is: “the shorter the English text, the longer the translated text is likely to be”. The following table shows the average text expansion rate for different English text lengths:

English Text Length

Expansion

1 - 10

100 - 200%

11 - 20

80 - 100%

21 - 30

60 - 80%

31 - 50

40 - 60%

51 - 70

50 - 70%

71+

30%

...

Language expansion

...

In addition to English text length, the target language also has an impact upon the amount of expansion. The following table shows the expansion factor for the English text “Share” Shareinto various languages:

Language

“Share”

Expansion Factor

English

Share

1.0

German

Freigeben

1.8

French

Partager

1.5

Spanish

Compartir

1.8

Italian

Condividi

1.7

Japanese

共有

0.8

Chinese

共享

0.8

Korean

공유

0.7

...

In general, Asian languages are more space-friendly since use less space as they tend to be more compact than European languages. But there’s no “always”. CJK (Chinese, Japanese and Korean) languages have more complicated characters than Latin characters and their characters tend to be more square, thus taking more horizontal space. Japanese is especially problematic due to it’s use of Katakana for transliteration of foreign words. For example, “Follow” in English and Japanese both have 6 characters, but Japanese is 20% longer than English due to wider characters.

Date and Time

Date and Time should always be stored in UTC to allow it to be converted and displayed in multiple time zones. LUX components and guidelines follow the conventions detailed below by default:

  • Basic date format: dd-mmm-yyyy. For example 15-Aug-2020.

  • For the current day and the day before that you may use Today and Yesterday.

  • Basic time format: #0:00 PM/AM. For example 1:36 PM.

  • For combined date and time use the word at. For examples: 05-Mar-2020 at 7:27 AM or Yesterday at 12:16 PM.

All applications built for Verint should allow the above defaults to be automatically changed based on the users specified browser locale (or manual setting if an application allows it). Details of country and region specific conventions are available here.

Many frameworks and libraries (such as Moment.js) offer full and constantly updated internalization features for easy localization of dates and times.

Decimals

Despite being the conventional standard (and the LUX default) Great Britain and the United States are two of the few places in the world that use a period to indicate the decimal place. Many other countries use a comma instead. Likewise, while the U.K. and U.S. use a comma to separate groups of thousands, many other countries use a period instead, and some countries separate thousands groups with a thin space.

As with Date and Time above, all applications built for Verint should allow the decimal character defaults to be automatically changed based on the users specified browser locale (or manual setting if an application allows it). Details of country and region specific conventions are available here

Right to Left

In certain languages, such as Arabic and Hebrew, text is read from right-to-left (RTL). This makes it necessary to flip your entire design. A modular design approach will come in handy while accommodating RTL languages. For example, the application below is designed to flip neatly for Hebrew and other RTL languages:

...

When localizing for RTL, the elements below should be mirrored:

  • Horizontal ordering.

  • Text (from LTR to RTL).

  • Text field icons should be displayed on the opposite side of a field.

  • Navigation and menu buttons should be displayed in reverse order.

  • Icons that communicate direction, such as arrows, should be mirrored.

The elements below should not be mirrored:

  • Vertical ordering.

  • Clocks.

  • Video and audio controls.

  • Timeline indicators.

Most of the recent native frameworks are now mirroring-aware, making it easier to create a mirrored layout with very limited code changes.

Nation Flags

Avoid using flags to represent languages; language and country are different concepts. Flags are symbols that represent countries or nations, whereas languages represent a shared method of communication between people. For example, Spanish is spoken in 29 countries, and Spain is only one of them. Countries like Canada have more than 1 official language, so it cannot be represented by a single flag.

When designing a language selector, use plain text, despite its lack of visual appeal. Only use flags to represent countries or nations, not languages. Language names in the selector should always be shown in their own language, in order to make it easy for users to be able to identify their language of choice regardless of the currently-selected language. For example, English will always be labelled ‘English’, and French will always be labelled ‘Français’, even if Hebrew is selected as the current language.

Headers

Content Headers

Headers are the titles and subtiles subtitles used to illustrate the importance of a section or page. The underlying heading order and structure is used to index the structure and content of your applications application's pages for assistive tools.

In LUX, all headers should be at the same size as its corresponding section text using the matrix below. Headers one stop higher (two at most) than the section text may be used when there is no exact match or extra emphasis is required for that specific section. For example, if your section copy text is set at 12px, use the small, medium or large header depending on how much emphasis is needed. If your section copy text is set at 14px, only the medium or large headers should be used.

Header

rem

px

Html macro
<style>
	@import url('https://rsms.me/inter/inter.css');
	html { font-family: 'Inter' !important; }
</style>
<h1 style="font-family: 'Inter', arial; margin: 0; font-size: 32px;">Huge Header</h1>
2rem

2 rem

32px

32 px

Html macro
<style>
	@import url('https://rsms.me/inter/inter.css');
	html { font-family: 'Inter' !important; }
</style>
<h2 style="font-family: 'Inter', arial; margin: 0;  font-size: 24px;">Large Header</h2>

1.

5rem

5 rem

24px

24 px

Html macro
<style>
	@import url('https://rsms.me/inter/inter.css');
	html { font-family: 'Inter' !important; }
</style>
<h3 style="font-family: 'Inter', arial; margin: 0;  font-size: 16px;">Medium Header</h3>
1rem

1 rem

16px

16 px

Html macro
<style>
	@import url('https://rsms.me/inter/inter.css');
	html { font-family: 'Inter' !important; }
</style>
<h4 style="font-family: 'Inter', arial; margin: 0;  font-size: 12px;">Small Header</h4>

0.

75rem

75 rem

12px

12 px

Html macro
<style>
	@import url('https://rsms.me/inter/inter.css');
	html { font-family: 'Inter' !important; }
</style>
<h5 style="font-family: 'Inter', arial; margin: 0;  font-size: 8px;">Tiny Header</h5>

0.5rem

8px

...

...

0

...

.5

...

Use relative em units to accommodate for user browser preferences.

...

Don't skip HTML heading hierarchy levels in order to comply with screen reader guidelines.

...

rem

8 px

Labels

Effective form labelling helps users to understand what which information to enter into a form Input. Using a input.

  • A common method of space saving is using placeholder text as a label

...

  • . However, this is not recommended because it hides context and

...

  • can present accessibility issues. The use of placeholder labels should be restricted to forms where the field purpose is a universal standard, and where accessibility can be guaranteed, e.g. login forms.

  • Provide a text label left assigned , above or next to its associated field and left aligned to its associated field (Checkbox . Checkboxes and Radio buttons Buttons are exceptions to this rule).

  • In situations when where horizontal UI real estate space is scarce limited, or responsive design is used, render the label above it’s its associated field.

  • Ensure that all labels and associated fields are vertically aligned as columns in a table.

...

Required fields

It’s well known that users don’t read instructions, and they are particularly less likely to read instructions at the top of a form. Form fields seem self-sufficient and each field has a specific instruction — its label, hence all required fields should be marked in close proximity with its associated label.

  • Provide a star (asterisk) symbol position in superscript.

  • Use the Verint warning color with the star symbol to identify it’s necessity.

...

Accessibility

...

Accessibility

Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility.

For accessible labels, you should also follow these additional requirements:

  • Use the appropriate HTML <label> element and label for attribute.

  • Labels must remain visible when an input gets focusis focused.

  • Labels must be announced to the screen reader on focus.

  • Ensure the helper help text that which appears under underneath an input is read when an assistive technology user stops at an input using ARIA.

  • Use sentence case capitalization (see Capitalization section below under Text Formats).

Capitalization

  • We use different capitalization styles for different types of content to improve scannability, organize information, and guide users to key actions.

  • When building new LUX

...

  • applications, also align capitalization practices with platform conventions to match user expectations (e.g. specific iOS conventions).

Styles

Title Case (Most Words Are Capitalized)

...

Use title case for menu labels, buttons, navigation, and section headers.

Do capitalize

  • The first letter of nouns, adjectives, verbs, adverbs, and pronouns

  • The first and last words of the text element

  • The second word of a hyphenated compound unless it is an article or preposition (for example: “Quick-Search Options” and “Add-on Choices”).

Don’t capitalize

...

LUX uses two capitalization styles:

Description

Use for…

Title Case

  • All words in the text element are capitalized (for example: System Management), except for articles (“a,” “an,” “the”) or prepositions with fewer than five letters (“to,” “on,” “at,” “by,” “from”, for example: Forecasting and Scheduling).

  • The second word of a hyphenated compound is capitalized (for example: Quick-Search)

...

Sentence Case (Most words are lowercase)

...

Use sentence case for all body copy, image captions, and secondary, editorial subheadings.

...

  • , unless it is an article or preposition (for example: Add-on).

  • Page title

  • Widgets and other containers titles

  • Navigation items

  • Tab titles

  • Popup and dialog headers

Sentence Case

  • All words in the text element are not capitalized, except for:

    • the first word of the text element

...

    • ,

    • names and titles of individuals,

    • unique names of organizations, products, services, technologies etc.,

    • published work titles.

Anything else, including:

  • Secondary headers

  • Data table headers

  • Form elements labels

  • Action menu items

  • Buttons

  • Links

  • Popup titles

  • Toast titles and text

  • Body copy

Examples

Form

Message popup

Generate Schedule.pngImage AddedNo Assigned Shifts.pngImage Added