Introduction
While hardly an expert on the deep technological aspects of Internationalization (often referred to as I18N) and the related topic of Localization (L10N), I have been responsible at the executive level for Internationalization/Globalization standards for transactional (financial) applications, as well as a contributor on Internationalization/Globalization issues in many of my consulting engagements.
The Main Issues for Internationalization and Localization of Websites and Web-based
Transactional Applications (Summary)
Example: On the right of the screen is a thumbnail of a website that is Internationalized and Localized for German and English. It happens to be the website for a tool (AttrakDiff) that we use extensively for online 'card-sorting' studies related to naming and categorization of website commands into a good navigation structure. (note: Many are surprised that many modern German technical terms are "borrowed" from English)
- Internationalization:
- Internationalization refers to the overarching framework or architecture of an application to support multiple languages, multi-byte characters, different sorting orders and ease of Localization; which is described under Localization below.
- An Internationalization framework includes multi-language, multi-format (date/time/address), and, for eCommerce applications, multi-currency capability. Specifically, we are talking about error, warning and informational messages, labels on screen controls and elements, online help, dates, time/time zones, numbers, currency, phone numbers, personal titles (Mr., Dr., Mrs., etc.) and postal addresses.
- Localization:
- Localization (L10N) is when an entity (group, company, engineer, third party, partner, etc.) converts the current language application to another language.
- An application must be easy to Localize by separating all user viewable messages into one “area.” Someone who is converting the application from one language to another need only look in one area to convert/translate the messages, as opposed to searching throughout the entire application looking for and hoping they find all the messages/text that could be displayed to a user and, thus, need to be converted.
Critical Internationalization (and Localization) Requirements, by Category
- General
Documentation defining the process to Internationalize / Localize the application is always necessary.
- Language & locale
- User selectable language within a website or system
This requires that more than one language be supportable by a single instance of the system (rather than running a separate system for each language)
- Ability to switch from one language to another within a session (i.e. “on-the-fly”)
This is only required for certain kinds of websites, but it should be kept in mind as an issue for anyone developing a truly Internationalized site.
- Messages (error, alerts, informational) should be in the language chosen by the user.
A fall back strategy is that messages are displayed in the language of the localized version of the site.
- Formatting/presentation
- Support for the ISO/IEC 10646 Unicode universal character encoding standard used for representation of text for computer processing
- Applies to characters, numerals, special characters, and diacriticals
- Supports left-to-right AND right-to-left AND vertical input and reading
- ‘BIDI’ (Bi-Directional) support:
- Middle Eastern languages such as Hebrew and Arabic are written predominantly right-to-left.
- Numbers are written with the most significant digit left-most, just as in European or other left-to-right text.
- So the complete document is bi-directional in nature, a mix of both right-to-left (RTL) and left-to-right (LTR) writing. Text written in the Hebrew and Arabic languages is often referred to a bi-directional, or ‘bidi’ for short.
- Cultural sensitivity to use of color, graphics, and symbols
- Observe that many colors, graphics, symbols, and words that are suitable for the western culture may have different meanings and may even confuse users from other cultures.
- For example, the red color indicates stop in the US but it might not be the case for other cultures.
- An envelope graphic may replace the mailbox graphic that is used as indication for "email". The envelope is easier to recognize for users from other cultures than the mailbox.
- Many Western languages are written from left to right, but Arabic and Hebrew are written right to left, and this orientation can affect the interpretation of visual cues and icons. For example, an arrow pointing to the right can mean "continue" in the United States but just the opposite in countries where Arabic is spoken.
- Sensitivity to etiquette, policies, tone, formality and metaphors
An excellent example to illustrate this point is the example of AttrakDiff, used at the beginning of this posting. Great effort was taken by the AttrakDiff team, including extensive ethnography, online surveys, interviews and so forth to ensure that the German was well-translated for English speakers. Literally translated German can seem gruff and overly formal in tone to many English speakers.
- Support for Arabic lunar calendar
- Currency & exchange rate (for eCommerce applications)
- By default, the system must support all currencies as by ISO 4217 standard.
- Currency should be displayed using common currency codes (e.g. USD, EUR, GBP) or currency symbols (e.g. $,€,£).
- Transactions/monetary amounts should always be stored with a currency attached.
- All screens displaying summary account information will allow for the ability to display amounts in user-selected currencies.
- Monetary values must have a precision of 18,3 digits
- Some countries have multiple interchangeable currencies so we would need to support these. For example, Argentina permits the Peso & the US dollar (1:1), Belize permits the Belize dollar & the US dollar (2:1)
- Many other issues with banking systems…
There are issues such as International identification of banks and accounts, but that is beyond the scope of this summary.