If your company sells a product that contains a software component, here are some tips to consider when you perform software localization to penetrate your international markets:
Command line, to localize or not
Do you have a command line in your application? Do you translate it or leave it in its source language. If you translate it, you may frustrate existing users who have gotten accustomed to use the English commands. If you don’t you may frustrate the new users who see your user interface and documentation localized, but not your command line. So what do you do?
Those who’ve been around during the DOS days, or those or who still use UNIX or Linux commands can attest to the fact that command lines in general are cryptic and will have to be memorized anyway. So the simplest solution is to leave them in the source language and translate their manual (man) pages.
But wait! There is a better solution yet. Create aliases to the English commands in each target language and build them in the application. This way, no matter what language is used, the command will be executed. Your existing users can continue to use the command line in English and your new users can learn the new commands in their native language. A win-win situation for all!
Dialog boxes, to localize or not
Many companies capture and insert dialog boxes in the help and docs. They use them to present a visual point to the reader about how to best operate the software. Some technical documents contain hundreds and even thousands of dialog boxes, significantly increasing the cost of localization. We are often asked to estimate the cost of dialog boxes localization and to identify ways to reduce their costs by perhaps not localizing them. Here is what we suggest.
In the online help, instead of leaving the dialog boxes in the source language, consider removing them when unnecessary. Often the reader of the help has the software running simultaneously and has a visual of what that dialog box will look like live with the software. If it can be eliminated, get rid of it all together in the source files. In the case where the dialog box is needed, you will need to localize it. Read Do’s and Don’ts when Localizing Art to save on the costs of dialog box recapture. It has 8 excellent tips on how to do so!
Lastly, stamp your new source language images with the release date with each release. This way, new dialog box and other art and images that are created after the last localization effort has taken place can be quickly and easily identified and accounted for when a new localization updated is required. All old images will not have to be touched, significantly reducing the cost of recapture and edit.
Is meeting your software localization budget an issue for you? Don’t cut important corners. Contact the experts in software localization and we will show you how to do it correctly!
About the Author
Nabil Freij is the author of Enabling Globalization and the president, founder, and owner of GlobalVision International, Inc. (www.globalvis.com), a Software Localization and Translation specialist. He is trilingual and holds an MSEE from Brown University and an MBA from Bryant University. Freij has worked for 25 years in the hardware, software, and localization industries. He has traveled the world and lived in five countries. He is frequently published and quoted. Nabil is married and has two children. He currently resides in Palmetto, FL. Mr. Freij can be reached at firstname.lastname@example.org . You can read his blog at: http://blog.globalvis.com.