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.