Author: Janusz

Text sources could have very different internal structure and for this reason our R&D give free hand our users, so actually you can fully define parse rules for your non standard text file. If you needn’t use a parsing definition, because your file is simple text file e.g. this is an EULA, you should select “Plain text” option in the Project Wizard. Otherwise, select the “User defined text file”.  Below are 4 examples of text definitions for different text files.

Example 1

Let’s assume that a text file is similar to standard INI file with keys, separators and values:

For this simple structure Sisulizer should automatically detect and set correct structure, so you need only click “Next” button.

 

Example 2

In our next example original and translation (identical with original but after localization replaced by strings in targeted language) are separated by line breaks and all pairs are separated by empty lines.

For such structure we need define detailed rules for context and text items. One context item with default settings item is automatically added to list. For optional editing of existing rule double click it or click “Edit” button. For adding new rule (e.g. text rule) you need click “Add” button and next select “Text”item in “Type” dropdown menu visible in bottom part of opened “Text Rule” dialog. Then you need set appropriated characters before or/and after item. You can type it manually or click “+” button and select item in popup menu.

With our defined rules based on carriage returns and line feeds (items in file are separated by line breaks and empty lines) we can add localization languages, finish the wizard and scan source.

 Example 1 with comments

Text files often contain comments with important information from developers. Comments are usually preceded by special marks, and in our example we used “#”

Commonly used comment marks are “//”, sometimes “#”, “;” or “?”, but there is no fixed syntax , so Sisulizer doesn’t fill automatically context and text items. However, we can use rules from our first example (without comments). You also need define comment.  For doing it you should click on “Comments” tab in bottom part of the wizard window and type comment “#” in line comment field.

That’s all. Now you can only add language and scan file.

Example 2 with comments

There is big difference in defining rules for our second text file, if we add comments. It looks innocently…

… but here we can’t use simple definition with comments, because:

• Comments are located between empty lines, while our context/text rules use carriage return and line feed, so it can break our rules.
• Comments occur in irregular order.

