• Choose a category
• All
• Classic-Fiction

By Root 5441 0

the right balance between what’s global and what’s local is ultimately up to you. Overall, the best approach seems to be having multiple resource files—either local or global. You might start with a local resource file for each page, and then merge strings and other resources into a global resource file as you find them referenced from multiple pages.

Important

From what I have learned on the battlefield, having a single global file to hold all localizable resources turns into a not-so-pleasant experience, even for a moderately complex Web application. One issue is the size of the file, which grows significantly; another issue, which is even more painful, is the possible concurrent editing that multiple developers might be doing on the same file with the subsequent need for a continuous merge. However, I encourage you not to overlook the naming issue.

When you have hundreds of strings that cover the entire application scope, how do you name them? Many strings look the same or differ only in subtle points. Many strings are not entire strings with some sensible meaning; they often are bits and pieces of some text to be completed with dynamically generated content. And the concatenation might be different for various languages.

Trust me: naming a few of them in the restricted context of only some pages is doable; handling hundreds of them for the entire application is really painful.

Using Resources: Declarative vs. Programmatic

In ASP.NET Web Forms, a key decision to be made early is whether you want to insert localizable text declaratively, programmatically, or both. Inserting localized text programmatically means writing a method on each Page class that assigns ad hoc text before display. This approach offers the maximum flexibility and allows you to retrieve localized text using the API that best suits you. Here’s some code to read the value of the resource item named Welcome from a resource file named literals.resx:

MyResources.Literals.Welcome

MyResources is the default namespace of the assembly that contains the resource file. Literals is the name of the file and the class name that ultimately exposes text items as public static properties. Finally, Welcome is the name of the resource item. For this code to work, you must ensure you create an assembly with a Literals.resx file whose access modifier in Visual Studio is set to Public. Note that the default value is Internal, which will not make resource items publicly available. (See Figure 7-11.)

Figure 7-11. Editing a RESX document.

The preceding syntax is general enough to work with any RESX file, regardless of its local or global status. This is also the natural way of localizing applications in ASP.NET MVC. However, it doesn’t get along very well with the ASP.NET server controls that populate Web Forms pages. The point is that you can’t use the preceding expression in a <%= … %> code block in all possible locations within a Web Forms page.

The following markup compiles just fine:

<%= MyResources.Literals.BookTitle %>

Unfortunately, you can’t embed the code block as the attribute of a server control. (This is where the key difference between Web Forms and ASP.NET MVC arises.) The following code won’t even compile:

The reason has to be found in the way in which a server control produces its own output.

In the end, for a Web Forms page the most convenient approach results from any of the following:

Design your own localization layer that each page passes through to have its text localized. This layer is a sort of transformer that reads from localization storage and replaces placeholder text. Your localization storage can be RESX file or, why not, your own database table.

Go with any shortcuts that Visual Studio and ASP.NET machinery might have released. This includes a tailor-made syntax for local resources and a specific expression builder for declaratively binding control attributes to localized text. However, the declarative syntax