Changing Your Vendor - Not as Easy as Changing Your Shirt

"Say, a salesman from a translation company has been after me for the last few months, and he wants some business from us. Shall we look into changing vendors?"

What's your first answer to this question?

When I'm not in the market to change vendors and I observe that it's not appropriate to go into the matter too deeply, I usually pull one of several quick answers out of my drawer and use it:

• "No."
• "Sure, we can include the vendor in the next request for proposal."
• "Forward him to me and I'll find out more."

I have nothing to fear by looking into a new vendor, of course, except that things that aren't broken now, could get broken with a different vendor, and who wants to trade the devil you know for the devil you don't know?

Last week one of my clients asked me the question about changing vendors. Sensing there was time for a little bit of education, I let her be the expert by suggesting a short true-or-false quiz:

True or False:

1. You're convinced that your current vendor is much too expensive. ("much" is an important word here.)
2. Our engineers and your other service providers, like the Web team, cannot work with the current vendor.
3. Your in-country offices are complaining loudly about the current translation work.
4. Your customers overseas are complaining about the current translation work.
5. You hate the vendor for some other reason, and dread working with it.
6. You're not inclined to let me to fix the problem.
   

I recommended that, if she scores 2 or more True, we can look into peeling off one of the languages and trying the new vendor. If she scores 1 True, we should have a chat with the current vendor and work something out.

If she scores 0 True, she is in the localization minority and should count her blessings early and often.

I also mentioned that a switch of almost any magnitude will involve a lot of re-plumbing and education. In my experience, the current vendor is charging a fair price for good, steady, reliable work, and is making my client look good (or at least, not embarrassing her). OTOH, if she really wants to make a switch, we should select a time of relatively low volume and a project/language of relatively low risk to do so.

What do you think about changing vendors? I often see problems in the chemistry with project managers. That's an easy change to make, probably easier than most people realize. But don't discard the vendor just because you don't get along with the project manager; they have others, and if they want to keep your business, they'll help you switch.

Putting More "Sim" in your "SimShip"

How are you doing on your simultaneous shipment ("simship")? This is a common term in the industry that refers to releasing your domestic and localized products at the same time. Is your organization getting closer to simship? It shouldn't be getting further from it.

What measures have you put in place to reduce your time to market for localized versions? It's never easy to pry finalized content from writers and engineers in time to have it translated, but that's the dragon that most of us have to slay, so we focus on it a lot. How can we peel off content and get the translation process started sooner?

In the same way that eating lightly 5 times a day keeps you from getting really hungry and eating voraciously 3 times a day, we've found that handing off smaller bits of content even before they're finished keeps us from having to panic when somebody calls for a localized version.

We manage projects for a client who has the advantages of lots of sub-releases (3.1.2, 3.1.3, 3.1.5) between main releases (3.1, 3.2), and few overseas customers who want the sub-releases. (They also have the disadvantage of lacking a content management system that would make this much easier.) Even if your situation is not an exact match, you'll find that some principles apply anyway.

• The biggest nut in the product is a 3500-page API reference guide in HTML. (Most products have a big, fat component that dwarfs all of the others.)
• One month before each release, we assume that any new pages are about 95% final, so we hand them off for translation.
• By the release date, we know whether we need to release a localized version of the entire product or not. If so, we proceed to hand off all of the rest of the product for translation, knowing that there will be some re-work of the new pages handed off a month before; if not, we hand off only the changed pages.
• Thus, we almost always have pages from the API reference guide in translation. If we need them for a release, we have a lot of momentum already; if we don't need them for a release, we put the translations into our back pocket and wait until it's time for the next localized version.
  

This costs some more money than normal because of the inevitable re-translation that goes on, not to mention the hours refreshing the localization kit, and preparing files for translators. But this cost is acceptably low compared to the look of anguish on the international product manager's face when we have to say, "It will take about three months to finish the Korean version because of all of the change since we last localized it."

We also need to assume that, sooner or later, there will be a request for the product in certain languages. If business conditions change and the new translations never see release, then the effort has been wasted for those languages, but that's a normal business risk.

I Don't Want to Localize That, And You Can't Make Me

Ever hear your children make similar utterances, except with different predicates ("go to bed," "clean my room," "do my chores")?

One of our clients is staffed with people too polite to say things quite so bluntly (but not too polite to dig in their heels similarly). The upside is that I enjoy working with almost everybody I've ever encountered there; the downside is that there are some places where their global-readiness is stuck.

Web presence
I bend over backwards to uphold a simple rule of Web navigation: Localize everything along the click-path to a visitor's goal. So, if a visitor starts on a Russian home page, and decides she wants to download a Russian version of the trial product, I believe in ensuring that she doesn't have to put up with English on her way through the site, unless she wants to do so. Or, if we need to push her to an English page, I try to make it apparent with "English only" next to the link.

We've made a lot of progress in combing out the remnants of English that dot many localized sites (that makes my skin crawl - how about you?), so that each page is linguistically pure to several levels. That was expensive and it took a lot of time.

The problem now is that this client's site relies on a lot of plumbing for verifying that the visitor is not from an axis-of-evil country, or hacking the site, or trying to perform unsupported operations, and the UI for all of this infrastructure is in English. Much of it is just background code, but several pages (login, registration) are in English, and the infrastructure team is not interested in localizing any of it, despite my polite persistence.

License agreement
This is a hot one. When you download trial software from Germany or Finland, do you click "I accept" to a license agreement in that language? Granted, German and Finnish are not the lingua franca that English is, but how much more does it say about the relationship you want to have with your customers when you make some effort to inform them of your business terms in their language?

"We don't translate anything legal, and it's not hurting sales," I keep hearing. This is a battle I know I'll never win, so I look for victories elsewhere.

Site logic
There was a sudden need some months ago to place a terms and conditions page in the click-path to a particular download. Naturally, the terms and conditions were in English only, and I could have lived with that. The problem is that the code behind the page sent the visitor to a particular next page, without regard for where the visitor was going when he landed on the terms and conditions page.

So, visitors on the way to download the Korean/Japanese/Chinese/Spanish... version of the product sailed along the click-path in their own language until reaching the terms and conditions page. Then they agreed to text they almost certainly did not read, then they landed on a completely irrelevant page of English, with no reasonable way of getting back to their intended destination.

This is related to the inflexible plumbing I mentioned above. It's great infrastructure; it's just monolingual and it doesn't really need to be.


Anyway, these bits of stubbornness amount to a small downside in a client that is not stingy about localization in general and that has a strong global presence. They're correct when they say, "I don't want to localize that, and you can't make me," so it's easier to roll with the punches and enjoy other victories.

Besides, if I'm around long enough, they'll move on and I can take the matter up with their successors.

What things have people told you they're not going to localize, and you can't make them?

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.