But don’t worry, if you know regular expressions, you can find workaround based on regular expressions and define correct rule (Thanks Jaakko for help). Here essential is (^\s*#.*?\r\n|\r\n)+ expression used as “Before item” in context rule.

Sum up:

• Sisulizer is really flexible tool.
• Regular expressions are your big friends, so visit them sometimes.

Hints:

• As written above, Sisulizer has one predefined key/value rules set, but you can add your own fixed rules via “Tools” menu -> “Platforms” -> “Text…”. If you often localize text file based on this same internal structure, consider this solution – it could really speed up your work.
• You can export and import definitions to external files, directly via Project Wizard or later via “Format” tab in text source properties dialog.
• You can learn about regular expressions on Wikipedia, ICU or Regular Expressions Info websites.

If you use binary localization, you can browse component structure directly from Sisulizer’s Visual Editor. This view could be useful if you have not in SLP visible text items, not mapped components and folded tree structure makes work much easier and shows internal dependencies inside browsed form. Below is example screenshot from main form of our Delphi sample.

You can open this window by click “Browse Components…” item in Visual Editor context menu.

You can also browse form resource via “Shows as Text” and “Shows as Binary” sub-menus in context menu of form node in Project Tree. Those features is described in this article.

Janusz

From build 339 you can specify the minimum translation status that are used when building localized items. By default this is the lowest translation status, Not translated, that means all translation are used no matter what the status is. If you set this value to any higher value then Sisulizer uses only those translations that have translation status equal or higher than the value specified here. This new feature is available via Project menu -> Options -> General tab -> When building use translations that have at least this status.

Here you can select required status in drop-down menu. After selecting, output files will contain originals instead translations with statuses lower than selected. Below is list of all Translation Statuses ordered from lowest to highest:

• Not translated
• Best guess
• Auto translated
• Translated
• For review
• Complete

This feature can be useful in your localization job, for example:

• If you would like release your application only with high quality and validated translations.
• You don’t want use poor quality translations provided by machine engines during tests of localized files. They can make unclear those tests and not validated strings with invalid placeholders can crash applications.

This feature works on project level, so selected setting is used for all sources included to project.

Janusz Grzybek

Our samples are very useful for our users and are by default installed during Sisulizer setup. Samples contain not only simple source and SLP files. Typically our samples comes with documentation, resources and code files which can be used within your application, e.g. for implementing switching at runtime. So we recommend installing them with main application. However, if you didn’t know it and unchecked it or you deleted those files by accident, you can reinstall it.

Run latest Sisulizer’s installer and in “Sisulizer 4 Setup – Existing Installation” step select “Modify the existing installation”

Next in “Sisulizer 4 Setup – Select Samples” step check desired items or simply click “Check All” button for installing all those items. Then, click “Next” button in all other steps of setup.

All samples are available via menu File -> Open Sample… or via Open Sample button on Sisulizer’s start page. PDF documents about .NET and VCL localization installed to samples folder can be opened via Help menu.

Janusz

Sisulizer’s Exchange Wizard is very flexible tool and you can use it in many different ways. Below example shows how to add to Exchange Packages only not translated strings, even though every language has a different amount of not translated strings.

Let’s assume that in our SLP we have 4 languages (German, Finnish, Japanese and Arabic) and those languages contain different count of not translated strings

• German: 2nd, 3rd and 8th strings on below screenshot (in ascending order)
• Finnish: 4th and 5th strings on below screenshot (in ascending order)
• Japanese: 5th, 6th and 7th strings on below screenshot (in ascending order)
• Arabic: 2nd, 3rd, 8th and 9th strings on below screenshot (in ascending order)

All those not translated items are marked by red rectangles on screenshot.

marked ob below screenshot by red rectangles

We want to send to our translators a SLE package with not translated strings only. So in the “Translations Statuses” tab of “Exchange Wizard – Filters” we should uncheck all statuses expect for “Not Translated” status.

However, if we generate one Exchange Package with all languages, generated SLE will contain sum of all not translated items in all languages, that is 2rd to 9th. So, when our potential Arabic translator opens sent SLP package, he will see also items already translated to Arabic. Similar issue, but for Export wizard was described in this article.

But, don’t worry, because you can easily solve this problem by checking the “Create several packages, one for each selected language” option in  the “Exchange Wizard – Languages and items” step.

Using this option generates separated packages for each language in one operation and all SLE packages will contain only not translated items in selected language.

Of course, this is only very simple example, and you can combine different settings of translation statuses in your own Exchange setup. However, I hope it shows capabilities of the Exchange Wizard.

Janusz Grzybek

Import method is the most important import option in Sisulizer’s Import Wizard. It specifies how Sisulizer will support imported contents. To select an import method use the “Import Wizard – Options” step of the wizard.

Sisulizer supports three import methods:

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

Because each method can produce different results, so it sometimes confuses our customers.  However, I decided to use here an exercise based on a small sample SLP, instead of standard article.

Example

This is our example, main SLP file.

Below is imported SLP file.

Please don’t worry about below results of different import settings. Our example is very specific, both the original and the translation column are in English, both SLP files contain duplicates translated in different way (expect one string). There are no typical duplicates of strings commonly occurred in standard an application for example “OK” or “Cancel”.

Localization resources can contain dozens occurrences of those strings, and “By value” or “By context first then by value” could be the best solution for quick importing good translations. Actually, this example shows general behavior of different import settings, so don’t take this example into the consideration, when you would like to select best method of import. Your choice should depend on your needs and specific resource contents.

Import results

• Import method: By context
• Overwrite method: Never

• Import method: By context
• Overwrite method: Always

By context method always gives most accurate translations, because import is based only on context, while context in Sisulizer projects is always unique. This is very good solution if your SLP should contain duplicates translated in different way. By the other hand, it gives less translations than By value method, if imported file doesn’t contain translations for duplicates.

• Import method: By value
• Overwrite method: Never

• Import method: By value
• Overwrite method: Always

By value method do not use context at all, and it compare only originals in both SLP files. When imported file contains duplicates translated in different ways, Sisulizer use always translation for first occurrence of original found in imported SLP. This is, because context is ignored, while originals are identical and Sisulizer doesn’t know which translations should be used. In our example  Sisulizer use “Trabant is the best German car”, while “Volksvagen is also good German car” is ignored.

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

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

By context first then by value method combine merits of both previously described methods, and for this reason this is my favorite method. First Sisulizer try import translations based on context. Next, for not imported items in first import pass based on context, Sisulizer use by value method. So for all items with matched items, even originals translated in different ways, you’ll get accurate translations. Additionally, for other items Sisulizer use translations based on originals – for example, when your main SLP contains 30 “Cancel” originals and imported file only one “Cancel” translation, this translation will be used for “cancel” originals in your main SLP.

Notes

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

Janusz Grzybek

Source properties dialog contains lot of important settings. We often discuss about those settings in our support forum and our users ask where is this dialog. You could open this dialog via several GUI commands:

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

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

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

Janusz Grzybek

We always say using resource DLL files is the best solution for localization of your application, but unfortunately some older programming platforms e.g. still very popular Visual C++ don’t support it internally. However, Microsft added partially support for this solution to MFC 7 libraries. If your application use MFC 7 you could use Sisulizer to build localized resource DLLs for your application.

Generally, MFC 7 doesn’t support language switch at runtime. Your MFC application will use automatically the resource DLL which matches the Windows locale if available. But optionally you could use a custom or third party solution for implementing switching at runtime. Many Visual C++ developers don’t know they could generate resource DLL directly in Sisulizer projects based on Windows32 exe files, so I decided to write some hints related to this feature.

If you want to set up resource DLLs as output for your Sisulizer project, just select Resource DLLs option in File tab of source properties dialog and set appropriated output filename pattern matched with MFC or with your custom solution. Here is article with detailed information about output options.

MFC requires using language IDs for resources inside resource DLL e.g. for dialogs, icon resources etc. instead of neutral or original language IDs. For doing it, you need to go to the  Options tab of source properties dialog.  Please uncheck Keep original resource language id, and select Set the language always in the Set language of a neutral resource list.

If your application also requires for resource DLL specified info related to language in version resource, go to Resource options in source properties dialog and check appropriated options in Versions section. If your application uses MFC libraries, check  Application uses MFC library in this same tab.

If your application has many languages, resource DLLs with all duplicated resources could significantly increase size of your application. In this case you could try uncheck Copy all resources option in resource file tab of source properties dialog. Build resource DLL with checked this option, next uncheck it, build again and compare sizes. So if this streamlined DLL works with your application we recommend to use it.

Resource DLL built by Sisulizer is immediately ready to use without additional preparing. If resource DLL is matched with your locale, simply copy it to installation folder and run your application. All screenshots were made with our Visual C++ example in vcpp subfolder in our samples folder. You could use it for experimenting with all above mentioned tricks and options.

Janusz Grzybek