How To...

Sisulizer 3 – TM Editor

To Sisulizer 3 have been implemented features for editing content of translation memories. With previous Sisulizer versions you got extended translation memory management features, but these features were limited to “what” items, “how” these items should be saved to selected translation memory and used during auto-translating process. Now you can also edit any content of a selected translation memory directly in Sisulizer without using an external database tool. You can directly change a selected translation, add new strings or remove existing. So, implementing of these features supplement already existing management of translation memory and gives you comprehensive translation memory solutions. New editing functionality is available in “Search” and “Edit” tabs of “Translation Engines” dialog.

Edit Tab

Here you can preview, edit, remove selected or all items saved to the Translation Memory, but of course you can limit range of preview to selected language pair, document, etc. It could be useful for translation memories with lot of saved items. Below is screenshot from this tab, where you can find selection settings in upper part for limiting content displayed in preview box visible in bottom part of dialog. All editing features are available via buttons on preview toolbar.


  • Documents – here you can select content saved to translation memory from specified document, or keep default “All documents” setting for preview all documents saved to translation memory.
  • Language pair – here you can select content saved to translation memory for specified language pair, or keep default “All languages” setting for preview all language pairs saved to translation memory.
  • Page – here you can select page displayed in preview box.

Edit toolbar:

  • Remove – this remove selected string pair in preview box. Button is unavailable (grayed), if you don’t select an item pair in preview box.
  • Remove all – remove all items shown in preview box
  • Edit – this button open edit dialog. Optionally, you can open this dialog by double click desired row (string pair) in preview box, instead using of button on toolobar. Button is unavailable (grayed), if you don’t select an item pair in preview box.
  • Add – this button open edit dialog where you can add new pair and additional data related to this item pair.

As I mentioned above, for “Add” and “Edit”, Sisulizer opens special dialog, visible on below screenshot, where you can add/edit original and translated strings, set translation status or even change original or translation language.

Search tab

“Edit” tab is comfortable solution for review or edit couple strings or whole the Translation Memory, but for search specified string pair I recommend use “Search” tab. Generally, this tab looks similarly to “Edit” tab. Edit toolbar and behavior of edit features is identical with “Edit” tab, while preview box is almost identical with preview box from “Edit” tab, expect “Id” column replaced in “Search” tab by “Documents” column.  However, you can’t find here “Documents” and “Page” settings. Instead it, you have “Search” field with “Exact match” option. When you type unique translation in this field, preview should show one pair. If you type unique original in this field preview could show more items – one per translation language.

Views of both tabs and contents visible in preview box are independent of translation memory engine type.

Short summary

Because our R&D had implemented many improvements to translation memory in Sisulizer 2010, since first official release of this version, I decided add here also short review other tabs visible in “Translation Engines” dialog.

  • Info – it contains common info about selected translation memory.
  • Documents – here you can remove selected documents previously included to translation memory or import new document e.g. SLP,  TMX, etc. to translation memory.
  • Tools – here you can manage backups of translation memory, clear or export translation memory content.
  • Add settings – it contains settings related to adding items from Sisulizer projects, e.g. when Sisulizer should save content of SLP to translation memory, how filter saved items by translation status, saving unused translations from project.
  • Import settings – it contains settings related to items imported from external files, for example how supports export sub-language ID or what translation status should be added to imported items.
  • Translate settings – here you can set behavior of auto-translating for selected translation memory, e.g. how support sub-languages, what translation status should be set, how overwrite existing strings.


How To...

Sisulizer 3 – New HTML Editor

Sisulizer 3 comes with a completely redeveloped HTML Editor. New HTML Editor is more comprehensive and flexible than the editor implemented to Sisulizer 2010. It comes now with four different edit/preview methods for HTML content. You can switch easily the preview/edit method by clicking on corresponding tab which are added on the bottom of the preview window. So you can check quickly all four alternate preview methods for each file.

