How To...

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

Leave a Reply