Summary

Adam's presentation answers the following questions:

• What is all this "-zation" language and how do globalization, internationalization, and localization fit together?
• What is the typical process for a localization project?
• How should you prepare a localization kit and request a proposal?
• What factors should you consider in choosing a localization partner?
• What should you prepare for your localization partner in beginning a project?
• How long does localization take? How much does it cost?
• What techniques are used to edit the user interface text?
• Is it better to use translators in the U.S. or those in each target country?
• How can you maintain terminology and develop useful glossaries?
• What issues arise in translating documentation? Formatting it? Converting it to appropriate deliverable files?
• What do translation memory tools do? How can you use them effectively?
• How should you address updates?

Terms

Adam began his presentation by defining some common terms.

Internationalization is the process of insuring that software will handle all of the issues that come up when you're not dealing with English anymore. Issues such as operating system interaction, time and date formats, double-byte character sets, etc. You can think of internationalization as structuring the English product so it will work correctly around the world.

Localization is the process of adapting software text into target languages. That means translating it into French or German or Japanese, and dealing with the documentation, packaging, and all the related items that go with it.

Globalization is the combination of all these activities. It's everything that you need to do to get your product to market worldwide.

Proposals

For many client companies who are beginning to go through a localization process, the first step is to get proposals. Optimally, clients would work with localization vendors before the proposal stage, but that's frequently not the case. When creating requests for proposals, it's important to carefully define what work is involved so that you can determine how long it's going to take, and how much it's going to cost.

Early Involvement

The best way to ensure that you get an accurate proposal is to invest some time up front figuring out what your project entails. You'll need to identify the people in your organization who can provide the required level of information.  In most companies, a localization vendor's main contact is the product manager, localization manager, or someone else who is assigned localization responsibility, but who doesn't usually have access to all the information that is needed. This person has to go into the development organization and hunt down the details about the product. To do this, they talk with developers, engineers, documentation writers, graphic artists, and anyone else who is developing components of the product. This interaction is especially critical for engineering process and requirements. Localization can be a big success if you work closely with the developers. But if you just take the product off a server and try to have it localized, the localization process is going to be a much bigger challenge.

Getting people involved early is therefore a real key to success.  The most successful companies have a team of people who act as a sort of localization committee. The group might be chaired by the localization manager, but it includes people from all of the different parts of the development process.  These people regularly communicate about international issues, not only during the actual localization process, but as a standard part of each product's development cycle.

Audience Identification and Language Selection

Another issue to consider when developing requests for proposals, is who will be using the product. The intended user of the software or documentation may not be obvious to a localization vendor or to others who work on the project.  It's important to spend some time up front identifying the target audiences, locales, specific areas, regions, etc.  How well educated are the users?  The people using your product in one market may be very different from the ones using it in another market.  What will users expect to do with the materials?

It's important to be clear about what languages you are targeting. Saying that you need Spanish or Chinese is not enough.  There are variants for many languages, for example, the French used in Canada is different than the French used in France. You'll need to find out where the product will be used so that you can select languages appropriately.  Spanish varies dramatically, depending on where you are in the world.  The Castillian spoken in Spain is quite different from the Spanish used in Latin America.  There are even differences between various countries within Latin America. Some words are subtly different, other words for the same concept (computer, for example) are completely different.  The same thing is true for other languages, such as Portuguese.  Many companies hope that they can translate into one version of Spanish that everyone in the world can use.  It's nearly impossible to choose one variation and keep everyone happy.

Chinese is another commonly misunderstood language. There are a number of different spoken dialects, the most commonly used being Mandarin. But when specifying languages for translation, you need to be concerned not with the spoken dialect, but with the character sets used for written material. People in Taiwan and in Mainland China may both be able to speak Mandarin, but they write very differently, using two different character sets. You will need to specify whether you need Traditional Chinese, Simplified Chinese, or both.

Clear Project Details

