by Michael S. Kaplan, published on 2011/01/10, original URI: http://blogs.msdn.com/b/michkap/archive/2011/01/10/10113642.aspx
So the other day someone asked an interesting question of several internationalization experts:
Hi,
We have a requirement in our web application to set the current thread’s “CurrentCulture” as per the following rules: -
• if the browser has a user language set, use it. For this we use Request.UserLanguages
• If the browser does not have a user language set, use the regional settings of the client machine.
But I am not sure how to get the culture of the regional settings of the client machine. I can use JavaScript code window.navigator.userLanguage and get it but not sure how to use this to set the current thread’s “CurrentCulture” on the server side in my base page’s InitializeCulture() method.
I am also using the following web.config entry:
<globalization culture="auto" uiCulture="auto" enableClientBasedCulture="true" />
Maybe it's just me, but I am having trouble with the premise of the question.
First, let's look at the GlobalizationSection.EnableClientBasedCulture property's description:
Gets or sets a value indicating whether the Culture and UICulture properties should be based on the AcceptLanguage header field value that is sent by the client browser.
Okay. So the plan is to do a bunch of work manually.
Work that one also plans to do automatically, since that configuration setting is already going to do it, and the manual code to be written will override that with what theautomatic code was going to do anyway.
This seems like a little bit of over-engineering to me, though the intent is pure and the result is not in fact one that any reasonably minded person could seriously consider to either mildly or intensely incorrect, which makes being overly critical of such a plan, in a larger world containing scenarios, designs, code, and test suites, any which can be entirely devoid of anything useful in either intent or implementation, to be somewhat uncalled for (or perhaps even obnoxious); this is especially true in the given example since perhaps one could (in that manual code) constructively extend the solution to support the occasionally seen notion of multiple accept languages for the "see hoofbeats, expect unicorns" scenario of multiple accept languages where the first language was unrecognized while subsequent languages were not.
Thus, as the previous overly complicated sentence implies, this bit is really not so bad.
In the spirit of constructive criticism, it would be much better to pan the second part of the solution:
If the browser does not have a user language set, use the regional settings of the client machine.
In the default case, the client sends the HTTP_ACCEPT_LANGUAGE that is made up of the user's default locale to the server.
This far-fetched scenario posits that a huge swash of users have managed to choose no language (which actually means they have explicitly removed all languages from their Internet configuration options), and further that these people who have explicitly chosen to divorce their browser of the one default link to their default user locale explicitly desire nevertheless to see the setting used and that this setting should somehow be divined and used.
This seems rather disrespectful of a person's rare apparent (if not clear) desire to not see this setting used.
I mean, we don't know why this rather minuscule percentage of the population would in fact make such a choice, but does it really make sense to ignore the choice?
Why not assume that the lack of an HTTP_ACCEPT_LANGUAGE means that the user is perhaps wanting the sever to use its own preferences, since the user is not stating any of their own?
I don't know what the standard says here, but without a quote in the standard making a claim that such a specific behavior is desired, I myself would rather not make such a change....