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
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
Squares instead of foreign language characters on Windows 8
Whenever you encounter squares in Windows 8 software dialogs, file names, menus instead of e.g. Japanese characters like in 火.txt, you do not have the corresponding language pack installed.
The solution is fortunately easy.
Make sure you are logged in with administrator rights.
First open the Windows control panel. If you don’t know how to find it, take a look here.
Next, click on Languages. You should see something like this:
Click Add Language. And select the desired language. Here we go for Chinese (Simplified).
Chinese (Simplefied) has regional settings as well. We pick one.
Now we are back, and see our changed language preferences. We can see our changes in the list, but the new language pack is not installed yet.
So we double click it, or click on Options, to open the Control Panel – Language Options dialog again. Here we chose to Download and install language pack
Here is the installation process. Depending on the selected language, and the already installed languages the packs are quite big, eg. 80 MB or 147 MB.
You may need to restart your Windows.
Now you should have the fonts installed, and should not see any squares.
Hope this helps… Just let me know. Currently it looks that the installation of additional language packs do not work under all circumstances. I have to dig deeper into it, and will come back with another article, soon.
For older Windows versions like Windows 7 or XP please check Janusz’ article here.
Renate
What the heck is a Windows language pack?
A language pack consists of different informations you need to work within a language.
The display language of Windows in example contains resources with all text elements of Windows dialogs, menus, output, and error messages, and tool tips.
Another important thing you need is the keyboard layout for the desired language. Depending of a language the keys on a keyboard have different characters printed on. Some languages have in example umlaut characters, like ä,ö,ü in German, Turkish, and Finish. Or accents, like in é, à, î, and ô (and more) in French, and their is a whole bench of other characters in other Northern Europe languages. Naturally this language feature is not limited to European languages.
But even if the characters which two languages or regions are using are identical, they may be used in a different order. Especially numbers, brackets, punctuations, and currency symbols may be on different keys.
Don’t trust my word. Give it a try. Visit an internet café or a PC in a hotel lobby, on your next travel into another country. Typing such simple thing as an email may be very challenging. 
A Windows language pack also includes sets of regional settings for Clock, Currency, number formats, and more.
Depending on the language, it may also contain fonts, or special character entry tools, like Microsoft IME for Japanese or Microsoft Pinyin SimpleFast for Chinese.
More things to read
- How to install a language pack in Windows 8?
Hope this helps. Just let me know, and leave a comment.
Renate
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
Importing TMX file exported by Sisulizer into SDL Trados
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
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.
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
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.
Hint
If you aren’t familiar with validation features I recommend to read the following articles on our blog:
Janusz Grzybek