Three simple steps to localize

C#, VB.NET, Delphi, C/C++, Visual Basic, Java, XML, Databases, HTML, HTMLHelp, ...

[an error occurred while processing this directive]

Preparing your Delphi applications for localization

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

Below is a sample form that needs preparing 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 another language will be longer even much longer than the original value. This will make label and edit box 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.

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. Fortunately this process is very easy in Delphi.

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

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);
						resourcestring
						SClickButton = 'Click the above button to process data';
						begin
						Label2.Caption := SClickButton;
						end;

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 it is strongly 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.

Packages

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

Samples

The sample projects, both original and prepared for localization one, can be downloaded here.

[an error occurred while processing this directive]

[an error occurred while processing this directive]