Selected Customers

Buy Now

Offers are for commercial and industrial customers only.
All prices are net.

Complete Price Sheet.

Not sure which edition is the right one? Visit our Edition Comparison

Update to Version 4

Sisulizer version 4 is a paid update recommended for all Sisulizer customers.

Update to Sisulizer 4

Still using Sisulizer 3 or Sisulizer 1.x/2008/2010?

Time to update to version 4 now and profit from all new features in version 4.

Software Localization News

Version 4 Build 365 released


The new build comes with many new features. [...]

10 Years Sisulizer


Celebrate and save Big. [...]

Delphi Berlin, Android, Project Merge...


Build 360 [...]

Delphi 10, VS 2015, .NET 4.6


Up-to-date for the future. [...]

Windows 10, Delphi XE8


Ready for the future. [...]

Our customers use Sisulizer...

to reach international customers with software in their language

to localize their in-house software in the international subsidiaries

to build multilingual custom software for their clients' enterprises

as Localization Service Providers because it is the localization tool of their customers

to localize software at Government Agencies

To teach software localization at Universities

for software localization on Electronic Devices

To translate software for Biomedical Hardware

to localize software in the Mining Industry

to create multilingual software for Mechanical Engineering


For VCL developers (Delphi and C++Builder) our developers offer a very interesting PDF file with indeep information about the localization process. Please click here to download.

Preparing your Delphi and C++Builder applications for localization

This document describes the basic steps that you should perform before starting localizing your Delphi or C++Builder applications.

Below is a sample form that needs preparing for localization.

Sample Delphi dialog for localization

The form contains three cases where we have to change it in order to easy localize the form. Each case is marked with red bounds and with a number.

Another control following TLabel

The Value label is immediately followed by an edit box. This will cause you problems because it is very likely that the translation of the Value to other language will be longer even much longer that the original value. This will make label and edit to overlap each other. The translator can replace the edit control more right to make room for the longer label but this will take some time and will cost. Remember if you localize to 10 different languages most likely every single translator has to do the same modification that will take a lot of time and even more important make your UI to look different on each language.

A better approach is to design the original UI such way the translators need hardly ever relocate controls. In this case we can place the label and edit on different lines - label above the edit. This gives label possibility to expand very much without overlapping the edit control.

This case is marked with #1 on the above picture.

TLabel's AutoSize property

Turn on the AutoSize property of TLabel. This makes sure that longer translation of the Caption property is not cut when drawn on the form.

This case is marked with #3 on the above picture.

TCheckBox's Width

TCheckBox does not have AutoSize property. You have to manually set the width of all check boxes to the maximum width allowed by its position.

This case is marked with #2 on the above picture.

Properties that are set on run time

Label2.Caption is set to Label2 on design time. On run time this is replaced with "Click the above button to process data" string. So the original string is not used at all. Keeping it will only make your localization project larger and more expensive. A good practice is to set all these Caption property some fixed value such as "dummy". After creating Sisulizer project you can easily exclude all strings having "dummy" value.

This case is marked with #3 on the above picture.

Prepared form

Below is the sample form after it has been prepared for localization.

Sample form for localization

Label and edit are not on the same line any more. Check box width has been set to maximum possible width. Label's auto sizing has been turned on. Unused strings have been replaced with dummy word.

Hard Coded Strings

Most applications have hard coded strings inside the code. You have to remove them and replace them by the resource strings. This is called resourcing. Fortunately it is very easy process in Delphi.

procedure TForm1.FormCreate(Sender: TObject);
 Label2.Caption := 'Click the above button to process data'; 

Add a resourcestring block above the begin block. Give a unique name for the resource string id and set the resource string to match the hard coded string value. The name of the resource string should also be as describable as possible. SClickButton is much better than SStr1. Finally replace the hard coded string with the resource string.

procedure TForm1.FormCreate(Sender: TObject);
 SClickButton = 'Click the above button to process data';
 Label2.Caption := SClickButton;

In C++Builder string resourcing is a bit more complicated. You have to create a resource script file (.rc), add a STRINGTABLE and finally add an item to the table.

Use inherited forms

When you write properly internationalized code you have to change the default behaviors of each form and frame. This is why you better derive an abstract form from TForm and derived all your forms from this form. Do same form frame. This makes it easy to initialize the form in the constructor of the base form.


The default font of Delphi forms is either Tahoma (Delphi 2006 and later) or MS Sans Serif (up to Delphi 7). MS Sans Serif looks a bit old fashion so it is better to use Tahoma. However it is not a good idea to hard code the font name the form. A better choice is to change the font name to MS Shell Dlg 2. It is a generic font that Windows replaces on fly to the most appropriate font. On English Windows XP it is Tahoma. On Simplified Chinese XP it is Simsun. Using MS Shell Dlg 2 always ensures that the font of your application uses the default user interface font of the target operating system.

Another issues is the font size. The default font size on Western Windows is 8. However on Asian Windows it is 9.  Change the font size on run time in the constructor of the base form to match the default font size of the active locale.

function GetDefaultUISize: Integer;
 if IsActiveLocaleAsian then
  Result := 9
  Result := 8;

Make Delphi to create DRC file

Delphi resource file (.drc) is used by Sisulizer to get the complete resource string context of the items.

When Delphi compiler compiles a resourcestring it stores the string is a standard Windows string resource and assigns an id for the string. If you add new resourcestrings into the application or delete existing ones, the compiler will give most resourcestrings new ids. This will most likely cause loss of translations or a existing translations to be replaced with wrong translations. To prevent this give a DRC file name so Sisulizer can use it to link resource string variable names and resource string ids (e.g. SSampleString equals 4567). The resource string variable name will change only if the programmer will intentionally change the resourcestring variable name. DRC files use .drc file extension (e.g. C:\Samples\Project1.drc).

You can localize a Delphi binary file without specifying the DRC file but in that case Sisulizer uses the resource string ids as the context. It is very likely that Delphi compiler will change the resource strings ids next time you compile your project. This will cause lost of translations or switching of translations. This is why the is very much recommended to specify a DRC file. To create a .drc file choose Project | Options | Linker from Delphi and check Detailed in the Map file radio group.

C++Builder does not use DRC files.


VCL itself contains hundreds of message strings. They are added to the resource string resources of your application just like your own resource strings. However if you use runtime packages VCL's resource strings are not linked to your application but are inside the package files (.bpl). If you want to localize them you have two choices. The first option is not to use runtime packages which case the string are linked to the application. The second option is to localize the runtime package files. They are Windows DLLs and are localized in the same way as you application files (.exe).


The sample projects, both original and prepared one, are found here.

File Descrition Original Delphi project Prepared Delphi project Original C++Builder project Prepared C++Builder project