by Michael S. Kaplan, published on 2007/11/18 16:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/11/18/6376418.aspx
Not every experience at Microsoft is a great one from an internationalization standpoint.
Like the other day when I was running a commonly used internal tool and was greeted with the following error message:
Now this did not bother me too much at first.
Because I know my settings are pretty freaking random.
(And also, because the site worked anyway when I ignored the error)
In fact I have no idea what my settings are from day to day -- unless I remember the last bug I have had to take a look at (since that is usually the source of the settings!).
And since these bugs are almost never mine I am simply trying to repro them to find the person who ought to be looking at the problem (if there is one, I mean).
So anyway, judging no one and nothing, I decided to look and see what the settings were in IE at that moment that were breaking this managed application (yes, it is a managed app):
Now I remember the bug I was looking at, and I admit that these would not be the most common settings one might have, but why on earth should THESE settings deserve that mondo error message?
So I decided to try changing the settings to another language, like Tamil.
Same error message, and then the application failed, too (here is a clipped version of what popped up in the browser with Tamil settings -- clipped to avoid revealing what the application is):
There are no words.
Someone reported that the application was requiring en-us settings, so rather than fixing the problem, someone else took the time to add this crappy warning, instead.
We have to do better here, as a company. A process that needs to start from within....
This post brought to you by ⊬ (U+22ac, a.k.a. DOES NOT PROVE)
Dean Harding on 18 Nov 2007 6:13 PM:
Well, you did say it was an internal tool, and 99% of Microsoft employees would be English-speakers, right? Obviously on a for-public-consumption tool that'd be bad, but when you know your audience, it's not such a big deal, don't you think?
(Unless I'm wrong about my 99% assumption, of course...)
Michael S. Kaplan on 18 Nov 2007 6:23 PM:
Well, remembering that, at least in IE, regional options and default user locale control the setting -- and almost no one outside of the US would be likely to have US date format expectations....
Makes this a bit worse in my book. :-(
Dean Harding on 18 Nov 2007 6:41 PM:
Ah, that's true. Actually, when I first saw your post, I didn't get the whole image so I didn't see the "String was not recognised as a valid DateTime" error (Don't know what happened there...)
Jeroen Ruigrok van der Werven on 19 Nov 2007 7:31 AM:
Michael,
try the Visual Basic editor within Office for a world of pain.
See http://www.in-nomine.org/2007/11/04/office-2003-visual-basic-editor-and-applocale/ for a detailed background.
Michael S. Kaplan on 19 Nov 2007 9:48 AM:
Of course that is just the world of a non-Unicode app -- but they are able to deal with things once the code page is set right (via AppLocale or via the default system codepage).
Imagine if it would only be English though -- if Japanese never worked. Ick!
Jeroen Ruigrok van der Werven on 20 Nov 2007 5:30 AM:
Heh, I know what you mean. On my standard XP install I always use NL, EN, CH, JP and KO.
For all my users I install the complete fonts from XP (that asian and whatever option at install time) as well as the Office Unicode/international fonts. With today's hard disk space a few MB for additional language support never hurts.
And Adobe Reader gets installed with the font packs as well.
I just wish such things were becoming more default in applications.