Localizing .NET web applications

It seems that globalization often makes the wish list of many a web site until the client realizes professional quality translations require a significant investment of time and money.

On occasion however smaller web applications with their limited vocabulary are prime targets for localization globalization and it can be quite feasible to translate the couple of hundred strings involved.

Here’s a very brief whirlwind overview of what’s involved.

Create the default language resource file

Create a new folder inside your App_GlobalResources folder to contain your language resource files. Then create a new resource file (e.g. Localization\Language.resx) to use when no translation exists for the user’s preferred language.

Detect the user’s browser settings and switch

In .NET 1.1 this required a couple of lines of code in your global.asa.cs:

public void Application_BeginRequest(object sender, EventArgs e) {
    Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(Request.UserLanguages[0]);
    Thread.CurrentThread.CurrentUICulture = new CultureInfo(Request.UserLanguages[0]);
}

Update

Sander Rijken points out that .NET 2.0 lets you do this with a line in your web.config <system.web> section instead:

<globalization culture="auto" uiCulture="auto" />

or indeed at individual page level with:

<@ Page ... Culture="auto" UICulture="auto">

Localize the classes

For every bit of code that sets a string that will end up on the user’s display you now have to move that into the language resource file and replace the code with a reference to it. So if for example you had;

if (name.Length == 0) error.Text = "Please enter a name";

Then you move “Please enter a name” into the resource file and give it a sensible key such as NameBlankError and modify the above line to read;

if (name.Length == 0) error.Text = Resources.Language.NameBlankError;

There is a Resource Refactoring Tool to do this for you now! Just right-click the string, choose Extract to resource and fill in the blanks.

Localize the pages

Unlike the WinForms designer the WebForms one doesn’t support multi-language so you’re instead forced to do it by hand. One way is to remove all the text from the page and place it into the resource language file.

Then create a private void Localize() method in each page that simply looks something like;

public void Localize() {
    Title = Resources.Language.LoginPageTitle;
    loginButton.Text = Resources.Language.LoginPageLoginButton;
    reminderButton.Text = Resources.Language.LoginPageReminderButton;
}

Obviously you need to call this from the page, I find that calling it from Page_PreRender works a treat.

One disadvantage to this technique is your page itself ends up looking very blank in the designer or duplicates text that soon gets out of date. You could avoid this by leaving the default-language text in the page and not calling localize if you are running in that language. Be sure to put “\***” or something in the default language resource file for it though so that if it’s missing for other languages you immediately spot the missing text during testing.

Don’t treat types as strings

If you have a number, treat it as a number and pass it around as a number. The same applies to dates etc.

If you need to pass over to SQL etc. then use a parameterized query, they’re fast and will take care of all the regionalization stuff for you!

To get those pesky strings in and out of the correct types see the following extra steps!

Always use .ToString() to format output

Almost all basic .NET types include locale-aware formatting and so keep an eye on the ToString methods. Remember even numbers are formatted differently across the globe. 1,234.00 in England and the US becomes 1.234,00 in various parts of Europe.

Be very careful of outputting currencies. .NET won’t convert the amount for you but you could easily find yourself with the wrong currency symbol and therefore a totally different price!

Always use .TryParse to read input

When accepting information from users hand over that string to TryParse for it to try and work out what’s going on. It will helpfully return a boolean indicating if it did the job okay – if not time to use that localized error-message.

Auf wiedersehen!

[)amien