When obtaining proposals, it's very important to provide clear project details. These details should include word counts for all items, page counts for documentation, and engineering specifications.  These specifications should describe how to compile and test the products.  SimulTrans has a list of about 50 items that should be covered when requesting a quote, and you can use that list as a guideline when developing requests for proposals.

To get accurate estimates, you should really provide the actual files.  Many companies ask localization vendors for quotes but provide only a letter or note which loosely describes the product.  You can get a ballpark estimate like that, but you really can't effectively figure out how much work the project entails.

If you use any specialized tools to develop the software, you'll need to provide information about them.  Maybe custom resource types have been created, and localization companies need to know what tools are being used to create them.  If the tools are proprietary, you'll need to plan to provide them, and the localization company will need to plan time to learn them.

You should also state whether the product was translated previously, and whether or not you were happy with the translation.  Try to establish how much of previous translations can be reused.

Quoting Methods

It's important that you guide the proposal process actively. Some people just write a specification, send it to 20 different companies, and see what pricing they get back. That approach really doesn't help you determine whether or not you'll work well with a company.

Even if you do send out the actual software or the document, it's a good idea to provide common specifications to each vendor.  Everyone counts words differently, so it's a good idea to ask vendors to base their estimates on your stated word count. If you do that, you can compare the pricing more easily.

Comparing quotes can be hard.  One company might include 20 line items for one book, and another company might consolidate the activities into one or two line items.  But you need to be careful that they are actually describing the same set of tasks.  You'll also want to get details about process, schedules, and rates.  There are really no standards in the industry.  Companies have different philosophies about how to approach projects.  You should try to find a company that matches your philosophy and project needs.

Translation Tests

Many people think that small test translations are a good way to evaluate localization companies.  They might ask for a sample translation of two pages in French, or an applet in Japanese.  Generally, this isn't going to be a good indicator of how well a real project will go.  Samples can only tell you how well one translator did translating some words that they knew very little about. The translator creating the sample is probably not going to be the same person who would work on 500,000 words in a help system.  Most localization companies handle one or two-page projects much differently than large ones.  Small projects might get handed to in-house translators and reviewers, while large projects would probably be sent out to translators in the target countries.

A better way to evaluate companies is to talk to references. You'll get an idea of how they interact, and what kind of procedures they have for managing projects. If you are determined to do a test, find a small project like a software update, or a small document. Since it is an actual project, you'll get a better sense of how you'll work with the company as a whole.

Project Setup

Project set-up is the task of planning so the project will be successful.

Localization clients often think that once they get through the proposal stage and send off the files, they're pretty much done. They want to just sit back, wait three or four months, and get it back complete and perfect. But that really doesn't work. You need to be on top of a project, and commit staff time to manage it. Otherwise, you'll end up with a project that's not as successful as you'd like it to be.

Team Members

It's critical that the right people be involved in the planning process. It's much easier to talk directly to these people than to try to extract information that's traveled between two or three people on its way to the vendor.  Meeting with the key developers helps prevent problems during the build phase, when the vendor discovers that the build tool isn't working, or header files are missing.  These discussions should happen up front.

Some of the people to include on the client side are:

• Project managers
• Documentation authors
• Production artists
• Software engineers
• QA engineers
• In-country reviewers

Some of the people to include on the vendor side are:

• Project managers
• Translators
• Production artists
• Localization engineers

Looking at the Project as a Whole

Build localization projects around products, not components. You need to think about what is involved in the product. You shouldn't focus on one or two obvious items, perhaps a user document and a piece of software.  Instead, you need to look at the big picture and figure out how the pieces fit together, and what order they should be done in.  If only some pieces of the product are being localized, you'll want to closely evaluate which ones make sense. For example, rather than localizing a huge user's guide but not the software, it might make more sense from both a user satisfaction and cost perspective to localize only the software.

Working Versions of Product

