Managing Cultures in a Global Application
I have been doing a lot of work on globalized applications lately and I have learned a lot. I thought I’d try to share some of what I’ve learned with everyone. One of the first issues we ran into was managing formatting of data for different scenarios. Educating developers on which culture to use when is challenging and you end up not having a unified formatting. The pattern we came up with was to create a class which defines the culture to use by scenario.
public static class Cultures
{
public CultureInfo UserFormatCulture { get { return Thread.CurrentThread.CurrentCulture; } }
public CultureInfo UserLanguageCulture { get { return Thread.CurrentThread.CurrentUICulture; } }
public CultureInfo DatabaseCulture { get { return CultureInfo.GetCulture("en-US"); }}
public CultureInfo DirectoryCulture { get { return CultureInfo.GetCulture("en-US"); }}
public CultureInfo DeveloperCulture { get { return CultureInfo.GetCulture("en-US"); }}
}
The UserFormatCulture is the culture used to format numbers, dates, etcetera for display to the user, or to parse information entered by the user. The UserLanguageCulture is used to look up resources in resource files. These two properties simply map to the built-in properties on the current thread used for the same purpose. The DatabaseCulture and DirectoryCulture provide the culture used to read and store data in external systems. This may be en-US or InvariantCulture depending on the system you are using. This was one of the biggest areas our developers made mistakes before we started using this pattern. We had data stored in many cultures and when we read data out of the directory server we’d get parse errors when dates weren’t stored in dd/mm/yyyy format of the user’s culture. Using this pattern makes it easy for even junior developers to use the right culture, and if you ever need to change, you have a centralized place to make the change.
-
Geremy