You can choose the following edit & preview options:

  • Editor – this is your old friend from previous versions of Sisulizer. Sisulizer use own parser for rendering HTML files here, and it allows our R&D on better control and support of issues related to localization of HTML, while this is impossible with third party components. Our HTML parser doesn’t support rendering of CSS, but for preview of visual styles you can use described below “Browser” preview option. Editor allows you on selecting localized text directly in preview window, and translated text is automatically displayed in preview during typing.
  • Browser – this preview method based on Internet Explorer components gives you real preview of HTML file, the same as in your Internet browser. It supports visual styles including CSS. With this method you can see localized items in visual preview immediately after adding or editing translation in sheet. It doesn’t require to build output files – simply, click “Refresh” button (visible on Visual Editor toolbar) after translating item and Sisulizer change content of preview.
  • Source code – this option gives you preview of HTML source code with colored syntax and selectable text items. Sisulizer allows you edit only items visible in sheet, but with “Source code” you can see also not editable tag, attribute and style items. You can’t edit those items, but I think “Source code” preview method is a real milestone, because preview of code gives you full control of localized HTML files.
  • Text – it shows HTML as plain text. It could be sometimes useful, for example if you want to check if “Source code” option correctly displays HTML content, etc.

In current build our old editor inherited from Sisulizer 2010 available via “Editor” tab is disabled by default. However, you can enable this tab at any time, if you need. For doing it you should go to “Tools” menu -> “Editors” -> “HTML Editor…” and check “Use” option.

Applying of this change requires restarting of Sisulizer.

Recently our developers also implemented settings for choosing custom a Web browser used with “Run localized  source” and “Run original source”. So now you can check how localized file behaves with different Internet browsers, while previous Sisulizer’s builds always opened localized files in default Web browser. You can also add default pre and post-name parameters used with selected browser. Those new settings are available via “Tools” menu -> “Platforms” -> “HTML…”.

Above settings doesn’t influence on HTML visual editor behavior.

Janusz Grzybek

How To...

Can I edit my source file in Sisulizer?

Our prospects often ask us, if they or their translators could edit and change code in source files for their Sisulizer projects. Sisulizer’s policy is never to change any original files, even if source file is plain text file. If you would translate text in typical text editor, you usually replace original text with new, translated text. However, Sisulizer works in completely different way and never change source file. When you create new project, Sisulizer scan source file for translatable text. Next, you translate those strings in Sisulizer and save it to SLP file. When you generate localized version of your source file, Sisulizer usually copy scanned content of your source file to new localized file and replace original strings with strings translated in Sisulizer. In every step (scan, translation and build) Sisulizer doesn’t change anything in your source files. Probably we never change this our policy in future, because:

  • As I mentioned above, Sisulizer needs to scan source file. This operation is repeated during each build process. So, all potential changes in your source file made could generate weird change loops between source and Sisulizer project. This would break any project logic and would make results unreliable.
  • If you edit/translate plain text file in typical text editor, you need to replace old text with new. If you don’t create backup copy of your source file, you will lose original text once and for all. In this case you can’t go back to original version of previously translated strings, so you also will lose context of whole text. It really makes it hard to localize next, yet not translated strings. But don’t worry, SIsulizer doesn’t change source files, so you are free from this issue.
  • Because Sisulizer doesn’t change source files, so it can’t be used by hackers to crack your software. Also your translators can’t change source files, even, if you send your sensitive files to them. Protection of sensitive data of our customers is very important issue for us, and blocking of editing source file/code is element of this protection policy.

If you would like to edit your source code, you need do it in your developing tool, because Sisulizer is localization tool, not globalization or developing software.

Janusz Grzybek

How To...

How to get quick info about localization envinroments on your PC?

Translator editions of Sisulizer don’t need any additional developing components on their machines. Developer editions in contrast do require installation of some additional components and frameworks if you want to build output files. Of course, it is not required for most platforms. However, for the following platforms you need to have installed appropriated developing environments:

  • .NET applications (required is at least MS SDK)
  • HTML Help (required is HTML Workshop)
  • Databases localizations (some databases require installation of appropriated engines)

You could check, if your system  meet the requirements of your localization process via “Tools” menu ->”Platform” -> your platform, e.g. .NET. However, if you want to check this in a quick way, simply go to “Help” menu -> “System information” . It opens a dialog with short and condensed information about installed components required to localize .NET applications, databases and info about your Windows and locales via following tabs:

  • Operating System
  • Locales
  • Compilers
  • Databases
  • .NET

On above example screenshot, you can see what types of databases engines are installed on my PC. This list doesn’t show in example Paradox, because I haven’t installed Borland Database Engine.


How To...

Unique features of Sisulizer’s Search & Replace functionality

Search & Replace is an important and often used operation in localization process, so Sisulizer has even special menu in main menu bar dedicated to search operations.

