How to handle hundreds of .resx files

We are implementing a large system based on smart clients at the top. One of the demands fore the project is that the gui must support several languages. Let say we have 100 forms and 4 languages for each, that will be 400 forms... which is not that maintainable..

What is best practice for this kind of work? Maybe use a "master.resx" ? Anyone have a good solution or comments ?

What we did for our applications: create a custom translation system. We don't use the resx files for translating. Some of our applications are ClickOnce-deployed smart clients that talk to a web service. When loading a form, the client asks the server for the translations (and other stuff) of the specified form. The biggest advantage is the dynamic nature. We can easily modify translations without having to recompile and redeploy the client. The disadvantage is that you can't translate the forms in the Visual Studio designer. We have a database, with a specialized tool to manage our applications, the security of the client and server, the translations, ...

I have worked on systems where translation strings were kept in a central database and passed out through a centralised translation process.

It still gets unwieldy just through the sheer volume of strings to remember:
'OK, so now I need to tell the user that the connection failed.  Wait, what's the name of that string again?'

I always felt that a good naming convention would have saved a lot of issues and maybe splitting things out by form might have made things a little easier to find.


It's good that you're thinking this through at the start, rather than halfway through the project.


Herbie

In our system, we have 1 table for system messages (error messages, ...) and a table with prepared translations for the forms, which has 1 record for each type of form, where the translations are stored as XML (1 column per language, 1 XML-fragment per language). Our management tool allows us to enter the translations in grid controls, and when we publish, the hierarchical data is flattened, the XML fragments are generated and stored in the table. When the client asks for the translations of a form, the server just sends the right XML-fragment to the client.

TommyCarlier wrote:

What we did for our applications: create a custom translation system. We don't use the resx files for translating. Some of our applications are ClickOnce-deployed smart clients that talk to a web service. When loading a form, the client asks the server for the translations (and other stuff) of the specified form. The biggest advantage is the dynamic nature. We can easily modify translations without having to recompile and redeploy the client. The disadvantage is that you can't translate the forms in the Visual Studio designer. We have a database, with a specialized tool to manage our applications, the security of the client and server, the translations, ...