SlMake updates in recent builds

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.

Build 343

Added -uilangs parameter to exchange task.

Build 334

Added  -config parameter to create task.

Build 332

Added -origlang and -outitem: parameters to add task

Build 323

Added -subdirs parameter to add task. Here is article about this task.

Build 310

Added -input: parameter to create task.

Build 307

Added -name: parameter to validate task. Here is article about this task.

Build 306

Added -invalid: and –marked: parameters to exchange and export task. Here and here are articles about these tasks.

Build 303

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.

Janusz Grzybek


Short explanation of Import methods

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:

  • By context
  • By value
  • By context first then by value

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.

Import results

  • Import method: By context
  • Overwrite method: Never


  • Import method: By context
  • Overwrite method: Always


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.

  • Import method: By value
  • Overwrite method: Never


  • Import method: By value
  • Overwrite method: Always


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.

  • Import method: By context first then by value
  • Overwrite method: Never


  • Import method: By context first then by value
  • Overwrite method: Always


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.


  • For clarify, we used here different settings for two Import options only (import method and overwrite method), while in our Import Wizard you can customize lot of things, so your import results could be different, depending on selected settings.
  • Be careful with using By value method always setting for Overwrite method. It could cause replacing good translations of duplicates in main SLP by undesired translations.
  • Read this article with hints about assigning different translation statuses for items imported with different import methods.
  • Homework – with By value method all items have been translated, expect the last. Why?
  • Look on By value (value for money?) import results – Trabant is winner!

Janusz Grzybek

How to find the source properties dialog?

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:

  • Open Project menu, go to Edit Source sub-menu and select your source file in the list.
  • Right click on your source node in Project Tree (usually next level node after “All” root node”) and select Properties item in context menu.
  • Select your source node in Project Tree and click “Source Properties” button on Project Tree toolbar.

Below are some additional, short, but useful info about source properties:

  • Source properties dialog may look completely different for different source types. They have different options and even tabs in Source properties dialog. However, some tabs are common for all source types/platforms. Those tabs are: File, Encodings, Engines, and Spelling.
  • Each source (even from same type) has own source properties, and if you changed path or original language in one source, in other source still remain old settings of paths and languages. This is a very flexible solution, because you can manage sources from one project in different ways. However, if you would like to change a setting in many sources, you need to do it separately for each source.
  • If you added a folder as source to project, source properties settings and potential changes are concerned to all files from folder added to project.
  • Many source properties settings require re-scan for applying.
  • Usually changes in source properties require access to source file (e.g. access to file is required for scan), and if source is unavailable (e.g. as result of changed path), you can’t apply changes.

Janusz Grzybek

Using resource DLLs in MFC application

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.

Janusz Grzybek



Sisulizer and Microsoft Access 2010 64-bit

With Sisulizer you can localize Microsoft Access database files with all four available database localization methods in Sisulizer, including Cloning. You also can use MS Access databases (both old *.mdb and new *.accdb database file types) as Sisulizer’s Translation Memory engine. Here is article with info about creating new a Translation Memory.
When you installs MS Office 2010 it will also install Access engine, and after that you can use Access with Sisulizer. If you don’t have Microsoft Access and/or Office installed, you can download a free Access engine from Microsoft’s website. It works perfectly with Sisulizer, if you have installed 32-bit Access database engine.
However with 64-bit version of MS Office is also installed 64-bit engine not supported by Sisulizer. For this reason you can’t localize new Access format, that is .accdb, while old, that is .mdb still works because Windows itself contains both 32-bit and 64-bit engines. The problem is that once you have installed 64-bit version of MS Office you CANNOT install 32-bit engine. The installation does not even start. Unfortunately, we can’t help you with solving this issue, because this is Microsoft issue. Optionally, you can switch back to 32-bit MS Office.
Access databases before Microsoft Access 2007 don’t require installation of dedicated driver.


How can I simoultanously build Windows 32-bit, 64-bit and OSX files?

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:

  • Go to “Project”, then to “Edit Source” sub-menu and select your source.
  • Next, in opened source properties dialog go to “Platform files” tab and add appropriated versions of your source file. Here is example screenshot:

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.

Janusz Grzybek


Squares instead of foreign language characters on Windows 8

Whenever you encounter squares in Windows 8 software dialogs, file names, menus instead of e.g. Japanese characters like in 火.txt, you do not have the corresponding language pack installed.

The solution is fortunately easy.

Make sure you are logged in with administrator rights.

First open the Windows control panel. If you don’t know how to find it, take a look here.

Next, click on Languages. You should see something like this:


Click Add Language. And select the desired language. Here we go for Chinese (Simplified).


Chinese (Simplefied) has regional settings as well. We pick one.


Now we are back, and see our changed language preferences. We can see our changes in the list, but the new language pack is not installed yet.


So we double click it, or click on Options, to open the Control Panel – Language Options dialog again. Here we chose to Download and install language pack


Here is the installation process. Depending on the selected language, and the already installed languages the packs are quite big, eg. 80 MB or 147 MB.

