27 February 2008

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.

Labels: , ,

21 February 2008

Localizing multimedia (Flash, QuickTime) - Part 2

Part 1 described the background education many companies (especially upper management) require when they want to have their multimedia files localized. This part describes what you, as localization project manager, need to know. This information is important for you to request and deliver the right things, but it's not very likely that upper management will be interested in it.

Assume content like a 60-second product introduction, with actors speaking on screen and graphical text in need of translation and layout.
  1. As usual, you should plan for a glossary or terminology list. It's always important to ensure you use a properly current term for "pain relief" or "outfielder's glove," but the cost of opening up an already localized complete project to tweak a couple of words - particularly spoken words - can be prohibitive. If your in-country partner has approved of your terminology ahead of time, you'll save yourself headaches in the long run.
  2. Pare down your cast for the localized version. If your commercial includes one female and two male actors, do you really want to pay voiceover fees for all three of them? Consider using the same voice for both males, and subtitling the female. When your budget gets bigger, you can spring for all three linguists.
  3. Files are huge, so don't count on moving them over the Internet. You'll want the translation studio to work as far upstream as possible, so plan to give them the original video footage, not a compressed QuickTime or Shockwave Flash (.swf) file. These can be several GB in size for only a few minutes of video, so plan on moving DVDs or thumbdrives.
  4. If the commercial was created as a digital studio file (e.g., Final Cut Pro), hand off the entire project, just as you would hand off all the surrounding files needed for a software localization project. This enables the localizers to open graphics, replace text and drop in the voiceover, then output localized versions on par in quality with the source version.
  5. Studio time is not very flexible. Even though your movie has only 60 seconds of voiceover, you may need to book half- or even full-day linguistic talent in multiple languages. This can be a rude surprise when it seems to you that the original voice talent was nearly free (or so you thought). And, as stated above, opening and closing these projects to make apparently minor changes can run into major money for engineering time.
Clients are not always specific about the output and deliverable formats they want for these localized assets, so it may take a while to find somebody who will give you more details beyond, "We need the video in Japanese, and quickly." Part 3 will cover that.

Labels: , , ,

14 February 2008

A localization lesson from North Korea

You never know how your next lesson in localization will reach you. What if you were to learn something from a digital trailblazer like North Korea?

The International Herald Tribune reports that North Korea is offering overseas shoppers the chance to buy hundreds of its goods through the Internet. Offered items include boxing gloves, bicycles, commemorative stamps, roller skates and uniforms for Taekwondo. While the site is obliging enough to accept credit cards, it has not yet reached the level of capitalistic level of revealing prices.

But the most forward-thinking aspect of the site is that, right out of the gate, it is localized into Korean, English, Chinese, Russian and Japanese. How many of us are that enterprising and globally inclined? Show this post to your boss and say, "See? Even lowly North Korea can develop and implement a localization strategy. Why can't we?"

The hitch: The site has been live since 31 Dec 07, but it spends a lot of time off line. Try your luck: www.dprk-economy.com/en/Shop/index.php

Labels:

07 February 2008

Making Sense out of Outsourcing Localization to China - Part 2/2

[Continuation of last week's post, Part 1]

Since it was my charter to make this offshored localization project work, we built checkpoints into the project to detect problems as soon as they arose.

We scheduled bite-sized chunks of translation, engineering, layout and editing work early in the project, then handed them off for review in our client’s in-country offices. We established twice-per-week conference calls with the vendor’s team to reinforce the decisions we made in e-mail threads. To overcome low TM matches and shorten the project schedule, we sent source and target files from previous projects for realignment in TM. We agreed mutually on a format for weekly reports that would highlight project status without becoming onerous. In short, we followed every prescription for a successful localization project, and we followed them more carefully than normal.

Our client’s Korean office has expressed satisfaction with the final product. The decision-makers, pleased that nothing went awry – at least, nothing that required their intervention or remorse – asked for a post-partum on the project, in which I underscored these points:

· It was a pleasure dealing with the vendor. They were prompt, courteous, efficient and unequivocally determined to making us happy.

· Even with the short time allowed for the project, they brought to our attention errors in the source materials and they addressed what they considered pre-existing translation issues.

· Their end of the conference calls was noisy to the point of distracting. Several of them in a meeting room with poor acoustics talking into a cheap speakerphone made for frustrating encounters twice a week, regardless of whose bridge we used. The project succeeded in spite of it, but it struck me as a poor choice of places to save money.

· It became apparent that they were cutting corners in ways that experienced LSPs don’t bother trying to cut them (rogue copy of TM software; use of a shareware help compiler on a project that depended on features unique to RoboHelp; testing on Windows MUI instead of native localized OS). I can overlook some things like this, but I’d rather not have to.

Our client had already localized this product into Korean over several versions for a number of years, qualifying it as a sustaining effort. Vendors in China and India have done a brisk business in sustaining engineering, especially for large IT companies with legacy code bases. Naturally, they are turning the corner towards new product engineering, which, like localizing a product for the first time, demands more of the relationship between client and vendor.

Recommendation: If your team is sufficiently aware of what it takes to localize your product, and has a history of successful localization, then testing the waters with a Chinese or Indian vendor in 2008 should be among your options. If your organization is new to localization or must entrust the process to someone who is, this might prove rash. In no event, however, should you simply find the lowest price, lob your product over the partition and hope for the best.

If you enjoyed this post, please read the related article, "Offshoring and localization projects, Part I."

Labels: , , ,