This was so interesting, that I had to share it more widely... I'm working with one global customer concerning Internet facing MOSS site, which will eventually have more than 50 local sites within their own languages (including the corporate sites in multiple languages). Translation of the labels used in the sites are based on standard RESX handling, without any custom resource providers.

So basically as part of the solution deployment, the resx files are distributed to app_GlobalResources folder of IIS application in each WFE (requires some extra effort to be automated during deployment, but that's a separate story). The RESX files are not included in to the assemblies to provide more flexible way of updating just the translations without any other changes.

As part of the following releases, there was a requirement to generate the translations for the Caribbean English. You might wonder the business case, but there are certain phrases, which should be translated differently as for the US... similar way as there's different translations for UK. For initial testing, the RESX file with the correct culture information (en-CB) was created. When the file was introduced to the application, whole application came down with following error message.

Compilation Error
Description:
An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0101: The namespace 'Resources' already contains a definition for 'CUSTOMER'

Well... that's interesting, since based on the .NET 2.0 documentation, the en-CB is officially supported locale. I did little bit more digging on the case and found out that there's actually a KB article released concerning issues with few locale codes, if certain security fix has been installed. KB article defines that for example in this case, the locale should be actually en-029. After changing the RESX file name correctly, everything started working again and translations were successful.

 

Improving the translation logic

Obviously the situation declared above was extremely scary. You can pull down the whole farm just by providing wrongly named RESX files. That's not good at all. Actually there's similar implications when the RESX file contains duplicate keys etc. It's of course clear mistake in the RESX, but the fact that the farm will be dropped to it's knees, is simply extremely scary. In our case, we luckily had strict process of getting the new files published in the farm (similar as declared here), so this didn't cause any catastrophic issues to production.

What can you do? - ASP.net provider model to rescue... since we can extend or change the default asp.net functionalities, we can write our own resource provider to manage the different translations. Of course the requirement of having custom provider to be written depends on the requirements for the project - especially on the high availability sense. Depending on the requirements and implementation, you can also define your own logic concerning fall back mechanisms and duplicate keys etc. etc. etc. More information on the resource provider can be found from the following MSDN article.

This approach also provides more flexible ways to provide the translations. By creating a custom resource provider, we could also fairly easily provide UI to update the translations directly for example from the site settings page of the particular country sites. This way the maintenance of the labels can be more easily delegated and managed by the web masters of the particular country sites.

Hopefully this was useful.