#1,119 – Localization I – Set UICulture Tag

The first step in localizing an application is to add a UICulture tag to your project file, as shown below.  This tells the compiler that you’ll be localizing your application and specifies a default culture to use.

To make this change:

  • Open your project file (e.g. .csproj) in a text editor
  • Add the following tag within the first PropertyGroup:
    • <UICulture>en-US</UICulture>
  • Save your change
  • Open the project in Visual Studio
  • Rebuild the project

1119-002

The application will run as it did before, but the compiled versions of your XAML files (BAML) are now located in a separate DLL–a satellite assembly.  We can see this by comparing the contents of the \bin directory before and after the change.

Before making the change, we just had an .exe file.

1119-001

After the change, the main directory contains the .exe file and a new en-US sub-directory.

1119-003

In the en-US folder is a DLL containing the BAML.

1119-004

 


Note: You’ll also need to set the NeutralResourcesLanguage attribute in AssemblyInfo.cs.

#1,118 – An Example of Input that Obeys CurrentCulture

One step in internationalizing an application is to respect the current regional settings when reading numeric or date/time values from a user.

If you are parsing user-entered text and converting to numeric or date/time data, the Parse methods associated with individual data types respect the current regional settings.

Below, we read text from two TextBox controls, interpreting the first value as a double and the second as a DateTime using the corresponding Parse method.

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                double num = double.Parse(txt1.Text);
                DateTime dt = DateTime.Parse(txt2.Text);
            }
            catch (Exception xx)
            {
                MessageBox.Show(xx.ToString());
            }
        }

On an English/US system, we can enter the data as “1.1” and “5/2/12”.  The date is interpreted as May 2nd.

1118-001

For French/France, we must enter “1,1” for the double.  “5/2/12” is interpreted as Feb 5th.

1118-002

#1,117 – Internationalization II – Obey CurrentCulture for Input

The first step in internationalizing an application is to ensure that your application honors the user’s current regional settings, as reflected by the CurrentCulture property of the application’s main thread.

Current culture impacts not only how you display the following types of data, but also how the user inputs this data:

  • Numeric data
  • Date/time values

These values are typically stored internally as numeric (e.g. double, int) or DateTime values.  The values exist in memory in a culture-agnostic form.  You need to worry about regional settings only when you display a value to the user or receive input from the user.

In .NET, if you use the Parse method of a numeric or date/time type to convert a user-supplied string to the internal type, the parse operation will expect the string to be in a format that is valid for the current region.

 

#1,116 – An Example of Output that Obeys CurrentCulture

The first step in internationalizing an application is to respect the current regional settings when outputting numeric, date/time, or currency values.

Below is an example of an application that displays numeric and date/time values, using the ToString method for instances of double and DateTime.

    <StackPanel>
        <StackPanel Margin="10" Orientation="Horizontal">
            <StackPanel>
                <Label Name="lbl1"/>
                <Label Name="lbl2"/>
                <Label Name="lbl3"/>
                <Label Name="lbl4"/>
                <Label Name="lbl5"/>
            </StackPanel>
            <StackPanel>
                <Label Name="lbl6"/>
                <Label Name="lbl7"/>
            </StackPanel>
        </StackPanel>
        <Button Content="Gen Strings" Padding="10,5"
                Margin="10"
                Click="Button_Click"/>
    </StackPanel>

In the Click event handler, we set the labels’ content.

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            DateTime rightNow = DateTime.Now;

            lbl1.Content = rightNow.ToString();
            lbl2.Content = rightNow.ToString("d");  // short date
            lbl3.Content = rightNow.ToString("D");  // long date
            lbl4.Content = rightNow.ToString("t");  // short time
            lbl5.Content = rightNow.ToString("T");  // long time

            double num = 123456.789;
            lbl6.Content = num.ToString();
            lbl7.Content = num.ToString("n");
        }

With regional settings set to English (United States), the output looks like this:

1116-001

If I change my region to French (France), the formatting changes as expected.

1116-003

1116-004

#1,115 – Internationalization I – Obey CurrentCulture for Output

The first step in internationalizing an application is to ensure that your application honors the user’s current regional settings, as reflected by the CurrentCulture property of the application’s main thread.

Current culture impacts the display of the following:

  • Numeric data
  • Date/time values
  • Currency values

All of these values are typically stored internally as numeric (e.g. double, int) or DateTime values.  These values exist in memory in a culture-agnostic form.  You only need to worry about regional settings when you display a value to the user.

In .NET, if you use the ToString method on a numeric or date/time object, with or without formatting strings, the resulting string will correctly reflect the current regional settings.

If you’re using data binding to convert numeric or date/time data to strings, you need to manually set the Language property on each window or page to force data binding to use the culture correctly.

#1,114 – Culture Codes

In developing applications for Windows, a culture can be thought of as the combination of a particular language and the country or region where the language is being spoken.

Examples of specific cultures, representing a language and a region, include:

  • English / United States
  • English / United Kingdom
  • French / Belgium
  • French / France
  • German / Germany

Examples of neutral cultures, with no specific culture, include:

  • English
  • French
  • German

Cultures are represented in WPF by the use of culture codes or language tags, which conform to RFC 4646.  A language tag is composed of a code representing the language and a code representing the country or region, separated by a hyphen.

Below are several examples of names for specific cultures:

  • en-US  (English / United States)
  • en-GB  (English / United Kingdom)
  • fr-BE  (French / Belgium)
  • fr-FR  (French / France)
  • de-DE  (German / Germany)

A neutral culture is represented by the code for the language, by itself:

  • en  (English)
  • fr  (French)
  • de  (German)

#1,113 – Use of Cultures in Internationalization

When localizing an application or running a localized application, you’ll work in the context of a particular culture.  A culture can be thought of as the combination of a particular language and the country or region where the language is being spoken.

A developer targets one or more cultures when localizing an application.  For example, he might translate text in the application for the German-spoken-in-Austria culture or the English-spoken-in-the-UK culture.

Cultures are also used at run time.  A user runs an application within an environment that represents a particular culture.  This culture is then used by the application to determine which strings to load.

A culture that includes both a language and country/region indicator is known as a specific culture.  (E.g. French/Canada).  You can also work with neutral cultures, which are defined by a language but without a specific country.  (E.g. French)