Sisulizer – New row timestamps features in localization project

Timestamps columns

Since Build 331 Sisulizer’s scan feature adds date & time to new, and changed rows. This new functionality gives you full control on all changes made in source files during localization process. Before build 331, Sisulizer could mark only new items or changed items detected during scan, but it didn’t give you any information when it happened. Additionally, after removing row statuses you lost those flags from project. With build 331, you could still specify what and  when items were added e.g. in previous updates of your source after cleaning row statuses. I think this new functionality could be invaluable tool for developers and allows on good synchronization of developing process with localization. You can track those timestamps by new columns available in sheet, that is:

  • Creation time
  • Changed time

By default both those columns are disabled and if you would like display it in translation sheet you need move those columns from “Hidden columns” box to “Visible columns” box in “Columns” dialog.

You can open this dialog via “View” menu -> “Sheet Columns…” or via “Columns” button on sheet toolbar. More about sheet customization on this blog.

On below screenshot from an example SLP are visible those columns and also other related columns already implemented before build 331, that is:

  • Translation time – this column shows you translation date & time. Sisulizer add this timestamps only to manually added or edited rows, some some translated rows filled by Translate Duplicate, Import or Translation Engines features have empty translation time cells.
  • Previous original – Sisulizer not only marks changed source items, add timestamps to those items (based on scan/detection time), but also remember old original value, if changes were made in original values (strings) not in context (changed structure without changes in strings). So now you can in easy way compare old with new original values and find changes.

(Please, double click on image if it is too small for you)

On above screenshot you will find easily items with two dates. Older date is SLP creation date, newer is next scan date, when Sisulizer found new and changed items in source. Additionally, on our example:

  • Yellow and red dots in Flags column indicate all new and changed items. You can clear those statuses via “Project” menu. More information you will find in our Row Statuses article.
  • Invalidated marker, that is red dots in top right corner of translations cells indicate not verified translations of changed originals. When you edit translation, this marker is automatically removed. If you don’t want change translation, you can remove Invalidated status via context menu of translation cell. More information about Invalidated status is this article.

As you see on this short example, with all those extended features you get full control on changes made in source file.

Timestamps filters

That’s not all… In build 331 implemented also special filters for creation, changed and translation timestamps. Those 3 new filters are available in new “Time” tab of filters dialog. This dialog is available via “View” menu -> “Sheet Filters” -> “Edit…” or via “Filter…” button on Filter panel toolbar.

So from now you can filter sheet content based on time. Of course, you can combine all those 3 filters together or use it with other filters, e.g. with Row Statuses filter. Read more about the benefits of  filter combinations.


When you first time scan SLP created in an older Sisulizer build as build 331, Sisulizer add automatically “Creation time” timestamp to all rows with this scan date & time as initial value.

Beside filters, you can change displaying order in sheet by simple click on column header. Of course, this feature also work with timestamps columns.

We mentioned above about row statuses and row statuses filters. Give our  row statuses filter article a try.


Janusz Grzybek















How to validate required strings and custom placeholders?

Sometimes developers want to keep some important items untranslated.Your product’s name is a good example. The name may be in your string ressource, but typically the name is a trademark, and it should not be translated at all.

Take a look at the following string:

“SUPERCLEANER is very easy to use”.

SUPERCLEANER is the name of the product and if the company has decided that it must be always written like this the string should be set as required. When translator translates this is is very likely that they will translate it in a different way. For example Japanese translations might be “スーパークリーナーはとても使いやすいです”. This is according normal Japanese way but against company policy. It should be “SUPERCLEANERはとても使いやすいです”.

For avoiding this issue developers often replace sensitive names with custom placeholders, for example $APPNAME  replaces application name, $APPCOMPANY company name etc.  However, in this case translator could make mistake during typing unfriendly placeholder items or by using third party translation engines e.g. MS Translator or Google Translate, because they can change those items during auto-translating.

