Try to identify cultures by string name instead of LCID

It is a good idea to avoid using the locale LCID when referring to cultures in .Net.  Instead, use the language tag (e.g. use “en-US” instead of 0x0409). The biggest obvious reason is Custom Cultures.  All custom cultures share the same LCID, so new CultureInfo(custom culture lcid) throws an exception because the framework has no idea which Custom Culture should be loaded.

Even if there’s only 1 custom culture on the machine, the custom culture could be different on different machines.  For example, a client could have a different custom culture than a server, and they’d both use the same LCID.

Even worse, if some machines have a windows language pack installed, they might have locales that aren’t available on other machines.  Users with the 2nd XP ELK may have 046b available to them (Quechua – Bolivia), however those without that ELK could have a custom Quechua – Bolivia.  Hopefully in both cases “qu-BO” would work, assuming the custom culture was constructed correctly, however 046b would fail on the machine without the ELK installed and the custom LCID would fail on all machines.

So the moral is to use locale names instead of LCIDs.  Next question is how to get the name of an existing Culture.  CultureInfo.ToString() is preferred to CultureInfo.Name, but that’s a separate blog entry.


Comments (0)