Migration · Sisulizer
Move from Sisulizer without translating again.
Your translations are in the localized files Sisulizer built. Add the release you shipped, import the translations from its localized EXE, DLL, resource modules, or satellite assemblies, then scan your current build. No .slp project and no running Sisulizer needed.
- Bring
- The release you shipped and its localized files
- Not needed
- Sisulizer or the
.slpproject - You get
- Texts, positions, and sizes, item by item
- Then
- Scan for Changes to your current build
On this page
Find what Sisulizer built for you.
Sisulizer 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.
| Sisulizer 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 Sisulizer used other names, set the same name pattern |
| Multilingual Win32 and MFC files | MyApp.exe with several languages | Choose Multilingual Files; each language is imported from the same file |
| .NET satellite assemblies | de\MyApp.resources.dll | Imported for the assembly |
Translated .resx files | Form1.de.resx | Imported next to the source .resx |
Only the .slp project | — | Build the localized files once in Sisulizer if it still runs. Otherwise use translation memory, below |
Four steps from a Sisulizer 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 | Sisulizer, 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 Sisulizer's units: 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
Sisulizer migration FAQ
Do I need Sisulizer to move my translations?
No, if you still have the release you shipped and its localized files. Lingobit reads the translations from those files. Sisulizer is needed only to build localized files that you no longer have.
Why not export a TMX file from Sisulizer?
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.
My current build is newer than the last Sisulizer 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 Sisulizer project used.
Your Sisulizer work is not lost.
Add the release you shipped, import its translations, and scan your current build.