Author: Markus

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.

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.

A Merry Christmas to all our visitors!

We will be back with more articles around Sisulizer on the 28th.

Create Additional Income Streams for your Software

Software developers and publishers across the globe are being hurt by today’s economic downturn. One way to cope with today’s challenging economy is to open new markets for your existing applications. Translation can extend the reach of your software to other countries. By translating, say, the English version of your software and localizing it into other major languages, you can do a better job of selling it to the estimated 60 percent of Internet users who don’t speak English fluently.

Automated Localization Software

Sisulizer 2008 from Sisulizer Ltd makes it easy to manage the translation and localization of your software into multiple languages. It’s a Windows application that reduces the work required by software developers to localize their programs. Sisulizer manages the translation and localization process, while protecting source code from prying eyes. Sisulizer quickly pays for itself by opening new markets and new revenue streams, allowing developers’ end-users around the globe to use software in the language of their choice. Sisulizer is used by software development companies large and small. Customers include GE Healthcare, Philips, Qualcomm, Intuit, Sony, Siemens, Renault, General Dynamics, and Symantec.

Protecting Your Source Code

One way to get your application translated would be to send your source code to a professional translator, and ask him or her to separate the executable code from the text, and to translate only the text. There are too many dangers with this approach:

• It is unlikely that many translators would be familiar with C++ Builder, Delphi, Visual Basic, Visual C++, .NET ResX and WPF, HTML Help, ASP, PHP, JSP, XML, WebHelp, Pocket PC, Symbian, Java, and a dozen other popular computer languages that are supported by Sisulizer. It would be too easy for a translator to inadvertently change your source code while localizing the text.

• Given the amount of text that needs to be translated in a typical program, it would be a huge management challenge for the developer to keep track of hundreds of strings, and replace them with their translated text, without introducing source code errors.

• Sharing source code with people outside of your company is risky business, under any circumstances.

Localization with Sisulizer

Sisulizer uses an easy three-step process to localize your software:

• First, use Sisulizer to scan the application and locate all of the text that needs to be translated. Sisulizer works directly with .NET, C++ Builder, Delphi, Visual C++, Visual Basic, Visual Studio, Borland Developer Studio, Java, or Windows binary files, along with XLIFF and .NET assembly. The program works visually with HTML and XML. Sisulizer can also grab text from text files and databases. You determine which Windows resources you want to localize, including icons, menus, dialog boxes, strings, accelerators, versions, and manifest resources. Sisulizer also operates in the mobile world. The software supports .NET Compact Framework, Pocket PC, Symbian, and J2ME.

• Second, translate the text using Sisulizer’s visual editor. Begin the translation work yourself, and mark each phrase as translated properly, auto-translated, translated by best guess, out for review, or complete. Alternatively, you can use Sisulizer’s Exchange Wizard to create and send your translator a single file that contains a self-installing Sisulizer Free Edition, along with your project file. Your translator uses Sisulizer’s built-in WYSIWYG editor for all text in your application. When your translator has completed the translation, they’ll just need to send back a single file to you. Your translator never has access to your source code, ensuring that your valuable source code will never be accidentally changed or intentionally shared with third parties.

• Third, build the localized version. Simply run Sisulizer using the translated file, and build the new version of your application in the new language. There’s no need to manually track where each text snippet belongs. Sisulizer manages the localization project, and automatically builds your new version. In addition, Sisulizer’s Translation Memory feature saves time and money when you translate your next application. Sisulizer remembers all of the words and phrases that it has translated, and you have immediate access to all of these earlier translations in your next project.

Sisulizer comes in five editions that developers and translators can use to manage and control the localization process. Sisulizer 2008 has taken steps to provide translators with an intuitive software program that requires no technical skills to run. The latest version of Sisulizer now supports Windows Presentation Foundation (WPF). This allows each of your translators to see classic Windows WIN32 Forms, Windows Forms, and the new WPF dialogs, without having to wrestle with the .NET runtime. By freeing translators from the complexities of the .NET environment, it makes it easier for them to concentrate on translating the text, and not worrying about the underlying technology of the translation program.

To further improve translators’ productivity, Sisulizer 2008’s new spell-checker has a Word-like checker that inspects and analyzes each word as you type it. In addition to its built-in spell-checker, the program now supports the Hunspell engine, with more than 80 languages. It also works with the Lingsoft engine, with its excellent support for the Scandinavian languages. Sisulizer easily handles all languages, including right-to-left and double-byte languages.

