People keep asking questions like “How do I get Latin cultures in .Net?” Well, in Whidbey we’re adding Custom Cultures.
A custom culture is a culture that is created and installed on the system by a user with admin privileges. Once installed custom cultures behave pretty much like any regular cultures and can be requested by at any time by name.
Custom cultures are created and installed using the CultureAndRegionInfoBuilder class. An admin can run an application that uses the CultureAndRegionInfoBuilder to create and install the culture. Presumably an application that required a custom culture could use the CultureAndRegionInfoBuilder if the culture wasn’t present during installation. Alternatively a stand alone culture installer could use the CultureAndRegionInfoBuilder to install one or more cultures. Another possibility would be a culture editor that allowed the registration of custom cultures as an option.
Custom cultures also contain region data for RegionInfo.
Once installed, accessing a custom culture is as trivial as calling new CultureInfo(name) or CultureInfo.GetCultureInfo(name). Region data can by retrieved by using new RegionInfo(name).
Custom culture names should work anywhere a culture name was previously used.
Custom Cultures are mostly just like regular cultures. There are a few differences though:
The big difference is that they are not assigned a unique LCID, so it’s a really good idea to access cultures by name rather than LCID. I’d really recommend that you avoid LCIDs, they aren’t long-term helpful.
Another difference is that custom cultures may not be installed on every machine, but an app could save data that is to be read on a different machine, or make a web service request or whatever. So applications should have a fallback if a culture isn’t available and should persist data in an invariant form rather than a culture dependent form. This isn’t really unique to custom cultures since Windows ELK cultures on XP or Longhorn could offer additional cultures that don’t ship with Whidbey. Machines without those ELKs installed wouldn’t have access to those cultures.
Custom cultures can be different on different machines. I could build a different fj-FJ than you do. Alternatively you could override one of the system cultures, like en-US, with custom data. If I store dates expecting a MM/dd/yyyy form and another machine tries to parse the data as dd/MM/yyyy, then we’ll have a problem. User overrides have a similar problem, but you should always use them. The solution is to store data using the invariant culture, as binary data, or using specific formats that the application provides and knows won’t change.
Custom Cultures could also have data that is outside of parameters that an application expects. For example if you looked at all the current time patterns you could guess that “HH:mm:ss tt” was sufficient and provide a 20 character buffer or so for output. However if some custom culture chose “HH' hours 'mm' minutes 'ss' seconds 'tt'” then 20 characters wouldn’t be enough, and “morning” could be their AM string. That might seem contrived, however some languages may have month or day names, or country names, or whatever, that are much longer than the average in our current data set.
Whidbey supports 4 types of cultures:
This is probably worthy of its own blog entry, but in short culture data is subject to extreme variations and your application shouldn’t rely on consistency. Invariant is the only culture “guaranteed” to not change. Other cultures have in the past changed date formats, number formats, names, month spellings, etcetera. Sometimes this is due to political change, sometimes due to shifts in cultural preferences, and even, perhaps (gasp) bugs in the data. Your application shouldn’t rely on any particular culture’s data not changing, even without custom cultures.
User overrides can also impact culture data. Using user overrides is almost always the right choice. After all, the user overrode it for a reason. Server applications should consider allowing the client to format the data to allow for client preferences. For similar reasons, transmission of data should always use invariant or binary data. Rendering of data would then require reformatting to a user’s culture for display.
Custom Cultures are an exciting new feature that allows lots of often requested functionality. Applications will need to realize that these cultures now allow more choices and customization that were previously allowed and should be robust enough to handle those scenarios.
Remember that culture data can change, which is a good thing and indicates a user preference that should be respected. Since it does change, avoid relying on culture formatting preferences for persisting data that needs to be machine-read and instead use Invariant, binary or other static forms or protocols.