Soluling home   Document home

Visual C++

Visual C++ Localization and Internationalization

Visual C++ (Wikipedia) is a popular Windows development IDE. Soluling localization tool and service support Visual C++ and MFC.

The following chapters describe Visual C++ localization step by step.

The end of the document contains links to get the full source code of the samples. After reading this document, we recommend reading a tutorial about how to use Soluling.

Localization Process

You can localize Visual C++ applications using the following methods:

1. Executable file localization method

The first way to localize a Visual C++ project is to add an executable file into a Soluling project. Soluling reads the file to locate all the resource data it contains. When building, Soluling creates localized executable files. There is one output file for each language. You don't need to have the source code files. The only file you need is the original executable file.

2. Resource file localization method

Another localization method is to localize each resource file (.rc). Soluling reads the file to locate all the resource data it contains. When building, Soluling creates localized resource files. There is one output file for each language.

Resource files

Visual C++ applications use the standard Windows resources. They are defined in one or more .rc files. There are several resource types such as string, menu, and dialog resources. When Visual Studio compiles your application is also compiles the .rc files into the .res files. .res file is the binary version of the .rc file. The .res files are then linked into the final output file: portable executable.

Portable Executable

Windows (Wikipedia) application is a file that has an EXE file extension. In addition to an EXE file, it can contain any number of dynamic library files (.DLL). The format of EXE and DLL files is the same Windows Portable Executable, PE, (Wikipedia). A PE file contains compiled code and resources. You can not change the compiled code after it has been compiled from the source code, but it is possible to change the resource data. Soluling's Windows localization is based on changing of resource data inside the PE file. Similar file formats are ELF that is used in Linux, and Mach-O that is used in OS X and iOS.

The following picture shows the structure of a PE file. It contains two segments: compiled code segment and resource segment. The resources are in English.


If we want to localize this application into German, we need to replace the English resources with German ones.


The important thing here is that the code segment is exactly the same as in the original English PE file. Only the resource segment has been modified. It contains the same resource items as the original file, but each item contains German data (e.g., German text). In the same way, if we want to localize the application into French, we need to replace the resources with French ones.


In the above sample, we copied the original PE file and replaced the resources inside the PE file. This is the simplest way to localize Windows applications. The only thing you have to do is to properly internationalize your application. If you have already done it, you don't have to change your source code. You don't even have to recompile your application. This method is the default localization method of Windows application in Soluling.

There is another way to localize Windows applications. Instead of coping the PE file itself, we can copy only the resource data and store it inside a resource DLL. It is a special DLL that contains no code but only resource data. Resource DLLs are used to store localized resources. You can not run a resource DLL, but it is always used by the original PE file (exe or dll).

The format of the DLL is still a Windows PE file, but it contains only resource data. It can not be started, but the application can load and use its resources instead of the resources of the application file.

If you deploy the original application (e.g., C:\Sample\Application.exe) and the German resource DLL (e.g., C:\Sample\Application.DEU), the application has two choices where to load the resources: either from the application file itself or from German resource DLL. What choice to use depends on the application, framework, and the operating system where you run the application. In most cases, the framework you use (e.g., MFC or VCL) automatically looks for a resource DLL matching the system locale of the computer. However, you can add your own code that makes the decision of what resource DLL to load. Soluling comes with lots of code to access resources and even perform runtime language switches.

The following sample contains the original application file and three resource DLLs. This makes it possible to start the same application either in English, German, French, or Japanese.

By using resource DLLs, you can save disk space, and what is more important the application can choose the initial language it uses when it starts.

If your application is written in Delphi and you have added Soluling's NtTranslator unit into your application, the above application can start in any above language, and the user can change the language on run time.


MFC adds MFC-specific resource types such as RibbonBar.


If you use the executable file localization, then the ribbon resource is stored as RT_RIBBON_XML resource inside your .exe or .dll file. Check the Ribbon resource in the resource sheet, and Soluling scans the resource, and you can translate the strings.

If you use the resource file localization, then the ribbon file is a standalone file (e.g., res\ribbon.mfcribbon-ms). Add the file to your Soluling project in addition to the .rc file. Soluling scans the resource, and you can translate the strings.

Initial language of an MFC application

If you use MFC, you can take use MFC's automatic resource DLL loading.

MFC attempts to load the resource DLL for each of the following languages in order, stopping when it finds one:

  1. The current user's default UI language, as returned from the GetUserDefaultUILanguage() Win32 API.
  2. The current user's default UI language, without any specific sublanguage (that is, ENC [Canadian English] becomes ENU [U.S. English]).
  3. The system's default UI language. On Windows 2000 or later, this is returned from the GetSystemDefaultUILanguage() API. On other platforms, this is the language of the OS itself.
  4. The system's default UI language, without any specific sublanguage.
  5. A fake language with the 3-letter code LOC.

If MFC does not find any satellite DLLs, it uses whatever resources are contained in the application itself.

Windows development tools

There are several development tools for unmanaded Windows. Most important are:

Compiler Description Resources Is compiler supported
Visual C++
Visual Studio
Microsoft's C/C++ development tool. Standard Windows resources and
optionally MFC resources
Fully supported
Delphi Embarcadero's Pascal-based RAD development tool. Standard Windows resources and
VCL form resources
Fully supported from Delphi version 7.
Delphi 2-6: Not officially supported but can be used to localize most applications written in these older 32-bit Delphi versions.
C++Builder As Delphi but uses C++ as programming languages instead of Pascal, Standard Windows resources and
VCL form resources
Fully supported from C++Builder version 7.

If you use managed Windows development read .NET, Windows Forms and WPF tutorials.