Software localization process, and tipps around localization
The next Delphi Tage conference will be held 20th to 22th September at the Print Media Akedemie in Heidelberg. It is a good tradition that the Sisulizer Team will join to present the newest development in Software Localization. You’ll find more info in German language on the website http://www.delphi-tage.de/
We hope to meet you all in beautiful Heidelberg
Please consider to vote for Sisulizer at delphitools.info/2012/02/15/what-do-you-use-for-string-localization-in-delphi/ as your favorite localization tool.
Currently Sisulizer is doing well. GNU gettext/dxgettext is still leading.
If you do not already know: Sisulizer does support localization of PO/POT files, too. And I know that quite a few translators are using Sisulizer to translate, even when the developer just use GNU gettext. Why? Translators love the comfortable and intuitive user interface, and all the great filters, search/replace features, integrated translation memory, and the validation functionality. Especially the validation features help translators and developers to create great, and save localized versions of your software. Please read more in the following articles about localizing PO/POT files created by GNU gettext routines with Sisulizer:
Delphi experts Marco Cantù and Cary Jensen present their annual Delphi Developer Days tour. This six-city tour visits four cities in Europe and the UK, and two cities in the US.
Delphi Developer Days are two-day live Delphi events that provide you with the latest information on Delphi as well as practical techniques to help you improve your Delphi development skills. Each event includes both joint sessions, presented by Marco and Cary together, as well as simultaneous tracks, where Cary and Marco break out into separate rooms to present individual sessions. There is also an Embarcadero Technologies Keynote, and an additional guest speaker presentation in each city from Delphi experts including Bob Swart, Ray Konopka, Stephen Ball, Jim McKeeth, Daniele Teti, and Bruno Fierens. All sessions are in English.
A wide variety of topics are covered. Some topics, such as FireMonkey and LiveBindings, apply to the latest version of Delphi, but there are also many classic topics that apply across versions of Delphi, going back to Delphi 7 and earlier. Detailed descriptions and an agenda can be found at: http://www.DelphiDeveloperDays.com/descriptions.html
All Attendees Receive:
Space is limited to the first 35 people in each city. There are discounts for early registration, previous attendees, and groups of 3 or more developers from the same company; see online for details. Price and registration information is available at: http://www.DelphiDeveloperDays.com.
We want to thank all customers and prospects visiting our booth last weekend in Cologne at Delphi Tage 2011. To all that haven’t been there: you missed a real “hot” community event in the Früh Brauhaus. Everybody joining it knows what I’m speaking about. The sessions in Cologne’s MediaPark also had been hot, but for some other reason. David I announced Delphi XE2 the first time in Germany. He told that XE2 is the biggest step in Delphi’s history since version 1. Especially the 64bit version of Delphi made a lot of dreams come true. And with the first release of FireMonkey we saw the future of cross-platform development in action.
(David I announcing Delphi XE2)
At the Sisulizer booth you could see the brand new Sisulizer Version 3 with XE2 support (incl. Delphi 64bit, FireMonkey 32bit, 64bit, and OSX) in action. Also small dreams came true: We could show the long missing translation memory editor. Thanks to R&D who made some extra hours to make it possible.
Hope we will meet you all again next year.
We want to thank all customers and prospects visiting our booth last weekend in Berlin at Delphi Tage 2010. To all that haven’t been there: you missed the “Borsig Turm” an extreme beautiful location, highly motivated speakers with excellent sessions and a huge crowd of happy Delphi users. Hope we will meet you all again next year.
Software localization tools like our Sisulizer localizes binaries, like executables (.exe) or library files (.dll). That has many advantages like
to name a few.
This works fine when your strings are stored in string tables of Windows resources. Luckily this is very easy in Delphi. Just use a resourcestring block instead of hard-coding the string.
procedure TForm1.FormCreate(Sender: TObject);
begin
Label2.Caption := 'Click the above button to process data';
end;
procedure TForm1.FormCreate(Sender: TObject);
resourcestring
SClickButton = 'Click the above button to process data';
begin
Label2.Caption := SClickButton;
end;
Use unique and descriptive names as resource strings. That gives you and your translator a much better idea of the context of the string, and a way better chance for a fast and good translation.
What do you want to hear? Bad luck, internationalization tools are very expensive, chances a good that you have a lot of stupid work in front of you? I fear I have given too much people answers more of less like these. Shame on me.
First, you are not alone. And even better there is a great tool around that will help you through that job. And all this at a very competitive price.
CodeExplorer provides a whole set of ways to convert your hard coded strings to resources.
And it comes with various options for scanning, and converting, I.e. it helps you to identify strings that do not need to be localized at all, or do need special attention like SQL statements. It also provides warning mechanism for units.
CodeExplorer is made by our Dutch Embarcadero CodeGear Technology Partner fellow Modelmaker Tools. Prices start at EUR 99. Read more about resource string conversion with CodeExplorer on their web site.
Visual Basic 6 with UNICODE GUI possible with Hexagora controls and classes
Out of the box Visual Basic 6 comes without UNICODE support for its controls. Strings in VB6 are already in UNICODE but when it comes to display everything is converted back to ANSI.
The Italian Software Vendor Hexagora solves this problem with a set of UNICODE controls replacing the ANSI originals. Sisulizer supports projects using these controls right out of the box. Hexagoras controls together with Sisulizer make the dream of full UNICODE enabled applications with Visual Basic 6 come true. Please visit Hexagora.com for more information.
There are two types of byte-ordering: big- and little-endian. Intel processors use the little-endian order; this means the more significant digits in a number are on the right side. If we write a number like 4711, the most significant digit is 4 (= 4.000) and is on the left side. A BOM (Byte Order Marker) in text files indicates to the application the direction to read the numbers.
BOM is an acronym for byte-order-mark. BOM describes the order in which a sequence of bytes is stored in computer memory. The acronym is stored at the beginning of a text file to tell the reading application the order in which the bytes are organized, as big-endian or little-endian. BOM also indicates if a character is stored in 16- or 32-bit UNICODE. And, the BOM is also used to mark UFT-7 and UTF-8 files. These files are 8-bit files that use a code to store 16-bit characters. Therefore, the name BOM for these kinds of files is a bit misleading. While it is convenient to know the file format, a BOM can be used to mark the format inside the file.
If a file is read by an application not aware of BOMs, the system shows the characters used to sign the file as data. In this case, you can use Kaboom to read a file with a BOM and convert the file into a file without a BOM.
Code pages are necessary because ANSI files only have 8 bits to display a character (char). This means there are only 256 possible characters–not nearly enough for all languages of the world.
The American charset needs only 128 different chars = 7-bit. Because 7-bit was a bit inefficient for computers, this led to the need for another bit; thus, currently, another 128 possibilities are available to display chars.
On MS-DOS systems, some of these bits have been used for drawing boxes and lines. With Windows, these boxes and lines have been removed from the charsets and more foreign chars have been added. For the most Western languages like English, French, German, and others, these additional chars work efficiently. For example, the German charset needs only seven extra chars to the US charset – leaving enough space for special chars from Spain, Norway, and so forth.
However, for certain charsets, such as Cyrillic charsets, the space was not big enough. Codepages fill that gap. A code page in Windows is nothing more than information, so that the upper 128 chars use some other characters. For example, instead of the German umlaut Ü, a Cyrillic Ш appears. both of these items have the ANSI value 205. Thus, if the Windows codepage 1252 is selected, a Ü appears, while with the Russian Windows codepage 1251 Ш (sha) is displayed.
If code pages are used, the system cannot possibly show Ü and Ш on the same display. This is only possible if UNICODE is used. For example, this page uses UNICODE (UTF-8) to display both chars.
While this solves the problem for most of the languages, the code page technique does not help languages with more than 128 special characters, such as Japanese, Korean and Chinese. For these languages, MBCS is available. While the lower 128 characters are still the same as in US code pages, the upper 128 are specially encoded. In this system, one character of the upper 128 chars starts a multi-byte sequence. This means that one character is stored in one or many chars. For example, in Japanese shift-jis, one character can use up to five bytes.
Thus, if a person writes a text file on her or his computer and does not use UNICODE to save it, the current code page is used. If this file is given to someone with some other current codepage, the file is not displayed correctly. So, if you are in Western Europe or the USA, and you get a text file from someone in Greece, Turkey, China, or Japan, the chances are high that the file is useless to you. Kaboom can fix these problems. Simply convert the file into UNICODE and print, edit, or use the file in any way–without losing information. If you edit the file and you want to return it with your changes, simply convert the file back into the code page that the receiver needs. Kaboom makes the entire process easy and quick.
