A computer's locale is a setting that defines the user's language, country, and cultural settings, which determine such things as how dates and monetary values are formatted.

For example, the FormatValues example program shown in Figure 37-1 (and available in this lesson's code download) displays the same values in American, British, German, and French locales.

Figure 37.1. FIGURE 37-1

If you look closely at Figure 37-1, you can see that the same values produce very different results in the different locales. For example, the currency value 1234.56 is displayed variously as follows:

Not only do these results use different currency symbols, but they even use different decimal and thousands separators.

At first this may seem like a daunting task. How do you build completely separate interfaces for multiple locales? Fortunately this is one thing that Visual Basic and Visual Studio do really well.

To build a globalized program, start by creating the form as usual. Add controls and set their properties as you would like them to appear by default.

After you've defined the program's default appearance, you can localize it for a particular locale. First set its Localizable property to True. Then select a new locale from the drop-down list provided by the form's Language property. Now modify the form to handle the new locale. You can change control properties such as the text they display. You can also move controls around and change their size, which is particularly important because the same text may take up a different amount of room in different languages.

At run time, the program automatically checks the computer's locale settings and picks the language that is closest. Note that many languages have several sublocales. For example, English includes the varieties used in India, Ireland, New Zealand, and more than a dozen other locales.

There's also a locale listed simply as "English." If the user's computer is set up for one of the English locales that the program doesn't support explicitly, the program falls back to the generic English locale. If the program can't support that locale either, it uses the default locale that you used when you initially created the form.

Figure 37.2. FIGURE 37-2

The LocalizedWeekdays example program (available in this lesson's code download) is localized for English (the form's default) and German. Figure 37-2 shows the form's English interface and Figure 37-3 shows its German interface.

Figure 37.3. FIGURE 37-3

Having the program check the computer's locale automatically at run time is convenient for the user but it makes testing different locales tricky.

One way to force the program to pick a particular locale so you can test it is to select the locale in code. You must do this before the form is initialized because after that point the form's text and other properties are already filled in and setting the locale won't reload the form.

To add code to select a locale before the controls are loaded, you need to give the form a new constructor. If you type Public Sub New() and press [Enter], Visual Studio creates the following default constructor for a form:

Public Sub New()

    ' This call is required by the designer.
    InitializeComponent()

    ' Add any initialization after the InitializeComponent() call.

End Sub

Now you can add code to this constructor before the call to InitializeComponent. The following code block shows all the code used by the LocalizedWeekdays program:

Public Class Form1
    Public Sub New()
        ' English.
        'My.Application.ChangeCulture("en-US")
        'My.Application.ChangeUICulture("en-US")

' German.
        My.Application.ChangeCulture("de-DE")
        My.Application.ChangeUICulture("de-DE")

        ' This call is required by the designer.
        InitializeComponent()

        ' Add any initialization after the InitializeComponent() call.

    End Sub
End Class

The code uses the My.Application.ChangeCulture method to change the culture the program uses for string manipulation and formatting when processing dates, currency, numbers, and other values in the code. It then uses My.Application.ChangeUICulture to change the culture the program uses to retrieve localized resources to build the form's user interface elements.

The code contains statements that set the program's locale to English or German. Comment out the one that you don't want to use for a given test.

After you finish testing a form's localized version, be sure to remove the code that selects the culture so the program can use the system's settings. Otherwise, you might end up with some very confused users.

Within a Visual Basic program, variables are stored in American English formats. To avoid confusion, Microsoft decided to pick one locale for code values and stick with it. For example, if you're a German programmer your code still says For Each customer As Person in Customers and not Für Jeden Kunde Als Person In Kunden (or whatever it would work out to be).

When you move data in and out of the program, however, you need to be aware of the computer's locale. For example, suppose the program uses the following code to display an order's due date:

txtDueDate.Text = dueDate.ToString("MM/dd/yy")

If the date is October 31, 2011, this produces the result "10/31/11," which makes sense in the United States but should be "31/10/11" in France and "31.10.11" in Germany.

The problem is that the program uses a custom date format that is hard-coded to use an American-style date format. To produce a format appropriate for the user's system, you should use predefined date, time, and other formats whenever possible. The following code uses the standard short date format:

dueDateTextBox.Text = dueDate.ToString("d")

This produces "10/31/2011" on an American system and "31/10/2011" on a French system.

You can run into the same problem if you assume the user will enter values in a particular format. For example, suppose you want to get the whole number part of the value 1,234.56 entered by the user. If you assume the decimal separator is a period and just use whatever comes before it as the integer part, then you'll get the answer 1 when a German user enters "1.234,56"; and the program will crash when a French user enters the value "1 234.56."

To avoid this problem, use locale-aware functions such as the numeric classes' Parse methods to read values entered by the user. In this example, a good solution is to use Single.Parse to read the value and then truncate the numeric result as shown in the following code, rather than try to truncate the value while it's still in its string form:

Dim value As Integer = Int(Single.Parse(txtValue.Text))

For a list of standard numeric formats, see msdn.microsoft.com/library/dwhawy9k(VS.100).aspx.

For a list of standard date and time formats, see msdn.microsoft.com/library/az4se3k1(VS.100).aspx.

For more information on parsing strings, see msdn.microsoft.com/library/b4w53z0y(VS.100).aspx.

value = Decimal.Parse(txtValue.Text, NumberStyles.Any);

The LocalizedParsing example program shown in Figure 37-4 (and available in this lesson's code download) parses currency values displayed in labels in different languages, doubles the parsed decimal values, and displays the results. For each language, it selects the appropriate culture so it can parse and display the correct formats.

Figure 37.4. FIGURE 37-4

In this Try It, you write the program shown in Figures 37-5 and 37-6, which lets you select foreground and background colors in American English and Mexican Spanish.

Figure 37.5. FIGURE 37-5

Figure 37.6. FIGURE 37-6