Migration · Multilizer
Move from Multilizer without translating again.
Your translations are in the localized files Multilizer built. Add the release you shipped, import the translations from its localized EXE and DLL files or resource DLLs, then scan your current build. No Multilizer project and no running Multilizer needed.
- Bring
- The release you shipped and its localized files
- Not needed
- Multilizer or its
.mprand.m7pprojects - You get
- Texts, positions, and sizes, item by item
- Then
- Scan for Changes to your current build
On this page
Find what Multilizer built for you.
With binary localization, Multilizer wrote one of these for each language. Set the same kind of output in your Lingobit project before you import: Lingobit looks for the localized files where it would write them. Files in another folder, such as de\ instead of de-DE\, you pick with Browse.
| Multilizer output | Example | In Lingobit |
|---|---|---|
| Localized files | de\MyApp.exe | Localized Files, the default output. Import, and Browse to the language folder if needed |
| Delphi resource DLLs | MyApp.DEU | On the VCL Binary Output page, choose Resource-Only DLLs; Lingobit then finds MyApp.DEU next to MyApp.exe |
| MFC resource DLLs | MyAppDEU.dll | On the MFC Output page, choose Resource-Only DLLs. If Multilizer used other names, set the same name pattern |
| Multilingual EXE | MyApp.exe with several languages | Choose Multilingual Files; each language is imported from the same file. Checked for Win32 and MFC files; for a Delphi file, ask us |
Only the .mpr or .m7p project | — | Build the localized files once in Multilizer if it still runs. Otherwise use translation memory, below |
If you used the Multilizer localization components.
Then the application translated itself at runtime from .mld dictionaries, and there are no localized files to import. Lingobit does not read .mld files.
Bring the translations
If Multilizer still runs, export the translations to TMX, XLIFF 1.2, or CSV. In Lingobit, Import Matching Translations takes only the entries that match your strings, and Translate Using > Translation Memory fills them in with the Auto status for review. Professional and higher.
Ship without the components
Lingobit localizes the compiled application: it writes a localized EXE for each language, or resource modules such as MyApp.DEU that Delphi loads by itself. The components and their dictionaries are then no longer needed in the build.
Four steps from a Multilizer release to your next one.
Why import the localized files instead of a TMX export?
A TMX file holds pairs of source text and translation. The localized files hold the translated application itself: every item in its resource, with its size and position. Import them, and nothing has to be guessed.
| Topic | Import from localized files | TMX into translation memory |
|---|---|---|
| How strings are matched | Item by item: file, resource, and item ID | By source text |
| The same text in two places | Each keeps the translation it had | Found by its text; check the places where it was translated differently |
| Positions and sizes | Taken from the same release | Not in the file; controls keep the original sizes |
| Status after import | Imported | Auto, like other translations from memory |
| What you need | The release you shipped and its localized files | Multilizer, to export the file |
| Edition | Every edition | Professional and higher |
Import: the same release, a 100% match
Translation memory: texts only
Use translation memory when there is nothing to import from: the new version is a rewrite, for example from MFC to WinForms, or only a TMX, XLIFF, or CSV export is left. Other migration paths
Notes for Delphi and C++Builder.
What carries over
- Forms and resource strings of the EXE, DLL, and BPL files, with positions and sizes
- Resource modules such as
MyApp.DEU: Lingobit writes them under the names Delphi looks for, and Delphi loads them by itself - Forms open in the DFM preview for review
Test before you ship
- The application changes the language at runtime with its own code: test it with the modules Lingobit writes
- Custom VCL controls: map them to preview controls in the VCL Form Editor settings
- A non-Unicode application: check the code page warnings before Create Localized Files
Multilizer migration FAQ
Do I need Multilizer to move my translations?
No, if you still have the release you shipped and its localized files. Lingobit reads the translations from those files. Multilizer is needed only to build localized files that you no longer have, or to export translations that live in its dictionaries.
Why not export a TMX file from Multilizer?
A TMX file holds pairs of source text and translation. Importing the localized files matches every item in its resource, takes positions and sizes from the same version, and marks the strings as Imported. Translation memory is the better path when the new version is a rewrite or when no localized files are left.
Can Lingobit import Delphi resource modules such as MyApp.DEU?
Yes. Set the output of the project to Resource-Only DLLs before the import; Lingobit then finds MyApp.DEU next to MyApp.exe and imports texts, positions, and sizes.
Can Lingobit read Multilizer .mld dictionaries?
No. If the translations live only in .mld dictionaries used by the Multilizer components, export them from Multilizer to TMX, XLIFF, or CSV and use them as translation memory in Lingobit Professional or higher. See If you used the components.
My current build is newer than the last Multilizer release. Is that a problem?
No. Import the release the localized files were built from, then run Scan for Changes with the current build. Only new and changed strings need work.
Can you check our files before we buy?
Yes. Try the import with the free trial, or ask about migration and tell us which output your Multilizer project used.
Your Multilizer work is not lost.
Add the release you shipped, import its translations, and scan your current build.