by Michael S. Kaplan, published on 2006/05/06 15:41 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/05/06/591631.aspx
Earlier today I talked about Getting the real (localized) name of the keyboard.
In that post, I talked about how the change happened in XP to move from using Layout Text to using Layout Display Name, which on the whole was a good idea (the hard-coded localized strings in the registry being a bad way to manage the names since they would not work well with MUI).
But I didn't mention the way this broke some components, basically anybody who was relying on the Layout Text to represent the localized keyboard name.
Now I don't include the InputLanguage in that category, since although it was technically broken running on XP as compared to running on Windows 2000, even the first version of the .NET Framework could have fixed this problem if it wanted to (it is fixed for version 2.0). But certainly any other application getting keyboard names that are localized is broken since now they will always get English....
(this is an issue I hinted about ages ago in this post)
The same problem happens again in Vista, with the time zone names, stored in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\ on NT-based machines. Each time zone has a Dlt string for daylight savings time and an Std string for standard time.
This is really the same problem all over again, where Pacific Standard Time is given the two strings Pacific Standard Time and Pacific Daylight Time, and then localized in each language SKU. There is even a Display string I forgot to mention, (GMT-08:00) Pacific Time (US & Canada).
Not very MUI-friendly, is it?
So now in Vista these strings will all be in English all the time, and three new values (MUI_Display, MUI_Dlt, and MUI_Std) will contain strings in SHLoadIndirectString-friendly format, so they can be loaded from a DLL.
(As a by-the-way, SHLoadIndirectString is well designed in terms of backcompat since if the string passed in is not in the specific format, the same string is returned -- so people adding their own items will not see anything break!)
So, all is well and good and much more MUI-friendly, though it does mean there will be problems in the BCL time zone sample I mentioned here. Though more importantly, there are all of the appliactions like Microsoft Outlook that depend on the localized strings for their own UI. Oops!
Of course it is not like these applications are using documented means to get at the strings, so although there will of course likely be an effort to shim pre-existing applications, new ones will need to make the change to get the names the new way....
Getting the last few issues related to differences between localized versions and MUI is a very expensive process -- this kind of backcompat issue is just one example of the expense (and much of the Windows project can be thought of as a good negative example on how to not localize software, given how expensive these later fixes can get!).
This post brought to you by "ఈ" (U+0c08, a.k.a. TELUGU LETTER II)
referenced by