...
Internationalization (i18n) is the process of designing a software application 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:
...
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. Consult this overview of common color meanings for different cultures to ensure you don’t make any significant mistakes.
Flags
Avoid using flags to represent languages. Language , 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, hence is not suitable to 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, not languages.
...
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 LUX application below is designed to flip neatly for Hebrew and other RTL languages as shown below:
...
When localizing for RTL, the elements below should not be horizontally mirrored in RTL languages:
Main layout sections
Images, except when they correspond to direction (example: arrows)Horizontally positioned sections
Text
Text fields 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 arrows, should be mirrored
the elements below should not be mirrored:
Vertically positioned sections
Graphs (x– and y–axes are always shown in the same orientation in all languages)
Clocks
Video controls and timeline indicators
...
Always design with text expansion in minmind. When English text gets translated to 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. Make UI components expandable whenever possible. Do not assign a fixed-width or height to your UI component unless you have a good reason.
For longer text, wrapping is a good solution. Be aware of the potential vertical expansion since translated text will take more lines. Truncation with hover text can be a compromise. Be aware that this brings the risk of making the UI less effective.
...
In general, Asian languages are more space-friendly since 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-/mm/yyyy. For example 15-Aug-2020 03/08/2017.
For the current day and the day before that you may use , the default is Today and Yesterday.
Basic time format: #000:00 PM/AM. For example 105:36 PM55 AM.
For combined date and time use the default uses the word at. For examples: 05-Mar-2020 at 7:27 03/08/2017 at 00:55 AM or Yesterday at 12:16 55 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.
...
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. UK and US 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.
...
Headers are titles and subtiles 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 pages for assistive tools.
...
Header | rem | px | ||
|---|---|---|---|---|
| 2rem | 32px | ||
| 1.5rem | 24px | ||
| 1rem | 16px | ||
| 0.75rem | 12px | ||
| 0.5rem | 8px |
...
Accessibility
A few key To add to our general compliance information in Fundamentals - Accessibility, here are a few extra factors to follow for an accessible headers:
...
:
...
Don't skip HTML heading hierarchy levels in order to comply with screen reader guidelines.
Use title case capitalization (see Capitalization section below).
...
Effective form labelling helps users understand what information to enter into a form Input. Using a placeholder text as a label is often applied as a space-saving method. However, this is not recommended because it hides context and presents can present accessibility issues. Use of placeholder labels should be restricted to forms in which field purpose is a universal standard and accessibility can be guaranteed e.g. login forms.
Provide a text label left assigned aligned to its associated field (. Checkbox and Radio buttons are exceptions to this rule).
In situations when horizontal UI real estate is scarce or responsive design is used, render the label above it’s associated field.
Ensure that all labels and associated fields are vertically aligned as columns in a table
...
It’s well known that users don’t always read instructions, and they are particularly less likely to read instructions at the top of a form. Form fields seem are primarily 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 positioned in superscript.
Use the Verint warning color with the star symbol to identify it’s necessity.
...
Accessibility
A few key To add to our general compliance information in Fundamentals - Accessibility, here are a few extra factors to follow for an accessible labels:
Use the appropriate HTML <label> element and label for attribute.
Labels must remain visible when an input gets focus.
Labels must be announced to the screen reader on focus.
Ensure the helper text that appears under an input is read when an assistive technology user stops at an input using ARIA.
Use sentence case capitalization (see Capitalization section below).
...
When building new LUX products, also align capitalization practices with platform conventions to match user expectations (e.g. IOS specific conventions).
Styles
Title Case (Most Words Are Capitalized)
...