Fundamental Truths

Let's start with a few basic truths.

Pay now or pay later. When it comes to international product development, you can pay early and do things right, or you can pay later (and probably more) through increased localization costs, increased engineering involvement to firefight localization problems, and delayed shipment. Not to mention that you'll probably ship a shoddy product, which some markets will never forgive.

Localization and internationalization are symbiotic. Without localization, there is no need to internationalize. Without internationalization, you'll wish you never attempted to localize. When discussing internationalization basics, the eventuality of localization must therefore be kept in mind.

The greater the complexity, the greater the need. The more complex the product, the greater the need for a solid international architecture. A simple product and structure will most likely be easy to localize. A complex multimedia application with thousands of files is another story. These products require sound internationalization of the product and processes, or localization will be a nightmare.

The more you outsource, the greater the need. When handing off raw code and resource files for localization, you need a solid internationalization approach. If software strings are merely exported to a spreadsheet and sent out for translation, with internal engineers doing all the work with the actual files, creating the builds and so on, you may be able to get by with a kludged approach. But if you don't have the internal bandwidth to allow engineers to muck around with localization tasks, your product should be reasonably bulletproof. Otherwise, your engineers will spend an excruciating amount of time dealing with bugs and last minute changes needed to support localization efforts. This ties back in with the first point: either pay your engineers to work on architecture and design once or pay them to perform localization tasks many times.

It's a Big Change

A common problem for internationalization newcomers is underestimating the change required to do things right. There is a tendency to gloss it over by saying things like, "All I have to do is separate code from content." In reality, you need to focus on the concept of global product delivery, and this has a much broader impact than merely exporting strings into text-only resource files. Delivering global products requires changes to the overall software development process and means planning for additional players, milestones, builds, QA steps and so on.

If you are extremely lucky, you may be able to convince all the appropriate players and decision makers to do things right up front. But chances are that won't happen, and the process will be evolutionary. Try to look at it as a continuum and work on incremental improvements if you can't do it all the first time out.

Get Professional Help

There's undoubtedly a lot you can teach yourself, but there are two big reasons to seek help from those who specialize in internationalization. First, learning on your own is slow. It takes years to learn by trial and error. Engaging an internationalization consultant can jump start the process and save you time. Second, convincing management to make broad process changes can be daunting. External "experts" can go a long way in adding credibility to your recommendations.

A good starting point for working with a consultant is to request an internationalization audit. You'll get tangible results which can direct your further research and software or process changes.

Proceed with caution! You are entering the internationalization arena at a tumultuous time. Multilingual software has become a hot topic, resulting in a boom of newcomer consultants. You need to be methodical when choosing someone to work with. Don't simply do a Web search for internationalization consultants and pick one out of the stack. Instead, try to get recommendations. Spend a little time reading through archived notes on internationalization-related discussion lists, and identify people whose approach you like. Ask them for recommendations. If you have a relationship with a localization vendor, you can ask its representatives as well. Many localization companies offer internationalization consulting services themselves. Since you're reading MultiLingual Computing & Technology, pick out an author or two that you respect and ask them for recommendations. People are generally glad to help.

What Gets Internationalized?

So you're ready to get internationalizing? Let's talk about the pieces you'll need to change.

Core software product. During localization, you'll send files off to people who know nothing about your product. It's almost inevitable that something will be broken when you get the localized version back. In order to minimize breakage, you should spend a bit of time figuring out where the most likely breaking points are and make changes so that they are better protected. For example, if your build process is so complex that your own developers have trouble with it, it should probably be simplified. If all the text is buried in html, you should probably create a tagging method for identifying translatable and non-translatable strings. In the worst case, if you don't know where to begin with internationalization activities, consider passing the files to your localization vendor for suggestions on what you should change.

When researching specific internationalization techniques for software, you'll find two levels of information. Some guidelines have general dos and don'ts which apply to all software. Other information is specific to a particular operating system, environment or programming language. You should read up on both levels.

Other product components. A software product includes more than just the core application itself. You'll also need to consider internationalization of installers, help systems, tutorials, documentation, training materials, packaging, marketing materials and so on.

Processes. If your focus is only on software, you could end up with a beautifully internationalized product — and localized versions which ship painfully late and over budget. The entire product development process must be updated. You can learn this the long, hard, expensive way or face the music up front, define processes logically, and save time, money and frustration.

If your organization has a software process improvement initiative in place (the Capability Maturity Model, for example), make sure that each process area covers international product development issues.

Here are some specific functions to consider.

Configuration management. What is your current source control approach? Will the localization process use the same source control system? Does the system support a wide variety of file types so that it can be used for documents and graphics? How will file changes be tracked before and after files are sent for localization? How does the release process need to change to include localization stages?

Build process. How will your build process need to change to accommodate the creation of localized versions? Is your build process complex or simple? Is it well documented, or is it stored in the heads of a few key developers? Will vendors do builds? If so, what files and directory structures will you need to send them? Can tools like Catalyst be used to modify .dll files so that rebuilds are not necessary?

Testing. What is your current testing process? Can the bug database support a wide range of scripts, or will bugs in non-Latin-based versions have to be entered as screen shots? Can the database support screen shots?

Do you use automated test scripts? Can they support a wide range of character types, and will using them be efficient for testing localized versions? If not, how will testing be performed?

Is your lab set up to provide testing in the languages that you need? Do you have all the localized operating systems, applications, input method editors and other elements needed to perform testing of your localized product? Do you have processes established for how systems will be maintained, how scheduling will be handled, how testing will be staffed and so on?

Operational functions. Barry Caplan, founder of the www.i18n.com site, once referred to the functional areas required for international product delivery as the Seven Organizational Fingers. These areas are Product Development, Operations, Marketing, Sales, Finance, Customer Support, and Administration. The idea behind this concept is that when changing your software development approach for internationalization, you also need to consider how to support customers who speak other languages, how to handle funding and budgeting for localization activities, how to make marketing changes for regional customers and so forth. You can't simply internationalize the software and consider yourself done. The focus must be on creating a global product delivery organization.

Prioritize

Obviously the optimal approach is to do everything right the first time. Unfortunately, real-world demands prevent companies from doing things perfectly. We often have to make compromises and gradually work our way to doing it right. Given the likelihood that they'll be required, it's best to find compromises which introduce the least risk to product delivery.

For example, if your build processes are complex and you need to hand off the build task to a localization vendor, it probably makes sense to work on restructuring the build rather than adding comments in resource files to make translation easier. You can deal with that task later on. Or if you are developing a plan for testing localized versions of software, you may want to consider outsourcing the activity initially so that you don't have to deal with the process of organizing a multilingual lab and test approach right away. As time allows, you can create new processes to move toward higher levels of internationalization sophistication.

In Conclusion

Internationalization is a critical step in making sure you can fill your customer needs in countries far from home. But remember: the software itself is just one piece of the puzzle. Approaching the challenge systemically will dramatically decrease the pain level you'll experience during the learning curve.