Pour les développeurs VCL (Delphi et C ++ Builder) nos développeurs offrent un fichier PDF très intéressant avec indeep informations sur le processus de localisation. Veuillez cliquer ici pour télécharger.
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.
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.
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.
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 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.
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.
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.
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); 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;
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.
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; begin if IsActiveLocaleAsian then Result := 9 else Result := 8; end;
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.
|DelphiOriginal.zip||Original Delphi project|
|DelphiPrepared.zip||Prepared Delphi project|
|CBuilderOriginal.zip||Original C++Builder project|
|CBuilderPrepared.zip||Prepared C++Builder project|