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:
Collapsestatic 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:
Collapse
private string strResourcesPath= Application.StartupPath + "/Resources";
private string strCulture= "en-US";
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, andSetUIChnages 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:
Collapse
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:
Collapse
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
Collapse
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:
Collapse
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 likeResourceManager.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.
And thanks
For coming so far. I hope this 20 minutes was worth it, and give me your comments/ suggestion to improve this.
In action (French)
Article history
- August 20 2006: First published.
- September 01 2006: Added comparison with .Resx approach.
Is your email address OK? You are signed up for our newsletters but your email address has not been reconfirmed in a long time. To make this warning go away please click here to have a confirmation email sent so we can confirm your email address and continue sending you your newsletters. Alternatively, you can update your subscriptions.