Guide overview
Localization guides for the platforms you ship.
Each guide shows where your platform keeps translatable text, how Lingobit reads it from the build, and how localized files ship and stay current.
Main guides for Windows desktop applications
Pick the guide by the way the application stores resources and ships localized output, not only by the language it is built with. For .NET, the starting point depends on whether you localize WinForms UI, compiled WPF / BAML, or resource files.
| Platform | Start here when | Typical files | Localized output |
|---|---|---|---|
| Win32 / MFC | UI text is in native Windows resources: dialogs, menus, string tables, or RC/RES files | .exe, .dll, .rc, .res, resource-only DLLs | Localized binaries or resource-only DLLs |
| WinForms | You localize compiled forms and controls, with RESX and resource-file options still available | .exe, .dll, .resx, .resources | Culture-specific .resources.dll satellite assemblies |
| WPF / BAML | The WPF UI is compiled into BAML and ships through the .NET satellite-assembly model | Assemblies with BAML, *.g.resources, related .resources | Localized .resources.dll satellite assemblies |
| .NET Resources | The workflow is centered on RESX files, compiled resources, or existing satellite assemblies, not form preview | .resx, .resources, .resources.dll | Translated resource files or satellite assemblies |
WinForms, WPF, or RESX: choose by how the application stores its UI.
WinForms
You localize forms and controls from the compiled application and still want RESX and compiled-resource variants in the same release flow.
WPF / BAML
The UI is compiled into BAML, and you need WPF-specific preparation such as x:Uid, fallback behavior, and the satellite-assembly release structure.
.NET Resources
Resource files, compiled .resources, or existing satellite assemblies are what you hand off, and form preview is not the main question.
Every guide answers the same practical questions.
Where do the strings live?
The real resource model of the platform: native resources, compiled assemblies, BAML, RESX, .resources, or ResourceBundle families.
What should developers prepare first?
Some projects need Localizable = true, some need x:Uid, and some need hardcoded strings moved into resources before translation starts.
How are localized files loaded?
Satellite assemblies, resource-only DLLs, locale-specific bundle families, fallback behavior, and where language switching happens at runtime.
How do updates work later?
How Lingobit reuses translations, what to add from the next release build, and how to continue from existing localized files instead of starting over.
Also supported: Delphi, Java, Qt, Python, Apple, databases, XML, HTML, and help files.
- Delphi / C++BuilderVCL binaries, DFM resources with preview, resource strings, and resource-only DLLs.
- Java
.propertiesResourceBundles and JAR-based resource layouts. - Qt TS
.tsfiles from Qt tools; your build compiles them into.qm.Professional and higher - Python / gettextgettext
.pocatalogs; your framework tools compile them into.mo.Professional and higher - Apple XIBXIB files, storyboards,
.strings, and String Catalogs through Xcode's Export Localizations.Professional and higher - DatabaseText in database tables through ODBC, without direct database access for translators.Enterprise
- XMLElements and attributes selected by XPath rules; the XML structure stays protected.Professional and higher
- HTMLVisible page text, attributes, and templates; markup and server-side code stay protected.Professional and higher
- HelpCompiled HTML Help (CHM): pages, contents, index entries, and window titles.Enterprise
Your release is rarely only one file type.
- Supported formatsHelp content, structured data, exchange files, and resource models beyond the main guide.
- MigrationContinue from translated binaries, resource files, or bundles without retranslating everything.