Channels ▼


Using Localizable Resources

More often than not, Web pages are made of parametric content, be it plain literals, data-driven text, or images. In ASP.NET, data-driven content is usually associated to page controls via data binding, whereas images and literals are bound to the expected language through resources. A page that needs be localizable will resolve data-driven text using a different data source or perhaps a modified binding algorithm. But what about literals?

Page resources are literals stored in an application-specific assembly and bound to a culture identifier. Based on the culture that is currently set, the ASP.NET runtime loads the proper resource assembly and fleshes out the page's interface. Each resource file is a name/value collection filled with pairs of IDs and values. To localize a resource file, you keep the ID intact and just translate the text or, more in general, the HTML markup. Visual Studio 2008 provides ad hoc visual tools for the job. The resource file uses a particular naming convention to refer to the culture ID. If resources.resx is the file with the default text, then resources.XXX.resx is the name of the file with values for the XXX culture. For example, contains French resources, and so on. You can have as many resource files as required with no limitation at all.

Each resource file needs be compiled to an assembly to be usable at runtime. In ASP.NET 1.x, as a developer you had to create satellite resource assemblies manually using a command line tool. Starting with version 2.0, ASP.NET can create resource assemblies automatically, parsing and compiling any resource files found in two special folders -- App_LocalResources and App_GlobalResources.

As you can see, starting with ASP.NET 2.0 resources are split in two categories --l ocal and global.

A local resource is a resource file specific to a page. A simple naming convention binds the file to the page. If the page is named sample.aspx, its corresponding resource file is sample.aspx.resx. To be precise, this resource file is language neutral and has no culture defined. To create a resource assembly for a specific culture -- say, Italian --y ou need to name the resource file as follows: Generally, the it string should be replaced with any other equivalent string that identifies a culture, such as "fr" for French or "en" for English. You place page-specific assemblies in a folder named App_LocalResources located at the same level of the page in the server-side filesystem. The folder may group multiple resource files for each ASPX page found in the parent folder. Here's the syntax you use to reference a local resource:

<asp:Label runat="server" id="Label1" meta:resourcekey="Label1" />

The idea is that you associate each control in the page with localizable text with a resource key. The resource key is a string that conventionally contains the control ID. It only needs be a unique string, but binding it to the control ID greatly simplifies things. In the RESX file, you then add a bunch of entries in the form: resourceKey.PropertyName. For example, an entry named Label1.Text will automatically provide value for the Text property of the control bound to the specified resource key. In the resource file, you can set as many control properties as you need.

Global resources, on the other hand, are resources defined in a single place -- the App_GlobalResources folder -- and visible to all pages in the application. Global and local resources can be used simultaneously in the same page with no conflicts at all. A global resource consists of a unique name and a value. The syntax to reference a global value is different. It requires the use of the $Resources function.

<asp:Label runat="server" ID="Label1"
           Text="<%$ Resources:MyApp, App_Title %>" />  

The $Resources function is resolved at compile time and, in the example, will set the Text property to the value of the App_Title entry in the current resource file.

Both local and global resources are driven by the culture set on the page which is a parameter you programmatically control through Culture and UICulture page properties.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.