How do I create language satellite DLLs for a C++ (MSVC 2008) solution?

We are finally localizing our application and need to create satellite DLLs for the string tables (a month long process taking hard-coded strings out of the source code).

I have been looking at the MSDN and other help but I am quite confused about the mechanics of actually building the language DLLs.

We have English resources in the EXE itself. From my understanding we now need to create DLL project(s) that are named MyAPPXXX.dll.

I am not sure how we should do that. Is there just ONE resource/rc file and different sections in the file, or is the rc file copied for each language with the translations substituted?

I get lost trying to follow the instructions I see in other places about how to do this.

Is one DLL needed for each language, or do we have the same project with multiple configurations - and if the latter how is that done?

Here is a list of pages I have read about this - but the conflicting information and my ignorance leaves me confused:

http://msdn.microsoft.com/en-us/library/24b2tcy0%28vs.71%29.aspx

http://msdn.microsoft.com/en-us/library/8fkteez0%28vs.71%29.aspx

http://www.codeproject.com/KB/locale/multilingual.aspx

http://www.codeproject.com/KB/cpp/mult_lang_support.aspx

http://www.codeproject.com/KB/locale/MultiLangSupportMFCExtDLL.aspx

http://support.microsoft.com/kb/198846

http://www.codeguru.com/cpp/w-p/dll/mixeddlls/article.php/c12069

http://www.codejock.com/support/articles/mfc/general/g_multilang.asp

http://msdn.microsoft.com/en-us/library/aa645513%28v=vs.71%29.aspx

http://s开发者_JS百科upport.microsoft.com/kb/188659

http://msdn.microsoft.com/en-us/library/x6h91d9w.aspx

EDIT:

Can I just have different sections of an rc file for different languages or do I have to make copies of the rc file - one for each language dll?

---

You can have more than one .rc file. The only build environment from MS where this does not seem to be allowed is the WDK (Windows Driver Kit), but there you can work around it using #include statements.

Actually the way you combine or separate languages is entirely up to you. Resources have a language identifier coming with them (you give that in the form LANGUAGE LANG_ITALIAN, SUBLANG_ITALIAN, though winnt.rh, winres.h or afxres.h may have to be included for the symbolic names of the languages), so multiple languages can be carried in one DLL. You can also define a set of core languages within the .exe and separate the other languages into one .dll file each.

However, in the past there have been problems with how the language was picked (if that wasn't done explicitly by the user), which is why MS introduced the MUI support in Vista.

In my deployments the best choice so far was always one language per DLL and one "core language" in the .exe.

I also prefer separate .rc files per language, but one can undoubtedly achieve the same using #ifdef ...

NB: didn't see your update with the links, skimming over them now ...

---

Your first link, "Creating a Resource-Only DLL", prompts me to add another small fact. Since such a DLL has no entry point and no code, it is possible to use a DLL compiled for x86 in a x64 process. LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE will also allow it for files which do contain code.

---

Okay, what goes into the .rc files? Generally the .rc files will look something like this:

// ...
#include "afxres.h"
// ...
LANGUAGE LANG_*, SUBLANG_*

IDR_MAINFRAME MENU
// ... language-specific menu entries

IDD_ABOUTBOX DIALOGEX 0, 0, ...
// ... language specific pre-filled dialogs, control sizes adjusted and all

STRINGTABLE
// ... language-specific *strings*
END

So, the answer what goes where depends. If you don't have menus and dialogs that require translation, you are fine simply putting the language-specific string tables one per .rc file and build the .dll from that (if you use /noentry that's all it takes). However, if you have other items than bare strings that would require translation, you'd have to include those as well (usually dialogs and menus are among the more common ones). In this case you can adjust the control sizes and positions per-language. But be warned, the maintenance cost for this can be considerable. There can be better solutions for this, wxWidgets uses a so-called bag-sizers to accommodate for long strings, for example.