The Microsoft Locale Builder tool is great for building custom locales. In fact it seems to even do things that the CultureAndRegionInfoBuilder (CARIB) itself appears unable to do. The answer is by using Reflection. The behavior I’m describing is all internal to the CARIB and will likely have different behavior in future versions of .Net, so this only applies to .Net Framework v2.0
For example, there’s a Native Language name, however the CARIB doesn’t expose a native Language name. If you look at the output LDML there’s a field <msLocale:nativeLanguage type=”English” /> that provides the native language tag. Using Reflection you can also “see” a NativeLanguage property and m_nativeLanguage variable on CARIB.
In addition to the native language name, there are 2 other odd properties available to reflection. One is String NativeCalendarNames, stored in the m_calendarNames member and the other a bool m_forceWindowsPositivePlus.
NativeCalendarNames is described by tags like <msLocale:calendarNativeName type=”Gregorian Calendar” /> in the LDML. The property is an array of strings where the strings are in the windows calendar id order, see http://windowssdk.msdn.microsoft.com/en-us/library/ms776338.aspx. So NativeCalendarNames is a native name for CAL_GREGORIAN, etc.
The m_forceWindowsPositivePlus is an odd member. In .Net the positive sign is always “+”. In windows it is usually “”. Since the NumberFormatInfo is always returning a +, it is difficult to tell a windows custom locale if you want “” or “+”. This flag is set when the LDML is read. If the LDML is “”, then this will be false and the custom locale will write an empty string to the custom culture file. .Net will still treat the empty string as a “+”, but windows won’t end up prefixing/postfixing everything with a + that wasn’t there before.
In addition to the properties, “How to Save Custom Cultures Without Administrative Privileges” on MSDN discusses using reflection to write a custom culture .nlp file without saving it to the %windir%globalization folder, which requires administrative permissions. This can be used by locale data editors such as the Microsoft Locale Builder tool where creating files without installing them may be interesting.