How to fix an application that has a problem with decimal separator

Question

This post is about C# and .Net, but some info is valuable for other techonolgies.

Since I can remember, I\'ve been having problems with apps or games that c

Answer 1

There is really no other way to resolve this issue, just fix it in the code.
If you care to run FxCop you would soon learn to always pass valid CultureInfo to every possible ToString() or Parse() method. Frankly, this is the way it should be done, even when you know that CultureInfo.CurrentCulture is used by default.
By always passing IFormatProvider, you are telling other developers:

1. ToString(CultureInfo.CurrentCulture) or Parse(whatever, CultureInfo.CurrentCulture) - this is something end user will see or will be able to enter, so we need to care about his/her cultural background.
2. ToString(CultureInfo.InvariantCulture) or Parse(whatever, CultureInfo.InvariantCulture) - this is something we use internally and it is not meant to be shown to user.

Now, I know it sounds like a lot of work but this is simply something that needs to be done. You might just want to thank some poor soul in Microsoft, who with his/her good intention decided that end user's CurrentCulture is the best default for formatting providers... Obviously, other framework designers who did this in the past were wrong and folks from MS are right, ha? A lot of cash has evaporated because of this stupid, unfixable mistake.

Answer 2

Properly set Thread.CurrentThread.CurrentCulture and you wont have such problems. Read here how to write culture independent code.

EDIT: If you do not have access to the code, you can run the application under a user account which has the expected culture set. For quick access you could create an english user, a german user, a french user..

Answer 3

There isn't a silver bullet here.

Some suggestions:

The invariant culture can be used when dealing with internal data that is stored in a config file. This way no matter what culture the machine is you can read and write your own internal data in a consistent manner.

See here:

http://msdn.microsoft.com/en-us/library/4c5zdc6a.aspx

Other problems deal with something simple as string.ToLower().

Seems innocent enough, until you try to lowercase an English letter than doesn't exist in the current culture. (E.G. Turkish)

In these cases, calling string.ToLower() should be replaced with the culture overload and the current culture or invariant culture should be passed (depending on your situation).

Definately some pitfalls to watch out for.

Answer 4

I feel your pain, the port of RunKeeper to Windows Phone 7 got this wrong, and reported me breaking the speed of light, by a factor of 100 000 last month.

If you are being sloppy you'll run into these problems but for the most part they can be avoided. Strictly speaking you should always present information in it's localized format and then convert it to a culture agnostic or base value when you save it. This way you can always target specific cultures.

The problem I believe many .NET developers run into is that they do not understand that all the default parse methods fallback on the Thread.CurrentThread.CurrentCulture and use a specific number format for that culture and it is the same with dates and time zones.

Something that I might consider doing is to setup a chain of responsibility, one in which I had the culture specific variants queried first and a culture invariant fallback. I'd never mix these but I'd support a culture agnostic default that should work if you adhered to some typical convention (e.g. English number formats). But that might not be the right choice every time, educate you user if they think parsing a mixed numerical format CSV file is a sound thing to do.

Answer 5

In my opinion, the approach should be following:

1. in the internal storage, the numbers are just numbers. so no problem occurs.
2. when parsing input text sources, you should parse them according to the locale the source is created in -- most probably, invariant culture
3. when outputting the values to the user, format them according to the user-preferred locale. in C#, this means maintainging CurrentCulture (not CurrentUICulture, see here why).

This should be relatively simple and cover all the cases.

This all applies to the case when you are the application's author. For others' applications, the respective developers must fix their bugs themselves.