Practical ASP.NET

Supporting Multiple Languages and Cultures

ASP.NET can simplify the difficult task of internationalizing your Web pages. Peter Vogel shows you how.

• By Peter Vogel
• 09/16/2009

ASP.NET gives you the ability to support multiple languages relatively easily, important for Web pages that are as likely to be viewed in Bangor, Maine as in Bangalor, India. Alas, the process remains labor intensive and only addresses the simplest of problems.

As a Canadian, I understand the concept of having two official languages. Like my national government, your site may need to support multiple languages but only a single culture. Alternatively, you may need to go further, and support multiple languages and cultures, which means not only translating your text but also handling different ways of displaying dates and currency (among other issues). ASP.NET provides some support for making your site multi-lingual and multi-cultural, but there is no quick solution.

The first step in supporting multiple languages or cultures is to implement "internationalization." Internationalization ensures that your site isn't dependent on any particular language or culture. The next step is "localization," which is having your site display in a specific language or culture.

Two Steps to Internationalization
In ASP.NET, you are just two steps from internationalizing your site. First, open a page in design view. Second, from the Tools menu select Generate Local Resource. This generates a resource file with the same name as your page but with the extension .resx (e.g. filename.aspx.resx) and puts it in the App_LocalResources folder.

Now that you've created your resource file, you need to rename it to insert a culture code before the filetype. For instance, if the resource file is to hold resources to support the Spanish language in Mexico, then you’d rename the file to filename.aspx.es-mx.resx.

If you open the resource file, you'll find that it's already loaded with some resources, specifically the text from language specific properties for each control on the page (e.g. the Text property of Label controls).

Therefore, when you rename that initial resource file, the correct culture code to give the file is the one for your locale. To support more cultures, you must copy and paste the resource file, rename it to the new culture code, and translate the contents into the new language. There's no solution at this point but to roll up your sleeves and start typing in new text. You can also use the resource file to hold resources other than text (e.g. culture or language specific images). More on that issue next week.

ASP.NET will automatically use the right resource file based on the browser's culture settings, provided that you also set the UICulture property for the page's Document object to “auto.” The Culture property must also be set to “auto,” but that's the default setting, so it shouldn't be an issue.

You may have a page where you don't want the language to change. Perhaps you have a page holding legal text that your government requires to be present, or maybe you are presenting text aimed at one specific culture. In these cases, you can prevent resource files from being swapped by setting the Culture and UICulture settings for the page -- or just don't create any resource files for that particular page.

If you don't want to set UICulture on every page on your site, you can set a default value for the property in the web.config file. This example effectively sets the UICulture property to Auto for every page where the property hasn't been explicitly set:

‹globalization  uiCulture="auto" /›

More Interesting Problems
As useful and interesting as the automatic generation of resource files is, it really only addresses a small part of the problem in supporting multiple languages and cultures. First, it's not going to help you with different date, number and currency formats. More critically, it only addresses static text embedded in your Web page. What it omits is anything handled dynamically.

This solution also assumes that the user always wants the page to be displayed according to the localization settings made in their browser or operating system. That may not always be true: An international company, for instance, may only be willing to support two or three languages on an internal Web site even though they have employees in several countries. Alternatively, a single user may use browsers on several different computers but always want the site to display in his or hers native language. Either problem requires you to set the language and culture as part of the user's profile and use that setting to override any browser's settings.

Finally, not all resources are used in a single page (company name and legal disclaimers, for instance, may appear on every page on the site). You don't want to repeat resources across many resource files. I'll be looking at these problems in next week's column.