When planning a project, you should try to provide working versions of the product to the localization company.  This applies to both software and hardware. Translators can do a much better job if they can see what a button actually looks like, and how it functions.  It's also useful to provide any training materials or courses that may be available.

Development Tools

During the setup phase, it's important that you list all of the development tools and details about the development environment.  If you don't work out the details of required tools ahead of time, you may experience project delays when missing items are discovered because the software won't build.

Identifying Risks and Developing Contingency Plans

When planning any project, its wise to identify potential risk areas in order to try to prevent as many as possible, and to prepare plans for dealing with them in the event that they occur.

Some common risk areas for localization projects are listed below:

• Software Stability. What is the likelihood that the software will change?
• Degree of Internationalization. How thoroughly was the software internationalized?
• Documentation Construction. How well was the documentation written? Does it use a lot of acronyms? Will the style work in other countries? Are there examples that won't work outside the US (American football, American style mailboxes, etc.)?
• In-Country Review Process. Will reviewers have time to conduct the reviews, since the task is probably outside the scope of their full time jobs? Will they understand the proper level of comment needed?
• Staff Availability. Will software engineers be available to help address internationalization errors, or to help address build problems?

It's important to be reasonable when you're committing to deadlines, especially if the project has a lot of potential risk areas. With enough planning, it's possible to get localized product out quickly after English. Without proper planning and risk handling, you should expect delays.

Once you've identified the risk areas, you next need to think about what you will do when something goes wrong. Developing contingency plans helps mitigate the risks.

Time/Quality Tradeoffs

Quality may seem like a straight-forward issue. Customers always want excellent quality. But there may be occasions when you need to make compromises. Maybe you are trying to meet a date for a huge contract, and you need documentation translated as part of the deal. You might need to choose between delaying the delivery a month to ensure that quality processes are followed, or making the date by cutting some quality process corners. Another quality problem may come up based on the number of linguists that are working on a project.  If only one person is working on a document, it might take a while, but the consistency level will be very high.  If you have to split the document up and have ten linguists working on it, the end result is not going to be as consistent.

While time and quality are usually both high priorities, there may be times when you need to make tough decisions between those priorities.

Time and Cost Metrics

Each project is unique, and timelines for it will depend on the project's peculiarities. But there are some general guidelines for how long things take, and how much they cost.

Project set-up for big projects can take from two to three weeks, especially for the first project with a new vendor. Actual number of hours worked might be more like three to five days, but by the time you go through the proposal process, get the materials together, and choose a vendor, the time adds up. In some cases, it may take even longer than this.

Software translation rates average about 1,000 words a day per translator for European languages, or 750 words a day per translator for Asian languages. (Asian languages are slower because the input method is more cumbersome; entering Asian characters simply takes more time.)

Documentation translation rates average about 2,500 words a day for European languages, or 1,500 words a day for Asian languages.

Linguistic reviews are faster, with an average of about 5,000 words per day.

Keep in mind that these are general metrics. Actual rates vary based on how technical the subject matter is, the difficulty of the terminology, etc.

An attendee of the recent Localization Industry Standards Association Conference has been surveying rates charged by a variety of localization companies. Here are some of the industry averages that were derived:

• Software translation—$.35 to $.50 per word.
• Localization engineering—$80.00 per hour.
• Internationalization engineering—$150.00 per hour.

An important thing to keep in mind, however, is that not all companies charge the same way. SimulTrans, for example, does not charge engineering by the hour. Instead, they charge per dialogue box, string, or file, depending on what tasks need to be performed.

Order of Events

The globalization process proceeds most efficiently in the following order:

1. Internationalization
2. File preparation, analysis, and glossary development
3. User Interface translation
4. Help and documentation translation
5. QA and completion.

Internationalization

Internationalization Errors

There are a number of internationalization errors that can appear during the localization process.  A few of the most common ones are listed below:

