Which is a good way to maintain resources for Internationalization in .Net

Question

I have thought of three approaches to create and maintain resources in .Net projects for WinForms using Visual Studio 2008. (I am sure there should be more than three ways.) I need to decide on one before starting to implement internationalization for our product.

• Have individual sets of resource files (resx) for each windows form or piece of UI (a custom control) in each .net project. These are auto generated by Visual Studio when Localizable property is set to true in the form or control properties.
• Have one resource file per .net project. This is added manually and updated manually with the resource strings and messages.
• Have one resource manager project that has resources for all the components for a set of .net projects.

Personally, I do not like the first approach as it creates numerous resources files. The only advantage we get in this approach is that we do not need to set text in UI elements manually.

I like second and third approach as they are easy to maintain and there is only one set of resources that you need to handle. So no duplication of strings and messages. Easy for the translators also.

What are your thoughts? Please share.

Answer 1

If internationalizing your app means more than translating pieces of text you should go with the first one. You can create satellite assemblies to deploy different cultures. This way you are not localizing just text but also images, control layout, etc. This is the way how Microsoft recommends it and they have good reasons for taking this approach.

Answer 2

I've found that the simplest approach to internationalization is to simply maintain a list of all the different pieces of text in your application (labels, buttons, form captions etc.) in a spreadsheet or tab-delimited file of some sort, and then send this file to the translators to add (in one additional column for each language) all the translations.

You then call a simple method in the Load event of each form (which are all maintained in English) that iterates through all the controls on the form recursively and changes their Text properties to the translated values for whichever language you're translating the app into. The language can either be determined programatically (I forget where in the .Net namespace this is indicated), or you can have a simple language selection dialog when the application first starts (the advantage of this second method is that your app can be translated into whatever language the user wishes, without having to set the language for all of Windows - this is especially useful for kiosk applications).

In my opinion, creating and maintaining all the different internationalized versions of every form is a major pain, although it is useful when the translated text values are significantly different in size from the English versions.

Answer 3

Personally, I prefer the first approach because the context (in your case, the forms) is very important for a translator to do his job perfectly. In your second and third approach, the context is gone because it is just a list of strings.

Yes, the first approach can be a pain to maintain but at least your application would be translated correclty.

Answer 4

I have tended to use VS to create the project and provide the default set of resources but then maintain any additional resources outside of visual studio via the SDK tools winres.exe, resgen.exe and al.exe.

You can maintain the resources in a fairly simple folder structure of one folder per culture and just have a batch file or two to build the resources into satellite assemblies. This gives you the advantage of keeping the VS solution to the core product and all localisation can be done after the fact.