Exactly for this case Sisulizer has implemented our placeholder validation feature. By default it works only with standard placeholders e.g. “1%s” or “1%d”. But don’t worry, because in Sisulizer you can define items required in translated strings and those required strings are also checked by our Validation feature. So you can validate if translated resources still contains e.g. SUPERCLEANER or $APPNAME.

Just select the desired row in sheet and next

  • Go to “Row” menu and select “Required strings…” menu item
  • Or right click on row and select in context menu “Row” -> “Required strings…”. This option is shown on below screenshot.

It opens “Required strings…” dialog where you can type or paste your required items. Because this feature is related to row, so for every row this dialog you can see different content in this dialog. Of course, you can type more required strings for selected row (one per line).

As I wrote above it works per row, so during validating operation Sisulizer searches specified term only in rows where you typed required string. Also when you want to clear specified term, you need to select row and next open “Required Strings” dialog, because when you select another row, specified required string won’t be visible.

If you want to check required strings during validation you need to check “Required String” item in Validation dialog on list in “Types” tab.


If you aren’t familiar with validation features I recommend to read the following articles on our blog:

Janusz Grzybek

How to indicate in project which items are imported by context and by value?

We often show By context first then by value as most powerful and flexible import method. With this method Sisulizer tries first to import by context, and if no match exists, it imports by value. This combines the merits of By context (more appropriated results) and By value (more translated items) methods.

Usually, items imported by context are very accurate and they don’t require focused attention. Otherwise items imported by value method should checked in more detailed way. Unfortunately, Import Wizard does not allow to select an own translation status for items imported by context and by value in one pass.

However, you can use the following trick to save time and effort.

In our example we assign different translation statuses to items imported by context and by value. For doing it we don’t use By context first then by value method, however we’ll simulate this method by two passes of import operation. First, we set By context import method.

Next, we go in this same Import Wizard step to Import translation status section, check “Set status to” and select not lower a translation status, e.g. “Best Guess”.

Now we can click “Finish” button and perform import operation. After this, we repeat import operation, but now as import method we select “By value” method and change selected status of imported items to lower e.g. to “Auto translated”. Finally we got result similar to “By context first then by value” method, but we can distinguish items imported by value method from items imported by context method, because they have different translation statuses.

Janusz Grzybek


How to lock a form in my localization project?

Sometimes developers would like to lock layout of selected form in Sisulizer project and keep other forms editable. Sisulizer allows to lock selected control types, or all forms in whole project selected or sources, etc. in many ways. Here is article about this.

However, Sisulizer hasn’t implemented direct feature for locking all controls in a specified form. But don’t worry, because flexible filtering features allows you do it quickly. All editable items related to form layout, that is x & y position, height, width are Integer numbers, so if you will exclude all Integer numbers in specified form node, it automatically lock sizes and positions of all controls used in this form.

First, you need select desired form in Project Tree, next check “Integer number” item in Filter panel (indicated on below screenshot by red rectangle) and uncheck all other data types in filter. After this action you should see in sheet only Integer numbers. Now you can select all visible content by “Column” menu ” -> “Select Column” or via Column context menu. This second option is visible on below screenshot.

Next, click on “Exclude Row(s)” button visible on sheet toolbar or via sheet context menu.


This operation excludes all Integer numbers in selected form node, so form layout won’t be editable for translator. However, you can later revert all those excluded items via “Project” -> “Excluded Rows…” dialog.


In our example we used filter and excluding features. If you want learn more about filters used here, excluding features and combined using of different filers, I recommend you read below articles:




New API for Microsoft’s bing Translator

Recently Microsoft considerably changed their bing Translator service. Currently, bing Translator is a paid service – however a free version is still available and described below.

To use this service an account on Microsoft Azure website is required, and you need to register an API client id. Unfortunately, this process is complicated, because Microsoft sited have lot of menus, pages and forms, so users could mix up some steps or codes. Luckily, our R&D implemented very helpful links to changed Microsoft Translator API, available via “Get account” button and “Register account” buttons:

Below is a short guide, how to register bing Translator in your copy of Sisulizer:

