Category: How To…

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

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

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.

Hints

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

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.

Hint

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

• Validation features for software localization
• Build 300 – Validation improvements

Janusz Grzybek

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

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.

Hints

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:

• Filter panel – Common filters for translation sheet
• I want to disable localization for some rows. What is better – locking or excluding?
• How advanced use of filters increases localization efficiency

Janusz

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.

Notes

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