ASP.Net Localization (Satellite assemblies vs DB with custom ResourceProvider)

Question

I am looking for the best solution to make it easy to add new languages to an asp.net website without deploying/building the existing code base.

From what I have researched, it seems that you can compile resource files on the fly into Satellite assemblies but I am uncertain how to make the application use these DLL's once generated?

The other option I have seen is to store the translations in the Database, and write a custom ResourceProvider so that the built-in localization methods can be used, whilst abstracting the actual implementation (in this case a database).

Either way, the front end for this site will be the same (meta:resourcekey for the controls etc).

But I am struggling on deciding which approach will be the easiest to upkeep. For example, does publishing a new Satellite Assembly restart the Application Pool or does everything tick over nicely?

EDIT

The translations will be provided by a 3rd party API so human maintenance quality is not important. I thought I would add this due to the answers received.

Answer 1

With Asp.Net (currently) you do not have to compile by your own, you can simply deploy resx files (to App_LocalResources or App_GlobalResources folder) and Asp.Net will take care of compiling them into Satellite Assemblies. That's cool.

With Database approach, you are risking the problems with synchronization: how will you know if given resource string is translated? Also, correcting them is not very easy (for Translators/Localization Engineers). And you would need to prepare "install" script anyway. If that is what you are going to give to translators, good luck. You would face plenty of overtranslations and you would have to correct them (manually?).

Resx files (being simple XML) are a bit easier to validate (it is either valid XML in terms of given XSD or it is not). Besides, it is standard technology, you won't need to implement anything by yourself. That is why, I would recommend it.

---

EDIT

Another issue with Database-driven resources could be character encoding. You would need to create your own translation kit. My experience is, the result might be in several different encodings. Especially, if you want to use plain text file. On the other hand, default encoding of XML files is UTF-8...

Answer 2

RESX

Having around 30+ languages in mit Windows Forms and Web Forms application (this one, if I'm allowed to place a link), I finally had most success with simple RESX files in App_LocalResources.

What I discovered though was that the compilation was extremly slow in VS.NET, so did a slightly modified approach:

1. Have only English RESX files in the VS.NET solution.
2. Have a shadow structure of the website with only the App_LocalResources for all languages, including English in a separate folder, not visible to VS.NET.
3. Write a simple CMD script to copy the real English resources to the separate folder.
4. Use my free tool Zeta Resource Editor to actually translate inside the separate folder.
5. Have a publish script that copies the real web files (like ASPX, ASAX, MASTER, etc.) to the website and also copy the resources to the websites.

This approach makes compilation really fast and still allows me to keep compilation and translations separated.

The drawback is that the first call of the live web application compiles rather long, until now, I figures no way to speed this up/precompile (although I do believe that this is possible).

Database

I also did some projects with localization in database and custom <%#...%> blocks to load the languages.

Today, I would vote against this as it is non-standard. Although it would be probably just as fast to compile, no matter whether 1 or 50 languages are involved.

3rd Party Tools

You also could fetch a commercial product to do the translation, if I could afford, I would have done this most likely, too.

Just my two cent...