Internationalization in MFC

Question

It's finally (after years of postponing) the time to localize my app in a few other languages other than English.

The first challenge is to design the integration into my C++ / MFC application that has dozens of dialogs and countless strings. I came across two possible alternative implementations:

1. Compile and deploy localized resource files as DLLs
2. Extract and replace all strings with the localized version. For each language there will be an XML (or simple text) file.

Personally I opt for the second alternative since it seems to me more flexible. The changes are many but not hard to make, and very importantly the XML files will be very easy to modify for the translators.

Any advise is greatly appreciated.

Regards,
Cosmin Unguru
http://www.batchphoto.com/

Answer 1

I did some long-living MFC projects with different languages. I strongly recommend the first approach with resource-only DLLs.

The reasons:

(1) If the user does a XCOPY install, he always has the default language (English) in the main executables.

(2) If you don't translate everything (e.g. you're late with your release or forget some strings), the Windows resource functions if properly used return the resource in the default language automatically - you don't have to implement it on your own.

(3) My very person opinion: (a) Line breaks, tabs, whitespaces in XML files are a pain in your a**. (b) Merging XML files is even worse...

(4) Don't forget the encoding. It's okay in XML but your translators might use an unsuitable editor and damage the file.

And now for the main reason:

(5) You will have to rearrange many of your dialogs, because many strings are longer in e.g. French or German than in English. And making all statics, buttons, ... larger "just in case" looks crappy.

Another hint: Spend some bucks and buy one of the translation tools which import your projects / binaries and build up a translation database. This will be amortized after the first release.

Another hint (2): If possible make a release which doesn't contain any changes but only the multi-language feature. Also in future, if possible: Release your product in English. Then do the translation in one single step (per language) and release the other languages.

Answer 2

My good and friendly suggestion from somebody who worked a lot with localization:

1. Grab GNU Gettext,
2. Mark all your strings as _("English").
3. Extract all strings using gettext tool xgettext and compile dictionalries
4. Translate string using great tools like poedit.
5. Use gettext in your project and make your localization life simpler!

You can also use boost::locale for same purpose - it uses GNU Gettext dictionaries and approach but provides different and more powerful runtime and for windows developer it has very good addon - it supports wide strings that MFC requires to use for normal Unicode support.

Don't use resources and other "translation" tools that are total crap from linguistic point of view (and developer's point of view as well).

Further reading: http://cppcms.sourceforge.net/boost_locale/html/tutorial.html

Answer 3

Using a DLL resource library is a relatively straightforward operation, and allows you to manage not only strings, but other resources as well. And this is its main advantage, because i18n is not only about string translation.

However, depending on your needs, a text-based solution may be a better decision, because of its easier handling - resource scripts being more complex than xml files, especially for the average translator.

I would suggest creating your own abstraction layer, something like "LoadLocalizedString", etc.; in this way, you can start implementing it just with text files, and then change to something more complex when and if required in a transparent way - all the effort for making your software i18n aware would still be valid.

Answer 4

In our case we had diffrent dialogues per Language. The resource file was the same as the multiple laguages were implemented at development time. You could basically append on existing resource files the diferent languages. I hope it helps to find your way.

Answer 5

The DLL option is commonly used for this since the resource loading procedure (e.g. LoadLibrary) is already written - meaning you don't have to write any parsing/loading code. While XML is easier to edit, DLLs have a bit more security (users won't be able to easily edit them) and will allow the developer (meaning you) more time to work on application logic instead of writing a language loading system.

HMODULE hLangDLL = LoadLibrary("text_en.dll");
// more stuff
TCHAR mybuffer[1024] = {0};
LoadString(hLangDLL, IDS_MYSTRING, mybuffer, 1023);

Answer 6

If it is just the strings that are changing then I agree that XML is the way forward here for the exact reasons you outline. Easy for other people to edit, easy to change language at runtime, etc.

The only reason (in my eyes) that you'd choose option 1 is if things other than strings are being localized such as needing different icons.

If it's just text? I say go with the XML.