How To...

Some advices for translators

Recently, I wrote on our forum a thread with some advices for Sisulizer translators. This thread is located in an internal section of our forum, so it is not available for our other Sisulizer users. However, this thread contains general rules which could improve collaboration between developers and translators, increase quality of localized resources, speed up this process and save needless effort. For this reason I decided to publish the content (a bit changed) of this thread on our blog. Below are those short tips for translators.

Use only SLP received from your developer

Please, always use projects, exchange packages or official language packs created and updated by your software developers. I don’t recommend using a custom project based e.g. on exe or dll files – even if the developer Sisulizer projects are out of date, because it can cause incompatibility issues. For example:

  • Your custom project is based on last official software release, while at this same moment developer work on next beta build differ widely from your source file.
  • Incorrect (or missing) version of DRC file for VCL source files could generate mixed up translations in project. So, if our SLP is a bit out of date, I still recommend to wait for an official version released by developer.
  • Developers know code of their applications and usually exclude from translations undesired items and resources. Localization of those sensitive data could be dangerous and even cause exceptions in localized application.

Validate translations before sending project to developer

I recommend using of validation features via (Validation menu on main Sisulizer menubar) after translation process. You can use default validation settings for this. It allows you to fix quickly all potential mistakes (e.g. hotkey conflicts). Of course, developers also can do it after receiving your projects, but some text formatting rules used in some languages, while in other languages are treated as bugs. Unfortunately, developers usually don’t know all rules for all languages so I prefer using of validation features by translators. If Sisulizer treats some items as bugs, while it is accepted in your language, simple add these items to the list of excluded validations.

Check changed items in project updated by developer

Sometimes developers change original strings with already existing translations. In this case Sisulizer always keeps translated values, but they should be checked by translators. For facilitate this process I recommend using of Invalidated filter. Open filter dialog, go to Other tab and set Invalidated filter as True. Next, compare, check contents displayed in translation sheet and optionally change outdated translations.

Janusz Grzybek

How To...

Can I create localized version of my .NET exe file?

Awhile ago most common developer platform was Visual C++ (Windows 32). Standard practice for localization of Visual C++ application is to create localized binary source file. If your source file is e.g. sample.exe file, you need to create localized sample.exe file; if this file is DLL, you need create localized version of this DLL file.

This is a good solution if you want to localize your application just to one target language. However if you want to add support of five languages to your application, you have to create five exe files. Of course, you can avoid this issue by storing localization resources in external files e.g. INI, other text files, or binary files with stored strings, but it requires using of third party tools/components and including additional code to your application, because Visual C++ internally doesn’t support similar solutions. Unfortunately, solutions based on external text/ini or XML files don’t contain context values and it make translation job more hard. You can use binary localization based on resource DLL, if your application supports MFC 7. MFC 7 and later has a build in feature using resource DLLs. When a MFC applications starts MFC is looking for a possible resource DLL from the same directory where the original .exe or .dll is located. If MFC can find this it uses resources of the resource DLL instead of the original PE file. Resource DLLs are named ApplicationNameXXX.dll, where ApplicationName is the name of the .exe or .dll using MFC, and XXX is the three-letter code for the language of the resources. For example MyApplicationENU.dll is an English (United States) DLL and MyApplicationDEU.dll is German (Germany) DLL. Sisulizer supports (for Visual C++) both methods, so you can build output files as localized version of sources binaries and resource DLL if your application use MFC 7. Here is screenshot of source properties from project with Notepad.exe as source.

