Some people have used custom locales/custom cultures successfully and others are finding scenarios that don’t work. Feel free to comment about what scenarios work/don’t work for you. I’ll try to update this when I learn about new scenarios.
- Windows XP/Server 2003 and below don’t understand custom locales in native (unmanaged) code.
- Microsoft .Net v1.0/v1.1 don’t understand custom locales on any OS.
- Office doesn’t natively understand custom locales. This can lead to some odd behavior
- LCIDs embedded in documents will all be 0x0c00. Since 0x0c00 isn’t installed on all machines, and is likely different on other machines this will probably have some odd behavior.
- Similarly Office isn’t expecting LCID 0x0c00, so language specific tools like the spell checker may not work.
- Applications that depend on LCIDs may not work as expected. Many work with the 0x0c00 LCID, however that may not be present or may differ on different machines.
- Custom locales/cultures may have unusual values that might confuse logic that expected more traditional values. For example, a locale I have uses “tera’ HH:mm:ss” for its time format. Applications that then try to parse this format sometimes get confused by the extra constant “tera'” string.
- Applications sometimes rely on a hard coded enumeration of locales or locale data. These types of applications are more likely to have problems with custom data.
- ASP.Net applications work with custom cultures, however some users may not be allowed to install custom cultures on their web server. In particular, users hosted by an ISP that hosts several domains on a virtual server are likely to run into problems. A workaround is that if a custom culture is created according to standards with reasonable data and a standard name, and ISP may choose to install that culture(s). Those custom cultures would then be available to all users of the machine.
Things that work:
- Custom cultures behave like other cultures in .Net Framework v2 apps, and many applications that don’t depend on LCIDs work as expected.
- Custom locales work fine as LOCALE_USER_DEFAULT in Windows Vista applications. Many applications work as well as with custom locales as built-in locales. The ones that don’t are usually making data assumptions that aren’t always true.
- ASP.Net applications can use custom cultures, however they must be installed on the host server and are available for all users.
Please let me know of any other cases that you run into, or any workarounds you find. We’re working on some of the known limitations, but some of the issues are complex and will take some time until a full solution is available.