by Michael S. Kaplan, published on 2007/05/17 11:13 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/05/17/2696800.aspx
Brian asks via the Contact link:
I have a quick question about your post
and I must be missing something. I would like to create a custom CultureInfo in memory and maybe save it to disk and I think your solution could do that, but how to load it into a CultureInfo object with out adding a registry key? Thank you for your help.
The post Brian is referring to is Using without registering [the source code], which outlines the technique to make use of the CultureAndRegionInfoBuilder class without requiring administrative permissions on the box one uses for the custom culture creation.
This is very useful when the goal is to create the file on a machine where one does not need to actually use the completed culture, a common design pattern also used in tools like MSKLC.
However, what Brian is looking for is something different -- a way to actually use a custom culture with the CultureInfo class without requiring the culture to be installed on the machine.
This is a feature that is not currently available, though I have talked about the idea before, in posts like Private fonts: for members only, where I mentioned:
As I think about the way that private fonts are implemented in both GDI and GDI+, a possible model for a future version of a "private CultureInfo" seems to emerge.
It is obvious that if you are creating a CultureInfo that can be enumerated and used by everyone on the machine that you should have administrative permissions. But perhaps this model could be used to create a more private CultureInfo for use in a particular application. Just as with the private fonts you could not enumerate them or use them systemwide, but there already is a mechanism to get those things done. Is it something you could use in an application yourself.
Seems like an interesting idea, right?
In my opinion this could be a pretty compelling feature, one that has been requested both by customers like Brian and also by product teams with the notion of "document locales/cultures" like WPF (Avalon) and Word where they would like to have the ability to make use of the functionality without having to install it for all users publicly....
But for the moment that feature is not available. To make use of a custom culture via the CultureInfo class, you must have permission to write the file to the appropriate directory and some info to the registry under HKLM.
You may have some luck in the meantime doing the work manually -- i.e. loading the info/data via the CultureAndRegionInfoBuilder class and making use of it directly (some of the classes within the CultureAndRegionInfoBuilder class are even functional like the DateTimeFormat it has....
I could probably write a more substantive sample of using a "pseudo-culture" built up via this technique if people were interested.
This post brought to you by ช (U+0e0a, a.k.a. THAI CHARACTER CHO CHANG)
# G Rojas on 4 Jun 2007 3:58 PM:
I am investigating using a custom culture to have different strings displayed on our application based on client. I am able to create the custom culture and register it, however the ResourceManager does not seem to read the correct values from the custom culture file (i.e. en-US-XX)? Any ideas on why, or a better solution for this scenario?