views:

1301

answers:

3

I have been given the task of internationalizing a large client-server application. The remit is that I make the app 'World Ready' and then the compiled application and resources gets passed over to colleagues in another country for translation and release to their customers. There will be several countries and therefore several seperate translations.

The key thing here is that I want a simple two step release process: Step 1: I compile and release a 'World Ready' application to my colleagues in the various coutries Step 2: They do the localization of resources and then release to their customers

I don't want to add the extra steps of Make App World Ready -> Send files off for translation -> Wait weeks for the translations to come back -> Compile into App -> Release App.

I have been looking at .NET Globalization and the use of resx file. From what I have seen the resx file gets compiled into the application and therefore can not be changed once compiled. Even satelite assemblies do not seem editible. And even if I am wrong on that point, how would changes to the satelite assemblies be reflected back into the resx files in my project?

So now for the question. Given that I just want to compile the app first and let the translations be handled afterwards, are resx files the right way to go or should I abandon them and write a bespoke database driven solution that can be easily edited after the app has been compiled?

Hope that all makes sense. Look forward to your thoughts.

+2  A: 

Yep, the entire globalization framework in .NET is based of RESX files and the satelite assemblies they create. Once you've compiled the main app, the RESX files can be compiled into their satelite assemblies independently.

I know there are tools out there that aid in the translation process but I'm not famliar with any off them off hand.

Paul Alexander
+5  A: 

Yes, resx files are the best solution.

For translation of the resources you should look at a localization tool, for instance Passolo. It does either

  • take the original resx as input and generates translated resx file which you need to check in to your codebase
  • take compiled assemblies as input and generates satellite assemblies.

We are translating assemblies, because this allows to localize the gui layout as well. To allow an external tool to open a gui editor, it needs the code and this is in the assembly.

If you only focus on test translation, translation of resx is probably simpler to handle.

Such an external tool provides this important functionalities:

  • gather all string together, you not have to handle hundreds of resx files
  • manage translation text of many languages, mostly with gui designer.
  • recognize if a source text changed or has been added, so you now which texts need to be translated.
  • translation of duplicated texts only once.
  • usually nice ui to edit translations.
  • export/import to csv and similar formats to be processed by other tools or even other companies.
Stefan Steinegger
A: 

Check Rick Strahl's resource provider

YordanGeorgiev