Plan Web Sites to Support Globalization
This post will be about the globalization and localization techniques ASP.NET provides us. There are two types of resources which you can use in an ASP.NET page: global, which means they are accessible from all pages, and local, for each given page. First let’s see how to use global resources.
To enable them, add a special folder named App_GlobalResources. In this folder, you can insert whatever resource you’d like to use. Let’s insert a .resx file, this will be the default culture you’d use. Let’s call it GlobResx.resx. Add a key-value pair, for example HeaderText = Hello World. Now on a random .aspx page, define a Label control, and set its text property to <%$ Resources: GlobResx, HeaderText %>. Now you are done, when you run your site, you’ll see Hello World as the label’s text.
Now let’s take a further step. Create a file named GlobResx.en.resx into the App_GlobalResources folder. Add the same HeaderText entry, but now use the value: Hello for the English-speaking World! If your browser is set up to use the English culture, you’d see your label shows the new text.
The last task to do is to create a regional resource. To implement this, create a new .resx file into your App_GlobalResources folder, and name it GlobResx.en-US.resx, and set our usual text to Hello United States! Now I think you understand the concept behind global resources. If a regional version of the page exists, the CLR and ASP.NET will show that one to the visitor. If this isn’t the case, but there’s a resource file for the user’s language, that one will be used. If neither of these files exists, the default values will be used, listed in our GlobResx.resx file.
The concept of local resources is the same. The main difference is that you’d use the App_LocalResources folder to work with them, and that they’re implemented on a page-level basis, so every page in your application should have its own resource file for each culture and region you’d like to support. These files follows the naming convention FileName.aspx.resx /FileName.aspx.en.resx/ FileName.aspx.en-US.resx.
To use localized resources, you have two approaches. The first one is called implicit localization, and you should imagine it as a shortcut between your page and the underlying resource file. You’d write the following code to link a control with a resource:
<asp:Label runat=”server” meta:resourcekey=”TitleLabel” />
Then, in your PageName.aspx.resx files, you should add entries like TitleLabel.Text, TitleLabel.ForeColor, etc. The point is that you can assign localized values for each property the given control exposes, by the traditional dot syntax.
Implicit localization is very straightforward and simple, but as well a bit inflexible. For a more flexible solution, you should use explicit localization, as it allows you to bind data to any properties, not just the ones that implicit localization supports. However, there’s nothing new here. The syntax of explicit localization is the same as the one of global resource’s. In the case of explicit localization, you should omit the class name (it was GlobResx in our example), so you should just include a resource key.
Now that the foundations are laid, we should consider what are the limitations of the standard globalization model in ASP.NET. So far, we’ve only worked with special XML files with the extension of .resx. Never did any database query for retrieving our globalization data. We did so because the default behavior of the ASP.NET globalization process assumes that data is stored in .resx files. Now we need to overcome this limitation, and our only choice is to implement a custom resource provider.
Now the task of implementing a custom resource provider is well outgrows this blog post, I’d prefer not to write it here. Refer to MSDN for the relevant source code and techniques. For this exam, you are good when you know what are the limitations of the default model, you don’t have to code another one.