Multilingual software · Windows desktop
Multilingual software: one Windows build, every language.
A multilingual application is one build plus a language file for each language. Lingobit Localizer makes those files from the EXE and DLL files you already ship, so translators never need your source code and nothing is rebuilt.
Making software multilingual is two jobs. Only one of them repeats.
Internationalization prepares the code once. Localization translates, checks, and ships every language, and it comes back with every release. That second job is the one Lingobit takes over.
Once: internationalization
- Text in resources, not in code. Dialogs, forms, menus, and messages live in resource files the application loads.
- Unicode throughout. Japanese, Polish, and Turkish text must survive every string operation.
- Dates, numbers, and money through the culture. Format them with the culture APIs of your platform, not with fixed strings.
- Room for longer text. German is often a third longer than English; layouts that only fit English break.
Every release: localization
- Find what changed. New, changed, and removed text in the new build, for every language.
- Translate only that. With your translators, an agency, or machine translation.
- Check it in the real UI. Cut-off text, broken placeholders, duplicate hotkeys.
- Ship the language files. Next to the unchanged build, ready for the installer.
How a Windows application finds its language.
Every platform has its own place for language files and loads them by itself, usually by the Windows display language. Lingobit writes the files in the form your platform expects.
-
WPF
Satellite assemblies
de\MyApp.resources.dllnext to the application. .NET loads the folder that matches the UI culture. .NET Framework 4.8 and .NET 5–10. -
WinForms
Satellite assemblies
The same culture folders as WPF, with the forms translated in the form editor. Your EXE and DLLs stay unchanged.
-
Win32 / MFC
Resource-only DLLs
MyAppDEU.dllnext to the unchanged EXE: MFC loads it by itself. Or a localized EXE for each language. -
Delphi / C++Builder
Resource modules
MyApp.DEUnext to the unchanged EXE: the Delphi runtime loads it by itself. Or a localized EXE for each language. -
Databases
Language columns or rows
Text your application keeps in Access or SQL Server tables, translated through ODBC and written back for each language. Enterprise.
Want users to pick the language in an MFC application? The Multilingual Library adds a language menu. For .NET, set the UI culture before the first window, as the WPF guide shows.
Translate the build. Keep the source code in-house.
Lingobit reads dialogs, forms, menus, and string tables from the compiled files. Your source code and your build stay as they are, and nobody outside your team needs access to them.
- Translators get a task, not your repository. Prepare Translation Task sends them only what needs work, for the languages they translate.
- They see the real dialogs and forms. Translator Edition shows the same preview, runs validation when they save, and is included with every Localizer license.
- CAT tools welcome. Translators who work in their own tool get XLIFF 1.2; Import Translation Results brings the work back.
Every release, every language, in five steps.
A new build should not mean translating the application again. Lingobit carries the existing translations forward and leaves only the changes for your translators.
- Scan for Changes compares the new build with the project and groups the text as New, Updated, and Removed.
- Prepare Translation Task sends translators only the new and changed text.
- Import Translation Results merges their work back like a new build.
- Check in the Output panel placeholders, hotkeys, cut-off text; go to each finding and fix it in place.
- Create the localized files next to the build, ready for your installer.
On a build server, the command line runs the same steps: scan, validate, and create the localized files. Professional and higher.
Before you add the first language.
Most problems of a multilingual release show up before translation starts, if you look for them.
- Strings still in the code. Lingobit Extractor moves them into resources in C++, C#, Visual Basic .NET, Delphi, and Java.
- Text that will not fit. Pseudo Translate makes the text longer and swaps in other characters, so you see broken layouts before translators start. Professional and higher.
- Right-to-left languages. Flip mirrors Win32 dialogs and WinForms forms for Arabic and Hebrew; in WPF the application sets
FlowDirection. - Hotkeys. Check Mnemonics finds a letter used twice in one dialog or form.
- Text that must not change. Lock it, and neither translators nor an import can change it.
- Formats built from pieces. Write whole sentences with placeholders; validation then checks that every translation keeps them.
Multilingual software FAQ
What is multilingual software?
An application whose user interface is available in several languages from one build. On Windows the text sits in resources, and each language comes as a separate file: satellite assemblies for .NET, resource DLLs for MFC, resource modules for Delphi. The application loads the one that matches the user's language.
Do I need the source code to translate my application?
No. Lingobit Localizer reads the compiled EXE and DLL files and writes the language files from them, without a rebuild. Text written directly in the code is the exception: move it into resources first, by hand or with Lingobit Extractor.
Who does the translation?
Your own translators or an agency, in Translator Edition, which is included with every Localizer license; or translators in their CAT tool through XLIFF 1.2. Machine translation with DeepL, Google Translate, or Microsoft Azure Translator gives a first version to review. Professional and higher.
Can users choose the language themselves?
Yes, if the application sets it. By default each platform follows the Windows display language. A .NET application sets the UI culture before its first window; an MFC application can add a language menu with the Multilingual Library.
Our application is already translated. Do we start over?
No. Import Translations from Localized Files takes the translations from the localized EXE and DLL files, satellite assemblies, or translated .resx, PO, Qt TS, and Java .properties files you already have. Then Scan for Changes brings the project to the current build.
See your own application in another language today.
Add your compiled files to the free trial, machine-translate them, and run the localized version on your computer.
Related paths
- .NET ResourcesTranslate
.resxfiles when the translations must go back into source control. - MigrationMove from Sisulizer, Multilizer, or another tool without translating again.
- Supported formatsEvery file type Lingobit reads and writes.