by Michael S. Kaplan, published on 2011/05/04 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/05/04/10160919.aspx
It is time to come clean.
Those two blogs about questions Tom was asking me (Sometimes the things that used to be different aren't anymore and Leave it to Microsoft to take the most confusing thing and make it worse!)?
Well, it was just one email that he sent.
And that one email actually had three questions in it.
The only way I can get away with stretching one email with three questions into three separate blogs is that Tom only asks hard questions that have really complicated histories and underscore serious issues (I assume he figures the easier stuff out on his own, or that he knows it already!).
Anyway, without further adieu, I give you question number three:
Why do we have LOCALE_SENGCURRNAME and LOCALE_SNATIVECURRNAME, but not have LOCALE_SCURRNAME?
Oh boy.
Let's first jump into the whole area of some of the name properties we store in locales.
There are a few major ones I'm going to discuss here now:
And there are three potential items that can exist of each of them:
Okay, so let's look at the grid here:
| Native name | English name | Localized name | |
| Display Name | LOCALE_SNATIVEDISPLAYNAME | LOCALE_SENGLISHDISPLAYNAME | LOCALE_SLOCALIZEDDISPLAYNAME (aka LOCALE_SLANGUAGE) |
| Language | LOCALE_SNATIVELANGUAGENAME (aka LOCALE_SNATIVELANGNAME) |
LOCALE_SENGLISHLANGUAGENAME (aka LOCALE_SENGLANGUAGE) |
|
| Region/Country | LOCALE_SNATIVECOUNTRYNAME (aka LOCALE_SNATIVECTRYNAME) |
LOCALE_SENGLISHCOUNTRYNAME (aka LOCALE_SENGCOUNTRY) |
LOCALE_SLOCALIZEDCOUNTRYNAME (aka LOCALE_SCOUNTRY) |
| Currency | LOCALE_SNATIVECURRNAME | LOCALE_SENGCURRNAME | not available, and we don't have it |
| Calendar | CAL_SCALNAME | not available, but we have it |
Kind of available, sometimes |
POP QUIZ: Even the native name have some locale specific issues. Do you know what they are?
Now perhaps it would be even more interesting if I added a third dimension, indicating the "source product" (the display name concept was first regularized in .Net and was only "imported" into Win32 when they started working to share data better. That dimension would better identify items added specifically for the sake of parity between native and managed code.
And then a fourth dimension could be added describing where each item is used in Windows, if any (some were added only to complete grids like the one above).
Of course you would then be quite distracted by how I was able to give you a four dimensional representation in a two-dimensional web browser without requiring special glasses or screens.And you wouldn't be reading very carefully!
None of this gets into the core issue of why this information is considered important to have.
Like all the "English" constants are a very useful fallback for "ANSI" applications, since even the localized name a given UI language does not have to be well-represented by default system locale. Though the English name is always "safe" in that case.
And that the grid of languages that have a translation for every other country name and language name is more filled in than the same grid looking at currency names.
And that grid, in turn, is much more filled in than the same grid for calendar names.
We could obviously full in English names for the calendars ourselves if we wanted to -- every calendar has an English name, one that we use in the comments surrounding the calendar's data and it is used to form the constants for the given calendar's CALTYPE.
I suppose we don't because no one is asking for it. Or not enough people are. Maybe the people are simply don't manage to sound convincing enough (sounds like a weak justification if one can't convince the addition of one constant, a small number of strings, and a tiny bit of code!).
The issue with only the "native" name being available for calendars is one I also talk about in The example was wrong, but the point of the example was spot on! and that issue is one that haunts us now and will haunt us even more in the future. If it isn't addressed, I mean.
Anyway, thinking about the big grid, all of this blather leaves us with the currency names.
Yes, it is true that not every language has a name for every currency. But many do.
The real question is where we would use it. I mean, in Windows UI. After all, in Windows, where our cross-language currency story is so terrible, doing a bunch of work to better support the naming scheme of cross-language currency values would simply highlight how much we don't do for the currencies themselves!
You may be willing to accept my de facto explanation for why this may be the case, even if you think it's dumb. Though you may wonder why I'm writing about it here.
If that is the case then you probably don't know me very well; I too think it's dumb to not do some work here, and I don't tend to be afraid to say such things in this Blog! :-)
referenced by