Win32 resource scripts
Translate .rc files, or translate what they compile into.
Lingobit Localizer can translate a resource script as text: the quoted strings in .rc and .rc2 files, with everything else left as written. For an application you ship, translating the compiled EXE or DLL usually goes further: you see each dialog, fix its layout, and need no rebuild per language.
.rc files: Professional and higher; EXE and DLL: every edition
- Translated
- The text in double quotes
- Skipped
#include,#define, comments- Encodings
- ANSI, UTF-8, UTF-16, as in the original
- Output
de\MyApp.rcfor each language
On this page
The .rc file or the compiled build?
Both start from the same resources. The difference is what Lingobit can see: text in a script, or the dialogs as Windows draws them.
| The .rc as text | The EXE or DLL | |
|---|---|---|
| What is translated | Every quoted string | Dialogs, menus, string tables, version info, by resource |
| Dialog preview and layout | No | Visual editor: move and resize controls; truncated text is reported |
| Identified by | Place in the file | Resource type and ID |
| Result | A translated .rc you compile for each language | A localized EXE or DLL, or resource-only DLLs, without a rebuild |
| Edition | Professional and higher | Every edition |
The text route fits when the translated .rc itself must go into your repository or into someone else's build. For everything else, start from the build: Win32 / MFC guide.
How the .rc file is translated as text.
Add MyApp.rc or MyApp.rc2 to a project; it opens as C++ source. Each string in double quotes becomes one row in the project table. Create Localized Files writes de\MyApp.rc with the translations in the same places and every other character as it was.
STRINGTABLE
BEGIN
IDS_SAVED "Datei gespeichert." // was "File saved."
IDS_ERROR "%s kann nicht geöffnet werden."
END
IDD_ABOUT DIALOGEX 0, 0, 200, 80
CAPTION "Info über MyApp"
FONT 9, "Segoe UI" // lock: a font name
BEGIN
LTEXT "MyApp Version 1.0", IDC_STATIC, 10, 10, 180, 10
DEFPUSHBUTTON "OK", IDOK, 140, 60, 50, 14
END
What stays your job
- Lock what is not text. Font names, window class names in
CONTROLstatements, and file names are quoted strings too. Locked strings are not translated and not sent to translators. - Language and code page. The
LANGUAGEstatement and#pragma code_pageare not changed; set them in the translated file, or save it as UTF-16. - Layout. Coordinates stay as in the original. A German label that is a third longer needs a wider control, which the text route cannot show you.
- The build. Compile each language's
.rcinto its EXE or resource-only DLL, for every release.
In the next release, Scan for Changes compares the new .rc with the project. Because strings are found by their place in the file, a moved or edited string can come back as new; translation memory then suggests its old translation.
Recommended
Translate the compiled build instead.
Add MyApp.exe or the DLLs to the project. Lingobit reads the dialogs, menus, and string tables the resource compiler put there, by resource type and ID, and shows each dialog in the visual editor.
- See the dialog: type the translation in place, then move and resize controls; the changes are stored with the translation.
- Check the layout: Validation reports text cut off in dialogs, controls outside the dialog, and duplicate hotkeys.
- No rebuild: Create Localized Files writes a localized EXE or DLL, or resource-only DLLs such as
MyAppDEU.dll. - Existing translations: localized EXE files or language DLLs you already have can be imported, also ones built from translated
.rcfiles.
Questions.
Can I keep using my .rc files and still translate the build?
Yes. Developers keep editing the English .rc as before; Lingobit works on what the build produces and brings only new and changed resources to translation in each release.
What about strings that are still in the C++ code?
Text hard-coded in .cpp files is not in the resources at all. Lingobit Extractor moves it into the string table first. See Lingobit Extractor.
Are .res files read?
The compiled EXE or DLL is the input for the binary route. Translate the file the .res is linked into.
Does this work for MFC Ribbon files?
Yes. .mfcribbon-ms files are read as their own format, with the category, panel, and button text (Professional and higher).
Related paths
- Win32 / MFC — Translate dialogs, menus, and strings in the compiled build.
- Resource-only DLLs — One EXE, one language DLL per language.
- Lingobit Extractor — Move hard-coded strings into resources.
- Supported formats — Every format and the edition that reads it.