The documentation of all Sisulizer Build Server command (SLMAKE) can be found here.
Download your free eval at www.sisulizer.com now!
From build 339 you can specify the minimum translation status that are used when building localized items. By default this is the lowest translation status, Not translated, that means all translation are used no matter what the status is. If you set this value to any higher value then Sisulizer uses only those translations that have translation status equal or higher than the value specified here. This new feature is available via Project menu -> Options -> General tab -> When building use translations that have at least this status.
Here you can select required status in drop-down menu. After selecting, output files will contain originals instead translations with statuses lower than selected. Below is list of all Translation Statuses ordered from lowest to highest:
This feature can be useful in your localization job, for example:
This feature works on project level, so selected setting is used for all sources included to project.
Our samples are very useful for our users and are by default installed during Sisulizer setup. Samples contain not only simple source and SLP files. Typically our samples comes with documentation, resources and code files which can be used within your application, e.g. for implementing switching at runtime. So we recommend installing them with main application. However, if you didn’t know it and unchecked it or you deleted those files by accident, you can reinstall it.
Run latest Sisulizer’s installer and in “Sisulizer 4 Setup – Existing Installation” step select “Modify the existing installation”
Next in “Sisulizer 4 Setup – Select Samples” step check desired items or simply click “Check All” button for installing all those items. Then, click “Next” button in all other steps of setup.
All samples are available via menu File -> Open Sample… or via Open Sample button on Sisulizer’s start page. PDF documents about .NET and VCL localization installed to samples folder can be opened via Help menu.
Sisulizer’s Exchange Wizard is very flexible tool and you can use it in many different ways. Below example shows how to add to Exchange Packages only not translated strings, even though every language has a different amount of not translated strings.
Let’s assume that in our SLP we have 4 languages (German, Finnish, Japanese and Arabic) and those languages contain different count of not translated strings
All those not translated items are marked by red rectangles on screenshot.
marked ob below screenshot by red rectangles
We want to send to our translators a SLE package with not translated strings only. So in the “Translations Statuses” tab of “Exchange Wizard – Filters” we should uncheck all statuses expect for “Not Translated” status.
However, if we generate one Exchange Package with all languages, generated SLE will contain sum of all not translated items in all languages, that is 2rd to 9th. So, when our potential Arabic translator opens sent SLP package, he will see also items already translated to Arabic. Similar issue, but for Export wizard was described in this article.
But, don’t worry, because you can easily solve this problem by checking the “Create several packages, one for each selected language” option in the “Exchange Wizard – Languages and items” step.
Using this option generates separated packages for each language in one operation and all SLE packages will contain only not translated items in selected language.
Of course, this is only very simple example, and you can combine different settings of translation statuses in your own Exchange setup. However, I hope it shows capabilities of the Exchange Wizard.
We published on our blog article series about the SlMake tasks in the past. However, our R&D implemented a lot new features in the meantime (Last the article about the Slamke was published in Marth 2010). I always update appropriated articles after changes in SlMake, but it is made without announcements. So, articles are still topical, but our users could overlook it. For this reason I decided write this short preview of all new features implemented to SlMake since March 2010.
Added -uilangs parameter to exchange task.
Added -config parameter to create task.
Added -origlang and -outitem: parameters to add task
Added -subdirs parameter to add task. Here is article about this task.
Added -input: parameter to create task.
Added -name: parameter to validate task. Here is article about this task.
Added -output: and –al: parameters to create task. Here is article about this task.
Besides those new parameters our developers improved behavior of some tasks and parameters in the meantime. They also fixed some bugs reported by our users. You can find full info about those changes in our changelog.
If you haven’t read our articles about SlMake yet, I recommend you go to this article with general info and additional links.
Import method is the most important import option in Sisulizer’s Import Wizard. It specifies how Sisulizer will support imported contents. To select an import method use the “Import Wizard – Options” step of the wizard.
Sisulizer supports three import methods:
Because each method can produce different results, so it sometimes confuses our customers. However, I decided to use here an exercise based on a small sample SLP, instead of standard article.
This is our example, main SLP file.
Below is imported SLP file.
Please don’t worry about below results of different import settings. Our example is very specific, both the original and the translation column are in English, both SLP files contain duplicates translated in different way (expect one string). There are no typical duplicates of strings commonly occurred in standard an application for example “OK” or “Cancel”.
Localization resources can contain dozens occurrences of those strings, and “By value” or “By context first then by value” could be the best solution for quick importing good translations. Actually, this example shows general behavior of different import settings, so don’t take this example into the consideration, when you would like to select best method of import. Your choice should depend on your needs and specific resource contents.
By context method always gives most accurate translations, because import is based only on context, while context in Sisulizer projects is always unique. This is very good solution if your SLP should contain duplicates translated in different way. By the other hand, it gives less translations than By value method, if imported file doesn’t contain translations for duplicates.
By value method do not use context at all, and it compare only originals in both SLP files. When imported file contains duplicates translated in different ways, Sisulizer use always translation for first occurrence of original found in imported SLP. This is, because context is ignored, while originals are identical and Sisulizer doesn’t know which translations should be used. In our example Sisulizer use “Trabant is the best German car”, while “Volksvagen is also good German car” is ignored.
By context first then by value method combine merits of both previously described methods, and for this reason this is my favorite method. First Sisulizer try import translations based on context. Next, for not imported items in first import pass based on context, Sisulizer use by value method. So for all items with matched items, even originals translated in different ways, you’ll get accurate translations. Additionally, for other items Sisulizer use translations based on originals – for example, when your main SLP contains 30 “Cancel” originals and imported file only one “Cancel” translation, this translation will be used for “cancel” originals in your main SLP.
Source properties dialog contains lot of important settings. We often discuss about those settings in our support forum and our users ask where is this dialog. You could open this dialog via several GUI commands:
Below are some additional, short, but useful info about source properties:
We always say using resource DLL files is the best solution for localization of your application, but unfortunately some older programming platforms e.g. still very popular Visual C++ don’t support it internally. However, Microsft added partially support for this solution to MFC 7 libraries. If your application use MFC 7 you could use Sisulizer to build localized resource DLLs for your application.
Generally, MFC 7 doesn’t support language switch at runtime. Your MFC application will use automatically the resource DLL which matches the Windows locale if available. But optionally you could use a custom or third party solution for implementing switching at runtime. Many Visual C++ developers don’t know they could generate resource DLL directly in Sisulizer projects based on Windows32 exe files, so I decided to write some hints related to this feature.
If you want to set up resource DLLs as output for your Sisulizer project, just select Resource DLLs option in File tab of source properties dialog and set appropriated output filename pattern matched with MFC or with your custom solution. Here is article with detailed information about output options.
MFC requires using language IDs for resources inside resource DLL e.g. for dialogs, icon resources etc. instead of neutral or original language IDs. For doing it, you need to go to the Options tab of source properties dialog. Please uncheck Keep original resource language id, and select Set the language always in the Set language of a neutral resource list.
If your application also requires for resource DLL specified info related to language in version resource, go to Resource options in source properties dialog and check appropriated options in Versions section. If your application uses MFC libraries, check Application uses MFC library in this same tab.
If your application has many languages, resource DLLs with all duplicated resources could significantly increase size of your application. In this case you could try uncheck Copy all resources option in resource file tab of source properties dialog. Build resource DLL with checked this option, next uncheck it, build again and compare sizes. So if this streamlined DLL works with your application we recommend to use it.
Resource DLL built by Sisulizer is immediately ready to use without additional preparing. If resource DLL is matched with your locale, simply copy it to installation folder and run your application. All screenshots were made with our Visual C++ example in vcpp subfolder in our samples folder. You could use it for experimenting with all above mentioned tricks and options.
Sisulizer 3 comes out with capacities to build 32-bit, 64-bit Windows and OSX output files for this same source in Sisulizer project. Currently this is possible only for latest Delphi/FireMonkey version, because both WIN32, WIN64 and OSX binaries created by Delphi compiler contains the same identical resources. For this reason you do not need to add separated sources for each platform. Just add Windows 32-bit file as source to Sisulizer project.
However, if you want to build WIN64 and/or OSX version of localized file, you need to add appropriated exe as platform files in your source properties. For example if you want to build localized 32 and 64 bit versions of sample.exe for 32-bit version of sample.exe added as source to Sisulizer project, you need add 64-bit version of sample.exe file as platform file. You can do it in the following way:
When scanning and building, Sisulizer treats platform files just like the main file. So if you have WIN32 as main file and WIN64 and OSX32 as platform files, Sisulizer scans and build three files on each run. Solution implemented to Sisulizer allows on adding next platforms in future, when programming environments developers will release it.
If you want to check, how it works in “real live”, open Sisulizer, go to “File” menu and select “Open sample” menu item. next, open FireMonkey/Converter folder and open SLP in this folder.