The community is working on translating this tutorial into Romanian, but it seems that no one has started the translation process for this article yet. If you can help us, then please click "More info".
If you are fluent in Romanian, then please help us - just point to any untranslated element (highlighted with a yellow left border - remember that images should have their titles translated as well!) inside the article and click the translation button to get started. Or have a look at the current translation status for the Romanian language.
If you see a translation that you think looks wrong, then please consult the original article to make sure and then use the vote button to let us know about it.
Please help us by translating the following metadata for the article/chapter, if they are not already translated.
If you are not satisfied with the translation of a specific metadata item, you may vote it down - when it reaches a certain negative threshold, it will be removed. Please only submit an altered translation of a metadata item if you have good reasons to do so!
The time where you created a piece of software to be executed on just a couple of local computers are pretty much gone. Thanks to globalization and the Internet in particular, software today is generally used all around the world, on a very wide range of devices. This means that your code needs to handle a lot of culture-specific cases, like dealing with numbers and dates in another format than what you expect. For instance, did you know that in many countries, a number with fractions (e.g. 1.42) doesn't use a period but a comma as the decimal separator (e.g. 1,42)? And are you aware that in many countries, the day is written before the month in a date, while others write the year first?
Dealing with all this can be a major hassle, but fortunately for us, the .NET framework has several classes which can help us deal with these situations. The most commonly used is the CultureInfo class, which we'll discuss in the next article, but .NET also offers classes for working with regions and even specific calendars (you do know that even the calendar is not the same around the world, right?).
This topic is especially important if you're working on an application which should support multiple languages, but even if that's not the case, you still have to deal with the fact that it might be used on a device which doesn't use the same notations for e.g. dates and numbers. To illustrate just how important that is, consider this example:
string inputNumber = "1.425";
double usNumber = double.Parse(inputNumber, CultureInfo.GetCultureInfo("en-US"));
double germanNumber = double.Parse(inputNumber, CultureInfo.GetCultureInfo("de-DE"));
Console.WriteLine(usNumber.ToString() + " is not the same as " + germanNumber);
Think of the inputNumber variable as something we just received from the user of the application, e.g. something typed in a text field on a web form. We use the double.Parse() method to turn it into a float, but we pass in a second parameter of the CultureInfo type - if we didn't pass in this parameter, the system settings would be used, which could then be English, German or something completely different. Now notice the output:
1,425 is not the same as 1425
Quite true! Our number value just got a thousand times bigger, because in Germany, they use a comma as the decimal separator, while a period acts as the thousands separator. This would be a major problem in most applications, but the good news is that while the example illustrates the problem, it also illustrates the solution: You always have to be in control of how you receive input and then deal with it accordingly, because as you can see, thanks to the CultureInfo class, .NET is capable of parsing a number (and dates too!) in any of the possible formats, as long as you tell it what to expect.
Dealing with cultural and regional differences is perhaps even more important when programming than in real life. Fortunately for us, the .NET framework can be a huge help in these regards, as long as you know where to look. In the next couple of articles, we'll discuss the tools offered by the .NET framework for dealing with these differences.