Sisulizer 2008 also supports machine translation using Google™ Translate. This feature allows the automatic translation of text into 34 languages. If your budget is extremely low in these times of economic strain, you can use this feature to perform your translations for free. But be aware that machine translation cannot replace the work of a professional “human” translator.

For More Information

Sisulizer 2008 runs under Windows XP/Vista/2003. Download a free 30-day trial version of Sisulizer from http://www.sisulizer.com/downloads.shtml. For more information, contact Sisulizer Ltd & Co KG, Graf-Salm-Str. 34, 50181 Bedburg, Germany. Internet: http://www.sisulizer.com/

The Bottom Line

Today’s turbulent economy is going to worsen before it gets better. Developers need a marketing strategy that wrings every penny out of each of their applications. Localization is a cost-effective way to create additional income during an economic downturn. Finally, software localization has become so easy with a tool like Sisulizer that there is no technical reason not to create sites in all of the major languages.

— Al Harberg, DP Directory

If you are new to software localization and visit the web sites of software tool vendors, they will tell you that What-You-See-Is-What-You-Get (WYSIWYG) is an extremely important feature. We all know it is important for desktop publishing. WYSIWYG editing eliminates the need to print a flyer again and again to see how changes look. But why is WYSIWYG important to software localization?

A real life story

In a real-life story, just few weeks ago, we decided to install a business application on my computer. The vendor was very happy that it was localized in my native language, German. Because I’m in the software localization business, I was curious about what tool the software company used for localization. To my surprise, the company did not use a tool. They simply put all strings into a database and the translator completed the localization without a WYSIWYG editor. The result made me chuckle—because the company also failed to make a quality check. The translators did as well as they could with the tools they had. However, after their strings were loaded into the application, the strings broke the layout in the user interface. Yes, words in German sentences are longer—and most translators are aware of that. But in this case, the translators could not use their knowledge and experience because they didn’t have the right tools.

With WYSIWYG the translator easily could use the empty space better.

Context? What context?

The translators had to work blind with a list of sentences in a database—without any chance to see screen elements filled with their translations. The translators couldn’t give feedback to the developers that their strings were too long. They could only translate string by string without seeing the context. A WYSIWYG tool could have saved the translators and the software company a lot of time and effort.

The text for the check box is cut and the usage of it is now unclear. At the same time, there is more than enough room on the right side.

A state-of-the-art localization tool can give the translator the chance to see everything in WYSIWYG. With this feature, he/she can also adapt the size of the dialog boxes, buttons, labels, and more to make them fit the user interface perfectly. In this example, the results of localization without the proper tools are buttons with truncated captions. One missing word can make a big difference: for example, “Delete” and “Delete All” are not the same.

Furthermore, the application has even more problems. The English caption “count” can have two meanings in German: “Anzahl” (number of) or “zählen” (counting). If you do not understand the context, you cannot decide which term to use. With a good WYSIWYG display, the translator can easily avoid the wrong word. When I first saw the dialog box, I thought I had to wait until some counting had completed. When the counter did not change; I recognized my mistake and had a good laugh.

The correct translation here would be “Anzahl”. In a WYSIWYG environment, a ten-year-old child can sort this out. Without a WYSIWYG environment, even a degreed and experienced translator has a 50/50 chance to fail.

The complete application was full of truncated strings and incorrect translations. After my tests, we decided not to use the business application in future. The software basically failed our tests because of bad localization.

What would you think about the quality of an application you want to build your business processes on if the software looks difficult to use? What would you expect under the covers? You would probably remove the software and forget about it—especially if the vendor did not even made a quality check of the translated software. With a problem like this, software vendors lose many potential customers. The vendors save a little money with cheap localization tools that do not have WYSIWYG features, but lose many customers. My story is true—and, unfortunately, is very common. We frequently see problems in many programs out there. Time to spread the word that there is a solution for software localization called What-You-See-Is-What-You-Get.

— Markus Kreisel

Business colleagues often ask me if localizing software into foreign languages really means more sales and better revenues. If you complete the localization process in the right way, the answer is “absolutely, you can achieve higher profits”. Moreover, would successful software companies like Microsoft have been localizing software for years without a proven business case for the process?

Economies like USA, Germany and Japan are incubators for large sales profits with professional localized software. And, smaller foreign software markets are extremely profitable if you sell the first localized product in your category in those countries. However, if your software does not sell well in your own language, then localizing will not make the situation better. But if you have a product with huge sales in your home market, you can build on your success with localized software. If you see more and more customers from other countries buying your software, even though it is not localized, you should jump on this business opportunity—and localize your software. If you are not sure how to start the localization process, then this article is your starting point.

