• You do not need to give third-parties like translators access to your source code
• Your source code will not be changed itself
• Less files need to be exchanged with your translators

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.

Don’t use hard coded strings like

procedure TForm1.FormCreate(Sender: TObject);

begin

  Label2.Caption := 'Click the above button to process data'; 

end;

Use Delphi resourcestring blocks like

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 if you have hard coded strings in 100k+ lines of Delphi code

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.

Resourcing with CodeExplorer

CodeExplorer provides a whole set of ways to convert your hard coded strings to resources.

• Converting a hard coded string at the cursor.
• Converting all hard coded strings of an entire file, or even multiple files with sophisticated wizards
• Converting hard coded strings by using the command line tool

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.

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.

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.

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.

Typical display of a dialog shown with the wrong system codepage.

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, DBCS 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.

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

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

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

The hard job

Does your software have a large online Help file? Guess what is the hard part? Translating the initial language version can be expensive; however, this part of the process is not difficult. The difficult part comes when you improve your software and online Help. Finding the differences between the original Help file and the updated Help can be hard, especially as you want to keep your translation costs low and the translation process efficient.

No tools

Why is that so? When we began localizing software from English to German, back in 1995, no tools existed for online Help localization. Computer-aided translation tools focused on documents for printed manuals; software localization tools ignored online Help. And no online Help authoring tool had real localization support.

Localizing with HAT

You can use the same process we did: we translated online Help in the same online Help authoring tool that is used to create the software’s original Help by copying the original project. We did that easily because we used a tool we know ell, ForeHelp. But with every new version, we had difficulties in determing what needed changing. Fortunately, the Help authoring tool was extended with a functionality that listed the changed and new topics. Unfortunately, we found that determing what changed in a Help topic was still very tedious work.

Localizing with HTML Editor

Later on, with the introduction of HTML-based online Help, html editors, like Dreamweaver or FrontPage, became very popular for creating the translated versions. But, even with these tools, determing changes is difficult. This is because changing the layout of an html Help page usually changes the file date too. Therefore, you might that the page needs updating, when it really doesn’t. You might have to read an entire page, sentence by sentence, to determine this. Even a file diff tool does not help much because it usually does not see the difference between html tags and real content.

HATs with localization support

A few years ago, the first online Help authoring tools offered localization support. Often, this kind of feature exports xml file(s). Surprisingly these tools are either topic based or process such small chunks of text that it is hard to determine the context. The context is usually in a separate file. None of these Help authoring tools (HATs) offer built-in translation memory support.

Localization Tools with HTML Help support

The newest generation of localization tools like Sisulizer, finally integrates online help localization in a software localization process. Whenever you implement changes in the software, and/or html help, just rescan, and your translator sees exactly the strings that must be translated. And, because the text is segmented in linguistic sentences, instead of splitting at html tags, the context is always clear. At long last, you have access to a tool that allows all parts of your application to share the same translation memory.

You may want to give this tool a try. Click the following link to get a 30-day full evaluation version: Sisulizer Localization Tool Evaluation. During the Setup process, please choose Sisulizer Enterprise.

— Renate Reinartz

The reason is this: Software developers are all brilliant in their job! And there is nothing on earth they cannot code in a few hours, especially if the code concerns exporting and importing strings. Don’t take me wrong: I have falling into this coding trap many times.

A developer may think that having all strings in one format can do the job. However, the context for the strings can be lost in one file format. He/she may produce a text file, Microsoft Office® document, database, or xml file(s). If the programmer plans in advance, he/she might even export only changed or new strings; or, even better, add this kind of information to the translatable text. But have ever considered working with translation memory. Usually, money is not the issue: even successful software companies resist spending money on a localization tool.

The funny thing is that software developers love to automate their work and hate to code the same thing twice. That is exactly the point where you can get them.

Life is like that: if you haven’t done it, you can hardly imagine doing it. To be honest, if you never have localized software on your own, especially for more than one release, you hardly know anything about the complexity of the process.

No translator enjoys translating the same strings again and again. And translating text out of context is just guessing. trust me: you should not hire a professional software translator for that kind of work.

Markus article A beginner’s guide to Windows software localization provides more detailed information about these issues.

— Renate Reinartz