fforts to simplify application globalization and localization have definitely succeeded over the past few years. ASP.NET 2.0 made the process of localizing resources and deploying them with applications easier for developers. For example, Visual Studio 2005 can automatically generate local resources on a per-form basis, and can also generate static classes for all strongly-typed resources. Visual Studio 2005 and ASP.NET 2.0 natively provide methods that streamline the process of retrieving resources programmatically. ASP.NET also automatically detects browser culture preferences, assigning the detected culture preference to the culture of the requested thread.
Current Resource Capabilities
For example, to generate a local resource file from an ASP.NET Web Page you can simply go to the Tools Menu in the Visual Studio IDE and click the "Generate Local Resource" item; Visual Studio will place the generated file in an App_LocalResources
folder. You can also generate Global Resources by adding a new item of type Assembly Resource File to the Web site and placing that file in the App_GlobalResources
folder (which Visual Studio will create for you).
ASP.NET supports "implicit" localizationmeaning that if you follow the correct syntax and all the resources are present, localization can occur automatically. To take advantage of implicit localization, resources must follow the conventional Key.Property
pattern. For example, for a button (Button1
) in a form where you would like to localize the Text
and the BackColor
attributes, the resource file should contain the Button1.Text
content and the Button1.BackColor
You activate this implicit localization by using a special meta
attribute in the markup as shown below:
<asp:Button ID="Button1" runat="server" Text="DefaultText"
You do not have to explicitly indicate which property is being localized if the property is defined in the resource; ASP.NET makes that substitution automatically.
You can also use a resource expression to localize the properties of a control, as opposed to using implicit localization; this explicit method requires one expression per property to be localized. For example:
<%$Resource:Class, ResourceID %>
In the preceding expression, the Class
value is the name of the global resource file without the extensionin other words, the base file name. If you're pulling the resource out of a local resource file, you don't need the class value. The ResourceID
value is a key that identifies the resource to link to.
So, to localize the button Text
property using an expression, you'd write:
<asp:Button ID="Button1" runat="server"
Text="<%$ Resources:WebResources, Button1Caption %>" />
Finally, if you need to set a resource value at run timeand the value is unknown at design time, or will depend on a run-time conditionyou're better off accessing the resource programmatically. A clear example is when a developer needs to manage errors in an application. In this case the UI should present localized error messages to the end user, but the developer can't know which localized message to display in this scenario at design time.
To do this, you can call the GetLocalResourceObject
or the GetGlobalResourceObject
method of the HttpContext and the TemplateControl classes in the framework:
ASP.NET and Visual Studio 2005 build a strongly typed resource class behind the scenes for each global resource file and make those classes available through IntelliSense, so you can also use the strongly typed static class to retrieve a global resource with this syntax:
For example, to display a "Welcome" string:
Need for Additional Resource Management
Dim welcome as String
Welcome = Resources.WebResources.WelcomeText
Despite all the advantages built into ASP.NET 2.0, the process of localizing a Web application poses several challenges that the .NET 2.0 framework does not resolve. Modern applications are not restricted to a few Web pages and controls; instead, the number of resources they must translate and manage increases constantly.
Visual Studio 2005 lacks a mechanism for synchronizing resource filesthat is, keeping resource keys in synchrony with the invariant culture. It also lacks a versioning and management system.
The rest of this article describes a project we've built while managing internationalization projects called the Localization Management Toolkit, intended to help solve some of the problems associated with managing resources and translation for large global applications.
Introducing the Localization Management Toolkit
Even though Visual Studio 2005 automates resource generation per Web Form, the task of synchronizing, managing, and versioning the resource files, and shipping them to translators for an application quickly becomes cumbersome when more than three cultures and thousands of resources are involved. The entire resource-management and translation process is easier to manage when there is a central resource repository. The Enterprise Localization Management Toolkit (the sample code
, in beta as of this writing, accompanies this article) introduces a mechanism that supports this central repository and single file creation, while still keeping the automatic resource generation capabilities of Visual Studio 2005. The Toolkit's features greatly simplify communication with the translators, reducing the number of files to track while maintaining high developer productivity.
The Toolkit consists of three main parts:
- A central repository in an SQL Server 2005 database
- A Windows application for the technical manager
- A Web application for developers and translators
Developers use the Web application to modify the values of the resources they create or delete resources, while translators use it to review newly created resources and perform their translations based on the invariant culture value of a particular resource.
If translators do not have Web access to this application, they can use the resource editor utility that ships with the .NET Framework 2.0 SDK and work with a single resource file that administrators can generate using the Toolkit administration tool.
Administrators use the Windows application (The Toolkit Administration Tool) to import new resources into the database, and generate updated resource files for an application. The Administration Tool also supports adding a new culture to an application automatically, generating the appropriate file for translation along with the resource files for the newly added culture. It tracks resource file generation, so you can know exactly when each file was generated.
In short, here are the features of the Toolkit:
- Microsoft SQL Server-based repository to store and manage the localized resources across all ASP.NET applications within an organization.
- Web-based resource management application for use by programmers, translators, and deployment personal.
- Support for the generation of loose resource files or satellite assemblies.
- Ability to automatically populate the localization database based on keys specified by a developer or Web designer by importing resource (.resx) files into the database.
- Ability to generate .resx files from the database after they have been translated and reviewed by the translators keeping track of the version.