That’s because the name Siri sounds suspiciously close to the Japanese word shiri – a colloquial term for buttocks that, appropriately enough, rhymes with “crass.”

Get localization right, from the bottom up

“Here’s our pet rabbit. Can you change its DNA for us?”

“Nice house of cards. Could you replace the red one in the bottom row with this green one?”

“Good job localizing the Web site. Can you change all instances of usted to tú?”

Has this ever happened to you? It’s happening with one client on a Web portal we’ll soon roll out in Latin American Spanish.

***

In Spanish, there are two levels of address: formal (usted) and informal (tú). Historically, if you’re talking to the king or somebody whose business you want, you use formal address. If you’re talking to your friends or to a small animal, you use informal address.

A few years ago, this was a no-brainer in localization. Most software, Websites and marketing material still used usted because you’re talking to customers and you want to honor them. Trendy sites like AOL.com and terra.com used tú because they wanted to be your friend as quickly as possible.

NAFTA, the Web, immigration patterns and cross-border commerce have brought Mexico and the U.S. so close together that the old rules don’t apply as much anymore. Cell phone companies, auto dealers, even banks are using tú in customer-facing materials. There aren’t reliable rules anymore; the choice depends on the organization’s messaging.

***

We started localization about five months ago, assuming usted. We dutifully created a glossary and asked for in-country review by the customer, a wireless network operator. The customer must have been too busy, so we received feedback from a business development manager along the way. The comments gave us some terminology preferences, but no mention of usted vs. tú.

Now the portal is up in Spanish, and the customer has finally begun to review it. New and changed text is coming back to us with tú. They haven’t asked us to change the DNA of the rabbit yet, but sooner or later the usted and tú fronts will collide and we’ll need to work it out.

The moral: You should have learned long ago to have your customers specify the region for the Spanish (or French or Arabic or Chinese…) they want. Remember to ask them about usted vs. tú as well.

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit: bloomsberries

Obviously, the answer is “yes.” Automakers localize their products by placing the steering wheel on the left or right, yet everything remains in English.

So it is with a marketing campaign. A client is launching a campaign in several English-speaking countries: USA, UK, Canada, Australia, even Hong Kong. Nobody consulted me on the campaign – why would they when translation is not involved? – but I heard about it through the grapevine and weighed in.

This is a localization issue. Even though the other locales all use English, we are, in effect, translating content for them.

Mind you, it’s not the kind of localization effort that calls for translation memory and engineering, but there is a big QA lesson from localization that I’ve tried to impress on the team: We need to run the campaign past a stakeholder in each country during this process.

If it’s worth going after customers in the other locales, it’s worth researching terminology, spelling and suitability to get it right, and part of that is in-country review.

“Do NOT try to get this right yourself,” I’ve told the marketing team. “No matter how much research you do, you’ll miss something that an in-country local would spot in a heartbeat.”

What do you do differently for English-to-English (or French-to-French, Spanish-to-Spanish, etc.) localization?

To ensure uniformity of translation throughout the product (and, as the international effort grows, throughout the company), it is a good practice to put in place a glossary, which contains approved translations of key words and phrases. A translation glossary gives the equivalent of the key terms in the target language.

Translation Glossary/Terminology List - Example

The Explanation column in the example is very important for preserving contextual information for the benefit of the translators. Note also that the glossary plays the important role of dictating what should not be translated.

Here are some key moments in the life of a glossary:

1. Client hands off early version of product to localization vendor for creation of glossary.
2. Localization vendor compiles list of key terms, with contextual comments.
3. Client conducts training session for translators and editors (optional, and too often overlooked)
4. Translator translates (or, in some cases, doesn’t translate) into target-language equivalents.
5. Vendor returns glossary draft to client.
6. Client sends glossary out for review by stakeholders most likely to complain about undesirable translations, in order to avoid these complaints once the product has been released. (This is extremely important, and should be performed by in-country partners and co-workers whose livelihood depends on the quality of the translation.)
7. Client returns glossary comments to vendor, who incorporates them.
8. Once approved, the glossary goes to translators, reviewers, editors and client for continued reference.

A typical glossary will contain a few dozen up to a few hundred terms. It’s a big piece of the translation-quality puzzle and it represents the good business sense of establishing terms up front to avoid unpleasant surprises at the end.

This post describes more production details, including the output and deliverable formats in which clients want to receive these localized assets.

