Seven Habits

Globalization can be a daunting task, but the following tips will help you be successful in globalization.

1. Plan Ahead

It sounds obvious that you should plan ahead, but globalization is often treated as an afterthought, something that can be simply tacked on at the end of the product-development process. The results are usually disappointing and needlessly expensive. Planning ahead means that you understand the business rationale for each market you intend to market it—and what that rationale will require of you for each market—at the earliest stages of project planning. If you do not plan product or service features with target-market requirements in mind, you may find that localization at the end is difficult or even impossible and that quality suffers.

Develop a plan and allocate resources early on so that problems can be anticipated and dealt with in a timely manner. Make sure that this plan accounts for internationalization, the localization process, quality assurance, market research, after-market support, verification of local regulatory compliance, and any other processes that apply to your product: nobody likes to be stopped at the last minute because someone forgot a minor, but important, step early on.

2. Internationalize, Internationalize, Internationalize…

Close related to the last step is the need to thoroughly internationalize your project. In this step you work to actively anticipate problems and systematically solve them while they can be easily resolved. Internationalization involves constant testing and an awareness on the part of content creators, programmers, designers, and anyone else involved in the conception and implementation of projects.

If you are a smaller developer, you might consider hiring an internationalization consultant to help you get going. If you are a larger developer, having a dedicated internationalization advocate involved with projects will more than pay for itself. Either way, make sure that this individual is involved early on and has the authority to send project portions back to developers and require changes to be made.

Very early on in the design process and internationalization requirements statement should be prepared that outlines exactly what the designers and developers need to account for and how compliance is to be verified. Such a statement can be more or less formal, depending on the circumstances—a statement on internationalizing a piece of documentation will generally be simpler than one for a complex piece of software—but should be as comprehensive as possible.

Finally, internationalization of any technology or software product must include a testing phase, ideally in conjunction with whoever will actually localize the product, in order to identify problems while they can still be fixed.

3. Check Quality and Consistency

Many problems with localization quality are actually the result of unanticipated problems in the source version of a product or documentation. Take for instance the two sentences “Push the start button” and “Push the on button.” A reader in English might gloss over the difference between these two sentences (they obviously mean the same thing, right?), but what will happen when a localizer who knows comparatively little about the product is confronted by the difference? The natural tendency of the localizer is to magnify the difference between these two, just to be on the safe side. The result is that localizers tend to find the problems in a product that were not previously noted, problems that may well have confused users in the source language as well.

The companies best at globalizing their products have a proactive quality assurance (not just an after-the-fact quality control) plan in place to identify problems and resolve them before they go to translation. While such plans won’t catch every problem, they will reduce the number of such problems and facilitate quality localization.

4. Communicate

The tendency for many companies with regard to localization is to “throw it over the wall,” i.e., they hand projects over to localizers and expect them back with no knowledge of how they are completed. The unfortunate result is that those individuals who are actually localizing the project often have no access to whoever created it and therefore cannot ask questions. As a result they often simply guess or make decisions that make sense but may not be what their clients want.

As one example, if a source document written in the U.S. is sent out for localization and references a U.S. service center’s address, the localizer may not that the client really want this text updated to refer to a European service center for another market. In such a case the wrong address may be given.

If, on the other hand, there is open, two-way communication between the client and service provider, the localizer could simply contact the client on such issues to make sure of the right decision. In a good working relationship the service provider should ask a lot of questions about what the client wants and how certain things should be handled. Over time, as the service provider becomes more familiar with how things are done, the questions should become fewer.

At the same time, the client should be comfortable asking questions about the service provider’s processes and how projects are handled, and the vendor should inform the client how to improve future projects. When a service provider asks no questions and won’t describe processes, it is a bad sign.

5. Get Organized

Project organization is vital. Every project sent for localization should include a bill of materials that specifies every piece of content and what should be done with it. Incomplete projects or “moving targets” (projects that change over time) result in missed deadlines, extra cost, and increased frustration.

While there are some cases in which localization should begin before a project is complete—e.g., when a client needs to get to market faster and is willing to pay extra to localize content that changes—, one of the most common problems for localizers is when a project is in process and the client asks them to make “just one little change.” Small changes quickly add up to become a major management burden. While not all changes are avoidable, most could be avoided by imposing a firm “freeze date” on product development and making sure that it is adhered to prior to localization.

Other areas of project organization include practical details, such as making sure that content (like graphics) is not needlessly duplicated and that source files for graphics are supplied (rather than web-ready formats). Taking a little bit of time to organize projects and supply the correct materials will save time and effort (and money) in the localization process.

6. Treat Globalization as a Business Decision

Although there are many technical components to globalization, the best globalizers never lose site of the fact that globalization is fundamentally a business proposition related to meeting the needs of local markets. All decisions must therefore anticipate the business rationale for making them. Quality goals, support mechanisms, even how much one localizes all are determined by business. When globalization is separated from business concerns and treated as a technical problem, quality and focus suffer. Content may be localized that does not need to be (e.g., promotional materials that don’t apply to a particular market). Successful globalization requires a clear balancing of business and technical demands to find optimal solutions.

7. Follow Through and Look Ahead

Those who do not learn from the past are doomed to repeat it…

Each time you globalize you will learn something new. Make sure that knowledge is not lost. If each project is treated as a one-off task, vital information will be lost. Instead, remember that planning for the next version starts before the last one is even done. Document decisions and problems and work with service providers to find out what problems they observed. Hold project post mortem sessions and ask for a candid assessment of how you can improve. If you found problems that you were not able to correct in the last version, make sure they are documented for the next version.

Further reading

To learn more, we encourage you to read the LISA Best Practice Guide Quality Assurance: The Client Perspective and the Globalization Industry Primer.