Application Localization in MFC

You can localize your MFC application using several different ways, such as translation of resource (rc) files, binary localization of executable files and creation of resource-only DLLs.

Translation of resource (*.rc) files

Although translation of resource files is a way recommended by Microsoft in MSDN documentation, I would recommend against this approach for several reasons. It is difficult for not-developers to translate *.rc files, even small mistake in translated resource file is very difficult to fix and it is difficult to maintain translated versions current. Microsoft itself does not utilize this way for translation of their applications.

First, even though somebody can translate *.rc file using only simple text editor, he/she would not be able to check or test his translations. To run localized application after translation of resource files, you have to substitute original rc files with translated files, compile entire application and only then run it. If translator makes a mistake and, for example, inadvertently change ID in dialog or menu, to find this bug, you would have to retest all GUI often in language not familiar either to you or to your testing team.

After you translated your rc files without mistakes and shipped translated application to happy customers, you find several small bugs in your application. If to fix those bugs you need to make small changes in interface, that means you have to change not only original resource files, but also all translated resource files. If you release next version of your application, this problem is even more exacerbated.

Binary localization of *.exe file

Binary localization resolves many problems that arise when you translate your application's resource files. First, in most cases you do not need to make any changes to the source code, except for placing all strings in resources. Then all translator needs to localize application is a binary file, you do not have to install development framework on his computer and send him all the source code.

If you are using specialized tools, such as Lingobit Localizer, maintaining translated version of software up-to-date is very easy, and in most cases, after changing original application you need to translate only new and modified strings.

If you do binary localization of executable file, in the end you receive one executable file for every translation. Sometimes it is desirable, for example, when you sell your software for different price in different countries. In that case, someone from United States cannot buy and use software for price that you designed for Poland.

Resource-only DLLs

You can do resource-only localization either using translation of resource files or using binary localization. In this article, we would consider only later approach.

Resource-only DLLs has most advantages that you get when you use binary localization and adds that you only have to distribute single executable file. This allows you to create single installation package in which user will choose interface language. Later user can change GUI language.

If you plan to use resource-only you have to be ready to change source code of your application. If you develop your multilingual application with help of Lingobit Localizer, you can use ready multilingual helper dll, that significantly simplifies development. With it, in most cases, you need to add only minimal amount of code to your application.