Client side locale settings on the server?

by Michael S. Kaplan, published on 2005/06/26 21:20 -04:00, original URI:

Recently overheard in the microsoft.public.dotnet.internationalization newsgroup:


I'm developing a web application, in that I have to display the short date according to the customized date format of client machine's culture.

For example Culture = "fr-CA"   and default Short date format =  "yyyy-MM-dd", when you customize the shortdate format to "dd.MM.yy". Then the short date should be displayed in the format "dd.MM.yy" to the client.

I'm able to display the date in the custom short date format while executing through the VS2005 IDE. But after deploying the same web application, the date is displayed only in the default short date format, though the short date format is customized.

A commonly asked question, though unfortunately the answer is not really one that will make peron asking happy -- those settings (basically user overrides) are not available on the server. They are retrieved through a call to the Win32 NLS GetLocaleInfo function (for the short date you would pass the LOCALE_SSHORTDATE flag).

The only piece of information that the server gets related to locale is the HTTP_ACCEPT_LANGUAGE (which, as I mentioned in the article GEOID -- The LCIDs maligned little brother....) is currently based on the user locale. Anyway, right now it is based on the setting that you can set your CurrentCulture to, but there is no way to get the overrides....

Of course if you have a client side component you could send the information to the server but that has all kinds of dependencies on what is running on the client side, which ASP.NET tries to avoid when it can.

Another option is to have UI in the application that allows your users to set their preferred format if they would like to do so. Most users probably would not bother (most users do not change the setting in the Regional and Language Options UI, either) but those who would like to change a setting would probably not mind doing so.

If anyone complains, you can either blame the IETF for not having an HTTP header with the info, or on the makers of all the big browsers for not agreeing on some sort of standard for passing the data. :-)

On a side note, in that post about GEOIDs I meant what I said about the fact that many settings probably should be configured to use the GEOID where they are using an LCID today. That PM (Matt Ayers) is right. I tend to raz Matt a lot because we just have that kind of a relationship, but I do like to give him credit when I think he's right. We really ought be more region based when it makes sense to be so....


This post brought to you by "" (U+2643, a.k.a. JUPITER)

# David on 27 Jun 2005 5:13 AM:

Just one side note here: Outlook Web Access displays its UI in the language that is set on the browser one is using. This is a horribly broken design. Whenever I travel in some foregin country and try to check email from an internet cafe, I get the UI in some language I don't have a clue about. So, just as a general thought: I really believe language choices ought to either be asked from the user, stored in some sort of user profile, but should in most cases NOT depend on the locals of the system someone is using to access a site.

# Michael S. Kaplan on 27 Jun 2005 5:21 AM:

Hi David,

Of course you can go to Tools|Internet Options..., hit the Languages... button, and select the language you want to see it in.

It really does boil down to a problem with no standard for communicating all of the different possible language settings. Just about every product can be said to be broken since they tend to default to using the one setting that is available....

# David on 27 Jun 2005 6:30 AM:

Well, not on a locked down computer in an internet cafe... I agree that the initial language for a web page is difficult to choose, but once any site is in a user context, it should store the language preference for that user and use that.

# CornedBee on 27 Jun 2005 6:33 AM:

To be precise, the value of the Accept-Language HTTP header depends on the browser settings. IE, by default, sends the Windows locale setting, but Mozilla, for example, uses its own internal setting. IE can be overridden as well.

The problem mentioned in the first comment is a result of poor web application design. Locale should of course default to the Accept-Language setting - that's what it's there for. However, every web application should allow the user to override this in their personal account settings.

# Tanveer Badar on 22 Dec 2007 1:06 AM:

There is supposed to be an implementation of <globalization enableClientBasedCulture/> in some future version of netfx. But MSDN says ( this is not in use (read not implemented) at the moment.

go to newer or older post, or back to index or month or day