Search menu for localizations

Generally, this feature is similar to Search/Replace features implemented to other third party localization and developing tools, text editors, word processors, etc. Sisulizer uses typical UI items and shortcuts for search features, for example:

  • You can use wildcards
  • You can use regular expressions
  • You can limit search results to whole words or strings
  • You can set up search direction
  • You can set up search range (from cursor or entire scope)
  • Search can be case sensitive
  • You can use standard shortcuts as e.g. F3

Many advanced text editors or developer tools have implemented identical or similar features. However, it could be misleading, because Sisulizer’s Search & Replace has many unique features adapted to localization process. Those differences could sometimes puzzle our customers become accustomed to other tools, and for this reason I’d like concentrate in this short article on differences and unique features of Sisulizer’s search & replace. Those unique features and behavior are shortly described in below points.

Working with sheet columns

Sisulizer’s main workspace based on a sheet which looks a bit similar to Excel sheet with vertical columns and horizontal rows. Sisulizer always searches items only in currently selected column regardless of Direction and Origin options selected in Search dialog. This range limitation prevents accidental and unintentional changes in currently not edited language columns. Off course, you can choose every column in sheet (also context column) for search. If you want to find selected text in several columns, simply select next desired column and use F3 shortcut and so on.

Sheet filters and text search feature

Sisulizer always searches text only in potentially visible contents of translation sheet. So if you use sheet filters e.g. text, row statuses or translation statuses filters, Sisulizer will search specified text only in filtered sheet content. For example, if you uncheck all translation statuses but “Auto translated” translation status and “Changed” row status, Sisulizer will use those filters also in search operation (look on below screenshot). So, with this flexible solution you can specify search range not only on item location, but also based on item status. Sometimes, it could stir up users, when they forgot to uncheck used filters, and for this reason they couldn’t find specified text. But don’t worry, Sisulizer displays “Special filters on!” warning at bottom of filter panel (look on below screenshot), when you use a sheet filter.

Filters used while translating

Additionally, you can separately use those filters only with search feature, without using it in sheet. Here is article about this pretty new functionality implemented to Search & Replace feature.

Project Tree and text search feature

Search range also depends on selected node in Project. If you select “All” (parent) node in Project Tree, Sisulizer will search selected text in whole project. When you select source node, Sisulizer will limit search range to selected source. If you select source sub-node e.g. form or stringtable, it limits search range to this sub-node, even if you use “Entire scope” setting. Combination of this feature and sheet filters gives you powerful possibility of precise specify search range. For example you can search selected string only in selected sub-node and additional narrow search results to items with selected translation and/or row statuses, etc.

Find results pane

If you click on “Find All” button in “Find text” dialog, Sisulizer will displays all matched results in “Find Results” pane visible in bottom part of Sisulizer’s main window. This is a very comfortable solution, because it gives you full preview of all matched items.

results of search in localizable content

If you want to go in sheet to selected item, simply double click this item on list in “Find Results” pane. It doesn’t clear find results list, so you can go back to this list in any moment and manage next matched items. Also when you change pane (by clicking on other pane tab) list is preserved, so when you change back to “Find Results”, you will see results of last search operation again. This list is cleared, when you close your project. Some advanced text editors or localization tools have implemented similar features, but this solution isn’t common and for this reason I described it here. If bottom panes aren’t visible, go to “View” menu and activate “Panes” menu item.

Search in Project Tree

Apart text search feature, Sisulizer has also implemented feature for search nodes in Project tree based on node name. It could be useful for big projects with lot of sources or sources with lot of nodes. This feature is available via “Search” menu -> “Find node” or via context menu of Project tree.

Find next/prev untranslated rows

If you don’t want to scroll whole project and use filters for search of not translated items, simply go to “Search” menu and click “Next Untranslated Rows”. It moves you in sheet to next not translated item in currently edited language column. Similarly, if you click on “Prev Untranslated Rows” item in this same menu, Sisulizer moves you to previous not translated item. This could really speed up translation process, especially if you use shortcuts instead of opening menu and clicking appropriated menu items. Below are those shortcuts:

  • Ctrl+G – Next Untranslated Rows
  • Ctrl+Alt+G – Prev Untranslated Rows


As I mentioned above, you can improve your search operation by using search feature in close collaboration with Sisulizer filters. However, if you aren’t familiar with advanced Sisulizer filters, I recommend you read following articles on our blog:

