Cleanup patch 2 - dynamically loaded languages

[Patch date 2003-06-05 19:30]

This patch has three goals:

To reduce the amount of data in emule.rc, so that it'll become faster to load and easier to manage. Also, looks like Galician (es_GL) is not supported under Win2k, so it was impossible to open emule.rc for editing in resource tool.

To split stringtables in logical, easy to manage units - one language => one stringtables, one file, one project.

To reduce the amount of static resource data needed to compile into the executable. Smaller executable is easier to distribute.

To allow different kinds of stringtable storage and loading methods to be explored. This patch adds a new language library that handles all identifier to string mapping.

For this end, I created a subdirectory, "lang", under emule source directory. Another logical place for this directory could be beside emule source directory, as stringtables are rarely changed by modders, so they really don't need to distribute the language library with the source code package.

In the new language directory, I placed all stringtable projects and resources, as well as language library project. To emule solution I added the language library project only - otherwise it'd be cluttered by a very large number of projects and resource files. Also, that's the only language project that produces external code emule project depends on - the language library itself. This dependency was brought to solution dependencies. It's adviced that you first build the language solution, thus producing all language dll's, and then build emule solution. You only need to build the language solution once if you don't change it, and can copy the directory as is, with all compiled files to under another emule solution if you so wish. eMule solution will build release and debug versions of the language library as needed.

Now that all stringtable resources have been moved, of course the string identifiers had to be removed from resource.h. Also, lang/lang.rc was added to emule.rc includes. If I knew how to get statically linked resources to be linked into the main application via language library, adding language resources as include to emule application resources would be unnecessary. If someone knows how to do it, please contact me on emule-project forums or at #emule@LiquidIRC - my username in both would be Elandal.

Changes in code were pretty straightforward:

In emule.h, added include, a new member stringLocalizer, and a new method ExitInstance().

In emule.cpp, added initialization of stringLocalizer to InitInstance() after CWinApp::InitInstance(). Added implementation of ExitInstance() that destroys stringLocalizer. In OnHelp(), changed MAKELANGID(...) to LANGID_EN_US now that the library includes provide these handy defines.

In Preferences.h, removed method CPreferences::SetLanguage().

In Preferences.cpp, removed implementation of method CPreferences::SetLanguage(), as it's now provided by language library. In CPreferences::LoadPreferences(), changed reference to SetLanguage() to use language library.

In PPgGeneral.cpp, added include and changed CPPgGeneral::OnInitDialog() to refer to the new CStringLocalizer class provided in the language library. In CPPgGeneral::OnApply() changed reference to SetLanguage() to use language library.

In HttpDownloadDlg.cpp, added include.

In otherfunctions.h removed GetResString().

In otherfunctions.cpp, removed implementations of GetResString().

After that, global search and replace GetResString to theApp.stringLocalizer->GetString (1748 occurences).

There is absolutely no point in providing a changed files package or a patch, as that global search & replace touched nearly all files anyway.

I did have trouble with Galician (gl_ES), with the language showing as "Greek" in language selection. As VS documentation notes this locale as "Windows XP", I guess it's not and won't be supported in Win2k or any other Windows version before XP. Adding a runtime check for OS version might be a good idea.