Wordcount Woes - Part 2

If you're working client-side, how many words have you paid for that translators didn't even need to touch?

I posted a couple of weeks ago on translatable words that vendors may miss in analyzing files. Alert reader arithmandar commented that slide decks can be even worse, if there is a lot of verbiage on the master slide that does not get easily captured (although Trados finds these words, according to him/her). Flash is another story altogether, and arithmandar's recommendation is that a Flash engineer should probably perform the analysis.

The other side of the coin is also unpleasant, but for the other party: Clients can hand off vast expanses of words that nobody will translate, artificially inflating the wordcount and estimate.

• Code samples - If your documentation contains examples of code used in your product (e.g., in an API reference), there is no point in having that included in the wordcount, because nobody translates code.
  
• XML/HTML/DITA/Doxygen tags - I hope your vendor is parsing these files to ignore text (especially href text) in the tags. Otherwise, not only will you get back pages that won't work worth a darn, but you'll also be charged for the words.
  
• Legal language - Some companies want their license agreements, trademark/copyright statements, and other legal pages left untranslated. (Usually these are American companies.)
  
• Directives - Certain directives and warnings apply to certain countries only. The documentation for computer monitors and medical devices often contains a few pages of such directives, which appear in the language of the country requiring them. There is usually set language for these directives, so free translation is not appreciated; have your colleagues in Compliance obtain the language for you, paste it in yourself, and point it out to your vendor.
  

Mind you, there are costs associated with finding and removing all of these words: Do you want to spend time extracting the words? Do you want to hire somebody to find and extract them? Will your savings offset those costs?

If the words to be ignored add up to enough money - as they often do for a couple of our clients - pull them all into a text file and send them to your vendor with instructions to align them against themselves for all languages in the translation memory database. That way, when the vendor analyzes your files, the untranslatable words will fall out at 100% matches.

Do you have ideas on how to handle such text?

Localizing multimedia (Flash, QuickTime) - Part 4

Oops! What about the broadcasters?

Sometimes you're localizing a commercial or a product demo intended for viewing over broadcast (think Home Shopping Network) or at the point of sale (think sports equipment demo). The localized Flash or QuickTime files that you poured into .flv or .swf format are of no help here, because someone has the intention of pushing a tape into a machine in a broadcast operations center or sliding a DVD into a player in a department store.

As usual, your client may take for granted that you understand this, and be dismayed when the right physical media doesn't show up. One client had no clear directions for us in this regard, and we've since learned that the question we need to ask is, "How will the localized multimedia be viewed?" or "Do you want a playable DVD for this?"

The project was rushed, and it was all we could do to determine ahead of time the proper specifications for the Web-based deliverable (described in the Part 3 post). They instructed us in the easy matters - "We need Italian, Spanish and German" - but we never did get a solid answer about physical media, so at the end of localization I asked the studio to bundle up these assets:

• the original, uncompressed audio/video footage (about 7GB)
• .mov files with each of the localized subtitles only (no audio/video; about 400MB each)
  
• the translated scripts
• the .flv files we'd used as previews for publishing over the Web

We didn't really know exactly what the client's in-country partners and customers would need - and were convinced it would take the client a long time to tell us - so we gave them a set of data files that would not paint them into a corner. That seemed better than our guessing at the ultimate use for these, and getting it wrong.

Sure enough, two weeks later they phoned. "Why doesn't the Italian version play when I put in the DVD?" the client wanted to know. I explained that the client would first have to determine exactly the format in which each country wanted the DVD, then have a studio build a playable DVD from the files we'd handed off. This last step would not require a studio with localization expertise and could probably be executed less expensively by the people who had created the original English-language media.

There was also some confusion about regional codes, which ended up relating only to piracy prevention. Since nobody was worried about illicit duplication of the media, that issue went away.

The moral: Ask all the questions ahead of time. Then ask at least one more.

Do you have that "one more question" you wish you'd asked ahead of time? Post it in a comment.

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.

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.

Localizing multimedia (Flash, QuickTime) - Part 1

Localizing multimedia such as Flash files and QuickTime movies is a different pond of koi from localizing documentation, HTML and even software. Advertisements, videos and clips abound on the Web, mostly because they tell a story in a much more compelling way than does mere text. Also, it's becoming easier for content owners to record footage and to host it on their Web site.

It's a brave, new content world. And they want to localize it.

The first hurdle is that the media is not very well internationalized. The movie file on the Web is usually greatly compressed, with several layers crunched into one or two, and billions of bits discarded. Nobody needs all of that detail to see the clip, but you need it to localize it properly.

The second issue is that site owners rarely understand how the original was put together, let alone what it will take to localize it. They may know about superless splits, B-rolls, dub houses, producers and BetaSP, but you trying to get files - extremely large ones - from them, with all of the video, audio, graphics and effects to localize.

Finally, in the same way that most companies regard a software project in its original language, the content owners view the multimedia as core work product that is already behind them, and wonder why there's so much work/time/money involved in preparing it for an overseas audience.

Despite these hurdles, content owners do indeed want to go down this path. In Part 2, we'll explore a typical project in more detail.