We have a software (C++/MFC) that is organized in several projects,
including EXE files and DLLs containing common functionality.
The localization concept we have been using so far was to put all
resources (strings, dialogs, menus, pictures etc.) into one
resource-only DLL, that is addressed from the programs at run-time via
LoadLibrary() and AfxSetResourceHandle(). This made localization easy
insofar as there was one single RC file to translate.

Now we are working on the concept for .Net/C# (managed code). There is a
lot of support for localization in .Net, with satellite DLLs, automatic
selection and fallback - but as far as I understand it, the built-in
concept is a separate satellite DLL for each project, making the
localization process more complicated (you easily forget something!)

An alternative would be to use a separate ResourceManager that reads
from a special resource-only DLL and change all strings at program start
- with the drawback that 1) every string has to be set explicitly
(although with Winforms and C# this is already easier than it would have
been in C++), and 2) you are limited in the kind of resources you can
localize - strings or pictures are OK - but how about dialog and form
geometry?
I am not sure about point 2) - can somebody clarify?

Actually, there is even a third possibility being discussed: if we have
to set every string explicitly anyway, we could as well throw away the
ResourceManager alltogether and put everything into the database - which
would have the advantage that localization could be done with simple
database tools and no localization tool would be necessary - not to be
neglected since localization is mostly done by external partters and
hence should be made as easy as possible.

If possible, we want to use the approach that is built in - but this
seems to conflict with the necessity of easiness for the partners.

What is the best solution here?
--
Hans Straub