51 lines
3.7 KiB
HTML
51 lines
3.7 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
|
|
|
<title>Overview of internationalization</title>
|
|
</head>
|
|
|
|
<BODY>
|
|
<!-- Java sync-link -->
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
|
|
|
<h4><A NAME="interover">Overview of internationalization</A></h4>
|
|
|
|
<p>Internationalization is defined as the presentation of information to users in an application according to regional cultural conventions. The application can be configured to interact with users from different localities in culturally appropriate ways. In an internationalized application, a user in one region sees error messages, output, and interface elements in the requested language. Date formats, time formats, and currencies are presented appropriately for users in the specified region. A user in another region sees output in the conventional language or format for that region.</p>
|
|
|
|
<p>Historically, the creation of internationalized applications has been restricted
|
|
to large corporations that write complex systems. Internationalization techniques
|
|
have been traditionally expensive and difficult to implement; they have
|
|
been applied only to major development efforts. However, increasing usage of
|
|
distributed computing and the World Wide Web have forced application developers
|
|
to internationalize a much wider variety of applications. This requires making internationalization techniques more accessible to application developers.</p>
|
|
|
|
<p>In a non-internationalized application, the interface that is seen by the user is unalterably written into the application code. Alternatively, however, the application developer can localize the displayed strings on the interface and add a layer of abstraction into the design of the application. Instead of printing a simple error message, an internationalized application represents the error message with some language-neutral information. In the simplest example, each error condition corresponds to a key. To print a usable error message, the application looks up the key in the configured
|
|
message catalog. Each message catalog is a list of keys with associated strings.
|
|
Different message catalogs provide strings for the different languages supported.
|
|
The application looks up the key in the appropriate catalog, retrieves the
|
|
corresponding error message in the requested language, and prints this string
|
|
for the user.</p>
|
|
|
|
<p>Localization of text can be used for more than translating error messages.
|
|
For example, by using keys to represent each element in a graphical user interface
|
|
(GUI), and by providing the appropriate message catalogs, the GUI (including buttons,
|
|
menus, etc.) can support multiple languages. Extending support to additional
|
|
languages requires that the application developer provide message catalogs for those languages. In many cases, the application itself needs no further modification.</p>
|
|
|
|
<p>Internationalization of an application is driven by two variables: the
|
|
time zone and the locale. The time zone indicates how to compute the local
|
|
time as an offset from a standard time (such as Greenwich Mean Time). The locale
|
|
is a collection of information about language, currency, and the conventions
|
|
for presenting information (such as dates). In a localized application, the locale
|
|
also indicates the message catalog where an application should retrieve
|
|
message strings. A time zone can cover many locales, and a single locale can
|
|
span time zones. With both time zone and locale, the date, time, currency,
|
|
and language for users in a specific region can be determined.</p>
|
|
|
|
|
|
</body>
|
|
</html>
|