ASP.NET 2.0 Localization of string resources

With .NET 2.0, localizing string resources is incredibly easy to do. You get the benefits of an easy to work with XML file format, strongly typed resource access, and so forth. But it can take a little brainstorming to devise an effective string resources strategy. Here are a set of guidelines that that should help you to avoid pitfalls.

NEVER Programmatically Combine Glossary Terms
This is crucial. Suppose you have a glossary term simply called "News". News happens to have a resource value of News in your English culture. Now suppose you have a glossary term called "Important" with a resource value of Important as well. ALWAYS avoid doing this kind of stuff:

string importantNews = Resources.Glossary.Important + " " + Resources.Glossary.News;

Your translations will fail because in many languages, the term important might fall after news rather than before, and in some other languages the separate translations of "Important" and "News" may be translated with different terms altogether when presented as "Important News". You should always create a new Glossary term for cases like this.

Use {0} in your resource strings that will be used in data binding expressions
This is similar to the previous point. In some instances you may have resources that have a dependent variable thrown into the mix, such as the following text:

Welcome John Smith please purchase all of our products today!

You should create a resource entry such as this:

Welcome {0} please purchase all of our products today!

Otherwise you will be concatenating string resources, similar to the previous point, which is a definite no-no!

Although you'll find that you have to programmatically do the String.Format() stuff to set data like this, with a little ingenuity of custom Expression Builders in .NET 2.0 you'll find that you can leverage these types of resources in data binding scenarios without having to resource to coding String.Format() yourself. I may cover an example of this in a future blog, unless a motivated reader should be interested in providing an example!

For larger applications and enterprises, consider resources re-use
Re-use can come in many flavours, but I like to think of resource re-use from a scope point of view. The lowest scope example of re-use is a lower-level application development perspective. In situations where your enterprise's applications are all .NET based, consider creating assemblies that contain your glossary resources. Then reference these assemblies in your applications (versioning where it makes sense). You'll still get the benefits of strongly typed resources.

Higher-level scope re-use can be achieved by versioning your resources in a .NET platform agnostic data store such as a database, and accessing resources via the database. Although database resources are not supported out of the box by .NET 2.0, it does give you the infrastructure to create your own custom resource provider, and there is an excellent example of this written by the very smart Michèle Leroux Bustamante, accessible at http://msdn2.microsoft.com/en-us/library/aa905797.aspx. Other applications in your enterprise, .NET or not, can then access these resources.

Another platform agnostic approach could be a web-services based approach for accessing resources. In this model, the shared resources could themselves be file system or database housed, and more importantly system access to resource keys would then be via your own web-service API.

Regardless of the scope of re-use, always thoroughly research and understand the performance implications of each, and design accordingly.

Avoid using standard .resx files for larger chunks of content
Larger chunks of content such as entire paragraphs, or content with complex formatting, or that is highly dependent on larger groups of content should be stored in separate, non-resx file on the file system. Ideally you keep your .resx files housed with smaller chunks of content. This will help to keep your .resx files reasonably "clean" and easier to work with, and more manageable over time.

Should you take this approach, you must remember that it is your responsibility to devise an approach to present the correct file system content based on the current UI culture of your application. You may consider alternative file system formats for storing this type of content. One approach could be a templating system that you devise, perhaps leveraging a template engine such as http://nvelocity.sourceforge.net/ But with a templating engine you will run into some inflexibilities such as not being able to utilize user controls within your template chunks. Thus I would recommend sticking to a user control template approach.

It is your responsibility to then load the correct translated content chunk, fall back to an alternative should your requirements necessitate this, etc. I may provide an example of this in the future, but would be happy if anyone has an example of this that they can share.

Happy Localizing!!!