Internationalization (I18N) Guidelines

This is a summary of the engineering changes recommended for software applications using standards-based and Sybase-specific internationalization technology.

General Principles

The general principles outlined here ensure that all solutions are aimed at the same set of goals with an ultimate goal of "seamless multinational environments" that support the success of Sybase's global customers.

Note that internationalization is not "just another feature." If an interface or application cannot handle a user's language, then you don't have any interface at all. Internationalization is an underlying part of an application's infrastructure and architecture. It must be approached with the same level of planning and market concern as you would in choosing between a command-line approach or GUI as an interface for end users.

The General Principles are as follows:

• Localizable
  All messages, icons, and human-readable content must be externalized and easily translated. The translated message, or resource, files must be seamlessly loadable by the application, depending on the current language and locale settings for the session, data-item, data stream, or user.
  
• Character Handling
  The application must correctly handle all character data based on the attributes of the character data, not the encoding. Ideally, an application or installation should operate independently of the underlying operating system's default character encoding.
  
• Collation
  Sorted strings of text should be collated in a culturally expected way. The sort order should be configurable depending on the language of the user or meta data about the installation or data itself.
  
• Text Handling
  For text-intensive applications, such as word processors or graphical display painters, strings of characters should be correctly handled as text streams. This means line wrapping, word selection, bi-directional displays, and cursor movement should all occur as expected, depending on the cultural context in use.
  
• Single Code Line
  A properly internationalized project uses a single codeline. This reduces maintenance costs and time-to-market. It allows for easier simultaneous worldwide release. Therefore, this requires some planning by the project team and the codeline czar. 
• Single Source
  More specifically, one source should be used for creating all worldwide binaries. Ideally, only one binary is needed for all locales and cultural customizations. This reduces maintenance even further, and allows for an even quicker penetration into new geographic or global markets.  

Portable
In order to be usable across all the Sybase hardware and software platforms, the code must be portable. This is true for internationalization code as well. The more generic the code is, the more portable it is. Therefore, the architecture should take into consideration the need for a portability layer between the OS and the internal cultural data handling systems.

1. Date -- including UTC, imperial eras, lunar/religious calendars and ISO 8601 formats
.
For example, what is 01-02-03? This date is interpreted differently depending on the country. 
January 2, 2003    U.S. 
February 1, 2003  Europe 
February 3, 2001  Japan

2. Time -- different local formats, plus ISO 8601 formats
   
3. Numbers -- decimals, group separators, and negative representation
    
For example, what is 123,456?
123456                U.S., U.K., Japan 
123 + 456/1000   Europe

4. Currency -- universal and local denominations, decimals, and negative representations

Other items that may require application-specific formatting include: forms of address, street addresses, telephone numbers.

Cultural Profile Preservation The cultural profile includes a prioritized list of the user's preferred language, territory, and local cultural conventions. This needs to be preserved as a user's virtual access spans multiple systems. The data's cultural context should be recorded and preserved wherever possible as well. 

User environment
The user's preferred cultural profile should first be determined from the operating environment. This would be the locale setting in UNIX or Posix, or the Regional Settings Properties Control Panel in Windows. After that, the user may have runtime overrides or environment settings for further application-specific settings. We also use the LANG or SYB_LANG environment variable in Sybase products. 

Across boundaries
Once the cultural profile has been set, it should be packaged and sent with other connection information when crossing boundaries for server, web, or application access. This allows generated messages downwind or several tiers deep from the client to return information in the correct language. 

Testable 
The application or system should be testable in that it should be easy to test its internationalization features with or without translated localization files. Internationalization testing should be an integral part of the normal nightly build and test. All external resource files or message stores should be tested before translation using psuedo-english formats such as "pig latin" or accented vowel replacement. Once messages have been translated, all nightly builds should be tested on a regular basis using English, German, and Japanese to check common problems that are exposed due to text expansion and multibyte character set usage. 

Related Links