For example, to format a currency in Java to a locale, you do:
NumberFormat fmt = NumberFormat.getCurrencyInstance(locale);
return fmt.format(amount);
Unfortunatekly, if your product is in USD and the customer is coming
from France, the Java way has you quoting the price in FF! The Euro
only makes things worse, where prices are generally going to be in
euros but the locale-based formatting will display the price in the
local currency--gives Italians a great bargain.
Anyone have a workaround for this?
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie."
-Orson Welles
> One of the places I feel Java has missed the boat on localization is
> currency formatting. Specifically, rarely do you want to just blanket
> format an amount to someone's locale. You want to format an amount of
> a currency to someone's locale.
>
> For example, to format a currency in Java to a locale, you do:
>
> NumberFormat fmt = NumberFormat.getCurrencyInstance(locale);
>
> return fmt.format(amount);
>
> Unfortunatekly, if your product is in USD and the customer is coming
> from France, the Java way has you quoting the price in FF! The Euro
> only makes things worse, where prices are generally going to be in
> euros but the locale-based formatting will display the price in the
> local currency--gives Italians a great bargain.
>
> Anyone have a workaround for this?
Hmm. You're saying "If I use the default Locale for formatting,
it will show my values in the user's local currency! How do I
get it to show always in dollars (or whatever)?"
If I understand your question, the answer is easy: instantiate
your NumberFormat with a US Locale, if you want it to use US
values.
Or is that too obvious? :-)
--
Kevin Kelley http://www.ruralnet.net/~kelley/
Starlight Software Co. http://www.kevin-kelley.com/
I find it very confusing to see "," used as decimal point character,
and I assume someone who is used to that would find "." equally
confusing, so simply displaying the amount in the home locale of the
currency would not be very user friendly.
Patricia
:> One of the places I feel Java has missed the boat on localization is
:> currency formatting. Specifically, rarely do you want to just blanket
:> format an amount to someone's locale. You want to format an amount of
:> a currency to someone's locale.
:>
:> For example, to format a currency in Java to a locale, you do:
:>
:> NumberFormat fmt = NumberFormat.getCurrencyInstance(locale);
:>
:> return fmt.format(amount);
:>
:> Unfortunatekly, if your product is in USD and the customer is coming
:> from France, the Java way has you quoting the price in FF! The Euro
:> only makes things worse, where prices are generally going to be in
:> euros but the locale-based formatting will display the price in the
:> local currency--gives Italians a great bargain.
:>
:> Anyone have a workaround for this?
: Hmm. You're saying "If I use the default Locale for formatting,
: it will show my values in the user's local currency! How do I
: get it to show always in dollars (or whatever)?"
: If I understand your question, the answer is easy: instantiate
: your NumberFormat with a US Locale, if you want it to use US
: values.
: Or is that too obvious? :-)
It is wrong :) I do not want to display $5.25 to a French user who
should see $5,25. There are also issues regardng the display of
negative amounts in addition to decimal formatting.
I think this creates all the desired characteristics for international
currency formatting in the locales with which I am familiar.
Regards,
Mark Thornton
In article <369DFCB6...@acm.org>, pa...@acm.org (Patricia Shanahan)
wrote:
> I think what is being asked for here is the ability to use the locale
> conventions for decimal point and grouping characters but use a
> specified currency symbol, and presumably that currency's convention
> for number of digit after the decimal point?
>
> I find it very confusing to see "," used as decimal point character,
> and I assume someone who is used to that would find "." equally
> confusing, so simply displaying the amount in the home locale of the
> currency would not be very user friendly.
>
> Patricia
>
>
> Kevin Kelley wrote:
> >
> > George Reese <bo...@imaginary.com> wrote:
> >
> > > One of the places I feel Java has missed the boat on localization is
> > > currency formatting. Specifically, rarely do you want to just
> > > blanket
> > > format an amount to someone's locale. You want to format an amount
> > > of
> > > a currency to someone's locale.
> > >
> > > For example, to format a currency in Java to a locale, you do:
> > >
> > > NumberFormat fmt = NumberFormat.getCurrencyInstance(locale);
> > >
> > > return fmt.format(amount);
> > >
> > > Unfortunatekly, if your product is in USD and the customer is coming
> > > from France, the Java way has you quoting the price in FF! The Euro
> > > only makes things worse, where prices are generally going to be in
> > > euros but the locale-based formatting will display the price in the
> > > local currency--gives Italians a great bargain.
> > >
> > > Anyone have a workaround for this?
> >
> > Hmm. You're saying "If I use the default Locale for formatting,
> > it will show my values in the user's local currency! How do I
> > get it to show always in dollars (or whatever)?"
> >
> > If I understand your question, the answer is easy: instantiate
> > your NumberFormat with a US Locale, if you want it to use US
> > values.
> >
> > Or is that too obvious? :-)
> >
> It is wrong :) I do not want to display $5.25 to a French user who
> should see $5,25. There are also issues regardng the display of
> negative amounts in addition to decimal formatting.
Actually the French user should get USD5,25 --- otherwise how could they
distinguish between all the varieties of $ (Australian, Canadian, New
Zealand, ...).
Now would a Portuguese user expect to see 5$25 USD or 5,25 USD ...
Mark Thornton
It depends on the environment and still does not work for the Euro.
If all prices are listed in USD, then the site likely will be showing
$5,25 and not USD5,25 simply because you have to write stupid code
logic to determine which currency symbol you want. Not to mention
that there is no good technique for international formatting of
currencies.
Mark Thornton <mth...@cix.compulink.co.uk> wrote:
: One solution would be to obtain a currency instance for the locale of the
: Regards,
: Mark Thornton
:>
> I think what is being asked for here is the ability to use the locale
> conventions for decimal point and grouping characters but use a
> specified currency symbol, and presumably that currency's convention
> for number of digit after the decimal point?
>
> I find it very confusing to see "," used as decimal point character,
> and I assume someone who is used to that would find "." equally
> confusing, so simply displaying the amount in the home locale of the
> currency would not be very user friendly.
You're right; I guess I outsmarted myself on this one. The
getCurrencyInstance(locale) seems to be conflating two concepts into
one: the currency in which to display a numeric value, and the
formatting (such as thousands separator) to apply to the values within
that currency. I don't see how to fix it without making it even more
complicated, though.
The currency instance could for example want to format the value into
pounds, shillings, pence, say; then the number of pounds would need
to have the appropriate number-formatting (thousands separator) applied.
Why does life have to be so complicated? :-)
I asked myself this question a few months ago. Good question! But
I found Java's NumberFormat class up to the job.
Depending on whether you want to work with primitive doubles or
BigDecimals (or even IBM's new BigDecimal class), the code that
does all conversions and formatting can be downloaded from:
http://www.jps.net/adahlman/programs
To see how well Java can format currencies in 73 language/locales
(as of release level 1.1.6) see the applet at:
http://www.jps.net/adahlman/programs/Currencies.html
The source code for CurrencyDecimal and BDFormat are there, too,
so you can see right away how easy it is to do. After looking
at that, please let me know what else you require.
- Tony Dahlman
George Reese wrote:
>
> One of the places I feel Java has missed the boat on localization is
> currency formatting. Specifically, rarely do you want to just blanket
> format an amount to someone's locale. You want to format an amount of
> a currency to someone's locale.
>
> For example, to format a currency in Java to a locale, you do:
>
> NumberFormat fmt = NumberFormat.getCurrencyInstance(locale);
>
> return fmt.format(amount);
>
> Unfortunatekly, if your product is in USD and the customer is coming
> from France, the Java way has you quoting the price in FF! The Euro
> only makes things worse, where prices are generally going to be in
> euros but the locale-based formatting will display the price in the
> local currency--gives Italians a great bargain.
>
> Anyone have a workaround for this?
>
Regards
Mark Thornton
In article <EYsn2.4936$TO5.1...@ptah.visi.com>, bo...@imaginary.com
Tony Dahlman <adahlman-d...@jps.net> wrote:
: Hi George -
For example, if the general ledger cash account has a balance of
$2,865, the data typically would be stored as the long integer
286500. You could obtain formatters for the default US locale and
the French locale like this:
CurrencyDecimal cd = new CurrencyDecimal(); // default locale
long balance = 286500;
Locale loc_fr = new Locale("fr","FR"); // French locale
CurrencyDecimal cd_fr = new CurrencyDecimal(loc_fr);
double francsPerDollar = 5.6755;
long balance_fr = cd_fr.roundInternalDouble(francsPerDollar *
balance);
Now you can output the balances like this:
String output_us = "101 Cash - US "
+ cd.displayAsCurrency( balance, 20 );
String output_fr = " - FR "
+ cd_fr.displayAsCurrency( balance_fr, 20);
which gives output like this:
101 Cash - US $2,865.00
- FR 16 260,31 F
---------------------------------------------------------------------
BTW, apologies for the broken links to the .java files on that
page. I'll try to fix those today. ;)
-Tony
Tony Dahlman <adahlman-d...@jps.net> wrote:
: And here's some code and output that shows how easily Java
I think this is where the confusion comes in. You keep saying
currency. What you want is specific currency symbol (e.g. USD$)
independent of locale, the currency symbol is placed in the locale
specific format, then format amount in locale specific format.
All these can be done if CurrencyFormat takes a separate "Currency
Locale" thingy along with the Locale (instead of lumping them together
in one). I think this can only be done by modifying the
CurrencyFormat class.
But like you said, what is Euro? Can this be just another Locale for
Currency purpose only? Is there one defined already?
On Fri, 15 Jan 1999 16:28:48 GMT, George Reese <bo...@imaginary.com>
wrote:
English (United States)............USD$2,865.34 <<--- this
amount displayed in very other locale:
Arabic (United Arab Emirates)......USD$ 2,865.34
Arabic (Bahrain)...................USD$ 2,865.34
Arabic (Algeria)...................USD$ 2,865.34
Arabic (Egypt).....................USD$ 2,865.34
Arabic (Iraq)......................USD$ 2,865.34
Arabic (Jordan)....................USD$ 2,865.34
Arabic (Kuwait)....................USD$ 2,865.34
Arabic (Lebanon)...................USD$ 2,865.34
Arabic (Libya).....................USD$ 2,865.34
Arabic (Morocco)...................USD$ 2,865.34
Arabic (Oman)......................USD$ 2,865.34
Arabic (Qatar).....................USD$ 2,865.34
Arabic (Saudi Arabia)..............USD$ 2,865.34
Arabic (Sudan).....................USD$ 2,865.34
Arabic (Syria).....................USD$ 2,865.34
Arabic (Tunisia)...................USD$ 2,865.34
Arabic (Yemen).....................USD$ 2,865.34
Byelorussian (Belarus).............USD$2 865,34
Bulgarian (Bulgaria)...............USD$2 865,34
Catalan (Spain)....................USD$ 2.865
Czech (Czech Republic).............2 865,34 USD$
Danish (Denmark)...................USD$ 2.865,34
German (Austria)...................USD$ 2.865,34
German (Austria,Euro)..............USD$ 2.865,34
German (Switzerland)...............USD$ 2'865.34
German (Germany)...................2.865,34 USD$
German (Germany,Euro)..............2.865,34 USD$
German (Luxembourg)................2.865,34 USD$
German (Luxembourg,Euro)...........2.865,34 USD$
Greek (Greece).....................2.865,34 USD$
English (Australia)................USD$2,865.34
English (Canada)...................USD$2,865.34
English (United Kingdom)...........USD$2,865.34
English (Ireland)..................USD$2,865.34
English (Ireland,Euro).............USD$2,865.34
English (New Zealand)..............USD$2,865.34
English (South Africa).............USD$ 2,865.34
Spanish (Argentina)................USD$2.865,34
Spanish (Bolivia)..................USD$2,865.34
Spanish (Chile)....................USD$2.865,34
Spanish (Colombia).................USD$2,865.34
Spanish (Costa Rica)...............USD$2,865.34
Spanish (Dominican Republic).......USD$2,865.34
Spanish (Ecuador)..................USD$2,865.34
Spanish (Spain)....................2.865,34 USD$
Spanish (Spain,Euro)...............2.865,34 USD$
Spanish (Guatemala)................USD$2,865.34
Spanish (Honduras).................USD$2,865.34
Spanish (Mexico)...................USD$2,865.34
Spanish (Nicaragua)................USD$2,865.34
Spanish (Panama)...................USD$2,865.34
Spanish (Peru).....................USD$2.865,34
Spanish (Puerto Rico)..............USD$2,865.34
Spanish (Paraguay).................USD$2.865,34
Spanish (El Salvador)..............USD$2,865.34
Spanish (Uruguay)..................USD$ 2.865,34
Spanish (Venezuela)................USD$2.865,34
Estonian (Estonia).................2 865,34 USD$
Finnish (Finland)..................2 865,34 USD$
Finnish (Finland,Euro).............2 865,34 USD$
French (Belgium)...................2.865,34 USD$
French (Belgium,Euro)..............2.865,34 USD$
French (Canada)....................2 865,34 USD$
French (Switzerland)...............USD$ 2'865.34
French (France)....................2 865,34 USD$
French (France,Euro)...............2 865,34 USD$
French (Luxembourg)................2 865,34 USD$
French (Luxembourg,Euro)...........2 865,34 USD$
Croatian (Croatia).................USD$ 2.865,34
Hungarian (Hungary)................USD$2 865,34
Icelandic (Iceland)................2.865,34 USD$
Italian (Switzerland)..............USD$ 2'865.34
Italian (Italy)....................USD$ 2.865
Italian (Italy,Euro)...............USD$ 2.865,34
Hebrew (Israel)....................2,865.34 USD$
Japanese (Japan)...................USD$2,865.34
Korean (South Korea)...............USD$2,865
Lithuanian (Lithuania).............2.865,34 USD$
Latvian (Lettish) (Latvia).........2 865,34 USD$
Macedonian (Macedonia).............USD$ 2.865,34
Dutch (Belgium)....................2.865,34 USD$
Dutch (Belgium,Euro)...............2.865,34 USD$
Dutch (Netherlands)................USD$ 2.865,34
Dutch (Netherlands,Euro)...........USD$ 2.865,34
Norwegian (Norway).................USD$ 2 865,34
Norwegian (Norway,Nynorsk).........USD$ 2 865,34
Polish (Poland)....................2 865,34 USD$
Portuguese (Brazil)................USD$ 2.865,34
Portuguese (Portugal)..............2.865$34 USD$
Portuguese (Portugal,Euro).........2.865$34 USD$
Romanian (Romania).................2.865,34 USD$
Russian (Russia)...................2 865,34USD$
Serbo-Croatian (Yugoslavia)........USD$ 2.865,34
Slovak (Slovakia)..................2 865,34 USD$
Slovenian (Slovenia)...............USD$ 2.865,34
Albanian (Albania).................USD$2.865,34
Serbian (Yugoslavia)...............USD$ 2 865,34
Swedish (Sweden)...................2 865,34 USD$
Thai (Thailand)....................USD$2,865.34
Turkish (Turkey)...................2.865,34 USD$
Ukrainian (Ukraine)................2.865,34 USD$
Chinese (China)....................USD$2,865.34
Chinese (Hong Kong)................USD$2,865.34
Chinese (Taiwan)...................USD$2,865.34
Here is the code:
import java.util.*;
import java.text.*;
public class CurrencyFormat {
public static void main(String[] arg) {
double dollarAmount = 2865.34; // USD$ amount
DecimalFormatSymbols currencySymbols = new
DecimalFormatSymbols(Locale.US);
Locale[] locales = NumberFormat.getAvailableLocales();
for (int i = 0; i < locales.length; ++i) {
if (locales[i].getCountry().length() == 0) {
// skip language-only
continue;
}
System.out.println(formatCurrency(dollarAmount,
currencySymbols, locales[i]));
}
}
/**
* Format a currency amount in a designated denomination locale
but displays in
* according to the displayLocal
* Just a kludge to show it can be done.
*/
private static String formatCurrency(double value,
DecimalFormatSymbols currencySymbols, Locale displayLocale) {
// this is the only way I can find to get the locale
specfic
// currency pattern.
ResourceBundle resource = ResourceBundle.getBundle
("java.text.resources.LocaleElements", displayLocale);
String[] numberPatterns =
resource.getStringArray("NumberPatterns");
// look for the currency sign to fixed up
// to show international currency symbol.
int moneySignAt = numberPatterns[1].indexOf('\u00A4');
String pattern = numberPatterns[1].substring(0, moneySignAt) +
"\u00A4\u00A4" +
numberPatterns[1].substring(moneySignAt);
DecimalFormatSymbols symbols = new
DecimalFormatSymbols(displayLocale);
// fix up the currency symbols to the currency locale
symbols.setCurrencySymbol(currencySymbols.getCurrencySymbol());
symbols.setInternationalCurrencySymbol(currencySymbols.getInternationalCurrencySymbol());
DecimalFormat df = new DecimalFormat(pattern, symbols);
return justify(displayLocale.getDisplayName()) +
df.format(value);
}
private static String justify(String s) {
StringBuffer buf = new StringBuffer(s);
for (int i = 0, end = 35 - s.length() ; i < end ; i++) {
buf.append(".");
}
return buf.toString();
}
}
>Patricia Shanahan <pa...@acm.org> wrote:
>> I think what is being asked for here is the ability to use the locale
>> conventions for decimal point and grouping characters but use a
>> specified currency symbol, and presumably that currency's convention
>> for number of digit after the decimal point?
>>
>> I find it very confusing to see "," used as decimal point character,
>> and I assume someone who is used to that would find "." equally
>> confusing, so simply displaying the amount in the home locale of the
>> currency would not be very user friendly.
>You're right; I guess I outsmarted myself on this one. The
>getCurrencyInstance(locale) seems to be conflating two concepts into
>one: the currency in which to display a numeric value, and the
>formatting (such as thousands separator) to apply to the values within
>that currency. I don't see how to fix it without making it even more
>complicated, though.
As a concrete example of the problem we are trying to solve, consider
the following chat between me in the USA and my imaginary friend
Pierre in Paris:
Pierre: Mike, how much does a Quarter Pounder with Cheese Extra-Value
Meal cost where you live?
Me: It costs $3.77 here.
Pierre: I don't understand. Could you use the French formatting rule?
Me: OK. It costs 3,77 $ here. How much is it there?
Pierre: It costs 8,73 FF here.
Me: I don't understand. Could you use the American English rule?
Pierre: OK. It costs FF 8.73 here.
Me: I think you made that up.
How do we get Java to produce "3,77 $" and "FF 8.73"?
--
Michael Malak | 1. All syllogisms have three parts.
mal...@rpi.edu | 2. Therefore, this is not a syllogism.
mY wrote:
>
> Is this what you want?
>
> English (United States)............USD$2,865.34 <<--- this
> amount displayed in very other locale:
>
...
> Japanese (Japan)...................USD$2,865.34
> Korean (South Korea)...............USD$2,865
> Lithuanian (Lithuania).............2.865,34 USD$
Bug in the South Korean display among others. You need to get the
number of decimal places from the currency's locale, not the number
formatting locale.
Patricia
It looks like the answer is that Sun fell asleep at the wheel on this
localization issue.
Cool code though! Thanks!
mY <being...@hotmail.com> wrote:
: Is this what you want?
: Here is the code:
: import java.util.*;
: import java.text.*;
: symbols.setCurrencySymbol(currencySymbols.getCurrencySymbol());
: }
: }
You should blame Taligent -- the Pink, OpenDoc people. Could it be
that they never use this stuff for any real world app?
I think the fix could be to create a Currency concept(just the
monetary symbols) that you can "intall" into a Locale. This way, you
can "use" EURO, Pound or USD$ all in the same locale. Each Locale can
have one or more "navtive" currency defined, this will take care of
the EURO situation. When you want to use one currency from one Locale
to another, all you have to do is take the Currency and "install" it
in the second Locale.
On Sat, 16 Jan 1999 05:47:06 GMT, George Reese <bo...@imaginary.com>
wrote:
>Heh, well, I had thought up this solution, but it is quite kludgy :) I
On Sat, 16 Jan 1999 17:57:29 GMT, in <36a0ce0f...@news1.ibm.net>
being...@hotmail.com (mY) wrote.....
> >It looks like the answer is that Sun fell asleep at the wheel on this
> >localization issue.
>
> You should blame Taligent -- the Pink, OpenDoc people. Could it be
> that they never use this stuff for any real world app?
The same folks who brough us the overly elaborate Calendar
class. It figures. However, I'd still assign some blame to
Sun for lax oversight of the design.
-- PGPfingerprint: BC01 5527 B493 7C9B 3C54 D1B7 248C 08BC --
_______ {pegwit v8 public key =581cbf05be9899262ab4bb6a08470}
/_ __(_)__ ___ ___ {69c10bcfbca894a5bf8d208d001b829d4d0}
/ / / / _ \/ -_|_-< www.geocities.com/SiliconValley/1394
/_/ /_/_//_/\__/___/@windsong.demon.co.uk PGP key on page
### end pegwit v8 signed text
528ae1644acf272aa91a786459f8cc2d882ea4653356b04f817f159c8c3d
bc116ff745c1f4437d22bf1d002ea6b0c974d63f4da24f0b4915780a3095
Maybe you should experiment with this.
Regards,
John O.
Patricia Shanahan wrote:
> I think what is being asked for here is the ability to use the locale
> conventions for decimal point and grouping characters but use a
> specified currency symbol, and presumably that currency's convention
> for number of digit after the decimal point?
>
> I find it very confusing to see "," used as decimal point character,
> and I assume someone who is used to that would find "." equally
> confusing, so simply displaying the amount in the home locale of the
> currency would not be very user friendly.
>
> Patricia