Soluling home   Document home

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.

• Localization process
• Resource files
• Portable executable
• Create project
• Translate the project and use the visual dialog editor
• Windows 32-bit vs Windows 64-bi
• Build localized files
• MFC and Ribbon
• Initial language of an MFC application
• Windows development tools

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.

The executable file localization method is the recommended method.

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.

C:\Sample\Application.exe

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

C:\Sample\de\Application.exe

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.

C:\Sample\fr\Application.exe

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.

Remaining of this page shows how to localize your Visual C++ applications using Soluling.

Create a project

Start Soluling. Click New from File or Files button in the main view or drag and drop your application's file (.exe/.dll) on the main view. Soluling starts the Project Wizard that collects the information needed to create a new Soluling project. The first sheet of the wizard is the Resources sheet.

This sheet lets you select the resource types you want to localize. Most applications only need Strings and Dialogs resources to be localized. Depending on your application, you might want to localize other resources, such as images and version resources. Click Next. If you have existing localized files, Soluling detects them and shows the Import existing localized files sheet.

If you want to import the translations from the existing file, keep all checkbox checked and click Next. Select Languages sheet appears.

Add the languages you want to localize to. Later you can add new languages at any time. Soluling tries to detect your original language. If it is not right, select it from the list. If the original language is country-specific such as English (United States), you can make it country neutral by clicking the scissors icon. Click Finish to complete the wizard.

Now your project is created, and you can start translating it.

Translate the project and use the visual dialog editor

Follow the general translate instructions to translate your project. When you have translated the project, you can build the localized files.

Soluling has a visual form editor for Windows dialog resources. It will be automatically shown when you select a form resource from the project tree. You can use the dialog editor to change the layout of the form. If you want to move or resize a control, use the mouse to select it. Then use either the mouse or keyboard to move or resize the selected item. If you use the mouse, drag the component to move it. To resize, drag one of its trackers. To move using the keyboard, press the Ctrl+arrow key. To resize, press the Shift+arrow key.

You can also change the layout properties (e.g., Left, Top, Width, Height) from the grid. However, by default, the grid does not show those properties. You have to turn them on. Right-click the grid and then select Filter. Select Data types sheet and check the Coordinate check box.

Now the grid shows the coordinate properties, and you can change them.

Windows 32-bit vs Windows 64-bit

Visual C++ supports both 32-bit and 64-bit applications. You don't need a separate Soluling project for each application file variant, or you don't have to all variant files into the same project file. Add either 32-bit or 64-bit application file and then add the other files as platform files.

• Open the source dialog: select the .exe file in the project tree, right-click and choose Properties.
• Select Platform files sheet.
• Click Add button and browse the matching platform 32-bit .exe file.

As a result, the 64-bit .exe has been added as a source and the 32-bit .exe as a platform file.

The advantage of the platform files over a separate project or two .exe files in a project is that you don't get multiple strings rows. If the same string exists both in 32-bit and 64-bit, only one row is added. This makes translation work easier. You can add any number of platform files. Just make sure that each EXE file you add is a result of the same Visual C++ project file. In addition to 32-bit, you might have Debug/Release EXEs or an EXE using different conditional compiling. Read more about the platform files.

Build localized files

Final step is to build localized files. Choose Home | Build All to build the localized files. Soluling can create four kinds of localized files for your application or library. They are:

By default, Soluling creates localized files. You can configure Soluling to create any combination of the above files in the Output sheet.

MFC and Ribbon

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:

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