• Home
• Imprint/Impressum
• Localization Glossary
• Who we are

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

Janusz

Thank you for visiting Sisulizer at Delphi Tage 2011

We want to thank all customers and prospects visiting our booth last weekend in Cologne at Delphi Tage 2011. To all that haven’t been there: you missed a real “hot” community event in the Früh Brauhaus. Everybody joining it knows what I’m speaking about. The sessions in Cologne’s MediaPark also had been hot, but for some other reason. David I announced Delphi XE2 the first time in Germany. He told that XE2 is the biggest step in Delphi’s history since version 1. Especially the 64bit version of Delphi made a lot of dreams come true. And with the first release of FireMonkey we saw the future of cross-platform development in action.

(David I announcing Delphi XE2)

At the Sisulizer booth you could see the brand new Sisulizer Version 3 with XE2 support (incl. Delphi 64bit, FireMonkey 32bit, 64bit, and OSX) in action. Also small dreams came true: We could show the long missing translation memory editor. Thanks to R&D who made some extra hours to make it possible.

Hope we will meet you all again next year.

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.

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.

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.

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

Hint

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:

• Filter panel – Other advanced filters
• Filter panel – Text filters
• Filter panel – Common filters for translation sheet
• How to indicate items with highest priority in localization project
• How advanced use of filters increases localization efficiency

Janusz Grzybek

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.

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.

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

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.

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:

And “Project” menu 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

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

Hint

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

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

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 MyApp.Form1.de.resources 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.

Hint

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

Is this possible display in Sisulizer sections from my INI file as separated nodes?

Yes, of course. This feature is by default enabled when you create a new project for INI files. If you don’t see sections as separated nodes in Sisulizer’s Project Tree, it usually means you disabled this option in Project Wizard. Don’t worry, you can enable or disable this setting at any moment. Just use menu “Project” -> “Edit source”, select your INI file, select the “Options” tab and check “Use separate node for each section in the project tree”.

For applying changes you need to re-scan your source. Selecting this option not only gives you a preview of all sections in the Project tree, but also allows to display in translation sheet only items from selected node after selecting it in Project Tree. Below is a screenshot from project for INI file with unchecked “Use separate node for each section in the project tree” option.

After checking this option (and rescanning) my sample project looks like on this screenshot.

Hints

1. If Sisulizer doesn’t add new sections added to your INI source files after re-scan operation, please check if you have checked “Check new items automatically” setting in “Keys” tab of INI source properties. If you haven’t checked it, please check it now.
   
2. Generally we always recommend binary localization (if it is possible) instead of solutions based on external text resources. Background is that binary localization allows translators a visual preview of forms and optionally to adjust controls. Additionally visual preview provides a better understanding of context for translated items. So, if you are a translator, try to convince your developer to change his localization method to binary localization. If you are developer, give your translators a gift and use binary localization.

Janusz Grzybek

Copyright The Localization Tool | Theme by DailyBlogTips