CHAPTER 10 Internationalization
320
USE CULTURALLY RELEVANT METAPHORS
In North America, using a shopping cart is a valid metaphor for purchasing items
because it easily translates to users ’ real-world experience. In Europe and Asia,
however, a shopping cart icon could cause confusion because users are more
familiar with shopping baskets than with carts. E-commerce sites should change
labels and/or images when serving customers in those countries ( Figure 10.9 ).
USE PLAIN LANGUAGE
Avoid confusing nonnative speakers by using plain language and refraining
from slang and colloquialisms in text. In addition, be sensitive when using
greetings such as “ Welcome, Ͻ fi rst name Ͼ “ for applications that may be
used by non-American users. North American culture is very informal com-
pared to many other cultures, as evidenced by its low Power Distance Index
in Hofstede’s cultural dimensions (see www.greet-hofstede.com/hofstede_united_
states.shtml ). In Asia, such informality would be considered inappropriate, as
people are usually addressed by their last name. Greetings used by Amazon or
Flickr are more appropriate for web applications with international audiences
( Figure 10.10 ).
In general, to make localization easier, avoid the following when developing
web content (Hurst, 2007):
■
Words with multiple meanings
■
Abbreviations
■
Mnemonics
■
Acronyms
■
Slang or jargon
■
Gender notation
■
Creation of new words
■
Shortened plurals or word combinations
■
Anything that portrays a way of life or culture specifi c to one country
FIGURE 10.9
Amazon uses the label “ basket ” for its e-commerce site in the United Kingdom.
(However, the icon still resembles a shopping cart.)
FIGURE 10.10
Greetings used by Flickr (a) and Amazon (b) are more appropriate for
international audiences.
(a)
(b)
321
Related design patterns
The patterns identifi ed in Chapter 11 — SEMANTIC MARKUP, UNOBTRUSIVE
STYLE SHEETS, UNOBTRUSIVE JAVSCRIPT, and so forth — are also relevant for
internationalization, as they help make web applications easy to localize.
DATE FORMAT
Problem
Using a date format common in one region can be confusing to users from
other regions. For example, the date format used in the United States (mm/
dd/yy or mm/dd/yyyy) would be confusing to European users because they are
familiar with dd/mm/yy or dd/mm/yyyy formats and to Japanese users who
use yy/mm/dd format.
Solution
Use the ISO 8601 recommended yyyy-mm-dd date format when showing dates,
or use a format that eliminates confusion between the month and the year in a
date ( Figures 10.11 and 10.12 ).
Why
Although web applications designed to be used exclusively by a country or a
region can depend on its native date formatting standard, users from other
Date Format
FIGURE 10.11
Sun uses the yyyy/mm/dd format for displaying dates (a slight variation from
the ISO recommended yyyy-mm-dd format).
FIGURE 10.12
PayPal uses a date format of the abbreviated month, dd, yyyy to make the
month and year obvious.
CHAPTER 10 Internationalization
322
regions may fi nd it confusing if it doesn’t match their local conventions. For
example, the date “ 02/04/03 ” may be interpreted as
■
2nd of April 2003 (Europe)
■
4th of February 2003 (United States)
■
3rd of April 2002 (Japan)
The international format defi ned by ISO (ISO 8601) addresses this problem by
defi ning a numerical date system in the format yyyy-mm-dd. Showing dates in
an ISO format or making the month and year obvious prevents confusion. In
addition, this approach is computer friendly, as it makes chronologically sort-
ing dates easier (see also www.w3.org/International/questions/qa-date-format ).
However, the ISO date format is diffi cult to read, as it is quite different from
most users ’ native date format. Therefore, when space and sorting are not
issues, use a more readable format that spells out the month and makes the
year obvious (e.g., February 4, 2003, or 4 February 2003).
How
Designers have two options to show dates:
1. Use a locale-neutral ISO 8601 recommended format. The ISO 8601
recommended format of yyyy-mm-dd is the solution most commonly
adopted by web applications with a diverse user base, where:
■
yyyy is the year (all the digits, i.e., 2008).
■
mm is the month (01, January, to 12, December).
■
dd is the day (01 to 31).
January 2, 2008 would then be shown as 2008-01-02.
2. Use a format that makes the month and year obvious. This approach
uses a name for the month and four digits for the year. So the date can
be written as January 2, 2008, or 2 January 2008. This approach is more
natural to users, since it is easier to read. However, it occupies more space
and, because it may affect sorting performance, is less computer friendly.
BE CAREFUL WHEN ABBREVIATING MONTHS
Abbreviating letters for months in dates (e.g., Jan. 2, 2008, or 2 Jan. 2008) may
be problematic for users in some countries. For example, in French, the fi rst
three letters of June and July are the same — juin and juillet , respectively.
CONSIDER USERS ’ LOCALE PREFERENCES WHEN
SHOWING DATES
For web applications, it’s possible to capture users ’ locale preferences and
display users ’ native date format using the Accept-Language HTTP header.
However, this method of showing dates may be inappropriate if the content
is not localized and therefore it is possible that the date format will not match
323
the language of the page. For example, if a page is presented in German, show-
ing dates in the North American mm/dd/yyyy format may be confusing (even
when users ’ locale preference is English), as users may be unclear if the page
uses the mm/dd/yyyy format or dd/mm/yyyy format.
USE CALENDAR POP-UPS FOR DATE SELECTION
To minimize date input errors, consider using pop-up calendars. They help in
several ways. First, they prevent data-entry errors caused by differing date for-
mats (mm/dd/yy versus dd/mm/yy). Second, because users can see both the
month and day, they can be sure that they have chosen the right date. When
using pop-up calendars, show the calendar as soon as the date fi eld has received
focus to encourage users to pick a date from the calendar; however, do not pre-
vent them from entering the date via the keyboard. In addition, when using a
pop-up calendar, ensure that the month is clearly shown ( Figure 10.13 ).
Related design patterns
Using a locale-neutral format requires more horizontal space than the U.S. for-
mat of mm/dd/yy or mm/dd/yyyy. Therefore, it’s important that pages use an
Date Format
FIGURE 10.13
This pop-up calendar from Flickr, although it uses mm/dd/yyyy format (even for
different languages), makes it easy to select a date from the calendar (a). The month in the pop-
up calendar is localized to the selected language (b).
(a)
(b)
CHAPTER 10 Internationalization
324
EXTENSIBLE DESIGN to accommodate additional space requirements. In addi-
tion, consider using the GLOBAL GATEWAY pattern to capture users ’ country
and language preferences.
TIME FORMAT
Problem
Like date formats, time formats vary from one region to another. Although each
time format shows hours, minutes, and seconds, their presentation order and
separators often vary in terms of a 12- or 24-hour format; the character used to
separate hours, minutes, and seconds; leading zeros; the display of time zones;
and the use of daylight savings times.
Solution
Whenever possible, show times in users ’ local time zones and use local conven-
tions for showing time — that is, either the 12-hour AM/PM system or 24-hour
system ( Figure 10.14 ).
If time cannot be represented in users ’ native format, use ISO 8601 recom-
mendations, which use the 24-hour system with either an hhmmss format or
hh:mm:ss extended format, where:
■
hh represents hours between 00 and 24.
■
mm represents minutes between 00 and 59.
■
ss represents seconds between 00 and 59 (or 60 in the exceptional case of
an added leap second).
Why
Users are likely to be most familiar with the local convention for their time
zone and may be uncertain about the time when presented with other conven-
tions. In addition, when time is presented in a different country’s time zone,
users may not know how to convert it to their local time zone or may make
errors when converting it.
How
Whenever possible, show time based on users ’ local time zones or stated pref-
erences. In cases where the event or activity occurs in a different time zone,
FIGURE 10.14
Google Calendar localizes time to users ’ local time zone, even when the
meeting is scheduled by someone in a different time zone.
325
show time using the event or activity’s time zone as the point of reference. For
example, when showing fl ight status, use local time zones from where the fl ight
will depart and where the fl ight will arrive ( Figure 10.15 ).
ALLOW USERS TO SPECIFY THEIR TIME ZONE PREFERENCE
When registering with an application or setting up a user profi le, ask users for
their preferred time zone ( Figure 10.16 ).
For tasks such as scheduling meetings or setting up events, when showing local
times, indicate the time zone and offset from GMT (Greenwich Mean Time) or
UTC (Coordinated Universal Time or Universal Coordinated Time) ( Figure 10.17 ).
Because GMT and UTC are usually the same,
6
GMT is more commonly used
because of users ’ familiarity with it.
Related design patterns
The localized DATE FORMAT pattern usually accompanies the TIME FORMAT
pattern, because most applications that show time or require users to select
Time Format
6
GMT is based on the rotation of the Earth, whereas UTC is based on cesium-beam atomic
clocks. The two times are usually the same, or no more than a second apart, as leap seconds are
occasionally applied to UTC.
FIGURE 10.15
When showing fl ight status information, departure and arrival times should be
shown using local departure and arrival times regardless of the time zone from which users are
viewing the data (www.fl ightview.com) .
FIGURE 10.16
When creating a meeting or an event in ReadyTalk, users are asked to indicate
both the time and time zone in which the meeting will occur.
CHAPTER 10 Internationalization
326
times usually show dates or require users to select dates. In addition, showing
time zones and time zone offsets requires additional space, making use of the
EXTENSIBLE DESIGN pattern as well.
NUMBER FORMAT
Problem
Conventions around the world for representing numbers vary in terms of group
and decimal (i.e., fractional) separators, precision required, units of measure,
and so forth.
Solution
Follow the conventions, formats, and regulations of the country from which
users are accessing the application.
Why
There are no universally accepted conventions for representing numbers. They
differ widely among countries. Since users cannot be expected to be familiar
with conventions of other countries, the usable option is to present numbers
in formats they are most accustomed to seeing.
How
When showing numbers, the whole (or integer) portion of a number is usually
split into groups by a separator. The way the number groups are created and the
separator is used varies around the world ( Figure 10.18 ). In the United States,
numbers are shown in groups of three, separated by commas (e.g., 1,000,000);
in India, numbers are shown in one group of three and then in groups of two,
separated by commas (e.g., 10,00,000); and in Japan, large numbers are created
by grouping digits in 10000s separated by ideographic characters that represent
powers of 10000 (e.g., 1 0000 0000).
FIGURE 10.17
When editing account information, Twitter allows users to specify their time
zone. Although it shows “ GMT-08:00, ” it clarifi es the time zone by indicating “ Pacifi c Time ” and
the countries in which it is applicable, “ (US and Canada). ”
327
Like grouping separators, the separator between the whole and the fractional part
of a number — known as a decimal point, decimal separator, and other terms —
also varies from one country to another. It can be a decimal point (i.e., a period),
comma, or another character ( Figure 10.19 ).
USE UNITS OF MEASURE FAMILIAR TO USERS
Use units for weights and measurements to suit the target country’s conventions
as well. For example, using pounds, feet, and inches (English or British system)
will not be effective in countries that use the Metric system, where the corre-
sponding units of measure are kilograms, meters, and centimeters, respectively.
Similarly, showing temperature in Fahrenheit will be confusing to users who are
only familiar with the Centigrade system. Therefore, if an application is likely to
be accessed by those familiar with different conventions, show units of measure
and temperature in both Metric and English systems or allow users to switch
from one measurement unit to another ( Figure 10.20 ).
Because users may be unfamiliar with the terms “ English ” and “ Metric ” sys-
tems, when feasible, use explicit and familiar units of measurement such as
°F and °C. Similarly, it is better to ask users to choose units of measurement,
such as centimeters, meters, feet, yards, and so forth, instead of asking them to
choose between English and Metric systems.
SHOW PHONE NUMBERS IN FAMILIAR FORMATS
Phone number formats also vary from one country to another in the total num-
ber of digits in the phone number and separators ( Figure 10.21 ). Therefore,
when possible, follow local conventions for showing phone numbers.
Number Format
United States 1,000,000,000 Groups of 3, separated by a comma (,)
Germany 1.000.000.000 Groups of 3, separated by a period (.)
Switzerland 1’000’000’000 Groups of 3, separated by an apostrophe (’)
France 1 000 000 000 Groups of 3, separated by a space
India 1,00,00,00,000 First group of 3, then groups of 2, separated by a comma (,)
Japan 1 0000 0000 Groups of 4 separated by ideographic characters
FIGURE 10.18
Examples of grouping separators in different countries.
United States 1,123.45 Decimal separator is a period (.)
France 1 123,45 Decimal separator is a comma (,)
Switzerland (German) 1’123.45 Decimal separator is a period (.)
Switzerland (French) 1 123,45 Decimal separator is a comma (,)
FIGURE 10.19
Examples of decimal separators in different countries. Multilingual countries
such as Switzerland use different decimal separators for different languages. A comma is used
as the decimal separator, except when the amount is in Swiss Francs, in which case a period is
used, and either an apostrophe or space is used for the thousands separator.
CHAPTER 10 Internationalization
328
An alternative is to use ITU-T E.123, which is the International Format that
recommends the following (see also Figures 10.22 and 10.23):
§ 2.1: The international number should be printed below the national
number, with corresponding digits lined up one under the other to facilitate
understanding of the composition of the international number.
§ 2.5: If it is desirable to write only the international number, it should be
written in the form: Telephone International ϩ 22 607 123 4567.
Australia 61 (0403) 416 7216
New Zealand 64 021 525-582
United Kingdom 44 07700 954 321
United States 1 (954) 555-1234
France 33 06 87 71 23 45
FIGURE 10.21
Local phone number
formats.
FIGURE 10.22
ITU-T E.123 recommendation for formatting national and international
numbers.
FIGURE 10.23
Phone and fax
numbers presented
in this example are
in an international
format.
FIGURE 10.20
Weather information from USA Today (a) shows temperatures in both °F and °C.
Weather.com (b) allows users to switch between “ English ” and “ Metric ” systems because it not
only changes units of measure for temperature but also for wind, pressure, dew point, and visibility.
(b)
(a)
329
Related design patterns
Like other patterns, using localized NUMBER FORMAT requires additional
space, and it’s important that pages use an EXTENSIBLE DESIGN to accom-
modate additional space requirements. In addition, consider using GLOBAL
GATEWAY to capture users ’ region and language preferences and present num-
ber formats accordingly.
CURRENCY AND CURRENCY FORMAT
Problem
Web applications (e.g., e-commerce applications) that show the value of prod-
ucts and services to users in regions around the world need to present prices in
local currencies. However, not only are currencies different around the world,
but their formatting in terms of the symbol and placement are different as well.
Solution
Show users currency in their native formats. In addition, where users may
encounter prices in a currency other than in which they wish to transact, allow
them to change it by specifying either country or desired currency ( Figure 10.24 ).
Currency and Currency Format
FIGURE 10.24
Fontshop shows prices in U.S. dollars ( $ ) (a), but allows users to select a
different country from the country selection menu (b), which changes the currency, in this case,
to Euros (€) (c).
(a)
(b)
(c)
Không có nhận xét nào:
Đăng nhận xét