.resx vs database vs custom solution for providing Localization/Globalization

Question

At my office, we have had a long-standing debate about Localization/Globalization and how to handle it. One side pushes for the Resource (.resx) file route built in to ASP.N

Answer 1

Localizing user interface should not be stored in database, it is preferable to use the standard resx method because this will give you the flexibility to customize the user interface of front end for each client/deployment, without the need to change the back end or store much data about each client customization in database.

Regarding data (bi-lingual data or multi-lingual data) store them in database and use whatever technique suitable for the context (table per language, or duplicate columns for each language).

Answer 2

using resx is the best approach for some static values that needs not to be manipulated via UI of the app but if your values needs to be updated DB driven would be the best for it. For me its still a case to case basis. But one of the blogs I have seen in the internet made the resx files updateable via user interface.. http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html.. hope this would help you.

Answer 3

As all the above are true, I want to add some additional insights.

I tend to use .resx based localisation, when working on "static" projects/websites like Dashboards or other small websites, which are focused on a specific usergroup.

When working on larger and more "dynamic" projects like shops, service-offerings, etc. (esp. when content is localized - not only labels) I like to use database localisation.

When you are developing on larger projects each language is maintained by another person, who is not necessarily in your project (especially in community-projects). Thus maintenance of different languages becomes a real hassle. On the other side providing users some good/easy UI to update their language is time-consuming as well. So try to find a good path for your project.

Answer 4

As you perhaps know, default method (which is actually industry best practice) for Localizing .Net Applications is using resource files (.resx in this case). If you want to use database, you would have to write your own ResourceManager.

From this, the answer should be obvious: use standard and do not reinvent the wheel.

You might be wondering why Localization via resource files became industry-wide standard. Well, there are many reasons (too many to mention here), most of them regard to Localization process. The key one is, it is painfully hard to update (i.e. fix or install) translations for database driven Localization. Just think of what you need to install it - some SQL script. You know what will happen if you send out this for translation? Or even mistakenly update it? These kind of files are not very safe to work with (and they tend to be very large), so either you would need to create some kind of generator (with resource-like file as an input, which totally bits the purpose...) or you would need to be very careful (and pray that a translator won't break the file).

That is to say, database-driven Localization is sometimes the only sensible way of doing things - this is when you need to implement so-called dynamic Localization, that is allow users to translate things or add their contents in multiple languages.
For static Localization (typical scenario) use resource files.

Answer 5

Rick Strahl (An MS MVP) has a great tool kit for managing localization via the DB - offer the ability to update and modify on demand through a controlled environment and does much of the heavy lifting for you. Histoolkit offer the following features:

Data Driven Localization Resource Provider

• Database driven Localization lets you store resources in a SQL Server database.
• Interactive Web based Resource Adminstration provides a live Web based adminstration for that can edit and update resources while the app is running
• Resource Editing Control associates icons with each localizable control and allows jumping directly to the administration form with the current resource id and locale selected.
• Resx Import and Export lets you import existing Resx resources, interactively edit them with the data driven provider, then export them back out as Resx resources.
• Localization Utilities like a JavaScript Resource Handler, functions to embed localized script values and much more.

He also summarises the issues very well here (Ive pasted some good bits here - not my own work!)

To Resx or not to Resx

The default resource storage mechanism in .NET uses Resx based resources. Resx refers to the file extension of XML files that serve as the raw input for resources that are native to .NET. Although XML is the input storage format that you see in Visual Studio and the .Resx files, the final resource format is a binary format (.Resources) that gets compiled into .NET assemblies by the compiler. These compiled resources can be stored either alongside with code in binary assemblies or on their own in resource satellite assemblies whose sole purpose is to provide resources. Typically in .NET the Invariant culture resources are embedded into the base assembly with any other cultures housed in satellite assemblies stored in culture specific sub-directories.

If you’re using Visual Studio the resource compilation process is pretty much automatic – when you add a .Resx file to a project VS.NET automatically compiles the resources and embeds them into assemblies and creates the satellite assemblies along with the required directory structure for each of the supported locales. ASP.NET 2.0 expands on this base process by further automating the resource servicing model and automatically compiling Resx resources that are found App_GlobalResources and App_LocalResources and making them available to the application with a Resource Provider that’s specific to ASP.NET. The resource provider makes resource access easier and more consistent from within ASP.NET apps.

The .NET framework itself uses .Resx resources to serve localized content so it seems only natural that the tools the framework provides make resource creation tools available to serve this same model.

Resx works well enough, but it’s not very flexible when it comes to actually editing resources. The tool support in Visual Studio is really quite inadequate to support localization because VS doesn’t provide an easy way to cross reference resources across multiple locales. And although ASP.NET’s design editor can help with generating resources initially for all controls on a page – via the Generate Local Resources Tool – it only works with data in the default Invariant Culture Resx file.

Resx Resources are also static – they are after all compiled into an assembly. If you want to make changes to resources you will need to recompile to see those changes. ASP.NET 2.0 introduces Global and Local Resources which can be stored on the server and can be updated dynamically – the ASP.NET compiler can actually compile them at runtime. However, if you use a precompiled Web deployment model the resources still end up being static and cannot be changed at runtime. So once you’re done with compilation the resources are fixed.

Changing resources at runtime may not seem like a big deal, but it can be quite handy during the resource localization process. Wouldn’t it be nice if you could edit resources at runtime, make a change and then actually see that change in the UI immediately?

Using Database Resources

This brings me to storing resources in a database. Databases are by nature more dynamic and you can make changes to data in a database without having to recompile an application. In addition, database data is more easily shared among multiple developers and localizers so it’s easier to make changes to resources in a team environment.

When you think about resource editing it’s basically a data entry task – you need to look up individual resource values, see all the different language variations and then add and edit the values for each of the different locales. While all of this could be done with the XML in the Resx files directly it’s actually much easier to build a front end to a database than XML files scattered all over the place. A database also gives you much more flexibility to display the resource data in different views and makes it easy to do things like batch updates and renames of keys and values.

The good news is that the resource schemes in .NET are not fixed and you can extend them. .NET and ASP.NET 2.0 allow you create custom resource managers (core .NET runtime) and resource providers (ASP.NET 2.0) to serve resources from anywhere including out of a database.