string floatstring = "0.45f";
float num = float.Parse(floatstring, CultureInfo.Invariant);
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US", false);
[.net] Default language VCS08
Author
How could I change the default locale used in VCS08?
There are lots of pains involving stuff like converting a floating point string to a type of float because norwegians (most of europe?) use "," as a decimal separator instead of ".".
In order to work that out, I'd have to use someting like this for every conversion:
While the extra parameter is something I can live with, it's annoying to receive exception messages in Norwegian when every other part of my program is in english, including my custom exceptions. It's more of a consistency issue..
I did find some info on this, where I could do something like
but it diddn't have any effect..
Anyhow, if any of you have some solutions or theories, I'd love to hear them! My default GUI language in VCS08 is english..
Hi,
Coming from Germany, I can understand your trouble :-)
Setting the culture of the current thread as you did should work. For example, on my machine the following code works as expected:
Therefore I'm confused why setting the thread's culture in your case did not have any effect.
If your app is a web application, you can use the <globalization> element in web.config to define the culture easily, like
Regards,
Andre
Coming from Germany, I can understand your trouble :-)
Setting the culture of the current thread as you did should work. For example, on my machine the following code works as expected:
// use default culture (in my case, German)var f = float.Parse("1.000,123");Console.WriteLine(f); // prints 1000,123// switch to different culture (here: english)var culture = new CultureInfo("en-US");Thread.CurrentThread.CurrentCulture = culture;Thread.CurrentThread.CurrentUICulture = culture;f = float.Parse("1,000.123"); Console.WriteLine(f); // prints 1000.123Therefore I'm confused why setting the thread's culture in your case did not have any effect.
If your app is a web application, you can use the <globalization> element in web.config to define the culture easily, like
<globalization culture="en-US" uiCulture="en-US"/>Regards,
Andre
I got the impression that Invariant was pretty much en-US already. Is there something specific that should be en-US that isn't?
I recently ran fxCop on a project of mine, and it gave all sorts or warnings for things like int.Parse(number), because it says that you should always include a CultureInfo when doing those parsings. So it's probably a good idea to include a culture info anyway, like int.Parse(number, CultureInfo.Invariant). It would seem to me that setting the thread's culture info might have other ramifications that you may or may not want.
Author
Thank you for your input, guys!
When I tried Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US", false); before my initial post, I only used a SocketException.Message as a testbench.
As Andre is saying, the above code works as intended.
The problem with socketexceptions showing in OS default language is probably something the System.Globalization namespace won't handle in .NET. My guess is that .NET just passes up the underlying WinSock exception instead of processing the error code and give a new exception message based on the Culture setting of the thread running.
If my memory serves correct, it's not *that* many common WinSock errors, so I could probably just check for the errorcodes and show my own custom messages in english.. I also cannot think of any other exception messages that aren't defaulted as english language for me except sockets, so it's probably not a big deal anyway..
About the practice of always overloading a Parse method with a CultureInfo.Invariant.. it's probably a nice habit to have. Since JIT would compile things like this to follow the client machine setting (at least i think it would?) I don't see the potential pitfall for bugs in multinational applications without doing this, but it might be a good reminder to the programmer that he's working with something that is handled differently in different countries and might therefore get unexpected results.
I'm sorry for any dumb theories or bad wording, I've been up all night playing Munchkin, feeling a bit smashed in my head. :-)
Edit: Oh and Kanato, in addition to what I just said, I also agree with what you just said. Changing CultureInfo on a thread level, might have sideeffects lesser .NETers like myself haven't thought about!
When I tried Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US", false); before my initial post, I only used a SocketException.Message as a testbench.
As Andre is saying, the above code works as intended.
The problem with socketexceptions showing in OS default language is probably something the System.Globalization namespace won't handle in .NET. My guess is that .NET just passes up the underlying WinSock exception instead of processing the error code and give a new exception message based on the Culture setting of the thread running.
If my memory serves correct, it's not *that* many common WinSock errors, so I could probably just check for the errorcodes and show my own custom messages in english.. I also cannot think of any other exception messages that aren't defaulted as english language for me except sockets, so it's probably not a big deal anyway..
About the practice of always overloading a Parse method with a CultureInfo.Invariant.. it's probably a nice habit to have. Since JIT would compile things like this to follow the client machine setting (at least i think it would?) I don't see the potential pitfall for bugs in multinational applications without doing this, but it might be a good reminder to the programmer that he's working with something that is handled differently in different countries and might therefore get unexpected results.
I'm sorry for any dumb theories or bad wording, I've been up all night playing Munchkin, feeling a bit smashed in my head. :-)
Edit: Oh and Kanato, in addition to what I just said, I also agree with what you just said. Changing CultureInfo on a thread level, might have sideeffects lesser .NETers like myself haven't thought about!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
