by Michael S. Kaplan, published on 2006/01/29 17:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/01/29/518934.aspx
Someone with the handle of *g* asked in the Suggestion Box:
Hi Michael,
I love your blog and read it regularily, even though my primary work interests are in device automation: simply because yours is one of the most interesting blogs to be had ;)
I am working with devices that store money, and send information on amounts with currency information in isocode. Some tasks here are:
- given an isocode, display an amount e.g. "deposit 123,45 €".
- given an isocode, display a note value: note that commonly (where common is less-than-well-defined as in: western europe and north america), for note values there is no fraction. You don't have a $1,00 bill, you have a $1 bill.
Now, there is always GetCurrencyFormat(). However, I have some problems with it:
- it assumes that I know the lcid; however, the devices I'm working with only send me the isocode an assume (incorrectly, I admit) that e.g. all EUR formatting is the same across all countries
- there is no sufficient discrimination between countries; e.g. if I have CAD and USD, both will show as $.
- for situation (b) above I can only do custom formatting with a CURRENCYFMT structure; plus I need additional "language knowledge" on how bill values are presented to the user.
Your thoughts?
I hope my answer does not cause *g* to find my blog less interesting!
There really is not a mechanism to support what is being asked for here -- because an ISO currency code without the context of a locale does not give enough information to do the formatting (and there is no automatable rule about the common name for curreny notes in any country, though there are patterns there is no way to definitively know what to call the currency short of the actual localization process. This is the problem in the request of the first bullet point -- the formats in different locales is often different, so we can't ever assume that it is not.
The second bullet point is not really a problem if you do know the locale, unless you are trying to equate the currencies of two different locales based on the currency symbol -- which is again a bug in what the software is assuming (a bug which should be fixed right away before it costs people a lot of money!).
When you get down to it, the third bullet point really is talking about a localization issue -- an interesting one, to be sure, but one that is way beyond what the NLS API is designed to handle.
For better or worse, the context of a locale is indeed at the core of NLS support on Microsoft products, and without that context there is no real hope of giving the right results. This particular dependency can lead to other problems which I will talk about soon. :-)
This post brought to you by "ᢨ" (U+18a8, a.k.a. MONGOLIAN LETTER MANCHU ALI GALI BHA)