Out with the LCIDs, in with the string-based identifiers! Well, mostly. You can still use LCIDs to retrieve data for Windows locales, as before. But as I've mentioned here previously, we've also introduced string-based identifiers and associated APIs that developers can use to retrieve locale data. One major advantage to using these identifiers is that they really open up the world of custom locales. You can now create custom locales with appropriately named identifiers and those identifiers will actually mean something.
The locale identifier strings that we're using follow the IETF standard as closely as possible, which means that we use ISO 639 and 3166 language and region identifiers wherever we can, along with appropriate script tags where relevant. So now you'll be able to use strings like en-US, fr-FR, iu-Cans-CA, etc. to retrieve locale data.
Unfortunately not all of the string identifiers introduced in the parallel APIs in .NET 2.0 follow the IETF standard. For instance, the .NET identifiers placed script name after region name rather than the other way around, so .NET 2.0 has e.g.
rather than e.g.
In order to keep things consistent between Windows and .NET, we've decided to update these identifiers in the version of .NET that will be included with Windows Vista. We plan to release a patch with the new identifiers that will be available to .NET 2.0 installations on downlevel platforms as well so that we can make it easier for developers who are creating managed applications that need to work across Windows versions. Affected identifiers include:
One thing to keep in mind regarding the highlighted entries above is that the CS identifier refers to the now-no-longer region entity Serbia and Montenegro, as Montenegro recently elected to separate from Serbia. The final set of identifiers for the new regions is not yet known, but as soon as the international standards community has reached a decision I will post a further update here.