Select an approach to localize large .NET applications

Question

I know that Question of Localizing .NET applications asked here many times.

But I am doubt about effectiveness of the approach to use Resources and 3-d party resource editing tools to localizing large .NET applications.

I am thinking about staying with one of the below approaches:

1. Set Localizable=True for all solution forms, and use 3-d party resource editor, for ex: Zeta Resource Editor, to edit and manage resources. Disadvantages:

   • Our solution has ~100 forms, and for 30 extra languages there will be 30*100 = 3000 new resx files!
   • A lot of efforts to interact with translators: I need to send them excel files with plain text after each product update and manually update project resources after each language changes.
   • Part (most?) of the language files will be always outdated, because translators might do their works after product release, and we can't include their changes without recompiling the project.

2. Use custom Dictionary based class (like GNU GetText), that will load an old-fashioned ini file with translations. Disadvantage: need to do an extra job, like writing a helper tool to edit ini files for translators. Advantage: new language versions might be published after product release as a separate ini files.

Unfortunately I can't compare performance of the both ways.

Which approach is better? Please share your experience!

Answer 1

Well, I don't want to get off-topic here of course, but no script that does what needs to be done is simple or trivial by any reasonable definition. The issues involved are far too extensive. The cost of writing even the most trivial script would far exceed the cost of purchasing a full-blown translation app. And that app would almost certainly do far more than a script will (even referring to essential features only).

Answer 2

We use a large excel file with keys in the first column, and one column per language. A little script in the excel document spits out the necessary resx files (one per language), these resx files are then checked into the source tree.

Only the translation assembly will have satellite assemblies, and handles the translations for the entire application. So all other assemblies (UI etc.) will have no satellite assemblies.

In forms we use the keys as texts (for labels, buttons, captions) and recursively translate the forms when shown. For non-control texts we just use a single static class to fetch the translated text given a resource key with code.

This "single file" translation database works very well, and using excel is convenient since your translators probably will already have it installed and are familiar with it.

Answer 3

You really should stick with the standard .NET localization system (ResourceManager).

One way to deal with the problems you are having (managing imports of a lot of .resx files in various languages into your solution, dealing with delays in the delivery of translations) would be to include just one language (English, typically) in your solution but keep localization enabled. So from now on you would build your solution with only English resources, but still with the ability to load satellite assemblies if present.

Then you can set up a different project (call it a localization project) for the sole purpose of managing the translation of your English resources into various languages. You'd have to regularly sync the English resx files from your main solution to your localization project (but then this allows you to do so in a controlled manner, which will help dealing with translators). Translations you receive would be checked into this project's source control system.

Then you'll need to write someting to build your satellite assemblies from your localization project and drop them into your English-only build, giving you a build with all its localizations. Building satellite assemblies from resx files can be done using Resgen.exe (to create .resources files) and then Al.exe (to create the dll files).