ASP.NET localizer

We are looking at how to best localize the static content of a packed ASP.NET app. The current idea is to use resource files and satellite assemblies to localize the texts in the web pages. 

Most examples seem to use one big resource file for the app and manually create an ID for text strings in the resx file. Then this is wired together. Either explicitly in code by calling rm.GetString(ID) or by creating a property on the control for specifying the ID and using a framework class or inherited control that read from the resource manger.
This all seems a bit tedious.

We have looked at a tool called ASP.NET Localizer (http://www.winformreports.co.uk/features_loc.htm). It has a control you can drop onto the form. It then stores all texts and other translatable properties of the built in web controls in the resx file created for the ASP.NET page. If you change the language in the designer, it creates a new resx file for that language and stores all properties you translate in the appropriate resx file. At runtime it reads the properties for the controls from the resx file. Seems pretty cool. Thoughts?

3 Comments

  • I implemented a pattern very similar to what ASP.NET 2.0 provides. All of our pages/controls inherit from a base class that provides a method that handles resolving a specific resource. The resources are organized by type (control/page). The base class resolves/caches the resource manager using the codebehind type of the page/control. Then in "code-in-front" (meaning the aspx or ascx) we use the databinding syntax to bind the properties to the resource. It would look a little bit like this if we were putting some resourced content into a LiteralControl on our page:



    <asp:Literal runat="server" Text='<%# base.GetResourceString("MyResourcedStringName") %>' />

  • My own apps use the database and cache the strings. No need to recompile for a change, and changes can be made by non-programmers.

  • I have the same advise as Richard. The whole .NET suggested way seems to be fine, but ist is sometimes hard to handle. If you have a "powerfull" sql server in the backend, you migth try to go that way.



    store all language data in the database. the greatest benefit is that you could build a simple web app to get the translation. one window the app an on the other window the translation tool (1 page lists all resource strings and the second page is for editing.



    one tip... in every try to get a localized strinbg from the db, i'll check if the ressource string is in, and if not i will do a insert. to the guy localizing is seeing all resources without my help. it is not allways perfect but with caching it meets my requirements.



    bye marco

Comments have been disabled for this content.