Glossary · Windows desktop
What is binary localization?
Binary localization means translating a compiled application, its EXE and DLL files, instead of the resource files in its source code. The localization tool reads the dialogs, menus, and strings the compiler put into the build and writes them back translated, so each language needs no rebuild and no access to the source.
- Input
- The EXE and DLL files you ship
- Output
- Localized files, language DLLs, or satellites
- Needs
- Text kept in resources, not in code
- Fits
- Win32, MFC, Delphi, WinForms, WPF
How it works.
A Windows build keeps its user interface as resources inside the files. A binary localization tool works on those resources directly.
| Platform | UI text in the build | Localized result |
|---|---|---|
| Win32, MFC | Dialog, menu, and string table resources | A localized EXE or DLL, or resource-only DLLs |
| Delphi, C++Builder | Forms (DFM) and resource strings | A localized EXE or resource modules such as MyApp.DEU |
| WinForms | Form resources in the assembly | Satellite assemblies: de\MyApp.resources.dll |
| WPF | BAML in the assembly | Satellite assemblies with translated BAML |
Binary or source localization?
In source localization, translators work on the resource files in the repository (.rc, .resx, .dfm) and developers build each language. Both are valid; the difference is who does what.
Binary localization fits when
- Translation should not wait for developers or touch the repository.
- Translators need to see each dialog and fix its layout for longer text.
- The source is not at hand: an older release, a third-party module.
- Every release brings a new build, and only what changed should go to translation.
Source localization fits when
- The text is in resource files the build compiles anyway, such as
.resxor.po. - The application is not a Windows desktop build: web, mobile, cross-platform frameworks.
- Developers want every translated file under version control.
Where it stops. Text written into the code, not into resources, is not translated either way; it has to move into resources first, which Lingobit Extractor does for C++, C#, Visual Basic, Delphi, and Java. User interface built entirely in code at runtime cannot be shown in a visual editor.
Binary localization in Lingobit Localizer.
- Visual editor: type the translation in the dialog or form, move and resize controls; the changes are stored with the translation.
- Checks: Validation reports text cut off in dialogs and duplicate hotkeys.
- Next release: Scan for Changes sorts the new build into New, Updated, and Removed.
- Existing translations: import them from localized EXE files, language DLLs, or satellite assemblies you already have.
Questions.
Is binary localization safe for signed files?
Changing a signed file removes its signature, so sign the localized files again in your release process, as you sign the original. Resource-only DLLs and satellite assemblies leave the signed EXE as it is.
Does it change the program code?
No. Only resources are translated: text, and the size and position of controls where a translation needs room. The code stays as compiled.
Is it the same as translating with a resource editor?
A resource editor changes one file once. A binary localization tool keeps the translations in a project, so the next build is translated again from them, and only new and changed text needs work.
Related paths
- Visual localization — Translate dialogs and forms in context.
- Resource-only DLLs — One EXE, one language DLL per language.
- Localizability — What the build needs to be translatable.
- Glossary — More localization terms.