Globalization of Windows Applications in 20 Minutes Using C#

Globalization of Windows Application in 20 Minutes

Prelude

There was once a time when multiple language support for a Windows application used to be a three to six months call, but with the advent of .NET, not anymore. Here is a 20 minutes crash course for globalization / localization of a Windows application. I think you'll find it as useful as I do.

Globalization, in simple terms, means enabling an application so that it works in different nationals, similar to how a global company operates in different countries. For a Windows application, globalization means it is intended for worldwide distribution. There are two aspects of globalization:

Internationalization: Enabling the application to be used without language or culture barriers, i.e., language and culture information comes from a resource rather than being hard coded in the application.
Localization: Translating and enabling the product for a specific locale. Based on a resource file, the application is translated into a language and culture.

Target

Modular design: Code Once Use Everywhere (COUE), this is the prime feature which is needed when you globalize an application. All anyone should do is convert any user interface output/message box /labels text etc., to something like frmMain.RM.GetString("10001"). No culture information or resource manager initialization need to be done again in forms or anywhere else.
Default language: Saving and retrieving the default language selected by the user in the Registry.
Features: How to take care of date/time, multiple forms, images etc.
Reusability: Minimum effort when you add a new form to the application.
Extensibility: Support for multiple languages like French, Spanish, and English, using resource files for each.

To hold your interest, here is how it looks:

Time starts now

The first thing we need will be three resource files for three languages English, French, and Spanish. I have used Google translate here[^] to accomplish this:

English file name: resource.en-US.txt.

Spanish file name: resource.es-ES.txt.

French file name: resource.fr-FR.txt.

Using the Resource generator (Resgen) in the Visual Studio .NET 2003 Command Prompt, we will create three resource files which can be understood by the application, here is how:

We are done with the resource files which will be used by the application and will look something like this (below) with the extension .resources for each text file:

Put these three .resources files in a Resource folder in the executable path.

Functionality

First run

When the application runs for the first time, we check for the Registry entry language of the application in [HKEY_CURRENT_USER\SOFTWARE\CODE PROJECT\GLOBALIZATION SAMPLE], and returns "en-US" if there is no entry yet. This value is set for the string strCulture of the application.

GetStringRegistryValue in the RegistryAccess class helps us get this:

static public string GetStringRegistryValue(string key, string defaultValue)
{
    RegistryKey rkCompany;
    RegistryKey rkApplication;
    rkCompany = Registry.CurrentUser.OpenSubKey(SOFTWARE_KEY, 
                false).OpenSubKey(COMPANY_NAME, false);
    if( rkCompany != null )
    {
        rkApplication = rkCompany.OpenSubKey(APPLICATION_NAME, true);
        if( rkApplication != null )
        {
            foreach(string sKey in rkApplication.GetValueNames())
            {
                if( sKey == key )
                {
                return (string)rkApplication.GetValue(sKey);
                }
            }
        }
    }
    return defaultValue;
}

Globalize application

Once we have the strCulture, we call the GlobalizeApp function:

// Resource path
private string strResourcesPath= Application.StartupPath + "/Resources";
// string to store current culture which is comon in all the forms
private string strCulture= "en-US";
//resourcemanager which retrivesthe strings
//from the resource files
private static ResourceManager rm;

private void GlobalizeApp()
{
    SetCulture();
    SetResource();
    SetUIChanges();
}
private void SetCulture()
{
    CultureInfo objCI = new CultureInfo(strCulture);
    Thread.CurrentThread.CurrentCulture = objCI;
    Thread.CurrentThread.CurrentUICulture = objCI;
    
}
private void SetResource()
{
    rm = ResourceManager.CreateFileBasedResourceManager
        ("resource", strResourcesPath, null);

}
private void SetUIChanges()
{
    ...
}

The GlobalizeApp function sets the culture information of the current thread, sets the Resource manager to the respective resource file, and SetUIChnages does all the user interface translations.

Modular design: Code Once Use Everywhere

This, as I said already, is an important feature because when an application expands or grows with time, you should be ready to change a new string with just one statement replacement. For this, I have created a public resource manager in frmMain:

