Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Programming Jakarta Struts, 2nd Edition [Electronic resources] - نسخه متنی

Chuck Cavaness

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








12.1 What Is Internationalization?


Traditionally,
software developers have focused on building applications that solve
an immediate business problem. While doing so, it's
easy and sometimes necessary to make assumptions about the
user's language or country of residence. In many
cases, these assumptions are valid and there's never
a question of who the audience will be. However, if you have ever had
to re-engineer an application because these assumptions
weren't correct, you know how hard it can be to go
back and correct the application design after the fact.

Internationalization (I18N), simply stated, is
the process of designing your software ahead of time to support
multiple languages and regions, so that you don't
have to go back and re-engineer your applications every time a new
language or country needs to be supported. An application that is
said to support
internationalization has the
following characteristics:

  • Additional languages can be supported without requiring code changes.

  • Text elements, messages, and images are stored externally to the
    source code.

  • Culturally dependent data such as dates and times, decimal values,
    and currencies are formatted correctly for the
    user's language and geographic location.

  • Nonstandard character sets are supported.

  • The application can quickly be adapted to new languages and/or
    regions.


When you internationalize an application, you can't
afford to pick and choose which options you want to support. You must
implement all of them or the process breaks down. If a user visits
your web site and all of the text, images, and buttons are in the
correct language but the numbers and currency are not formatted
correctly, it will make for an unpleasant user experience.

Ensuring that the application can support multiple languages and
regions is only the first step. You still must create localized
versions of the application for each specific language and/or region
that you want to support. Fortunately, here's where
the benefits of I18N on the Java platform pay off. For applications
that have been properly internationalized, all of the work to support
a new language or country is external to the source code.

A
locale
is a region (usually geographic, but not necessarily so) that shares
customs, culture, and language. Applications that are written for a
single locale are commonly referred to as
myopic.
Localization
(L10N) is the process of adapting your application, which has been
properly internationalized, to a specific locale. For applications
where I18N support hadn't been planned or built in,
this usually means changes to text, images, and messages that are
embedded within the source code. After the changes are applied, the
source code may need to be recompiled. Imagine doing this time and
time again for each new locale you have to support!

According to Richard Gillam from the
Unicode Technology Group, which designed
much of the I18N support in the Java libraries,
"Internationalization is not a
feature." Users will expect that the products they
use will work for them in their native languages. Things can go
wrong, and users get unhappy when assumptions that you make are
incorrect. Start planning early for I18N support in your
applications. Even if it doesn't look like
you're going to need it, if you do
you'll be that much further ahead, and it
won't hinder development as long as you do it right
from the start.


Not every application needs I18N support, and some developers and
development organizations frown on adding in functionality that
isn't part of the requirements. However, even if
your application has no requirements to support more than a single
locale, there are still benefits that you can gain from including
some aspects of I18N. For example, by using resource bundles for all
of your static text, you can save development and, more importantly,
maintenance time. We'll see how this is true later
in the chapter.


    / 181