download-and-install-updates-language-packs downloading-chinese-simplified-language  the-language-updates-are-being-installed installation-complete

You may need to restart your Windows.


Now you should have the fonts installed, and should not see any squares.

Hope this helps… Just let me know. Currently it looks that the installation of additional language packs do not work under all circumstances. I have to dig deeper into it, and will come back with another article, soon.

For older Windows versions like Windows 7 or XP please check Janusz’ article here.


What the heck is a Windows language pack?

A language pack consists of different informations you need to work within a language.

The display language of Windows in example contains resources with all text elements of Windows dialogs, menus, output, and error messages, and tool tips.

Another important thing you need is the keyboard layout for the desired language. Depending of a language the keys on a keyboard have different characters printed on. Some languages have in example umlaut characters, like ä,ö,ü in German, Turkish, and Finish. Or accents, like in é, à, î, and ô (and more) in French, and their is a whole bench of other characters in other Northern Europe languages. Naturally this language feature is not limited to European languages.

But even if the characters which two languages or regions are using are identical, they may be used in a different order. Especially numbers, brackets, punctuations, and currency symbols may be on different keys.

Don’t trust my word. Give it a try. Visit an internet café or a PC in a hotel lobby, on your next travel into another country. Typing such simple thing as an email may be very challenging. 😉

A Windows language pack also includes sets of regional settings for Clock, Currency, number formats, and more.

Depending on the language, it may also contain fonts, or special character entry tools, like Microsoft IME for Japanese or Microsoft  Pinyin SimpleFast for Chinese.

More things to read

  • How to install a language pack in Windows 8?


Hope this helps. Just let me know, and leave a comment.


How to prevent the lost of translations in source code localization, after including new items…

Sisulizer always requires a context value for translatable items. Context values unambiguously identify strings and should be always unique. This solution allows to identify the same original string with different translations, but also facilitate synchronization of Sisulizer project with updated source files during scan operation.

Generally, it works perfectly, if you localize binary C++ files, .NET binary or Visual Studio project files, C++Builder binary files etc. Strings in those source filetypes have own unique contexts, and if you include new string items, dialogs or controls, it doesn’t change context of existing items in Sisulizer project.

However, for sources without “real” context, such as source code files (e.g. pas, hpp, h or cpp), Sisulizer needs to create “virtual” context, based on item index or string values. By default (for legacy reason), Sisulizer use indexing method.

When you use a context method based on index for localization of your source code file, Sisulizer re-index contexts after including new items to file. It could sometimes cause losing of translations, because Sisulizer needs to change context values for all items followed after including a new item.

Similarly, Delphi re-index contexts after adding new strings to stringtable, but fortunately you can generate DRC file in Delphi and it solve this issue.  Here is link to an article about this issue.

Luckily, you can change context method from index method to another method based on string values. Generally I recommend:

  • use index method, if you often edit already existing strings in your source files and rarely add new items or remove existing items
  • use string values method, if you often add new strings and rarely edit existing strings in your source file

You can change this setting via “Project” menu -> “Edit source” and select your source. Next, in source properties dialog go to “Options” tab and change setting in “Context method” section from “Item index” to “String value”.

Applying this change requires rescanning of project. This is very sensitive operation, because it changes all contexts for selected Sisulizer source. So, this process could cause losing all your translations, but don’t worry, because Sisulizer has implemented features for automatically restoring your translations:

  • Sisulizer saves backup of your project with .~slp extension, unless you have disabled this feature in general settings. Here is article about this feature.
  • Translate Duplicate feature automatically re-translate all items with changed context and identical original strings, unless you have disabled Translate Duplicate feature or you use “By original and context” setting for this feature.  Here is article about this feature.
  • Sisulizer will keep project items with old context as unused items, unless you have checked “Remove unused items automatically” option in Sisulizer settings. Here is article about this feature, and here is general info about unused items status.
  • If you remove unused items from project or Sisulizer automatically removes those items (look above), Sisulizes automatically saves translations for unused items to Translation Memory, unless you have disabled this feature in your translation memory settings. You can find information about this feature in this article on our blog.

Janusz Grzybek

Importing TMX file exported by Sisulizer into SDL Trados

Sisulizer can collaborate with SDL Trados (popular CAT tool) via TMX standard. We already published article about this. You can read it here.

However, recently an user reported, he can’t import to Trados TMX file exported by Sisulizer for incompatibility reason. This may occur because Trados doesn’t support the value *all* as source culture attribute, while Sisulizer use it as default value. Below is a screenshot of Sisulizer’s TMX edited in a text editor and marked source language parameter.

But don’t worry. You don’t  need to edit Sisulizer’s TMX file manually in an editor before importing it in to Trados. You can change the value of this attribute in Sisulizer’s flexible Export Wizard. When you open Export Wizard and select TMX tab on first page of wizard, please change “Source Language” option from “All” to appropriated language e.g. “English”. That’s all.

It should resolve incompatible culture issue  during import  to Trados.

Janusz Grzybek