Sign in to follow this  

[.net] Default language VCS08

Recommended Posts

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:
string floatstring = "0.45f";
float num = float.Parse(floatstring, CultureInfo.Invariant);

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
Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US", false);

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..

Share this post

Link to post
Share on other sites

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.123

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

<globalization culture="en-US" uiCulture="en-US"/>


Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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!

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this