Software localization process, and tipps around localization
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:
Localization with Sisulizer
Sisulizer uses an easy three-step process to localize your software:
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
Localizing windows software has an easy phase and a hard phase. Usually, the user interface elements, such as the menu and dialogs, are easy. In most cases, the amount of translatable text is minimal. This leads many companies to the conclusion: “OK, let’s go for other language versions of our software.” If the process involves one language, you might not even consider using a localization tool.
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
In the past, I have worked with many software companies, and they all have one problem in common: Software developers like home-brewed solutions, independent from the development language they use.
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
Localized software opens new markets and creates more revenue. This concept sounds great; however, what does it mean for you, as a software developer? How can you write software that you can easily localize? And what does localization mean for your day-to-day work?
You might consider the following: What is different in other cultures? The differences include many areas:
Address, character sets, code pages, currency, date, language, list separators, measurements, numbers, paper sizes, phone numbers, sort order, taxes, time
Your first consideration is most likely the language. At the very least, you must think about how to translate all strings in the application user interface. Usually, these are strings for menu entries, dialog boxes, message boxes, the status bar, and error messages.
If you want to send all strings to a translator, you must consistently separate strings from source code. Start this process now. Don’t wait until you are under pressure to meet a deadline. All major development languages for Windows support resource files. You have no excuse! You can easily read strings from resources, such as in classic Visual Basic with LoadResString or LoadStr in a VCL application.
Solution: Store all strings in Windows standard resource files; or, if you develop with Microsoft .Net, use ResX.
Using a different language often means you must consider another character set. Especially if English is your first language, you might think that you need only 128 characters. However, many languages use special characters:
The list is endless. So how would you feel if you couldn’t use characters from your own native alphabet? What if your name is Henry, and you couldn’t write your name, because a Russian software developer would not support the letter H as his/her language does not use that letter? Would you write enry instead? Or would you directly uninstall the application?
Solution: You should use Unicode string handling in your application, whenever possible. This allows you to support all languages and character sets. The Unicode Windows API can help you accomplish this. If your development environment does support ANSI character sets, you should ensure that you do not restrict your input to the first 128 characters.
Unfortunately, few development systems support Unicode in their visual components. This is the case in Visual C++ and .NET languages like C#, Visual Basic .NET. Many others, such as VCL Delphi and classic Visual Basic development systems, do not have built-in Unicode support for the GUI. In these cases, your program will start with the code page the user set for non-Unicode applications in the system. You cannot influence this setting from within your application. If you exchange data with your translator or user, make sure that you know how to handle code pages (read more).
Solution: Use a localization tool that handles all languages and streamlines the data exchange process. Search for a localization tool that supports double-byte and left-to-right code, so that you don’t have problems later.
A number is a number is a number, you might suppose. Wrong. Numbers are formatted. Two things differ between countries: the decimal and the thousand separator. Some countries, like the USA, use a comma to separate thousands and a point as a decimal separator. Therefore, one thousand and two cents are 1,000.02. Other languages, such as German, use a comma and a point in the opposite way, so 1.000,02 displays the same as the previous example. In Switzerland, it is 1’000,02 because the Swiss use the quote sign as the thousand separator.
Solution: Do not store numbers internally, in databases, or in files as formatted strings. Always use a numeric variable type like Long or Float. When you display numbers, format them with the right system setting for the thousand and decimal separators. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space. When you allow user input, make sure that the user knows which format is required.
The currency used in a country affects your application, too. Most currencies have their own currency symbol. Examples are € for Euro in Europe, £ for the British pound, or Italian lira (outdated), ¥ for the Japanese yen or Chinese Yuan, and $ for the dollar used in Australia, Canada, Jamaica, New Zealand, USA, and many others. The currency symbol is defined in the character set used in the country. The symbol is also defined in the regional settings of the Windows control panel.
Because the symbol does not fully specify the currency as shown in the previous examples, you should use the international three-character currency codes derived from ISO 4217, like USD for US dollar, EUR for Euro and so on. If your application handles more than one currency, you should save the currency code, too. You should be careful when you define a currency field, and exchange data with a spreadsheet or database application, like Excel or Access. These applications use the system setting. The monetary difference is quite large in the conversion, such as going from the Japanese Yen (JPY) to the US $ (USD) without currency conversion.
In addition, you should be aware that the currency code might be placed in front of, or behind, the currency value.
Solution: Be sure to check the system settings for the default currency and symbol placement. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space. Be prepared and use the international currency codes. When you allow user input, make sure that the user knows which format is required.
You should never hard-code date values. The date order is different between countries. In the short date format, the USA uses mm/dd/yyyy where m is the month, d is the day, and y is the year. Germany uses dd.mm.yyyy. If you do not take care of this, for example, in Visual Basic, a date string like 12/9/2006 can be interpreted as 9th December or 12th September. If you use medium or long date formats, the day and month names must also be translated. If you use format routines, you should ensure that your development system supports date format in the way that you require. If you need to calculate with dates, store them in a format that is system independent like the ISO 8601 format yyyy-mm-ddThh:mm:ss; you can also convert the dates to a system-independent date number format, such as date serial. This makes dates sorting easy.
Solution: Be sure to store dates internally and in files without using a format. Use the data type for your programming language. If you allow user input, collect the day, month and year in separate fields, and internally build a date data type from these fields. When you display dates, format them with the right system settings. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space. When you allow user input, make sure that the user knows which format is required.
Who needs list separators? You do, trust me. You should consider list separators whenever you handle a string array in multi-column list boxes, memory, or comma separated values files (.csv). .Csv files are only comma separated for languages that use a comma as list separator. However, many languages do use a comma to separate decimals in numbers, that’s why they use a semi-colon (;) to separate string arrays.
Solution: Get the list separator setting of the user system. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space.
You should never hard-code local measurements, like inches and miles. Whenever possible, you should use the metric standards, such as centimeter and kilometer. You can take the same approach for weight: instead of pounds, use kilograms. In addition, the liter is more popular than pint or gallons. The metric system differs in other countries. Moreover, ISO favors the metric system now. Even kilobyte is no longer 1024 bytes in ISO; kilobyte is 1000 bytes, because average people are accustomed to counting metrics. I am personally humbled and embarrassed that I missed that for seven years. On a more serious note, in some European Union (EU) countries, placing ads with non-metric measurements is against the law.
Solution: Don’t hard-code measurements and be prepared to select and convert them.
If you print many documents, you might have wondered how many odd formats your printer driver can handle. Not surprisingly, paper sheets come in many more sizes than just the standard letter and A4 paper.
Solution: If you must format the printout, check the paper format. You can get this information from the Windows API or directly from the printer object or class in your development language. Do not expect only one of these sizes because user-defined types might be used. For example, professional output devices might have sizes like A4+ for borderless A4 output.
Usually, an international phone number has three parts after the leading plus sign: country calling code, area code, and local phone number. A country calling code consists of one to three digits; for example, 1 for USA and Canada, 32 for Belgium, 420 for Czech Republic, and 86 for China. However, many countries, such as Denmark, do not have an area code. The number of area code digits also differs. Sometimes it is a defined number, like three in the USA; however, in Germany, the area code can have three to five digits after the leading zero. German callers do not use the leading zero in international calls from Germany. This contrasts with Italy, where you must dial the leading zero in international calls. The digit number for the local number also differs. In Germany, local numbers can contain three to seven digits, sometimes even eight for numbers to a pbx. In some countries like the USA, phone numbers can also contain an extension at the end, separated by a hash #, which is used only by the pbx of the phone holder. The only consistent aspect of a telephone format is that an international phone number can’t be more than 15 digits.
Solution: To be safe, internally save international phone numbers. Don’t accept input that is only in your local phone format. You should always accept international numbers. For example, don’t limit the area code to three digits or require seven digits for local numbers.
As described in the previous information about character sets, different countries or languages have different lists of characters, or, in other words, different alphabets. Thus, the languages can have additional characters like umlauts or accents, such as in German, French, Danish, Swedish, Norwegian, Finnish, Turkish, and so on. Some languages don’t support some of our favorite characters, like h in Russian, x in Greek, and many more. All these languages sort their characters differently. If you do alphabetical sorts in your application, you should at least think about supporting the sort order in the localized language. Amazingly, even large or popular applications do not support sort order in their localized applications, at least in the past. Supporting different sort orders depends on the importance of your users alphabetizing their data. For example, if you have an application that handles addresses, contact information, or other large amounts of data, your user will definitely miss this feature.
Solution: In .Net, you can check the culture name space for the sort order. In other development systems, you must check your string sorting routines; and, for your own implementation, you may have to collect the data on the web first.
If you design an online contact form, you should never force your user to enter a state, or, even worse, select one of the 50 US states. Not all users live in the USA and are used to providing the state they live in. Some users might live in countries that use other systems, like departments in France or counties in Great Britain.
If you produce an accounting application, keep in mind that tax systems are different in many countries. In the EU, for example, a gross tax is named a value-added tax, but no local sales tax.
If you use time, you must consider the twelve and twenty-four hour models over the world. Twelve-hour systems, as used in the United Kingdom or USA, use am and pm to define whether the time is before or after lunch. You must ensure that time zones are reflected in your application. Which time coding do you need? Local times, like Eastern Standard Time (EST) in New York, Mountain Standard Time (MST) in Colorado, or Pacific Standard Time (PST) in California, USA? Greenwich Mean Time (GMT) is international time and is the basis for the world time clock. GMT is the preferred time if you exchange data in other countries. This time system is based on the local time in the English city Greenwich (GMT+0). All time differences are given in GMT+x or GMT-x. For example, France, Germany, and the Netherlands show GMT+1, PST is GMT-8, EST is GMT-5, and Japan is GMT+9. Differences may also occur in summer and winter. Most countries have summer time savings, although Japan does not. There is another time system, Zulu or UTC. If you need to code time, such as in e-mail or Internet formats, you can check the related RFCs to store time.
Solution: Make sure that you store time internally and always use the same time zone in files. When you display a time format , use the correct system settings. The Windows API provides functions to get the appropriate values. In .Net, check the culture name space. Use GMT time coding, instead of local formats, such as MST and PST. These time formats are not common outside the USA, and a US user probably has no clue as to what CET (Central European Time) means.
Depending on your application, you should check legal issues, cultural differences, standards, and more. These issues may result in logical changes to your source code. For example, accounting rules differ between the USA and Germany and popular payment methods can vary.
Cultural differences can bring you serious trouble or kick your product completely out of the market. I’m sure that you don’t want to offend your users. You should never use certain colors, body parts, or animals. Different cultures see these things differently. There is a rumor about Borland from the very early days. In Germany, Borland used a pig in the Turbo Pascal ads. These ads were very popular: a pig brings luck and can represent speed in Germany. The rumor is that the Borland founder and former CEO, Philippe Kahn, stopped the German ads. As a native Frenchman, he did not want a pig associated with his products.
Don’t be shocked about the number of differences in our many global cultures. Most of the differences are easy to address in your application code. Other software companies have tackled these problems, so you don’t need to reinvent the wheel. Many fine tools are available. In particular, the Windows API provides all of the tools you need. Moreover, if you are already using .NET, you are a top priority with Microsoft, because Microsoft knows they must appeal to the global programmer and provide you with the right tools—at the beginning of your software development process, when it matters most.
When you write flexible code, localization is a snap. However, if you have hard-coded some of the items mentioned in this article, you have much work to do. Take the chance to implement this article’s recommendations in the beginning of your project. Plan a bit more in advance. This will save you time and money.
Most developers who have hard-coded strings are afraid of converting their application to string resources. Yes, if you have a large application with many strings, this process can cost you a few extra days. However, you will save more time and money when you start the localization process. All your hard work will pay off, as you can process every language and every update easily and efficiently. Remember to ensure that your resource files are Unicode-aware, so that you are prepared for the future.
— Renate Reinartz
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.
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:
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.
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.
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.
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 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
Welcome to The Localization Tool, a blog for everything related to software localization.
— Markus Kreisel
