Global resource vs. Local resource in ASP.NET

Question

We use resx files to localize our web applications. We usually create local resx files (that map to a specific page) when only one page uses a certain phrase, and a global resx file when more than one page needs the phrase.
But the good thing about global resx files is that they are a class, and you can call the phrases like you call properties of a class:

Resource.UI.iNotFound

So I was thinking - why have local resx files at all? why not use one global resx file for the whole application, and that way avoid runtime errors from calling non-existent phrases?

I'm sure there's a good answer for that, I just don't know what it is....

Answer 1

I kept on looking for guidelines, and found this in MSDN:

Choosing Between Global and Local Resource Files

You can use any combination of global and local resource files in the Web application. Generally, you add resources to a global resource file when you want to share the resources between pages. Resources in global resource files are also strongly typed for when you want to access the files programmatically.

However, global resource files can become large, if you store all localized resources in them. Global resource files can also be more difficult to manage, if more than one developer is working on different pages but in a single resource file.

Local resource files make it easier to manage resources for a single ASP.NET Web page. But you cannot share resources between pages. Additionally, you might create lots of local resource files, if you have many pages that must be localized into many languages. If sites are large with many folders and languages, local resources can quickly expand the number of assemblies in the application domain.

When you make a change to a default resource file, either local or global, ASP.NET recompiles the resources and restarts the ASP.NET application. This can affect the overall performance of your site. If you add satellite resource files, it does not cause a recompilation of resources, but the ASP.NET application will restart.

So it seems that it's really up to the programming team to weigh the pros and cons of each method and choose what's good for them.

Answer 2

Joe90 - I have to say that in my experience, I can't agree that managing lots of local resource files scattered throughout your whole project is easier than managing one, global resource file. There is nothing to stop repetition of the same translations again and again and they are very difficult to track down. Access to the Global resource file is very easy to co-ordinate within a team and multiple users can see at a glance whether their required translation has already been done.

I started off with exactly the same policy as Lea - i.e. start with a local resource file and then move this to a global resource file if it was referenced more than once. This soon became loads of hassle to manage and I've since moved to using global resource files every time now.

There don't seem to be any clear guidelines by Microsoft as to what the best practice is, or even, how the two methods are implemented so that we can hazard a guess!

I'm guessing the comparison/payoff is that local resource files only require a recompile of the file they relate to, whereas changing a global resource file seems to require a recompile of the whole web site - with an inherent loss of session state etc. so requires taking the site offline during the update to be safe.