Internationalization

...

and Localization

Internationalization (i18n) is the process of designing software applications so that it can 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.

...

Avoid using flags to represent languages, ; language and country are different concepts. Flags are symbols that represent countries or nations while , 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, hence is not suitable to 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 select component selector should always appear be shown in that their own language, in order to make it easy for users to always be able to return to identify their language of chose choice regardless of the current currently-selected language selected. e.g . For example, English will always be labelled as ‘English’ ‘English’, and French will always be labelled ‘Français’, even if Hebrew is selected as the current language.

Right to Left

In certain languages like , such as Arabic and Hebrew, text is read from right-to-left (RTL) necessitating . This makes it necessary to flip your entire design to be flipped. 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 as shown below:

...

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

• Horizontally positioned sectionsHorizontal ordering.

• Text (from LTR to RTL).

• Text fields 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, like such as arrows, should be mirrored.

the The elements below should not be mirrored:

• Vertically positioned sectionsVertical ordering.

• Clocks.

• Video /and audio controls and timeline .

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

...

Always design with text expansion in mind. When English text gets translated to into another language, the translated text can be as much as three times 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:

...

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” “Share” into various languages:

...

In general, Asian languages are more space-friendly since use less space as they tend to be more compact than European languages.

...

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 an the application allows it). Details of country and region specific conventions 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.

...

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 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 by a manual setting, if an application allows it). Details of country and region specific conventions conventions for specific countries and regions are available here.

Headers

Content Headers

Headers are the titles and subtiles subtitles used to illustrate the importance of a section or page. The underlying heading order 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.

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

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

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

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

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

...

Image Added

Accessibility

To add to Unless otherwise specified, see our general compliance information in in Fundamentals - Accessibility, here are a few extra factors to follow for accessible headers:

...

.

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

• Not skip HTML heading hierarchy levels in order to comply with screen reader guidelines.

• Use title case capitalization (see the Capitalization section below).

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 is often applied as a space-saving method. However, this is not recommended because it hides context and can present accessibility issues. Use The use of placeholder labels should be restricted to forms in which where the field purpose is a universal standard, and where accessibility can be guaranteed, e.g. login forms.

• Provide a text label, left aligned to its associated field. Checkbox Check boxes 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.

Image Modified

Required fields

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

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

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

...

Accessibility

To add to Unless otherwise specified, see our general compliance information in in Fundamentals - Accessibility, here are a few extra factors to follow for accessible labels.

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 the Capitalization section below).
  

Capitalization

...

When building new LUX applications, also align capitalization practices with platform conventions to match user expectations (e.g. IOS specific iOS conventions).

Styles

Title Case (Most Words Are Capitalized)

Image Modified

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

...

• 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: “QuickQuick-Search Options” Options and “AddAdd-on Choices”Choices).

Don’t capitalize

• Articles (“a,” “an,” “the”) or prepositions with fewer than five letters (“to,” “on,” “at,” “by,” “from”) unless they’re the first or last words of the text element.

...

Sentence Case (Most words are lowercase)

Image Modified

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

Only capitalize the first word of the text element, as well as any proper nouns.

...