n-Tiered .NET application localization guidelines

Question

I would like to get some of your ideas about

• resource name / categorizing
• place of resources

Let me just give you the scope of the application:

• 3 or more supported languages
• 3 MVC websites [with a lot of shared resources, and also some unique resources]
• 1 shared MVC extensions library
• 1 core business library, which has shared functionality, and business objects [also contains resources]
• 3 business libraries that have specific business logic for the three websites [also with resources]
• 1 SQL 2008 database shared among all websites, sends sometimes localized emails.

I would like for it to be easily maintainable (so also easily exported/imported for translation), not to be duplicate (since we have common resources), and understandable for everybody that comes in contact with the code

Place of the resources:

• should I create one assembly containing all the translations? And create a reference to that assembly in my projects (even if possible adding it to SQL server)?
• or should I use source control to keep all the resource files in sync?
• some other ideas?

resource name / categorizing:

So we have localized emails, text on buttons (command like texts), labels, error messages, information messages etc etc.

How do you categorize these items into resources files, do you just dump them all in one file? Or do you categorize them into a strings , and an emails resource files, which categorization do you use?

Answer 1

One assembly containing all the translations is a problem, since it means all your assemblies are coupled to that single assembly.

What we usually do is have each assembly have its own resources, and then generate and translate a single .pot file from all referenced projects (there is a nant script which does that).

Answer 2

As Groo mentioned, one mega-assembly would be a bad a idea since it would cause a coupling issue. For example, if you wanted to change the button text in web site 1, you'd have to update that assembly, which then causes an update to web sites 2 and 3, even though 2 and 3 didn't need any changes at all. Just like with anything else, you want to isolate your changes where possible so that if something breaks, it breaks as little as possible.

I would define your assemblies so that you can share some as needed, but have others that contain resources needed only for individual projects. From the description you've given, here is how I would structure your resources:

• 1 UI-related resource file shared across web sites
• 3 site-specific UI-related resource files
• 1 business logic-related resource file in the core library
• 3 site-specific business logic-related resource files, stored in their respective business logic projects

In some cases above I may have mixed up where you just need a resource file and where you need a full standalone assembly, but the division of resources is essentially the same. And of course, you'll need one copy of each of the above files per language.

I would absolutely recommend storing these files in source control. They're a part of the source of your app, just like the code, and source control will give you the same benefits.

Regarding SQL Server, when you say that it sends localized e-mails, do you mean that it does that through a stored procedure, or that some other code uses data from the database to send e-mails? Either way, I don't have much of an answer. I don't know how SQL Server itself handles localization, and if it's an app that's sending the e-mails, it depends a lot on where the localized text needs to come from.

Finally, regarding your question on categorizing the resources, it really just depends on what seems the most natural to you and (I assume) your team. From what you've described, it sounds like you might want to split your resources out into text that will be shown on web pages, and text that will be included in emails, but it's hard to say. This is a very personal choice, and it has no effect on the code other than making it easier for everyone to find the resource they're looking for, so just go with what makes the most sense to you.

Answer 3

We have a similar system setup; What we use is a database just for the text. Then we have a common assembly that provides methods to get localized strings along with a custom expression provider so we can use standard <%$ Resources:zzzz %> syntax inside aspx/ascx files.

Our database is set up so we can provide a default text for a token, along with a localized version and an application (eg, simplified our "Translation" table has the following columns: (Token, Locale, Application, NativeText) ). This way we can provide overrides for specific applications if we need to.

This has the advantage that we can also provide a Translation Editor (we don't currently, but it is a possible future option), and also exporting/importing translations isn't too bad (not claiming that it is without fault - I think translation is going to be a hard topic no matter what).

We do still use standard resource files, but only for strings that are truly application specific and also unlikely to change; I'd advise against this. It just means we can't create the list of strings to translate as easily.