1. Do I need a software localization tool?

Absolutely. The main reason is that your translator is not a developer. You want to localize the professional way? In most cases, you want to hire a professional translation expert who is a native speaker of the target country to translate your strings. To keep your costs down, you want to provide a single source file with all the strings to be translated, along with an easy-to-use editor. This approach gives you several advantages:

• Most translators dislike learning new formats that different software compilers require. The professional translator will charge you more for the learning curve.
• Professional translation experts prefer to get all strings in one single source. This also keeps your costs down, as the translation professional might charge you more for each document that you send.
• And your translator can work faster and concentrate on his/her job if you provide an easy-to-use, intuitive editor. A good software localization tool offers an effective text editor that is easy to learn.
• Your translators will give you a better word price if they can re-use what they have already translated in other projects. As a developer, you have a large collection of useful functions you can reuse frequently. Professional translators have something similar with their translation memory. Your software localization tool should support the access to standard translation memory, like Trados.

You, as a developer or owner of a software company, get higher localization quality with an effective tool because of the WYSIWYG (What-You-See-Is-What-You-Get) display. An effective software localization tool provides this feature for all visible elements. The translator sees the context of the string while translating—this means you spend less time answering the translator’s questions. If a string is too long for a dialog box, he/she can recognize that and implement a shorter translation. Or, the translation professional can even change the size of the screen element to make the text fit.

And what happens if you choose not to use a localization tool? The major pitfall with software localization completed without a tool appears when you are ready to update or upgrade your software. Each time you issue a new version of your software; the development process creates new strings or changes many existing strings. A professional translation tool quickly scans your application for these changes. And, your translator does not have to start from scratch—he/she charges you only for the changed or new strings. So the translation tool pays for itself and saves you time and money.

2. Which software localization tool is the right one for me?

You can find many, many software localization helpers on the internet. But the range of really effective, professional tools is very small. So what separates the wheat from the chaff? The following information can help you choose the right tool for your software.

Source code localization is an outdated approach to software localization. The newest generation of localization tools supports binary localization. You should not expect less in the tool that you choose. Source code localization works on your source code, which you should not share with a third party. Personally, I would never allow an application to change my holy source code and perhaps make a mess of it. Binary localization solves this problem smoothly. The process works only on the resources of your compiled Windows application. You don’t need to recompile your application to add a new language. Using resources reflects Microsoft’s recommended method for localizing software. If your development platform supports this process, you should be using it.

A software localization tool must be as easy to use as possible. The reason is simple. Your translator has to learn the tool in minutes, not days. Some vendors offer training. However, few software developers, owners, and translators have the time to invest in this type of training.

The software localization tool should come with a free translator license for all of your translators. And this license should run without the need for the translator to install the run-time version of the software. Provide the right translation tools so that your translator can be up and running within minutes.

Far Eastern languages need special features in an effective localization tool. You might not plan to localize for these languages for now. Japan and China are very good future markets, especially if you are the first mover in your product category. You might possibly bundle your software with computers or other software; and chances are high that these products might sell in countries like China. However, Chinese and Japanese markets require a lot of prior planning. You should not switch the localization tool under time pressure to climb the highest translation mountain—double-byte languages. Choose a software localization tool that is already prepared for these challenging languages. The right tool ensures that, if your boss drops into your office and ask you to prepare for Chinese localization, then you are well prepared for the challenge. Choose the tool wisely and check to ensure that the vendor has experience with exotic character sets. Check if the vendor has developers in Japan or China. Developers with these skills have practical day-to-day experience with double-byte character sets and do not read about them from a book. Do you expect that a developer not used to entering text with an IME would know about that? Your Japanese or Chinese translator needs an IME because keyboards cannot provide the hundreds or thousands of characters used in their language.

Another issue is the support for multiple platforms. The tool that you choose should support as many platforms as possible. This gives you the chance to import strings from different sources into one localization project. This way you can reuse translations made for languages such as Delphi in your XML files. The tool should support database localization in case you have tables to translate. And the right tool can give you the best support when you must switch platforms, such as going from classic Visual Basic to Visual Basic .Net. A state-of-the-art software localization tool has full WYSIWYG support. This means that you see all dialog boxes, menus, and components as they are shown at run-time in your program while translating. Your translators see the context of the text they are reading. If you localize from and to certain languages, such as English to German, you soon recognize that German strings are longer than the English originals. A good WYSIWYG display shows these occurrences so that you can enlarge the labels. Moreover, if you have created your own visual components, you should be able to edit them inside the parent forms. And the GUI of your localization tool should support UNICODE to allow editing of all the possible character sets without restarting the software. Moreover, the localization tool should support UNICODE for filenames and everything the tool uses for input. All these things should be supported for foreign character sets.

