Ausgewählte Kunden

10 Jahre Sisulizer

10 Jahre Sisulizer


Feiern Sie mit uns die Software, die Software-Lokalisierung seit 10 Jahren vereinfacht.

"In den letzten 10 Jahren haben sich alle Softwareentwicklungsplattformen weiter entwickelt. Es gab 15 Delphi, 9 .NET, 5 Windows, eine Reihe Java, Datenbank, Android und andere Plattform-Updates.

Jedes dieser Updates lieferte viele Herausforderungen, bot aber auch neue Möglichkeiten für Entwickler, die ihre Software lokalisieren. Das Ziel von Sisulizer war und ist, Sie als unsere treuen Kunden von den Details der neuen Formate zu verschonen, so dass Sie stets auf den aktuellsten Plattformen sofort mit Ihrer Arbeit beginnen können.

Sie haben uns in den letzten 10 Jahren geholfen, Sisulizer immer weiter zu optimieren. Vielen Dank! Ihre wertvollen Anregungen motivieren und geben uns den Antrieb, weiterhin unseren Vorsprung vor den Mitbewerbern zu bewahren.

Jetzt aber zurück an die Arbeit. Neue Plattform-Versionen stehen an und wollen von Sisulizer unterstützt werden. Zeit zu lokalisieren und neue Märkte zu erreichen."

--- Ihr stolzes Sisulizer Team

Angebot gültig bis 30.6.2016

Die Angebote richten sich an kommerzielle und industrielle Kunden.
Alle Preisangaben sind netto.

Komplette Preisliste.

Suchen Sie die richtige Edition? Besuchen Sie unsere Vergleichstabelle

Updaten Sie auf Version 4

Sisulizer Version 4 ist ein kostenpflichtiges Update für alle Sisulizer Kunden.

Update auf Sisulizer 4

Verwenden Sie noch Sisulizer 3.x, Sisulizer 2008/2010 oder Sisulizer 1.x?

Aktualisieren Sie jetzt auf Version 4 und nutzen Sie alle Neuigkeiten in Version 4.

Softwarelokalisierungs-News

Version 4 Build 360 veröffentlicht

18.4.2016

Der neue Build kommt mit vielen neuen Features. [mehr]

Delphi Berlin, Android, Projekt zusammenfügen...

6.5.2016

Build 360 [...]

Delphi 10, VS 2015, .NET 4.6

14.10.2015

Bereit für die Zukunft [...]

Windows 10, Delphi XE8

28.4.2015

Bereit für die Zukunft. [...]

Willkommen 2015, Willkommen VS 2015

16.1.2015

Verbesserter .NET support und mehr. [...]

Unsere Anwender verwenden Sisulizer...

um internationalen Kunden Software in ihrer Sprache anzubieten

um Inhouse-Softwarelösungen zu übersetzen

um mehrsprachige Anwendungen für Firmenkunden zu erstellen

als Lokalisierungs-Dienstleister, um Kundensoftware zu übersetzen

um Software für Behörden zu lokalisieren

um Schulungssoftware an Universitäten zu übersetzen

um Benutzeroberflächen elektronischer Geräte zu lokalisieren

um Software im Medizinbereich zu übersetzen

um Software für Bergbauunternehmen zu lokalisieren

um mehrsprachige Steuerungssoftware im Maschinenbau zu erstellen

 

Für VCL-Entwickler (Delphi und C++Builder) bieten unsere Entwickler eine sehr interessante PDF-Datei mit Hintergrundinformationen zum Lokalisierungsprozess. Bitte klicken Sie hier zum Starten des Downloads.

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

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.

Fonts

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;

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.

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 one, are found here.

File Descrition
DelphiOriginal.zip Original Delphi project
DelphiPrepared.zip Prepared Delphi project
CBuilderOriginal.zip Original C++Builder project
CBuilderPrepared.zip Prepared C++Builder project