Build 339 – selecting translation statuses for build

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.

statuses_for_build

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

How to install Sisulizer’s samples?

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”

setup_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.

setup_select_samples

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

Generating exchange packages with different amount of not translated items

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

sheet_view

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.

exchange_translation_statuses

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.

not_translated_all_languages

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.

separateted_sle

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.

not_translated_one_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

SlMake updates in recent builds

We published on our blog article series about the SlMake tasks in the past. However, our R&D implemented a lot new features in the meantime (Last the article about the Slamke was published in Marth 2010). I always update appropriated articles after changes in SlMake, but it is made without announcements. So, articles are still topical, but our users could overlook it. For this reason I decided write this short preview of all new features implemented to SlMake since March 2010.

Build 343

Added -uilangs parameter to exchange task.

Build 334

Added  -config parameter to create task.

Build 332

Added -origlang and -outitem: parameters to add task

Build 323

Added -subdirs parameter to add task. Here is article about this task.

Build 310

Added -input: parameter to create task.

Build 307

Added -name: parameter to validate task. Here is article about this task.

Build 306

Added -invalid: and –marked: parameters to exchange and export task. Here and here are articles about these tasks.

Build 303

Added -output: and –al: parameters to create task. Here is article about this task.

 

Besides those new parameters our developers improved behavior of some tasks and parameters in the meantime. They also fixed some bugs reported by our users. You can find full info about those changes in our changelog.

If you haven’t read our articles about SlMake yet, I recommend you go to this article with general info and additional links.

Janusz Grzybek

 

Short explanation of Import methods

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.

import_methods

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.

main_slp_example

Below is imported SLP file.

imported_slp

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_by_context_overwite_never

  • Import method: By context
  • Overwrite method: Always

import_by_context_overwite_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_by_value_overwite_never

  • Import method: By value
  • Overwrite method: Always

import_by_value_overwite_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_by_context_first_than_by_value_overwite_never

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

import_by_context_first_than_by_value_overwite_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

How to find the source properties dialog?

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

Using resource DLLs in MFC application

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

 

 

Sisulizer and Microsoft Access 2010 64-bit

With Sisulizer you can localize Microsoft Access database files with all four available database localization methods in Sisulizer, including Cloning. You also can use MS Access databases (both old *.mdb and new *.accdb database file types) as Sisulizer’s Translation Memory engine. Here is article with info about creating new a Translation Memory.
When you installs MS Office 2010 it will also install Access engine, and after that you can use Access with Sisulizer. If you don’t have Microsoft Access and/or Office installed, you can download a free Access engine from Microsoft’s website. It works perfectly with Sisulizer, if you have installed 32-bit Access database engine.
However with 64-bit version of MS Office is also installed 64-bit engine not supported by Sisulizer. For this reason you can’t localize new Access format, that is .accdb, while old, that is .mdb still works because Windows itself contains both 32-bit and 64-bit engines. The problem is that once you have installed 64-bit version of MS Office you CANNOT install 32-bit engine. The installation does not even start. Unfortunately, we can’t help you with solving this issue, because this is Microsoft issue. Optionally, you can switch back to 32-bit MS Office.
Access databases before Microsoft Access 2007 don’t require installation of dedicated driver.
Janusz

 

How can I simoultanously build Windows 32-bit, 64-bit and OSX files?

Sisulizer 3 comes out with capacities to build 32-bit, 64-bit Windows and OSX output files for this same source in Sisulizer project. Currently this is possible only for latest Delphi/FireMonkey version, because both WIN32, WIN64 and OSX binaries created by Delphi compiler contains the same identical resources. For this reason you do not need to add separated sources for each platform. Just add Windows 32-bit file as source to Sisulizer project.

However, if you want to build WIN64 and/or OSX version of localized file, you need to add appropriated exe as platform files in your source properties. For example if you want to build localized 32 and 64 bit versions of sample.exe for 32-bit version of sample.exe added as source to Sisulizer project, you need add 64-bit version of sample.exe file as platform file. You can do it in the following way:

  • Go to “Project”, then to “Edit Source” sub-menu and select your source.
  • Next, in opened source properties dialog go to “Platform files” tab and add appropriated versions of your source file. Here is example screenshot:

When scanning and building, Sisulizer treats platform files just like the main file. So if you have WIN32 as main file and WIN64 and OSX32 as platform files, Sisulizer scans and build three files on each run. Solution implemented to Sisulizer allows on adding next platforms in future, when programming environments developers will release it.

If you want to check, how it works in “real live”, open Sisulizer, go to “File” menu and select “Open sample” menu item. next, open FireMonkey/Converter folder and open SLP in this folder.

Janusz Grzybek

 

How to prevent the lost of translations in source code localization, after including new items…

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