You're not my type if you have no culture

by Michael S. Kaplan, published on 2008/09/25 10:01 -04:00, original URI:

This blog is about CultureTypes.

The list can be kind of confusing, perhaps even a bit daunting to people.

But it all makes sense, if you know where it came from.

Thus this blog!

The full list of members of the CultureTypes enumeration are:

Member name Description
NeutralCultures Cultures that are associated with a language but are not specific to a country/region. The names of .NET Framework cultures consist of the lowercase two-letter code derived from ISO 639-1. For example: "en" (English) is a neutral culture.
SpecificCultures Cultures that are specific to a country/region. The names of these cultures follow RFC 4646 (Windows Vista and later). The format is "<languagecode2>-<country/regioncode2>", where <languagecode2> is a lowercase two-letter code derived from ISO 639-1 and <country/regioncode2> is an uppercase two-letter code derived from ISO 3166. For example, "en-US" for English (United States) is a specific culture.
InstalledWin32Cultures All cultures that are installed in the Windows operating system. Note that not all cultures supported by the .NET Framework are installed in the operating system.
AllCultures All cultures that ship with the .NET Framework, including neutral and specific cultures, cultures installed in the Windows operating system, and custom cultures created by the user.

UserCustomCulture Custom cultures created by the user.

ReplacementCultures Custom cultures created by the user that replace cultures shipped with the .NET Framework.

WindowsOnlyCultures Cultures installed in the Windows operating system but not the .NET Framework.

FrameworkCultures Neutral and specific cultures shipped with the .NET Framework.

 Now you will notice that there are two categories there -- the ones supported by the XNA Framework/the Compact Framework, and the ones that are not.

A better way to look at these two categories are the culture types that existed prior to the 2.0 .NET Framework, and the ones added in 2.0.

Now prior to 2.0, the model for the split was as follows:

Note that when .NET 1.0 shipped, based on the Server 2003 data, it was (with one solitary almost entirely unknown exception) a superset of everything else available. Therefore the above model handles the scenarios one might throw at .NET quite well.

Arguing for handling the world of "supported in Windows but not in .NET" would be foolish -- that was an empty set for literally years.

But then XP SP2 and ELKs came, then eventually Vista came.

.NET suddenly had to care about the scenario that never mattered before.

Starting in 2.0, the split between

all had to be there, since there were many potential cases where an application might in theory have to change its behavior.

You know, change it based on what kind of culture is being used.

I have run across such applications in the past so I know they exist, and some of the scenarios are ones that I find totally reasonable

Further reading of random circumstances where this has come up:

You get the point. The consequences if trying to build a Culture architecture that will support all manner of applications running on all kind of version of Windows or hosted in several different versions SQL Server or on several different versions of web server and so on are huge. The current potential available feature set in .NET works with what is there now.

Though the average application never has to really care about any of this.

Hopefully the ones that do will see its designers much happier after they have read this blog. :-)


No character really felt like sponsoring today; I get the feeling they are up to something!

no comments

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.

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