3. What do I do after choosing the right tool?

If you have already separated the code from the strings using resource files in your project, you only need to scan your .EXE, .OCX, or .DLL with your localization tool. The tool can collect all strings and display them in an editor for translation. You can then create a translation package and send it to your translators. After they send back the results of their work, you can build the localized version. The process is really this easy. A good localization tool takes care of character sets and all of the nasty details. But there are two pitfalls you have to take care of.

The first problem occurs if you have not maintained resource files. But you are in luck. Probably your development system took care of that for you. All strings for menus and dialog boxes are stored in resource files by default. If you use Delphi, C++ or the .NET platform, you only take care of the strings you hard-coded in your source files. If you think that you might have been better off separating those strings into resource files from the beginning, you are right. But it’s not too late to do it. Moving all strings into string resources is not a hard job. Instead of writing the following code example:

“ShowMessage(“Hello World”);”

In C++ Builder with VCL, you can write this code:

“ShowMessage(LoadStr(SMyString));”

You can then create a string resource table entry named SMyString with the content “Hello World”.

For combined messages, you should use placeholders like %s in your strings to avoid problems with different grammar. While in English, you write “Insert disk in drive a:”, in German, the text is “Legen Sie eine Diskette in Laufwerk a: ein”. If you use a placeholder, such as “Insert disk in drive %s”, your translator can easily follow the German grammar in writing “Legen Sie eine Diskette in Laufwerk %s ein”. You just need to replace the placeholders with the current value after reading it from the resource.

The second problem is related to how common development systems for Windows organize the GUI. Except the new .NET platform and for UNICODE compiled C++, the development systems use ANSI GUI API calls. While you can easily create UNICODE strings (16-bit characters) inside your application, everything displayed in forms and windows is converted into ANSI (8-bit chars). This means that you must test a program localized into Japanese with a system configured to start non-UNICODE applications with a Japanese character set. You cannot change that character set inside your application. The decision is made before any lines of code are executed. You can read a description of how to set the right code page at the following link:

Working with Code Pages in Windows

Do not panic if your localized application shows only garbled characters. Your test system is not configured correctly. Your customers will automatically see everything correctly because their Windows system starts non-UNICODE applications with the correct character set. Everyone who is technically interested might search the web for the term LCID. Other people just trust their localization tool which does it correctly for you. A very elegant solution to solve this problem is to use third-party controls to make your GUI UNICODE-enabled. Borland VCL developers can find very good offers.

Have I mentioned that the software localization tool of your choice should be UNICODE-enabled in its own GUI? Sure, but it is important enough to repeat that.

4. How to find the right translator

If you choose the right tool, you have many options in choosing your translator. Whether you work for a large enterprise with other divisions that complete the translation internally or if you hire an external translator, the steps are always the same. You send a single file including everything your translator needs. He/she installs the files and can start right away. If you choose wisely, your translator does not have to download huge run-time tools like .NET—and he/she avoids the usual hassles if the tools do not easily install. While with a good localization tool, you can develop and localize the product at the same time, most companies start localization at the end of the project when schedules are tight. Every delay in this phase is critical—costing time and money.

Whoever does the translation—there is one rule you should never break. Always use a native speaker for the job. These translators might be more expensive, but they are worth every cent. If you fear the cost, go back to the beginning of this article. The starting point is that, if your product sells well in your home market, the price for the software localization tool and the translator is well worth the investment—and does not decrease your profits. If the cost is beyond what you are currently making, you should rethink whether the localization adventure is a good investment at this time. If the cost does not hurt your profits, then you should not compromise. Don’t send the message to potential customers in your new markets that they are second-class by presenting a product that shows odd, quirky translations. Choose an experienced translator or translation company with knowledge of software localization. The result will be quality sales and new revenue streams.

Software Localization – you can do it – but do it right!

Software localization for all major Windows development systems like products from Microsoft and Borland is an easy task if you follow some simple rules. I would say that the majority of developers can localize their product without a learning curve if they use the right tool. All trustworthy, reliable vendors of software localization tools give you a free test ride. Take advantage of these offers. Beyond the facts mentioned in this article, you must choose which tool you personally like most. Do not forget to look at the costs of the tool. Check any extra costs, like updates and support.

A last hint: a good vendor will support you and your problems 100% even while you are in your evaluation phase. Use this opportunity to check their service before you purchase their product!

— Markus Kreisel