CODEWITHSUNDEEP
c#asp.netlocalization
Akhil
Akhil

Reputation: 2030

Best Approach for Localisation variables

I read more articles related to localization best practices. From them we can identigy that always UTCtime is best for handling date time. Like that we have some guidence like concetenation of string, ui etc.

But i also found one article saying we need to handle string / integer conversion. I din't get it properly. The following is the explanation

"Be sure to always pass CultureInfo when calling ToString() unless it is not supported. That way you are commenting your intents. For example: if you are using some number internally and for some reason need to convert it to string use: 

int i = 42;
var s = i.ToString(CultureInfo.InvariantCulture);

For numbers that are going to be displayed to user use:

var s = i.ToString(CultureInfo.CurrentCulture); // formatting culture used

The same applies to Parse(), TryParse() and even ParseExact() - some nasty bugs could be introduced without proper use of CultureInfo. That is because some poor soul in Microsoft, full of good intentions decided that it is a good idea to treat CultureInfo.CurrentCulture as default one (it would be used if you don't pass anything) - after all when somebody is using ToString() he/she want to display it to user, right? Turn out it is not always the case - for example try to store your application version number in database and then convert it to instance of Version class. Good luck. "

But why this is needed. So in all datatatypes we need to convert / do like this? what is the advatages for this as i got same result as with out adding culture info.

Upvotes: 1

Views: 184

Answers (1)

Sinatr
Sinatr

Reputation: 21989

If you do like this

double i = 42.42;
var s = i.ToString();

and run it on your on English PC (US or UK locale), then s will be

42.42

Now run it on German or Russian PC and suddenly s become

42,42

This different decimal point could lead to countless bugs in many places (when you save/load data, when you show values and reading user inputs, etc).

One possible ultimate solution, if your software will run on different locales, is to use ColtureInfo.InvariantCulture always when you operate with data and only when require user interruction CultureInfo.CurrentCulture.

With int values problem could be with thousands separator (it could be missing, space, comma, point, etc).

I myself create extension methods, something like:

    public static string F(this string @this, params object[] args)
    {
        return string.Format(CultureInfo.InvariantCulture, @this, args);
    }

so that i just write

"{0} {1:0.#}".F(Msg.Localization.User.Prompt, i);

where Msg is a localized messages class.

Upvotes: 1

Related Questions