You'd think the two teams were communicating...

by Michael S. Kaplan, published on 2005/10/15 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/15/481281.aspx

The other day, Murtuza Shakir (an SDET on the Office team here at Microsoft) asked:

GetLocaleInfo accepted LOCALE_SLANGUAGE and returned the localized name. Is there something similar for CultureInfo in System.Globalization?

The LOCALE_SLANGUAGE lctyps is described as:

Full localized name of the language. This name is based on the localization of the product, thus the value changes for each localized version.

Now this is a fascinating question, which has an answer -- the CultureInfo.DisplayName property:

The culture name in the format "<languagefull> (<country/regionfull>)" in the language of the localized version of .NET Framework, where <languagefull> is the full name of the language and <country/regionfull> is the full name of the country/region.

When I answered the question, I described these two properties as being roughly analagous. Now of course, this led Murtuza to ask a perfectly reasonable question:

Thanks for the reply Michael.

"roughly analagous" = Does it always return the same value as for SLANGUAGE? If not , why is the difference?

I guess I did give a leading answer. Perhaps I imagined I'd be writing this up in the blog. :-)

The truth is that they are not always the same, for a myriad of reasons:

they are two entirely different pieces of locale data, internally (SLANGUAGE and SDISPLAYNAME)
they are stored in two different places (one in a .RC file that is built into kernel32.dll, one in the culture data and built into the BCL's resource strings)
they are two different products (Windows and the .NET Framework)
they are produced by two different divisions of Microsoft (Windows vs. Developer Tools)
They are translated by two entrirely different localization teams that handle these two different products
They use two different localization glossaries (since they have different terminologies, this makes some sense)

In fact, the only reason that match more often than they do not is that there is the same general intent in both cases. But there is currently not even a process that gets the original strings coming from the same source, letalone matching up the localized strings....

This of course leads to the subject line (You'd think the two teams were communicating...), which is kind of tongue in cheek since in this case those two teams are actually the same team -- the GIFT team! So perhaps the problem is that we do not talk to ourselves enough?

Ideally these two strings would have the same source and we would work out a process to have the localized strings shared between the two products. We really ought to do that someday, but in the meantime, we just manage to luck out since they really are intended to be the same across the two products. :-)

This post brought to you by "α" (U+03b1, a.k.a. GREEK SMALL LETTER ALPHA)

# Jonathan Wilson on 15 Oct 2005 9:34 PM:

Why does .NET even need its own string resources for this?

Why cant the .NET function just call GetLocaleInfo? (with LOCALE_SLANGUAGE or whatever other flag it needs to pass)

# Michael S. Kaplan on 15 Oct 2005 9:43 PM:

Good question, Jonathan. Remember that the .NET Framework has three things to keep in mind that Windows does not:

1) Neutral cultures
2) Cultures that do not exist on Windows
3) loaclized version of .NET does not have to match localized version of Windows.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

go to newer or older post, or back to index or month or day