A number of factors increase the complexity of developing and deploying these Intranet software applications. Each of them not only expands the scope of the work, but also increases the cost to write and maintain these applications. This module discusses two common features—internationalizationand platform independence—and the complexity they introduce.

Internationalization (I18N)

Writing software that is capable of running in multiple languages and in different countries is typically divided into two steps: internationalization and localization. Internationalization involves making the software capable of supporting different languages and locales. This involves externalizing the software's text messages to facilitate translation. Text messages include labels for fields and buttons, error and informational messages, and, of course, on-line help. Internationalization also involves supporting the different formats for data, time, and currency for both display and data entry. The collating sequence, or sort order, must also be addressed to display menu items and data properly.

Localization is the process of adapting the software to a locale or country. This can involve translating the externalized message into the language of the target locale. During internationalization, the controls are usually made aware of the locale so that the controls will automatically adjust date, time, and money formats to the user's setting. Localization may also involve rewriting part of the software for local tax laws and other regulatory requirements.

In the Americas and most European countries, a single byte alphabet is sufficient to represent the characters and punctuation used. A single byte allows a maximum of 256 characters. However, a number of graphical languages, such as Chinese, Japanese, and Korean, require more than one byte to represent the working set of characters and glyphs. These multibyte languages often require special visual components for display and data keying. Depending on the operating system, they may also require a special version of the operating system that supports the multibyte language. Special coding techniques are employed to handle the wide characters used with multibyte languages.

Platform Independence

Often it is desirable to allow some flexibility in the hardware platforms for the different tiers in the architecture. Selection of a database at the bottom tier that runs across multiple hardware platforms can significantly reduce the effort to achieve platform independence. The tuning and operation of the database changes on different hardware platforms.

At the middle tier, the selection of the object middleware, Web server, and programming languages have a significant effect on the complexity of platform independence. If true platform independence is desired, compromises must often be made to keep the business logic portable enough to run across multiple platforms. Of the three tiers, the middle tier poses the biggest challenge to achieving platform independence.

The top tier faces two significant independence issues: (1) hardware/operating system independence, and (2) Web browser independence. Some Web browsers run across multiple hardware platforms. However, care must be exercised to ensure that the features of the Web browser that an application requires are available across the platforms of interest. Some Web browsers do not support all of their features on all platforms they claim to support.

Web browser independence requires a significant effort in both design and testing. The major Web browsers continue to leapfrog over each other in features, each implementing the successful features of the other. If developers limit themselves to the commonly implemented features across the target browsers, Web browser independence is achievable, but at the expense of the latest features available on the browsers. Within the Intranet it is often possible for a company to standardize on one Web browser and eliminate the need for this independence.