How to create language satellite DLLs for C ++ solution (MSVC 2008)?

Question

We finally localize our application and need to create satellite DLLs for string tables (a month-long process using hard-coded strings from the source code).

I looked at MSDN and other help, but I'm pretty confused about the mechanism for creating DLLs.

We have English resources in the exe itself. In my opinion, we now need to create the DLL project (s) called MyAPPXXX.dll.

I'm not sure how we should do this. Is there only one resource file / rc and different sections in the file, or is the rc file copied for each language with replaced translations?

I get lost trying to follow the instructions that I see elsewhere on how to do this.

Do we need one DLL for each language or do we have the same project with several configurations - and if the latter, how to do it?

Here is a list of the pages I read about this, but conflicting information and my ignorance leave 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/wp/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://support.microsoft.com/kb/188659

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

EDIT:

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

Answer 1

You may have more than one .rc file. The only build environment from MS where this does not seem to be resolved is WDK (a set of drivers for Windows), but there you can get around it with the #include statements.

In fact, the way you combine or individual languages ​​is completely up to you. Resources have a language identifier with them (you specify it in the form LANGUAGE LANG_ITALIAN, SUBLANG_ITALIAN , although winnt.rh , winres.h or afxres.h can be included for symbolic language names), so there can be several languages ​​transferred to the same DLL. You can also define a set of core languages ​​in .exe and split other languages ​​into one .dll file each.

However, in the past there were problems with the choice of language (if this was not done explicitly by the user), so MS introduced MUI in Vista.

In my deployments, the best choice so far has always been one language for each DLL and one "main language" in .exe.

I also prefer separate .rc files in one language, but without a doubt, you can achieve the same using #ifdef ...

NB: you did not see your update with links, now viewing them ...

---

Your first link, “Creating DLLs for resources only”, offers me to add one more small fact. Since there is no entry point and no code in such a DLL, you can use the DLL compiled for x86 in the x64 process. LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE also allow it for files containing code.

---

Well, what is included in the .rc files? Typically, .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, on which it depends, depends. If you don’t have menus and dialogs that require translation, you simply put the language-specific string tables on a single .rc file and build the .dll from it (if you use /noentry whatever you need). However, if you have elements other than bare lines that require translation, you will also have to include them (usually dialogs and menus are among the most common). In this case, you can adjust the size and position of the control in one language. But be careful, maintenance costs for this can be significant. There may be better solutions for this, for example, wxWidgets uses so-called bagged devices to accommodate long strings.