37
votes

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....

4

4 Answers

50
votes

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.

15
votes

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.

7
votes

I have a development team of at least 10 developers on a single product and we are using one global resx for each site.

The problem with merging this big resx file should in my opinion not be a problem.

If you have 10 developers who themselves set the language on the site, how do you get a uniform way to express themselves on the site? Developers often tend to be good at code and not the grammatical expression. (I am a developer myself.)

A language expert should edit resx file and lock it for the developers!

2
votes

A Global Resource file is the best method for translation. The key is use a naming convention, like page name abbreviations for the first few letters of a string name so that you can locate resources per web page basis easily. Trying to reuse many phrases across multiple pages will cause more confusion for the translators.

You can define resuable phrases as much or as little as you want, like Yes, No, BTN_OK, BTN_Cancel, QTN_AreYouSure, etc by using a lack of page naming convention (no page name abbreviations for the first few letters). The majority of your lines of RESX will be specific to each page and you should not focus on trying to reuse as much as possible. Changing one phrase across the entire file can be carefully done in minutes using text find/replace when needed.