public static ResourceManager RM
{ 
  get 
  { 
   return rm ; 
   } 
}

So, when the main form loads, you set the culture and the resource file information to the public resource manager. And, in the new added form or anywhere you add a message box or label, you can call the resource manager like this:

this.Text = frmMain.RM.GetString("0006");
label1.Text = frmMain.RM.GetString("0008");

Translations

SetUIChanges describes how the translations are done:

Texts are directly translated from the resource file
Images have to be taken care for using multiple images
DateTime etc., which are Windows specific does not need to be translated at all (isn't that cool?)

The code-behind

private void SetUIChanges()
{
    if (String.Compare(strCulture,"en-US")==0)
    { 
        picTop.Image = picE.Image;
    }

    if (String.Compare(strCulture,"es-ES")==0)
    { 
        picTop.Image = picS.Image;
    }

    if (String.Compare(strCulture,"fr-FR")==0)
    { 
        picTop.Image = picF.Image;
    }
    label1.Text=rm.GetString("0001");
    label2.Text=rm.GetString("0002");
    label3.Text=rm.GetString("0003");
    btnSubmit.Text=rm.GetString("0004");
    btnCancel.Text=rm.GetString("0005");
    this.Text = rm.GetString("0000");
    lblselect.Text = rm.GetString("0009");

    lbltime.Text = DateTime.Now.ToLongDateString().ToString(); 
}

For images, I have used three hidden PictureBox controls as shown below:

Saving the default culture in the Registry

The code-behind:

static public void SetStringRegistryValue(string key, string stringValue)
{
    RegistryKey rkSoftware;
    RegistryKey rkCompany;
    RegistryKey rkApplication;

    rkSoftware = Registry.CurrentUser.OpenSubKey(SOFTWARE_KEY, true);
    rkCompany = rkSoftware.CreateSubKey(COMPANY_NAME);
    if( rkCompany != null )
    {
        rkApplication = rkCompany.CreateSubKey(APPLICATION_NAME);
        if( rkApplication != null )
        {
            rkApplication.SetValue(key, stringValue);
        }
    }
}

Acknowledgement

My humble acknowledgement to my boss who gave me a 6 days deadline, for globalization of an application we have been working on for a year.

What's wrong with the .Resx approach

i got a number of emails asking why not use the .resx approach for each form. Well, here are a few of the reasons. I prefer a single resource file compared to multiple .resx files for each form for three simple reasons:

Maintainability:

Assuming you are taking the .resx files approach:

Take a simple scenario. By mistake, you have a wrong translation for the "Submit" button, say for the German language. The original translation is "Einreichen", but you initially missed the last n and now, you have "Einreiche" instead of "Einreichen" for Submit buttons throughout your application.

What you can do to resolve this:

You have to go to each form and change the resource file of the form.
Compile the EXE again, creating the German DLL, and redistribute the whole EXE with setup including the new DLL.

On the other hand, if you use a single resource file as in this article, "Submit" buttons in all the forms translate into something like ResourceManager.GetString("101").

If the translation is wrong, just-

Update the initial German text file.
Resgen it and create a resource file.
Overwrite your existing resource file with the updated resource file.

You are done. Redistribution needs just the lightweight resource file and your EXE will automatically update the Submit buttons everywhere.

Extensibility:

If you have to add another language, say Latino, with the .resx file approach, you have to go to each form and create a resx file for Latino, and compile and create a Latino DLL.

With the Single Resource file approach, you just have to create another text file with the Latino translation as shown in the example above, Resgen it, and add a menu option for Latino, and you are done. You can have a Latino menu option even earlier, and add the resource file later; you won't even need to re-compile.

Dynamic UI changes:

With resource files, you can have a dropdown menu instead of the radio button in the example, and change the complete UI on the fly to whichever language you fancy. With the .resx and DLL approach, you have to start the application with that localized DLL.

I think you might be able to dynamically change the UI, but it will be a much more complicated process.

Another not that important reason is, the Resource file approach creates lightweight .Resources files whereas .resx creates a DLL for each language.

If you want to go by the standard approach, you can definitely get better results, but will not be as fast as this approach.