Linguistic Review – An important issue in production has to do with linguistic review. What happens when the client’s in-country reviewer plays the localized video and wants to change a few words in a subtitle or – much worse yet – a sentence of voiceover? This is not as simple as opening a Turkish MS Word document, modifying a few lines and saving the file back out. In this case, the subtitles and voiceover are separate video/audio assets, and it will be necessary to re-create them, to replace them in the main video project, and to output the final as a single, uncompressed file.

It’s a lot of work to clean up a few typo’s or update a term.

For that reason, it’s best to perform in-country review before production starts. Don’t wait until the video is ready; send the source and translated subtitles or script in a side-by-side table for review. That way, you can accommodate the reviewer’s comments because the project is still young and time is still cheap.

File specifications – Assuming that the localized video will end up on the Web, you need to obtain information about:

• codec used (e.g., Sorensen Spark Pro codec, 1 pass CVR)
• screen area/resolution (e.g., 240×180 pixels)
• output file format (e.g., .flv Flash video, .swf Shockwave Flash, .qt QuickTime video)
• target file size in megabytes (mostly as a sanity check that the localized files is of similar quality to the original).

These down-in-the-weeds specifications usually come from the video technician or webmaster. Note that, to play a multimedia file over the Web, the Web server must support the delivery of the format so that visitors can simply click on a link, and let a browser plug-in do the hard work. However, if you need to play the file on a computer without the Web server plumbing, you’ll need a standalone player for the specific type of video file. This may be Apple’s QuickTime Player, Windows Media Player or Moyea’s FLV Player. (These players are handy for quick previews for upper management, who don’t want to wait for them to be posted to the Web site.)

Deliverable format – What to give back to the client? If you’re lucky, the output file is all they want. If not, you can give them all of the project files, but only their own media studio will be able to work with them, and they won’t have the linguistic expertise of your localization vendor, so the files could end up amounting to a few DVDs of data nobody will ever use. On the other hand, that describes about 75% of everything anyway, so it’s cheap insurance against the day they change vendors or come up with some other wild reason to use them.

If the localized video is meant for broadcast, you’ll also need to output it to a tape master, at which point formats like PAL and NTSC come into play, depending on the target country.

In summary, multimedia is not as tractable as documentation, Web content or even software when it comes to localization. This is due mostly to fixed costs for studio time and voiceover talent, and to the non-text-based nature of audio/visual.

Did you learn this the hard way, as I did? Back in the old days, I would marshal the translators’ dictionaries and sources against the dictionaries and sources of my in-country reviewers to prove a point. Ultimately, of course, that never paid off, and I came to realize that regardless of who had which references, it’s the in-country reviewer who should generally prevail, for a couple of reasons:

• The reviewer, not the translator, has to live with the translation and can eventually be convinced that it’s important work.
• The reviewer, assuming I’ve selected him/her properly, is as close as I can get to the consumer of the translation (the real customer), and whether a linguist or not, best understands the terminology that will make sense to that consumer.
• Even when the task of review falls to a completely mismatched person, like a salesperson reviewing a user manual, there is still more value in having him/her review it than in sending it to another translator. I generally get less feedback from a non-technical reviewer, but it’s a better sign-off.

Sometimes, though, the in-country reviewers really are linguists (or want to be), and they introduce considerable changes in the course of their review. It’s important to give them guidelines for the reviews they perform so that they understand what we want and don’t want from them. Among those guidelines:

• First and foremost, look for areas in which the translators have completely missed the point of the source text. Customers will overlook small, stylistic differences between source and translation, but they will become angry if the translated content is just plain wrong.
• If the source text is wrong (e.g., incorrect procedure or misstated information), take it up with the writer of the source text. Our job is to translate the source, not define it. If you make your suggestions in English, we can forward them to the writers, but we cannot in good conscience put out a translated document that does not match the source.
• Be specific about the changes you propose. In reviewing a word processing document, enable change tracking so that we can easily find your modifications. In a PDF, annotate the document with your comments. For HTML pages, use a spreadsheet or table-formatted list. The easier it is to identify your changes, the easier it is to implement them correctly.
• While you’re welcome to review every sentence on every page, we don’t expect you to do so. You’ll know after a few paragraphs whether the translation is atrocious, and that’s the most important thing we want to establish.
• We’ll incorporate as many of your changes as possible. Some of them may have to wait for the next version of the product.
• In the case of long documents and detailed review, rate your comments by severity so that we can address the most urgent ones first.
• In order for us to keep to our schedule and deliver the finished product so that you can begin selling it, we need your comments back by [give a specific, reasonable deadline].

Frankly, the last point is the most important. Without a deadline, reviewers will often procrastinate the work mercilessly, and you’ll end up waiting a long time only to get nothing.