As I mentioned above most common localization method for Windows binary files is creating localized versions of source files. Developers and localizers are accustomed to this old method and often ask if this possible use this same solution for modern .NET platform (C##, WPF, Sliverlight). This is impossible, because .NET uses its own unique approach. In .NET the localized data must be in a satellite assembly files. They are DLL files that contain only localized resource data, no code at all. If your original application is MyApp.exe then the German assembly file is de\MyApp.resources.dll. Note that the satellite assembly file must locate on a locale specific sub directory of the original application. The name must be the same as the original but instead of having .exe (or .dll) extension the satellite assembly file uses .resources.dll file extension. Having a satellite assembly file on right sub directory with right name is not enough. The actual resource name must also be localized. .NET uses named resources where each resource has a string name. For example if we have MyApp.exe the name of main form could be MyApp.Form1.resources. The German satellite assembly file must use name. If the resource name is not right .NET cannot load the resource even if the file name and directory are right. For this reason you can’t find in Sisulizer option for build localized files in source properties of .NET source.


Solution implemented to .NET allows on creation multilingual application without using external tools and additional code included to your binaries, but it also has some pitfalls. If the resource name is not right .NET cannot load the resource even if the file name and directory are right. Also if you have signed your original assembly file and your localized satellite assembly files are not signed .NET runtime does not load the resources even if the pathname and resource names are right. So you should take care of this.

Janusz Grzybek

How To...

Is this possible display in Sisulizer sections from my INI file as separated nodes?

Yes, of course. This feature is by default enabled when you create a new project for INI files. If you don’t see sections as separated nodes in Sisulizer’s Project Tree, it usually means you disabled this option in Project Wizard. Don’t worry, you can enable or disable this setting at any moment. Just use menu “Project” -> “Edit source”, select your INI file, select the “Options” tab and check “Use separate node for each section in the project tree”.

For applying changes you need to re-scan your source. Selecting this option not only gives you a preview of all sections in the Project tree, but also allows to display in translation sheet only items from selected node after selecting it in Project Tree. Below is a screenshot from project for INI file with unchecked “Use separate node for each section in the project tree” option.

After checking this option (and rescanning) my sample project looks like on this screenshot.


  1. If Sisulizer doesn’t add new sections added to your INI source files after re-scan operation, please check if you have checked “Check new items automatically” setting in “Keys” tab of INI source properties. If you haven’t checked it, please check it now.
  2. Generally we always recommend binary localization (if it is possible) instead of solutions based on external text resources. Background is that binary localization allows translators a visual preview of forms and optionally to adjust controls. Additionally visual preview provides a better understanding of context for translated items. So, if you are a translator, try to convince your developer to change his localization method to binary localization. If you are developer, give your translators a gift and use binary localization.

Janusz Grzybek

How To...

How I can change the language of my Silverlight application at runtime?

Internally Silverlight hasn’t implemented mechanisms for switching UI language at runtime. However, you don’t need to worry about this, because Markus found out tricky solution based on Javascript embedded to HTML code for switching language at runtime. You can use it also for multilingual XAP files (XAP file contains resources for all languages of your Sliverlight application).

If you installed samples included to Sisulizer setup, you already have useful sample with this solution included. Go to Sisulizer installation directory (Windows XP), or Sisulizer user directory (Vista and Windows 7) and open

Net -> Silverlight -> Conveter -> Bin -> Debug -> Converter.slp

and use “Project” -> “Build All Sources in All Languages” menu command.

Next, open “all” subdirectory and open TestPage.html file. This file opens your Sliverlight application and contains Javascript code for switching language at runtime.

After opening this file (in your web browser) you should see in top part of window an option for changing UI language. Simply select other language in combobox and click “Change” button. That’s all. Below is a fragment of Javascript code responsible for language change included to TestPage.html file.

You can use, and of course adjust this code for your needs.

Janusz Grzybek

How To...

Build 313 – JSON localization support

Our developers implemented support for JSON (JavaScript Object Notation) format support to build 313. This is a lightweight data-interchange format. It is based on a subset of the JavaScript programming language but can also be used with other programming languages. More information about this new, but already popular format is available on JSON org website.

Generally JSON is built on two structures:

  • A collection of name/value pairs. In various languages, this is realized as an object, record, struct, dictionary, hash table, keyed list, or associative array. This is simple and useful structure for storing translations resources, because it contains name/value pairs. Sisulizer use “string” item visible on below image as context value and “value” as original language value.

  • An ordered list of values. In most languages, this is realized as an array, vector, list, or sequence.

Below is content of an example JSON file:

…and here you can see how this file is interpreted by Sisulizer:

Janusz Grzybek

How To...

Can I also translate my EULA text file with Sisulizer?

Usually End User License Agreement aka EULA are written as text files. Because Sisulizer supports localization of text files, you can also include it to your Sisulizer project file, and translate the EULA file together with your application files. In this way you do not need to separately translate your license agreement.
If you want to add your EULA file to an existing project, click “Add source” button in Sisulizer’s main toolbar, or use “Add source” menu item in “Project” menu or context menu of Project Tree. Next, select the text file containing your license agreement, and select “Plain text file” in Project Wizard.

When you select this option, Sisulizer certainly adds this file without problems to your project, but the content of your EULA file will be visible in Translation Sheet as one cell.

This makes it hard to translate, and quite impossible to profit from translation memory.

Fortunately Sisulizer supports a feature named segmentation, which splits your EULA source file into more segments like sentences. These smaller parts are way easier to handle and translate.

Enabling segmentation for your EULA source has the following advantages:

  • Better preview of translated text in Translation Sheet
  • You do not need to translate whole EULA text at once
  • After potential changes in EULA text you do not need to review and/or re-translate whole text
  • You can reuse translated segments also for EULA files from other your applications

You can enable segmentation in “Segmentation” tab of properties dialog in your EULA source.

Select here “Use segmentation” and next re-scan your project. After re-scanning of your project, Translation Sheet for your EULA node should look like on this screenshot.

Of course, you could also use custom segmentation rules for your EULA node. Read this article if you would like add your custom segmentation rules.  However, you should be very carefull with changing of segmentation rules, because these changes could cause missing of some translations.

Janusz Grzybek

How To...

How to change embedded images in localized files.

You can replace images, icons and other graphic resources in Sisulizer projects, and Sisulizer use these new images in output files. Below is a screenshot from our binary C# example installed by default with Sisulizer. If you select translation cell for original image, a three-dot-button appears indicated on below screenshot by a red arrow. When you click this button, Sisulizer opens file open/save dialog, where you can select desired image file.

On cells (original and translation) of image row are displayed hints with information about file type and size. I recommend using for translation always the same image file type as original, because using of other format could cause unexpected results or even crashing of localized application. Information about size can help you to adjust layout of localized forms etc.

When you select new image file, Sisulizer ask you about enabling automatic translation for this item.

When you turn it on Sisulizer remembers the file name and the next time the project is opened Sisulizer compares the translated data to the data in the file. If data in the file differs from the current data Sisulizer automatically loads new data from the file to the project.

Here is a screenshot of our example project with already replaced image.

When your source file contains images, but you don’t see images in sheet, it probably means you have excluded this data type from your project. In this case you should uncheck “picture” data type in “Excluded types” tab of source properties.

For some platforms, you also need to check if you have enabled localization of appropriated resource type. For example, if you want to localize icons in a Delphi application you should check “Icon resource [RT_ICON]” item on list in “Resources” tab of Delphi properties dialog.

Janusz Grzybek

How To...

Sisulizer doesn’t keep text format of paragraphs for my HTML sources. What can I do?

Sisulizer by default doesn’t keep text format for HTML sources. When you type translation, or even when you copy original to translation, Sisulizer removes all line breaks, tab characters etc. Below is a screenshot with a sample row which is copied to translation cell.

However, sometimes it is useful to keep these characters in your translations. Additionally, when count of line break characters of original differ from count of line breaks in translation, Sisulizer can’t correctly calculate differences in text length and for this reason translation cell on above screenhot is marked by red background color. If you would like to keep original’s text format in translation, you should check “Keep text format” option in “Options” tab of HML source properties dialog. Source properties dialog is available via:

  • “Project menu -> “Edit source” -> your source
  • “Properties” item in context menu of source node in Project Tree
  • “Source properties” button on toolbar of Project Tree panel

When you check this option and copy original text to translation for our example paragraph, translation looks as below screenshot.

In this case, Sisulizer not only keeps the format, but also can correctly calculate length of text.

Janusz Grzybek

How To...

How I can disable or enable some message dialogs in Sisulizer?

Sisulizer displays message dialogs with important information related to your project. However, you can permanently or temporarily disable displaying of these dialogs. For example when you didn’t specify key file for your .NET source file yet, Sisulizer will display appropriated message dialog every time when you scan this project, and it could be annoying. But, if you check “Do not show this next time” option, visible in left bottom part of dialog, Sisulizer doesn’t display this message anymore.

You can disable these pop-up dialogs for the following items:

  • Incompatible Ansi code page
  • .Net user interface culture
  • Exclude row
  • Exclude original
  • Prompt key file if not specified

However, you should remember that checking of above described option disable message dialogs for all your projects. So, you should be careful with this and you should be sure what you are doing. Don’t worry. If you already disabled a dialog and now want to enable it you can revert to displaying this dialog. Go to “Tools” menu and open “General settings” dialog. Here in “Settings” tab you can find “Enabled message dialogs” section, where you should check appropriated option.

Janusz Grzybek

How To...

Build 310 – new features for XML localization

Build 310 brings new, extended features for XML localization. Below is a short description of the main improvements for XML localization available in build 310.

Improved Localize attribute functionality

With previous builds you could set up  trigger values for disabling selected items from localization by adding Localize attribute for these values. With build 310 this feature was completely rebuilt. For example you can now use positive values for enabling selected items to localization, or localize only items with positive values of localize attribute. You can set up behavior of this functionality in “Options” tab of XML source properties dialog.

Here you can configure the following settings

  • Enable values field (new in build 310) – here you can type triggers for enabling  items to localization. By default Sisulizer use “1”, “true” and “yes” values, but of course you can type here any value. Type values should be separated by semicolons. When you type the same value in”Enabled values” and “Disable values”, Sisulizer uses this value only as disable value.
  • Disable values field – here you can type triggers for disabling items from localization. By default Sisulizer use “0”, “false” and “no” values, but of course you can type here any value. Type values should be separated by semicolons. When you type the same value in”Enabled values” and “Disable values”, Sisulizer uses this value only as disable value.
  • Localize only those elements that have enabled localize attribute checkbox (new in build 310) – when you check this option, Sisulizer automatically disables all items without enabled localize attribute from localization (attribute with values from “Enable values” field). It could be very useful if you want localize only a few items in a huge XML file.

Below I want to show how it works on this XML sample:

  • When you have unchecked “Localize only those elements that have enabled localize attribute”, Sisulizer disables from localization “Do not localize this” string, because this item has localize attribute with disable value, while “Localize this” (with positive value of localize attribute) and “Standard string” (without localize attribute) are enabled to localization.
  • When you have checked “Localize only those elements that have enabled localize attribute”, Sisulizer disables from localization both “Do not localize this” string, because this item has localize attribute with disable value, and “Standard string” because this item hasn’t localize attribute and to localization is enabled only “Localize this” item with positive value of localize attribute.

You can assign localize attribute to selected item from your XML file by selecting “Localize value” item in contetxt menu of tag/attribute item  in tags tree. Tga tree is available via “Tags” tab of XML source properties. Sisulizer can automatically assign “Localize value” for items with attribute names identical with names typed in “Tools” menu ->”Platforms” -> “XML” -> “Localize attributes”. Here you can also disable automatic detection of those items. You can read more about it in this article on our blog.

Localization of XML with included original – translation items pairs

From build 310 you can localize with Sisulizer bilingual files which contains both translations and original items. If you localize such file Sisulize should automatically import translation values to project. However, it requires some preparations in Sisulizer Project Wizard or later in XML source properties of your Sisulizer project. Below is example of XML code with original and translation values:

When we create new Sisulizer project for above file, we should set up context, context and original and translation values. You can do it via item’s context menu in tag tree. Of course, after changes in tag tree (for already existing projects) you need to re-scan the project.

When you set selected element as “Original value”, you should see small padlock icon on this item in tag tree. Notice, when you select misappropriated elements as context value, Sisulizer won’t import translations from source file.

Language attribute

XML specification has a xml:lang attribute that specifies the language of the element. For example in below sample values “xml:lang” tells that text in the data element is written in English.

<data xml:lang=”en”>This is a sample</data>

If XML file contains “xml:lang” attributes Sisulizer automatically changes the value in the localized files and our example in Finnish output file should look like this:

<data xml:lang=”fi”>This is a sample</data>

Starting from the build 310 there is a new option that specifies if Sisulizer should add “xml:lang” attributes. You can select the following settings for this option:

  • No – This is default setting and Sisulizer does not add any “xml:lang” attribute, but it translates if it already exists.
  • Root element – Sisulizer adds language attribute into the root element only.
  • Localized elements - Sisulizer adds language attribute into each element that is marked as translatable.

This new option is available in “Options” tab of XML source properties.

Build 310 also contains a feature where you can set any attribute to be a language attribute. So you can use any attribute beside or instead “xml:lang” attribute. For doing it you should open XML properties, go to “Tags” tab, select appropriated element in tag tree. Next right click on this element and select “Language attribute” from context menu. This makes Sisulizer to set the attribute value in the localized files to match the target lanugage.

Sisulizer can automatically assign “Language value” for items with attribute names identical with names typed in “Tools” menu ->”Platforms” -> “XML” -> “Language attributes”. Here you can also disable automatic detection of those items.


  1. More about XML localization you can find in this article of our blog
  2. Items visible in context menu for selected element of tag tree depends on source structure and position of selected element in this structure. So, not for all elements you will see “Language value” or “Original value” in context menu.
  3. XML samples from this article are based on sample XML and Sisulizer project files from XML directory installed with Sisulizer to installation directory on Windows XP and Sisulizer user directory on Vista/Windows 7. I recommend review those files and experiment both with code of XML files and tags settings in appropriated Sisulizer projects included to this directory.

Janusz Grzybek