Cheating to Install Custom Cultures – Updated 20 June 2006

Warning: This technique will make it hard for an installer build by the Microsoft Locale Builder tool to overwrite the locale you’re playing with.  You should use the locale builder installer to install and uninstall locales.  This technique is primarily interesting if you wanted to build a locale as part of another installer or something. 

*** Updated on 20 June 2006 to reflect changes in culture names ***

I’ve noticed some posts and comments about installing (or uninstalling) custom cultures by hand instead of using the CultureAndRegionInfoBuilder.Register() method.  (The Locale Builder beta tool for Vista uses the .Register() method.)  Note that any installation method besides .Register() are unsupported and will break if we change what Register() does, however personally I find this technique much simpler to use.

Also note that Custom Cultures/Locales are only supported by Microsoft .Net Framework v2.0 or Windows Vista or above.  (This won’t work on XP/.Net 1.1)

What some of you have noticed is that custom culture files are installed in %windir%globalization, and labeled with the culture name with a .nlp extension.  Ie: C:WindowsGlobalizationtlh-Latn-US.nlp.  You might be able to determine if a particular version of a custom locale is installed by doing a hash of that file and comparing that to your expected baseline.

In addition to creating this file, Register() makes one registry entry:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNlsCustomLocaletlh-Latn-US is created and set to tlh-Latn-US.

In .Net 2.0 RTM another key was created.  Current versions, including .Net 2.0 with current updates, and .Net 2.0 on Windows Vista or Server 2008 this key is not created or used since the custom locale names are now the same as the IETF names.  See Change in .Net Framework Culture Names for Windows Vista.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlNlsIetfLanguagetlh-Latn-US used created and set to tlh-Latn-US on .Net 2.0 RTM machines only.  It is no longer used as the IETF name property was deprecated and the culture name is now identical to the IETF name.

As with any mucking with the Registry, note that these keys or their values and properties could change or be extended at any time, so the .Register() and .Unregister() methods are the safest (and only supported) way to install a custom culture.

*** 14 May 2009 ***

I just posted the opposite blog, how to uninstall a custom locale

Comments (4)

  1. I don’t normally change existing posts, but I don’t want to be misleading.  With the change of…

  2. Joku says:

    Hello. I could not find article describing the purpose of these files:

    Big5.nlp 66,728 18-Dec-2007 21:06

    Bopomofo.nlp 82,172 18-Dec-2007 21:06

    Ksc.nlp 116,756 18-Dec-2007 21:06

    Normidna.nlp 59,342 18-Dec-2007 21:08

    Normnfc.nlp 45,794 18-Dec-2007 21:08

    Normnfd.nlp 39,284 18-Dec-2007 21:08

    Normnfkc.nlp 66,384 18-Dec-2007 21:08

    Normnfkd.nlp 60,294 18-Dec-2007 21:08

    Prc.nlp 83,748 18-Dec-2007 21:08

    Prcp.nlp 83,748 18-Dec-2007 21:08

    Sortkey.nlp 262,148 18-Dec-2007 21:08

    Sorttbls.nlp 20,320 18-Dec-2007 21:08

    Xjis.nlp 28,288 18-Dec-2007 21:08


    It was interesting that for the older Windows these weren’t listed in the article. What’s the purpose of these and do you happen know why only Vista need these also patched?

  3. Shawn Steele says:

    Well, that’s completely unrelated to this blog post, however those are just international related files that are updated by the patch.  The patch takes earlier patches too, so these aren’t directly related to the KB you’re asking about.  I think if you get the updated .Net that you get all of this anyway.  (SP or something).  I’m not a servicing expert, so don’t quote me on any of this 🙂

  4. In Cheating To Install Custom Cultures , I mentioned how to add the custom cultures without using CultureAndRegionInfoBuilder.Register().