Culture, Globalization and Headaches: International Application Development

If you will never develop software that is to be used in any location except North America, then no need to read this post. However the reality of the software industry is that the global economy rules and with the internet, even free software has become a global product. Though you may not have immediate plans for releasing your software to other countries that your own, it is prudent to consider globalization in all phases of development.

The application that we are currently working passes XML messages back and forth between processes, computers and servers. When we lined up a beta customer from Germany, we discovered that while we had thought about globalization we didn't realize how deep the hole really was. We always thought that we'd just go back and add other language translations. But it is never that simple is it?

As we've discovered, all communications that can cross language barriers must be done in invariant culture. This is especially important for our product because XML is essentially a big string and strings can be interpreted in different ways in different cultures. By keeping all communication invariant you ensure that things like numbers and dates are interpreted properly when they get to their destinations.

Take the invariant representation of the number 1234.998 for example. In the US english (en-US) culture the numer would be displayed as 1,234.998. In german from Germany (de-DE) the number would be displayed as 1.234,998 (the germans use a "," for the decimal separator and a "." as the thousands separator). Interesting isn't it? One can see how globalization and localization could cause some very serious and big problems. If the number was stored in the en-US culture and then intrepreted in the de-DE culture, the number would possibly become 1.234998 in invariant culture.

Consider globalization and localization at every stage of development. Some c# methods that we've found useful are listed below.

Going from invariant string representation to numbers

public static decimal ParseDecimalInvariant(string value)
{
return decimal.Parse(value, System.Globalization.NumberStyles.Number, System.Globalizaton.CultureInfo.InvariantCulture.NumberFormat);
}
public static double ParseDoubleInvariant(string value)
{
return double.Parse(value, System.Globalization.NumberStyles.Number, System.Globalizaton.CultureInfo.InvariantCulture.NumberFormat);
}
public static int ParseIntInvariant(string value)
{
return int.Parse(value, System.Globalization.NumberStyles.Number, System.Globalizaton.CultureInfo.InvariantCulture.NumberFormat);
}
public static long ParseLongInvariant(string value)
{
return long.Parse(value, System.Globalization.NumberStyles.Number, System.Globalizaton.CultureInfo.InvariantCulture.NumberFormat);
}

Going from numbers to invariant culture string representation

public static GetInvariantString(byte value)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture.NumberFormat);
}
public static GetInvariantString(intvalue)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture.NumberFormat);
}
public static GetInvariantString(long value)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture.NumberFormat);
}
public static GetInvariantString(decimal value)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture.NumberFormat);
}
public static GetInvariantString(double value)
{
return value.ToString(System.Globalization.CultureInfo.InvariantCulture.NumberFormat);
}

Also check out MSDN for info on globalization classes (System.Globalization Namespace) and articles such as this one CLR Inside Out: Windows Vista Globalization Features

Wow. That was long.

Just remember: "You can pay now or you can pay later, but sooner or later you still have to pay."