• Text processing problems (usually caused by applications that are not properly double-byte enabled)
• Display problems (problems with fonts, character shapes, printing, and directionality)
• Embedded strings (text that is hardcoded rather than stored in editable resource files)
• Concatenated strings (strings that are made up of more than one piece of variable data)
• Text within bitmaps (text is not editable)
• Overloaded dialogues (not enough room for expansion)
• Incorrect locale-dependent displays (time/date/currency formats, paper size, monetary units, etc which are defined in the program instead of provided by operating system settings.) Take advantage of Application Programming Interfaces (APIs) to avoid these problems.

Making sure that these issues are appropriately handled when the project is being internationalized will save time and money during the localization phase.

Localization

Starting the Project

The first step in the localization process is to analyze and prepare all of the files so that they are in good shape to be handed to translators. Some of the activities that take place during this preparation time are:

• Identifying any problems with the files
• Training the translators on the product 
• Preparing the files that will actually be sent to the translators by locking out text that shouldn't be changed, adding comments for unclear text, and defining acronyms
• Developing a glossary
• Using tools to create a translation memory
• Glossaries

Glossaries for localization purposes are lists of English and translated terms rather than a list of definitions.  Additional fields are frequently included, to define the part of speech, provide a bit of context, and perhaps list the component of the product from which it came.  Glossaries should be created and reviewed before translation begins, so that a baseline of agreed upon terminology is established.

Involving reviewers when developing glossaries is critical for avoiding linguistic disputes during the review process.

Creating Project Glossaries

The software user interface is where most glossary terms come from, because those terms will be used over and over again throughout the various product components. For example, software terms appear in the help systems, documentation, and packaging.  Other good sources of terms are help system indices.

Industry Glossaries

Many software glossaries are available on the web for your use. For example, Microsoft, Apple, and Sun all have glossaries for menu items like file and edit and print.  It should be obvious that using those terms is better than redefining them in a project-specific glossary.  If you don't, the operating system will use one term, while your product uses another.  Using non-standard terms can even create functionality problems in some situations. (One note of caution: Microsoft uses different terminology for it's various operating systems. The term for a function in Windows 98 may not be the same for that function in NT.)

Translation and Reviews

When it comes to the actual translation process, there are a few key issues to keep in mind.  Most importantly, translators should always be native speakers of the target language.  SimulTrans works primarily with small, single-language translation suppliers in the target country.  These "boutique" vendors provide a specific language focus, can gear up and down depending on project size, and tend to be less expensive than local freelance linguists.

In order to ensure high quality translation work, a number of quality assurance steps take place.  Before work is returned to SimulTrans, it is edited by a second person at the in-country vendor site.  Reviewers look for actual errors in translation, but also check for consistency, accuracy, style, and completeness.  In order to check for these things, reviewers must compare the English item to the translated item.

Sampling is a method of evaluating quality that multi-lingual companies employ throughout the localization process.  To do this, some portion of the document or other item is translated and provided to the localization company for review.  This sample can be from 10% to 100% of the entire piece.  The quality of the sample is evaluated to get an idea of how the overall quality stacks up.  Conducting sampling throughout a project helps ensure that problem situations are caught and corrected early.  The Localization Industry Standards Association has developed guidelines for sampling, and many localization companies apply those guidelines to their own sampling processes.

In addition to linguistic reviews, technical reviews of the translated material should be conducted by people in the target country, who are familiar with the industry. Technical reviewers provide important input about whether or not instructions are understandable, and terminology for the industry is correct.  Unfortunately, technical reviews are expensive.

When the files are reviewed and updated, they are delivered to the localization company.  At that point, a check is made to ensure that all files have been received, that open issues are understood, that potential client reviewer problems are detailed in writing.  The files are then sent to the client so that their reviewers can approve the translation.  The client review process is extremely problematic, because reviewers frequently don't have much time, and they may try to rewrite the piece rather than merely review it.  The best way around this potential problem area is to involve the reviewers early in the project, and get them to communicate directly with translators to establish a bond.

Tools

