As computers are going to be multiligual, therefore the ISO two charachter
of Roman Script may not be acceptable to certin nations, for instance
in my country few people can read the roman script and can understand
it. Therefore they will not like AFs or AFA for Afghanis. But they prepare
full name of Currency in Pashto (Extened Arabic).
This problem can be solved better by UNICODE.
Liwal
----- Original Message -----
From: <addison@globalsight.com>
To: Unicode List <unicode@unicode.org>
Cc: <sc22wg20@dkuug.dk>; <unicode@unicode.org>
Sent: Tuesday, December 21, 1999 2:39 AM
Subject: Re: Where to Add new Currency Sign? -- Cultural adaptability
>
> Alain wrote:
> I have seen but bad usages (including those examples) for this in all
> countries I have visited. Even at **most** foreign currency exchange
> places, affiliates to banks, which are said to be those who use this
> standard.
>
> That said, the approach remains the global solution in principle. But
> education is required. A lot of education. Is it the example of
> culturally-neutral identifier? I don't believe so. Addison, a coding
> specialist, just demonstrated it once more, but he is far to be alone.
>
> Well, Alain is being nice... but there is no excuse for not looking up the
> codes before implementation. I've worked on a few retail systems that use
> ISO 4127 for multicurrency. Yes, the codes are confusing in many cases...
I
> didn't remember the rule when composing the original message and "just
> winged it", which is usually a good way to "eat crow" later.
>
> There are *difficult* issues surrounding multi-currency. Most system
> designers in the U.S. conveniently ignore the issue (you *have* to have
two
> fields: one for the value and one for the currency type---assumptions are
a
> very bad idea), and it is not a good idea to invent your own standards as
> you go along. What you display to the user ("localization") and what you
> actually store *can* be different to reduce confusion, where it makes
> sense. However, ISO 4127 *is* the standard and it makes sense to promote
it
> as such by displaying it.
>
> The problem, typically, if faced by multi-country e-tailers. If your
> company is in Japan (¥ = JPY), with a server in Iowa ($ = USD), warehouse
> in Ireland (£= IEP or ? = EUR), and customer in the Czech Republic (Koruna
> = CSK), what currency do you see? What does each link along the way see?
> How do you pay your shipper? How are each of these formatted? Which credit
> card clearing house do you access? Answers to these questions could cost
> your company a lot of money is currency conversions, customer confusion or
> exchange rate fluctuations.
>
> ISO 4127 is not a panacea, but it provides a way to begin organizing this
> mess. Most implentations end up displaying the currency to end-users
> explicitly spelled out in the currently selected language (ruble is not
> spelled out in Latin characters in Russia! And, as Roozbeh pointed out
> earlier today, not everyone has an explicit currency character already
> extant like $--although it looks like Iran does in that part of this
> thread). One bad assumption is that everyone's "currency character" is one
> character long! Sure, pounds and dollars and yen and won all have symbols.
> But francs typically use two. And position varies. An "internationalized"
> interface can use ISO 4127 in a pull down box to the left/right of the
> value on screen (or in reports) to escape from the variable length and
> format problem (at least a little). Of course, there is still the question
> of numeric format... What's ¥0.01?
>
> Some globalization issues are not as easy as they look!
>
> thanks,
>
> Addison
>
> Addison P. Phillips
> Senior Globalization Consultant
> Global Sight Corporation
>
> mailto:addison@globalsight.com
> ================================
> 101 Metro Drive, Suite 750
> San Jose, California 95110 USA
> (+1) 408.350.3649 - Phone
> http://www.globalsight.com
> ================================
>
> Going global with your web site? Global Sight provides Web-based
> software solutions that simplify the process, cut costs, and save time.
>
>
>
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:56 EDT