Localizing multimedia (Flash, QuickTime) - Part 3

Part 1 of this series described the background education many companies (especially upper management) require when they want to have their multimedia files localized. Part 2 described what you, as localization project manager, need to know.

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., 240x180 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.

Instructions to in-country reviewers

"The best translation of any sentence is the one that the customer likes the best." -Me

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.