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:

add-a-language-cp-win-8

Click Add Language. And select the desired language. Here we go for Chinese (Simplified).

languages-add-language-cp-win-8

Chinese (Simplefied) has regional settings as well. We pick one.

language-add-languages-regional-variants-chinese-cp-win8

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.

change-your-language-preference-cp-win8

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

download-and-install-language-pack-win8-control-panel

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.

download-and-install-updates-language-packs downloading-chinese-simplified-language  the-language-updates-are-being-installed installation-complete

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

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

How to indicate in project which items are imported by context and by value?

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

 

How to lock a form in my localization project?

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:

Janusz

 

 

New API for Microsoft’s bing Translator

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.

ms_app_registration

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.

ms_translator_valid_key

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.

ms_account_information

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

Japanese characters are incorrectly displayed in Sisulizer. How I can solve it?

Windows 7

Sisulizer is fully compatible with Unicode and can display correctly all East-Asian (Japanese, Chinese, etc.) and RTL (Right to Left, e.g. Arabic and Hebrew) languages, but for displaying those characters, Sisulizer use fonts installed in operating system. Font issue could occur on all Windows versions, even on Windows 7. Generally, Windows 7 has very good Unicode support, but unfortunately not all Unicode fonts contain all Unicode characters. This is not Mojibake issue described on this our site. Mojibake issue is related to general implementation of code pages on older Windows versions (all Windows versions before Vista and Windows 7), and even if your localized Japanese application displays Mojibake characters on your Windows with installed East-Asian language support, Japanese characters should be correctly displayed in Sisulizer. However, if on your Windows 7 (Windows XP behavior is described below) you’ll find small squares or thick and short vertical lines in Sisulizer sheet instead Japanese characters, it certainly indicate font Unicode issue.

You can fix this issue in very easy way – without advanced changes in OS, or installation new fonts – directly in Sisulizer. Select language column where issue occur (e.g. Japanese), next go to “Column” menu and select “Language properties” menu item. In opened dialog window go to “Font” tab, uncheck “Use the default font” checkbox and select other font in dropdown menu.

I don’t know specific settings of your system, but if standard Unicode font such as Tahoma doesn’t display correctly characters, try Arial. This font usually works. Below is screenshot from this same sample Sisulizer Project, but with changed font.

Windows XP

By default, with Windows XP is not installed support for East-Asian language, and for this reason all Japanese or Chinese character are incorrectly displayed, whatever you a font selected. For solving it you need install East Asian languages from your Windows XP installation CD. Go to Control Panel on your Windows XP and click “Regional and Language Options”. Next go to “Languages” tab and check “Install files for East Asian languages” and optionally “Install files for complex script and right-to-left languages (including Thai)” in “Supplemental language support” section. If you didn’t inserted Windows XP installation CD, Windows asks you about this. For applying changes, you need restart OS.

If this changes in your Windows XP, don’t solve font issue, try trick from part for Windows 7 (changing displaying Font in Sisulizer).

For Windows 8 please cross-check our corresponding article here.

Janusz Grzybek

 

Build 330 – Improved Gettext support

Our developers continuously improve support of Gettext localization.  Gettext is free software and an OS independent platform. It is definitely a very popular localization solution chosen by developers. With Sisulizer build 330 our customers get following new or improved features related to Gettext support:

Support for partially translated source PO files

In build 330 added support for partially translated PO/POT files. For clarifying this improvement I need basically to explain how Gettext works. Gettext localization based on following item pair in PO/POT files:

  • msgid – this item contains original string
  • mgstr – this item contains translation

Before build 330, Sisulizer used “msgid” items as originals, when “mgstr” are empty. When “mgstr” item contains a translation, Sisulizer used this item as original. Since build 330 Sisulizer always uses “msgid” items as originals. Previous scan method worked perfectly when localization process was fully made in Sisulizer, because Sisulizer saves translations to SLP files, not to source PO or POT file. However, it caused troubles when source files were previously translated in other tools e.g. popular POEdit. Since build 330, you can also add as source (to Sisulizer project) fully or partially translated PO/POT files. It helps switching to Sisulizer, or translating PO/POT files generated by other Gettext tools used by your developers. After adding such file as source you can also re-use existing translations from this source file, by using Import feature. Because Sisulizer has implemented advanced and flexible import features, so you can do it in three different ways:

  • Use “Project” menu -> “Import Translations From Localized files”. In this case output filename should be matched with source filename. Here is article about this import method and here is article about output file settings.
  • Use “Project” menu -> “Import…” and select “PO file pair” in Select File Format step of Import Wizard. Here is article about this import method.
  • Use “Project” menu -> “Import…” and select “PO file” in Select File Format step of Import Wizard. It uses standard Sisulizer import method. You can find details also in this article.

Management of contents saved to output PO files

Sisulizer can build as output files both compiled MO files (used as localization resource files in localized application) and translated PO files (the same as source, but with included translations made in Sisulizer). Before build 330 Sisulizer always saved original items to translations (mgstr) items in output files. However, when this file was opened in third party tools e.g. in POEdit, it shows file is 100% translated, because output PO file didn’t contain empty translation items. Since build 330 you can decide what Sisulizer should to do with not translated items during build output PO file.  Now you can select following options

  • “All” – Sisulizer works like before build 330, that is Sisulizer saves (in output PO file) original to translation item (mgstr) if translation doesn’t exist.
  • “Translated” – Sisulizer keeps empty mgstr items in output PO file,  if translations don’t exist.
  • “Different” – Sisulizer saves only differences, that is when translation is identical with original, appropriated translation item in output PO file is empty.

You can change this setting in “Options” tab of source properties dialog. You can open source properties dialog via context menu of source node in project Tree or via “Project” menu -> “Edit source” -> select your source.

This feature could useful when your developer/employer use third party Gettext tools and it allows him check translation progress, forward it to other translators who use third party localization tools, use in SVN solutions, etc.

Other improvements

In build  330 improved also support of plural forms and support items with identical original values and different comments.

All those changes significantly improved compatibility with third party tools e.g. POEdit and now Gettext support in Sisulizer is actually “tool independent”.

Best regards,
Janusz Grzybek