It is all about making sure developers respect the user's preferences

by Michael S. Kaplan, published on 2005/04/11 07:16 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/04/11/407107.aspx

Now this is a topic I have talked about before, so I am going to put a slightly different spin on the issue, this time.

To review, a user can go into Regional Options and make choices about the language they want to use.

Now I could go on forever (hell, I have gone on forever!) about using the NLS APIs to have that setting respected and how it is such a good idea.

Generally speaking, they develop programs that meet requirements, and the "respect user locale" requirement is such a stealth one one that it usually does not show up on the list a developer is working from.

So, put yourself in my shoes. Or the shoes of a developer working on NLS. How do you make sure that the user preferences are going to be respected?

Well, the best way is to make sure that by default the APIs pick up the user preferences. It has to be harder to not get those preferences. And we do that -- all the NLS APIs like GetNumberFormat and GetLocaleInfo require developers to pass the LOCALE_NOUSEROVERRIDE flag explicitly to not get the user's preferences. In the same way, the CultureInfo ctor has a default that picks up that same set of user preferences. Sure, you can explicitly pass false to that UseUserOverride parameter, but the default does not require that.

Now there are people who actually work on .NET who feel that the .NET Framework should have had different defaults here -- better in their mind to go with the locale-insensitive behavior and then make picking up the user settings an "opt-in" process. But such an approach is doomed to be non-intuitive since users who make changes in Regional Options have a realistic expectation that they will be able to see the change picked up. It is the main reason that even the .NET Framework was given mechanisms to pick up these changes -- because people expect to not only make them but to see the results reflected by applications, managed and unmanaged.

So, over the objection of some people, the .NET Framework does the same thing as Windows functions like lstrcmp and lstrcmpi -- it respects the user's setting by the default in comparison, parsing, and formatting. If you are a developer writing code and you want to ignore those settings, you have to explicitly work at it....

Because I am a developer myself, and I know that sometimes the respect must be enforced to make sure developers do it. No offense to the developers (and this does not apply to all of you!) but it applies to enough to make doing it this way a requirement.

This post brought to you by "ܜ" (U+071c, a.k.a. SYRIAC LETTER TETH GARSHUNI)

Yeah like I totally sick of Word always assuming that I want to us US dictionaries no matter how many times I tell it to use UK dictionaries and save the Normal.dot with these settings.

Sometimes, respecting the user’s preferences is bad.

The case is of Excel exporting a worksheet to CSV. One might suppose that CSV means Comma Separated Values. But Excel, when exporting, separates values not with commas but with list separators. And when importing, it expects list separators, so if values in the file are comma-separated and the list separator is not the comma, all the fields get packed into one column.

I consider this a bug in Excel. Because a document exported in one region will not import in another. Or even on the same machine under a different user, who happens to prefer HIRAGANA LETTER YA as his list separator.

I also strongly suspect that the same bug applies to the decimal separator.

Centaur -- this is of course a good time to consider explicitly passing the flag to not use the user overrides. But it is definitely not the default case. :-)

Great Great..... I have been a follower of yours for some time, and found your blog by accident today looking for INSTRREV function that supports bytes not characters. I am totally in awe of your multilanguage exploits. Great Work! and an inspiration to the rest of us wanna be's.

I understand the general idea of getting options from user specific/machine specific settings, but I also agree with the comment about CSV files. CSV means comma separated values. It doesn't mean "machine list separator settings" separated values. I'd be interested to know why Microsoft thought that they'd lookup a separator setting for a file format that's supposed to be separated by commas (hence the extension CSV). Any takers?

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.