One of the advantages of using translation tools is that they can work interactively with glossaries.  MultiTerm by Trados is an example of a terminology management tool.  Translators can use it interactively when translating in Word or another package.  This helps ensure consistency, since it is easier to use than having to open a separate file or hardcopy to look up a term.

Managing Updates

One of the best ways to control cost and quality is by properly managing revisions. If possible, work from final English. If you need to start localization while still developing the U.S. software, then it's critical to minimize the number of updates you send to your vendor. You should establish clear milestones for sending updates at the beginning of the project, and then monitor progress against those planned dates. The best thing to do is to send off an initial release sometime after the user interface becomes reasonably stable, and then only make one or two udpates as the English progresses. There are no advantages to sending revisions every few days, or every week. You'll end up wasting your time and the vendors time in simply trying to manage all the files. Risk of version control problems also increases each time files are sent.

Version Control

You'll need to work with your localization vendor to define how you will jointly manage version control. Projects go badly because of version control problems. In some situations, a vendor may have a softcopy document that does not match the hardcopy, and they'll need to know which one is most current. It doesn't really matter what version control system you use, just make sure that everyone involved understands how versions will be tracked.

Tracking Components

Another important thing to do when managing a localization project is to carefully track all of the files related to the various product components.  One method for tracking components is to create a spreadsheet that lists all the files required for all items being localized, including bitmaps and graphics.  As part of this list, you can outline which files need to be modified, and which ones don't, which ones will be updated in the future, and which ones are final now.  Localization vendors sometimes get drops of huge numbers of files, without instruction of what is included and what files need to be modified.  Sending files like this not only increases the amount of time that the vendor has to spend evaluating the files, but also drastically increases the likelihood that something will go wrong.

The more detailed the descriptions you can give about the files and the product that you can provide, the better results you can expect. 

Localization Engineering

Strategy for Use of Localization Tools

Each project will be individually evaluated to determine whether or not the use of tools makes sense. There are many tools on the market, and they can be very helpful in preventing inadvertent errors that translators make when directly editing .rc files. .rc files contain the editable strings which appear in software user interfaces, but they also may contain controls which get broken when modified. When looking at an .rc file, it's easy to tell that some of the strings appear in the software. For other strings, it may not be so clear. They may look like screen text, but actually be part of a control.

Many localization tools modify binary .exe or .dll files rather than the .rcs, which prevents inadvertent changes to code. The tools create a toolkit from the binary file, and then graphically display user interface items so that the translator can modify the word and resize the dialog element. When working in text-based .rc files, translators see only the text, and they have to wait to see the built results, and then make adjustments for resizing etc.

Another advantage of tools is that they track the text in controls, and the translations for them. When a translator types in the name of a particular interface element, the translation would appear for each instance that it occurred in the binary file. Obviously, this saves a lot of time and money.

Using translation tools frequently makes sense, and localization customers may want to get involved with understanding the tool strategy, and developing products in a way that works well with these tools.

Software QA

There are four types of testing that can take place during the localization process.

Internationalization Testing ensures that the software has been properly internationalized, and identifies internationalization problems as previously described. Internationalization testing frequently occurs before translation actually begins.

Functionality Testing ensures that the operation of the software was not changed in any way due to the localization process. Functionality testing is usually based on English test cases provided by the customer. The degree of functionality testing that a vendor performs is negotiated with the customer.

Linguistic Testing (also known as basic user interface testing) ensures that there are no problems with dialog resizing, character truncation, word wrapping, etc. Linguistic testing occurs as a standard part of all software localization projects.

Compatibility Testing ensures that the product properly interacts with all of the hardware, software, and operating systems with which it is intended to work. Compatibility testing is an optional testing type that customers can request from vendors.

Documentation

There are a number of things that you can do to reduce document translation time and cost. The desktop publishing package that you select can play a big part in how easy a document is to translate. Several common applications are described in the next section. Regardless of the application you use, the way the document is structured is very important. As with software, your documentation should really be internationalized. The subject of document formatting is an entire presentation on its own, but here are a few issues to be aware of.