Janusz Grzybek

How To...

Using Trados with Sisulizer

Many translators especially ones connected with LSP prefer using Trados or other CAT tool as main translation tool. It sometimes could generate issues between developers who use Sisulizer as tool for scan/build and their translators who work with Trados and are not facilitated with Sisulizer. Flexible Sisulizer Exchange feature allows to create packages with included localization resources and special Sisulizer installer for translators, but they often haven’t to much time for learn a new tool. However, don’t worry, if you are developer you do not need to send this package to your translator if he doesn’t prefer this solution. Instead, you can send resources in format compatible with your translator’s tool e.g. Trados. This is an easy and efficient solution. Simply go in Sisulizer to “File” menu and select “Export” menu item.

Export translatable content as tmx or xliff

In the open wizard select TMX or XLIFF format. Both formats are common localization data exchange standards and are supported by all modern CAT tools. Sisulizer has extended support for TMX and XLIFF format and allows to save e.g. contexts, translation statuses, row statuses, comments, invalidated or marked flags.

XLIFF export features

Here is article about optional items saved to exported file. Unfortunately, other tools don’t support all these items, so you may want to uncheck those options. Generally if you keep all options checked, it doesn’t generate incompatibility issues with your CAT tool – they simply don’t read e.g. context, but unchecking above options could reduce size of exported file. Next, your translator can in easy way translate this TMX or XLIFF file in Trados. If you received translated file, use “File” menu -> “Import” (like for exchange package), select import options and import translations to your Sisulizer project.

Short summary:

  • Plus: your translator can us his preferred tool and it could speed up translation process
  • Minus: your translator can’t utilize advantages of visual localization and he doesn’t see context of localized items

Janusz Grzybek

How To...

Why are some of Sisulizer’s menu items invisible in my localization project?

Our customers often are confused by the fact that in some projects important GUI items in e.g. “Project” menu are missing, while in other projects those features are visible in the GUI. They ask us via forum what happened with their Sisulizer installation. This is not bug in Sisulizer or a result of a license problem. This is normal behavior, when your project has enabled “Project is in translate only mode” option. This option is available via “Project” menu -> “Options” -> “General” tab.

Where to select Translate only mode screenshot

Because in this mode users can only translate and optionally build projects, the following options are unavailable:

  • Scan sources
  • Add new sources
  • Edit source properties
  • Edit component settings
  • Add new languages to project
  • Clear row statuses and remove unused items
  • Remove excluded rows and originals

All those feature are reserved only for developers. The “Project is in a translate only mode” option prevents developers from undesired changes performed by translators in project. Because all those features are unavailable after checking above option, so all appropriated GUI items are also removed for projects in this mode. However, changes in GUI require restart of project, both for checking and unchecking “Project is in a translate only mode” option.

Here is screenshot of “Project” menu in standard mode:

Localization project options

And “Project” menu in translate only mode:

Localization project options in translate only mode

Sisulizer always set translate only mode for projects included to translation packages. So if you would like use all developer features in project generated by Exchange Wizard, you need uncheck described here option and restart project.

Janusz Grzybek

How To...

Build 316 – Improved export to TMX and XLIFF formats

With build 316, Sisulizer gives our customers new functionality in Export Wizard. Sisulizer has implemented a very advanced and flexible feature set for export to TMX and XLIFF formats, and gives you a possibility unavailable in other localization tool. Here you can learn how to customize content of exported file. Now, you can specify what Sisulizer should save to translation items in exported TMX or XLIFF file. Additionally, Sisulizer can save translated and not translated translation values to exported file in different ways.
This new feature is available as “Translation value” combo-box in “TMX” tab -> “Options” and “XLIFF” tab of first step of Export Wizard (“Export Wizard – File”).

Below is a screenshot from Export Wizard for TMX export format with visible “Translation value” option:

And for XLIFF export format:

Available settings for this new export option are:

  • Ignore if no value
  • Write empty if no value
  • Write original if no value
  • Write always empty
  • Write always original


With Sisulizer you can not only export localization resources to XLIFF and TMX files or import to Sisulizer XLIFF and TMX files generated by third party tools, but also use those file formats as sources in your Sisulizer project, that is, you could create new project (SLP) for TMX or XLIFF files or add those files to your existing project.

Janusz Grzybek

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