A little while ago, I ran across an issue with CultureInfo property, NativeName.
There is a discrepancy between zh-MO NativeName in .NET 1.1 vs. 2.0.
The following:
CultureInfo ci = new CultureInfo("zh-MO");
Console.WriteLine(ci.NativeName);
will return (.NET 2.0):
ci.NativeName "??(???????)" string (NOTE: Unfortunately, it does not look like blog posts here are saved in Unicode or UTF-8. Hence, you will be unable to see the actual characters. I encourage you to try it out in VS2003 and VS2005.
and will return (.NET 1.1):
ci.NativeName "??(??) (???????)" string (NOTE: Unfortunately, it does not look like blog posts here are saved in Unicode or UTF-8. Hence, you will be unable to see the actual characters. I encourage you to try it out in VS2003 and VS2005.
It turns out that the behavior in .NET 2.0 is current as it displays traditional chinese instead of simplified chinese. This is a bug/known issue for .NET 1.1: zh-MO (Macau) should show traditional chinese instead of simplified chinese.
To workaround this, you will have to implement your own NativeName string for zh-MO (Macau). You can choose to use the .NET 1.1 NativeName standard of:
"??(??)(???????)" (NOTE: Unfortunately, it does not look like blog posts here are saved in Unicode or UTF-8. Hence, you will be unable to see the actual characters. I encourage you to try it out in VS2003 and VS2005.
The two characters in bold mean "Traditional". Also, all the characters in the string are "Traditional" characters. .NET 1.1 will have the chinese style in parentheses (traditional vs. simplified) whereas you will notice that .NET 2.0 does not put this in parentheses. However, the characters in the string are representative of its traditional style (vs. simplified style).
Unfortunately, manual intervention/fix is the best solution. The fallback process for zh-MO (Macau) in .NET 1.1 goes to zh-CHS. You can read about CultureInfo Parent and the fallback process here and here. Hope this is of some assistance to anyone else dealing with Globalization.