When you click on “Get account” button in “Tools” menu -> “Translation Engines” -> “MS Translator”, Sisulizer will open Microsoft Azure Marketplace website in your default Internet browser. Here you can select most appropriated plan. At the bottom of the list with available paid options, you can find freware subscription plan for MS Translator. It allows you translate 2000 000 characters per month via registered API, and when month ends, counter is rested. I think this is still very good option, especially because Google doesn’t offer freeware version of their auto-translation service.

When you selected most appropriated option for you, click on “SIGN UP” button in bottom right corner of selected option. If you aren’t logged on your MS account, it should redirect you on Microsoft login website. After login, you’ll see checkout confirmation page. If you haven’t had account on Microsoft website yet, you could create your account by click “Sign up now” link in bottom part of login site.

When you finished subscription process, you can connect your subscription with API in your Sisulizer copy. Click “Register account” button in “Tools” menu -> “Translation Engines” -> “MS Translator”. This opens Applications site on your Microsoft account (if you aren’t logged to your account, you will be first redirected on login page) where you should click “Register” button. It opens form with automatically generated Client secret key.


Fill Client ID and all other required fields and click “Create” button. When you back on “Applications” site on your account, you’ll see new application entry in bottom part of site, with “Edit” and “Delete” links. Via “Edit” link you can later get access to your Client secret – for example, you could copy it and paste to your application.

Now, you can back to Sisulizer and paste Client ID and Client Secret keys to appropriated fields, like on below screenshot.


After this, I recommend you click “Test” button. From build 335, this feature perform real connection test with MS service, and when you have empty Client ID and secret fields, you’ll see this message:

When your data are incorrect, you’ll see this message:

When your Client ID and secret are matched with your account data, you’ll see this message:

Of course, for performing this test (and for using MS Translator) required is Internet connection. Because Sisulizer connects with external server during test, so it take some time, so be patient.


Your Microsoft could contains different keys, that is main account key, keys for other applications and services, client IDs, etc. and it could mislead user, so you need be careful and type/paste right keys to Sisulizer. For example, on below screenshot are indicated account keys, but they aren’t MS Translator API’s keys. However, I hope links available via Sisulizer GUI and this short guide help you correctly register your MS Translator service.


Data form above screenshots were made with test account, created only for this article and you should use your own data during registration.

Janusz Grzybek

Japanese characters are incorrectly displayed in Sisulizer. How I can solve it?

Windows 7

Sisulizer is fully compatible with Unicode and can display correctly all East-Asian (Japanese, Chinese, etc.) and RTL (Right to Left, e.g. Arabic and Hebrew) languages, but for displaying those characters, Sisulizer use fonts installed in operating system. Font issue could occur on all Windows versions, even on Windows 7. Generally, Windows 7 has very good Unicode support, but unfortunately not all Unicode fonts contain all Unicode characters. This is not Mojibake issue described on this our site. Mojibake issue is related to general implementation of code pages on older Windows versions (all Windows versions before Vista and Windows 7), and even if your localized Japanese application displays Mojibake characters on your Windows with installed East-Asian language support, Japanese characters should be correctly displayed in Sisulizer. However, if on your Windows 7 (Windows XP behavior is described below) you’ll find small squares or thick and short vertical lines in Sisulizer sheet instead Japanese characters, it certainly indicate font Unicode issue.

You can fix this issue in very easy way – without advanced changes in OS, or installation new fonts – directly in Sisulizer. Select language column where issue occur (e.g. Japanese), next go to “Column” menu and select “Language properties” menu item. In opened dialog window go to “Font” tab, uncheck “Use the default font” checkbox and select other font in dropdown menu.

I don’t know specific settings of your system, but if standard Unicode font such as Tahoma doesn’t display correctly characters, try Arial. This font usually works. Below is screenshot from this same sample Sisulizer Project, but with changed font.

Windows XP

