ORIGINAL QUESTION:
How do global web apps typically handle currency issues? In some
countries, $1,000.00 is one thousand dollars, and in others $1.000,00
means one thousand dollars. Do systems typically use one or the
other approach? Seems like it's hard to use both from a data entry
standpoint, because the system will have difficulty interpreting the
amount. Desktop client-server apps are typically localized for the
currency convention of the user. For global web-apps, is the best
approach to provided location-dependent front-end that do whatever
normalization is necessary before transferring to the back-end?
RESPONSE SUMMARY
For global websites, handle (i.e., accept and display) currency
amounts using one of these three approaches:
1. Require customers world-wide to use the currency-formatting
convention of the host country. E.g., many eCommerce sites based in
the U.S. require dollar amounts to be entered in U.S. format, e.g.,
$2,000.95 (usually with or without the comma).
2. Provide country-specific sites (e.g., Amazon.com vs. Amazon.co.uk
vs. Amazon.fr; Google.com vs Google.co.jp) that each handle money
(and other things, like dates) in the local way. Each
country-specific site has its own back-end servers, because the
inventories and product offerings differ in the different countries.
3. Provide localized front-ends that translate between country
conventions and a location-independent internal data-base format.
This is for situations where all transactions world-wide are
conducted against the same back-end servers. The conversion logic
can be either client-side code or in service-side middleware.
To localize money input fields, you can either accept and display
amounts in text-fields, properly punctuated (e.g., $10,000.00) or you
can break up amount fields so that the punctuation is outside of them
(e.g., $[1000].[00].
One way to find out where people are is to ask them (e.g.,
http://mkp.com). But that usually isn't really necessary, because IP
addresses map pretty well to locations, at least at a gross level
(see http://www.networldmap.com).
For non-monetary issues for international websites, see Jakob
Nielsen's Alertbox: http://www.useit.com/alertbox/20050808.html
INDIVIDUAL RESPONSES
From: "Mark Canlas" <[log in to unmask]>
From a technical standpoint, I don't think either of the values are
difficult for computers to handle, because they are both numerically equal.
They would be stored as 1000.00 in either case, and have a localized viewer
handle the user interaction with the value. Or at least that's how it should
be.
=====================
From: Andrew Krespanis <[log in to unmask]>
Globalized currency tracking requires at least 5 database fields/xml entities:
- Currency Code (US, GBP, AU, etc)
- Deliminator. Are there 'upper and 'lower' currencies? eg: $1.00 =
100c, which is a deliminator of 100. Other countries use deliminators
of 1000 or even 5 [only 2 very small countries], and then there are
currencies such as the Yen, which would have a deliminator of 0.
- The amount we are prepresenting. Whole value, not yet divided by deliminator.
- Currency symbol
- deliminator symbol ( period or comma... or? )
That is the bare minimum. Tracking exchange rates is a more complex exercise.
ZenCart and osCommerce both have feature-rich international currency
support (even if it is a little hard to setup initially)
=======================
From: [log in to unmask]
I actully have a lot of internationalization experience with GUI
apps, but very little with web apps. (Although I have designed a ton
of web apps, this subject has never come up.) So I will be very
interested to hear what the responses are.
It seems to me that the web app will need to ask the user their
country where they are transacting business, and then the web app
will need to be smart enough to know what the currency and numeric
format is for that country. As you no doubt know, this is done in the
Control Panel of the Mac and the PC. (I wonder if its possible for
the web app to query the control panel/OS ?)
In doing a globalization project for Lotus a long time ago, one thing
I learned is that most users don't think of themselves as
international. For example, if everybody in their country expresses
numbers as 1.000.000,00, then that is simply how its done, in their
mind. Even in places like Europe, where languages and customs vary
every few hundred miles, the people tend to see everybody else as
internatiional, not themselves.
What this means is that you will either need to figure out a way to
do it for them without them even knowing about it (Like the control
panel idea) or make it EXTREMELY EXPLICIT, by forcing them to choose
a currency and a numeric format (Note that these are two different
things) before they can complete a transaction. (YOu can make this
easier by dropping a cookie, if they let you.)
==========================
From: "Peter Boersma" <[log in to unmask]>
I've designed systems that were not allowed to fill in information on behalf
of the user, so we could not allow the system to enter the last two digits.
So, we have used:
- either seperate fields for the full amount and remaining parts:
"Enter amount in dollars and cents: $[1000],[00]"
- or an indication (or two) near the field on how to enter:
.cc
"Enter amount $[1000.00]"
(e.g. $ 990.34)
The last version worked better when a lot of amounts need to be entered
precicely and manually.
==========================
From: "Elizabeth J. Pyatt" <[log in to unmask]>
It depends on who your core audience is.
If your audience is primarily from the U.S. and prices are in U.S.
dollars, then it probably makes sense to use U.S. punctuation. See
http://www.amazon.com. You can order from just about anywhere, but
prices are in U.S. dolllars, and the content is oriented for a U.S.
audience.
You do have to watch for NOT overspecifyong name and address
conventions and you shouolld specify international shipping rates,
metric measuresments and so forth, but many people are accustomed to
shopping on a U.S. oriented site.
See Jakob Nielsen's latest column on this -
http://www.useit.com/alertbox/20050808.html
If you are creating separate sites for different countries and
quoting prices in native currency, then it would makse sense to
translate the number formatting. See http://www.amazon.fr/,
http://www.amazon.co.uk. This country to country customaization is
called "localization" because you set the standard based on customer
locality.
====End Original Responses========
Jeff Johnson, Ph.D.
UI Wizards, Inc.
Product Usability Consulting
http://www.uiwizards.com
--------------------------------------------------------------
Tip of the Day: Postings must be in plain text
CHI-WEB: www.sigchi.org/web POSTINGS: mailto:[log in to unmask]
MODERATORS: mailto:[log in to unmask]
SUBSCRIPTION CHANGES & FAQ: www.sigchi.org/web/faq.html
--------------------------------------------------------------
|