Using .NET to Parse Non-Arabic Numerals is Problematic

Globalization is a really, really big task for any application. You can't simply translate all of your text into a foreign language and call your application perfect. There are a lot of cultural things that you need to take into account. Some of those things are design details such as color changes. For example, a "good luck" color in one culture might be considered a "bad luck" culture in another and you don't want to slather your application with negative connotations before people even start using the software.

The other problem is that not everybody uses the Arabic (0..9) digits to represent numbers. Take, for example, Japanese. While it is quite common to see standard numbers, I've also been told that it is not uncommon to see the Kanji for those numbers as well. Here's a quick example:

521 - This is a pretty standard number, and this number will parse out as an integer by .NET when run through TryParse(). In fact, it'll parse out as a number in any culture (I tried 10 different ones and it worked in each).

五百二十一 - This is the Japanese Kanji representation of the number 521 (written out it would be ごひゃくにじゅういち). Given that .NET has such amazing globalization support already, I fully expected TryParse(), when supplied with a Japanese culture, to return the integer value 521. I was wrong.

Here's the sample code I wrote:

string culture = "ja-JP";
CultureInfo japan = new System.Globalization.CultureInfo(culture);
Thread.CurrentThread.CurrentUICulture = japan;
Thread.CurrentThread.CurrentCulture = japan;                

string input = "五百二十一"; // 521
int x = new int();
Console.Write(input + " is an integer : " +
                int.TryParse(input, 
                System.Globalization.NumberStyles.Any,
                japan.NumberFormat, out x));

Console.WriteLine();
string input2 = "521"; // "baseline" test
int y = new int();
Console.Write(input2 + " is an integer : " +
    int.TryParse(input2,
    System.Globalization.NumberStyles.Any,
    japan.NumberFormat, out y));

I expected to see to outputs of True, but in fact I got an output of False for the Kanji and True for what us folks in the US like to consider "regular" numbers.

Is this a "bug" in the .NET globalization code or an oversight, or did they intentionally choose not to support Kanji and Chinese numeric representations? I would think it would be a terrible oversight if this were the case. If you have any experience with globalization and applications that deal with a lot of numbers supplied by foriegn IMEs and you've got a workaround for this, I'd love to see it.

One theory I have for why it doesn't work is that there are Kanji that aren't actual "digits", they're more like factors. For example, to write the Kanji for 521, you write 5 , then 100, then 2, then 10, then 1. So, your symbols will look like:

5 100 2 10 1

Which is "5 100s, 2 10s, and a 1", or 521. My guess is that this was too much logic (sarcasm) for Microsoft to throw into the number format parser, meaning I'll probably have to do it myself if I want to accept Chinese number symbols as numeric input.

tags: japanese  dotnet  globalization  

links: digg this    del.icio.us    technorati    reddit