by Michael S. Kaplan, published on 2010/08/01 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/08/01/10044632.aspx
For a long time, I worked on the NLS Team.
MSDN might claim that NLS stood for National Language Support.
But given how often people take NLS in the direction I mentioned in You work in NLS? How many languages do you speak?, which inspires me to take Cathy's answer and say it really stands for Not Localization, Stupid. :-)
Because people assume that I must be in localization if I do international support.
Now of course it has been many years since I worked on the NLS team, and the NLS team as such is no more. I am on the World-Readiness Team.
Ironically, our reporting structure is such that we report up through the same part of the Windows/Windows Live organization that handles (among other things) localization, so although I am still not a localizer I do work on a team that handles things like localizability and in some sense am on the llocalization team, now.
Kind of a very roundabout application of the "if you can't beat 'em, join 'em!" philosophy, though one has to play fast and loose with the definition of 'em to make it work, and refer to two different groups of people in the two 'em instances.
Now all along, one of the most central issues that comes up when one is looking at bugs is determining where the bug fits in the following categorization:
Now Category #3 only becomes crucial toward the end of a project when it becomes harder to get approval to check in the changes that a bug fix would require if the localizer (who is making changes anyway during the process of localization) cannot work around the bug themselves.
People who do this kind of work all the time get quite good at putting bugs in the correct category.
Like a bug we were looking at the other day that showed the following screenshot:
Everyone kept trying to assign the bug to the localization team, though it clearly was not their bug since different language/locale settings were being used to load resources and provide format information. This is obviously a core bug with different parts of a dialog using different settings.
Now the quiz question for all of you:
Can you determine where each part of the dialog is getting its language/locale information from?
I'll give the answer in a little bit but if you want to make guesses in your head you can see if you were right!
Many possibilities:
Now if there was no bug, the UI language would always come from #3 and the locale used to grab that date/time string would always come from #1.
Given that it is a shutdown dialog it could be coming from a service (one of those session 0 services running under the LocalSystem account), which might force code that cannot get #3 and #1 to instead use #5 and #6.
The settings in this case were:
And despite the people who were so certain that it was a localization bug, this is clearly a core bug in whoever is putting up that dialog, since that code is clearly using the wrong answers to ask its questions of what languages to use for loading resources and what locale to use for formatting....
Of course to know what was actually used, at a minimum you would need to know enough of the language and date/time formatting information to know where the dialog is getting the information from.
Thus it is yet another irony that the person best able to assess where this core bug is getting its info from is a localizer, given how easily they can contact people who speak the various languages. :-)
Pavanaja U B on 1 Aug 2010 9:29 PM:
Instead of World-Readiness, why don't you call it Universe-Readiness? You can add Klingon support to justify the naming. Reecently, there was a report that aliens may be actually trying to contact us using twitter like messages and this must be happening from centuries. If you have Universe-Readyness, we might be able to decipher those messages :)
Michael S. Kaplan on 1 Aug 2010 10:00 PM:
Calling a tail a leg doesn't make it something you can walk on....which is to say, we're not equipped for that universe scenario. More likely we'd let Google jump in first and screw it up on someone's 20% time... :-)
Jody on 1 Aug 2010 10:42 PM:
Now, I really have to ask why, in the "no bug" case does the date come from "Default User Locale" and the body of the dialog come from "Default User UI Language"?
This drives me completely nuts. I live in Finland, but I am not from here originally, so I want my Windows 7 in English. But in order to get the correct currency, etc I set the Windows locale to Finland. And now all the weekdays and dates come up in Finnish! The only way around it is to set Windows to United States for the locale and manually change all the settings to match the Finnish ones.
So, why aren't the date texts dependent on the UI Language? In what situation does it make the any sense to display the dates in a localized language while the rest of the UI is in English?!
Michael S. Kaplan on 1 Aug 2010 10:49 PM:
Because there are more users who have decided over the years to keep some elements in their preferences consistent, dividing them differently than you want them....it is a lose-lose scenario (not as bad as one of those 51% vs 49% things but similar to it) since not everyone can be made happy, though luckily most people have both settings the same, so they never see a problem.