CHI-WEB Archives

ACM SIGCHI WWW Human Factors (Open Discussion)

CHI-WEB@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Johnson <[log in to unmask]>
Reply To:
Jeff Johnson <[log in to unmask]>
Date:
Wed, 17 Aug 2005 10:24:55 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (165 lines)
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
    --------------------------------------------------------------

ATOM RSS1 RSS2