Programming Microsoft ASP.NET 4 - Dino Esposito [161]
[ProfileProvider("MyProvider")]
public String BackColor
{
get { ... }
set { ... }
}
Obviously, the provider name must correspond to one of the entries in the Page Localization Localization is not a hard feature to build and doesn’t touch any staggering peaks of technical difficulty. A successfully localizable application just requires planning, development care, and constant small-scale refactoring. Frankly, localization is not for just any (Web) application either. In this regard, I consider localization as an all-or-nothing feature of a Web project: either localization is a requirement or it is not. If it is a requirement, every little piece of UI (text, layout, CSS, script, and images) must be architected and implemented to be easily replaceable and configurable. Otherwise, I just don’t care about localization and stuff literals in the page layouts. Considering localization from the perspective of an entire application with a not-so-short expectation of life, there are three aspects of it that need to be addressed: how to make resources localizable, how to add support for a new culture, and how to use (or whether to use) databases as a storage place for localized information. Let’s review the techniques that allow you to keep resources easily localizable. Making Resources Localizable Figure 7-9. Adding a new resource item to the ASP.NET project. You always use the resource name to refer to its content from within application pages. After a resource assembly is linked to the application, the ASP.NET runtime selects the correct value at run time according to the user’s language and culture. Note Instead of creating and maintaining a resource assembly, you can simply create an App_GlobalResources folder under the site root and place there any resource RESX files you might need. Such files are compiled into resource assemblies on demand care of the ASP.NET runtime. A possible drawback is that the RESX files are deployed as source code to the site. Global and Local Resources Figure 7-10. Global and local resource folders. In a local resource folder, you can have resource files with folder-level visibility (such as personal.resx in Figure 7-10) as well as page-specific resource files. In this case, a simple naming convention binds the file to the page. If the page is named sample.aspx, its corresponding resource file will be sample.aspx.resx. Global and local resource files can happily coexist in the same application. Finding
The whole theme of localization is nothing new in the .NET Framework, and ASP.NET is no exception. You have had tools to write culture-specific pages since the very first version of ASP.NET. In addition, these tools didn’t change significantly with the stream of versions, and today they form a rather stable API.
A localizable ASP.NET Web Form uses resources instead of hard-coded text to flesh out the user interface. In this context, a resource is meant to be an item of stored text associated with a public name and typically compiled into its own assembly. A resource assembly is a standard class library that contains one or more RESX files. A RESX file is an XML document that contains resource names and content. Visual Studio provides a typical dialog box to add such a new item to the project. (See Figure 7-9.)
The ASP.NET documentation distinguishes between global and local resources. Global resources are available to any pages in the application; local resources, instead, are specific to a single page or the pages located in a given directory hierarchy. In terms of syntax, global and local resources are the same thing—a RESX file. Local resources must be deployed to an App_LocalResources folder. You can have only one global resource folder in a site; instead, you can have multiple local resource folders, one for each section of the site you want to restrict resources to. In Figure 7-10, you can see a local resource folder under the Private folder that affects only the pages defined inside the Private folder and its child folders.