By default, with Windows XP is not installed support for East-Asian language, and for this reason all Japanese or Chinese character are incorrectly displayed, whatever you a font selected. For solving it you need install East Asian languages from your Windows XP installation CD. Go to Control Panel on your Windows XP and click “Regional and Language Options”. Next go to “Languages” tab and check “Install files for East Asian languages” and optionally “Install files for complex script and right-to-left languages (including Thai)” in “Supplemental language support” section. If you didn’t inserted Windows XP installation CD, Windows asks you about this. For applying changes, you need restart OS.

If this changes in your Windows XP, don’t solve font issue, try trick from part for Windows 7 (changing displaying Font in Sisulizer).

For Windows 8 please cross-check our corresponding article here.

Janusz Grzybek


Why to use a Software Localization Tool

This msdn blog post gives some insight into the not so far away past of software localization:

With tools like Sisulizer you can localize your software while you are developing it. A simple call of Project – Scan for Changes updates your project to the latest build and re-uses everything already translated. No more need to re-translate dialogs after your software changes while developing it. Your localized version can be released without delay.

Thanks to Gert from GdP Software ( for the above link.



Build 330 – Improved Gettext support

Our developers continuously improve support of Gettext localization.  Gettext is free software and an OS independent platform. It is definitely a very popular localization solution chosen by developers. With Sisulizer build 330 our customers get following new or improved features related to Gettext support:

Support for partially translated source PO files

In build 330 added support for partially translated PO/POT files. For clarifying this improvement I need basically to explain how Gettext works. Gettext localization based on following item pair in PO/POT files:

  • msgid – this item contains original string
  • mgstr – this item contains translation

Before build 330, Sisulizer used “msgid” items as originals, when “mgstr” are empty. When “mgstr” item contains a translation, Sisulizer used this item as original. Since build 330 Sisulizer always uses “msgid” items as originals. Previous scan method worked perfectly when localization process was fully made in Sisulizer, because Sisulizer saves translations to SLP files, not to source PO or POT file. However, it caused troubles when source files were previously translated in other tools e.g. popular POEdit. Since build 330, you can also add as source (to Sisulizer project) fully or partially translated PO/POT files. It helps switching to Sisulizer, or translating PO/POT files generated by other Gettext tools used by your developers. After adding such file as source you can also re-use existing translations from this source file, by using Import feature. Because Sisulizer has implemented advanced and flexible import features, so you can do it in three different ways:

  • Use “Project” menu -> “Import Translations From Localized files”. In this case output filename should be matched with source filename. Here is article about this import method and here is article about output file settings.
  • Use “Project” menu -> “Import…” and select “PO file pair” in Select File Format step of Import Wizard. Here is article about this import method.
  • Use “Project” menu -> “Import…” and select “PO file” in Select File Format step of Import Wizard. It uses standard Sisulizer import method. You can find details also in this article.

Management of contents saved to output PO files

Sisulizer can build as output files both compiled MO files (used as localization resource files in localized application) and translated PO files (the same as source, but with included translations made in Sisulizer). Before build 330 Sisulizer always saved original items to translations (mgstr) items in output files. However, when this file was opened in third party tools e.g. in POEdit, it shows file is 100% translated, because output PO file didn’t contain empty translation items. Since build 330 you can decide what Sisulizer should to do with not translated items during build output PO file.  Now you can select following options

  • “All” – Sisulizer works like before build 330, that is Sisulizer saves (in output PO file) original to translation item (mgstr) if translation doesn’t exist.
  • “Translated” – Sisulizer keeps empty mgstr items in output PO file,  if translations don’t exist.
  • “Different” – Sisulizer saves only differences, that is when translation is identical with original, appropriated translation item in output PO file is empty.

You can change this setting in “Options” tab of source properties dialog. You can open source properties dialog via context menu of source node in project Tree or via “Project” menu -> “Edit source” -> select your source.

This feature could useful when your developer/employer use third party Gettext tools and it allows him check translation progress, forward it to other translators who use third party localization tools, use in SVN solutions, etc.

Other improvements

In build  330 improved also support of plural forms and support items with identical original values and different comments.

All those changes significantly improved compatibility with third party tools e.g. POEdit and now Gettext support in Sisulizer is actually “tool independent”.

Best regards,
Janusz Grzybek



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.