• If pages or tables are packed full with text, there won't be room for expansion, and you'll run into problems with languages like German, which expand significantly.
• If graphics include callouts or other text, they must be editable. Remember to leave space for expansion. If possible, consider using numbers that refer to text within the document as callouts, rather than including the text itself in the callout.
• Try to name files logically, so that people who are unfamiliar with them can spend less time figuring out what they are.
• Use styles (predefined font, spacing, and formatting) consistently throughout documents. Set up styles for repeating component types, and apply them appropriately, rather than changing the properties of individual paragraphs.
• Use standard fonts, or provide all fonts when handing off files.
• When creating graphics for documents that will be translated, keep text in separate layers, and avoid using outlined text.
• Graphics should be linked rather than embedded.
• Use tagging features to automatically generate tables of contents and indices, rather than creating them manually.

Comparison of Applications

This section describes and compares several commonly used desktop publishing applications.

Adobe FrameMaker

SimulTrans used FrameMaker to format almost half of the documents in 1998. Both Mac and Windows versions were used, and occasionally even UNIX. FrameMaker is the best application for long documents, and was designed to handle book building. You may have heard of Frame-SGML, but that is a different application. Approximate formatting time in minutes per page: 10.

Interleaf

Interleaf was the next most commonly used desktop publishing package, making up 37% of the documents that SimulTrans formatted. SimulTrans used both the Mac and Windows versions, but a UNIX version is also available. As with FrameMaker, Interleaf was designed for long documents and to do book building. The interface is UNIX-like, however, and is slightly harder to use. It's popularity is waning. Approximate formatting time in minutes per page: 17.

Quark Xpress

SimulTrans used Quark Xpress to create their brochure, since it is the most popular application for creating marketing materials. The application is available in both Mac and Windows versions, and it is great for dealing with color and graphics. It lacks many of the book building features of FrameMaker and Interleaf. Approximate formatting time in minutes per page: 20.

Adobe PageMaker

PageMaker is also commonly used for marketing materials, and is available in Mac and Windows versions. It is more difficult to use than most desktop publishing applications. Adobe is positioning PageMaker for web design, but it may end up being eliminated with the advent of Adobe's design wonder. Aldus PageMaker 1.2 was the first desktop publishing package that SimulTrans used! Approximate formatting time in minutes per page: 20.

Output

Printing and shipping documents is expensive, so companies are increasingly using electronic methods for distributing documentation. There are a number of ways that this can be done. Live files can be given to users along with the application in their language. PostScript files can be delivered for printing. Text can be converted to outline fonts/EPS files, which can be printed on any printer. PDF files using target language fonts (when necessary) can be created for online use or for printing. HTML files can be generated for users with target-language browsers.

When printing Asian documents, special consideration needs to be given to how the files will be dealt with. In some situations and from some applications, Japanese PostScript files can be printed on standard office printers (depending on whether font definitions are included in the PostScript. Most applications do not do this.) Otherwise, the printer will need a Japanese Raster Image Processor. Another option is to request that your localization vendor provide either films or Camera Ready Copy (CRC). Printing can then be performed from these forms of hardcopy.

Creating a Localization Style Guide

When passing documents off for translation, it's a good idea to include a style guide so that the localization company knows how you want various issues handled. The guide should describe how to handle text expansion when page lengths are exceeded; specify fonts for the various non-Roman languages; define how much flexibility there is in moving graphics or other components; provide local addresses, phone numbers, warranty statements, regulatory statements, printing information, etc.; and describe how output should be handled (including detailed print or film specs if necessary.)

Tools

In order to allow translation tools to work efficiently, there are a few guidelines that should be followed when creating documents. You should avoid hard returns; avoid tags in the middle of words; turn off hyphenation; ensure that cross-references are correct; and flow text throughout the entire document (maintain only one text flow).