Localization Project Management Log

On FierceDeveloper, David Marino, the CFO and co-founder of Hidden Variable Studios, has written an article on localizing mobile apps.

It’s not the same kettle of fish as localizing a console game, let alone a software package, as David describes:

Coming from a console background, localizing games was the norm, but even a cursory glance at the App Store and Android Markets will tell you that this isn’t the case on mobile platforms. Only the giant companies of the world– Disney, Electronic Arts and Zynga–bother to localize their games significantly.

Still, there are good reasons for localizing any app, and David would be a lousy CFO if he hadn’t researched them:

According to the U.S. State Department, [localization] does [lead to increased sales]. They estimate that U.S. firms alone lose $50 billion in potential sales each year because of problems with translation and localization. If you want your game or company to move beyond being a local product, you need to think global, and if you want your product to compete successfully with other native products, you need to localize it.

We certainly are pleased when people in the C-suite – especially in the CF-suite – think and write things like that.

Have a look at the rest of David’s article on localizing mobile apps, and use it to bolster that localization business case you’re making.

John White of venTAJA Marketing is a localization project manager and consultant. He is also a marketing communications writer for technology and language companies.

How specific do you want to be about the language of your terms and conditions?

Suppose you have your copyright information or software license translated or localized into a variety of languages, and somebody exploits a mistake or misunderstanding or mistranslation. How do you cover yourself?

Here’s an example from the Terms and Conditions for Carbonite, a provider of online backup:

English Language

These Terms and Conditions of Use were negotiated and written in English. Any inconsistency between the Terms and Conditions of Use as expressed in English and any other language shall, to the full extent permitted by applicable law, be resolved by reference to the English version. Les parties ont convenu de rediger cette entente en anglais.

Is this a good way to leave yourself an out? Carbonite’s attorneys and management must think so. Ask yours.

John White of venTAJA Marketing is a localization project manager and consultant.

photo credit: tracie7779

Most people don’t understand localization. We can use this to our advantage.

Last week I had a kickoff meeting with a new client to manage their localization project. From previous discussions with them I had a pretty clear idea of how to start the project, what I would need from other people (engineers, QA team, in-country reviewers), and what was still unknown to all of us.

I did what any sensible project manager would do before a meeting: I wrote up an agenda.

It knocked their socks off.

“Wow! Who wrote this up?” asked the program manager.

“You’ve thought about this a lot more than we have,” admitted the product manager and engineering lead.

I merely smiled, pleased to see that they were pleased, but secretly wondering whether I’d made it look too easy. “Probably not,” I told myself. “This is the black magic for which they’ve hired me. They’re paying for this level of service and forethought.”

So, what did I put into the agenda that inspired this praise, and how can you do the same?

1. Process Overview. Assume that you’ll be working with smart, engineering-grounded, methodical people on the project, so spell out a smart, engineering-grounded method of localizing anything in general and their product in particular. They want to see the plan, and poke and prod at it a bit.
2. Who’s Doing What? Most of the time, of course, you’re going to be the main – maybe only – lightning rod on the project, but you can’t do everything. Tell Engineering at which point in the project you’ll need new builds and how much of their time you think it will take. Let QA know how the project will affect them and which test suites they’ll need to modify. Ask upper management or sales to choose  in-country contacts who can review glossaries and help find beta testers. Make sure everybody knows you plan to be the anchor on the project.
3. Open Questions. What don’t you know yet? Ask about resource freezes, file formats, weekly meetings, logins for offsite testers, schedules, and what status reports they expect of you. Most of all, talk about expected release dates for the localized versions; they’re almost certainly unrealistic, so the sooner you burst that bubble, the better.

If you take your colleagues by (pleasant) surprise early on, you can publish your high expectations for how the entire project will go.

 

It Helps to Have a Buddy
In the RipStik How-to-Ride video, the narrator recommends having a friend help you steady yourself when first you mount. This I would gladly have done, but my sons and nephews were too busy laughing at how ridiculous I looked to stop and help me.

Talk to localization professionals in other companies about their experience in simship. If you don’t know any, find some on LinkedIn, or lob a question about simship into Multilingual Communications (see “Blogos” link to the right). Don’t rely on your vendor for this; they’re in the back seat and you’re the one behind the wheel.

You Won’t Truly Know Whether Your Organization Is Up To It Until You Commit
I have no idea what possessed me to ask my nephew whether I could try his RipStik, but as I stood over it wondering how to operate it, I realized it wasn’t going to reveal its secrets until I’d made the first move…and the second and the third and so on.

You may be able to gauge your company’s commitment to simship by asking people, but you don’t know whether the process is truly possible until you’ve been through it. You, as localization manager, will of course shoulder most of the burden, but there are plenty of things you’ll need from other people, and only by doing it can you see how close to or far from the goal you’ve landed.

Quantify Your Goals
I challenged myself to get to the corner and back on the RipStik, but I forgot to specify the amount of time I was willing to spend on it. Not much of a goal.

When you launch the project, specify “simultaneous:” source plus 15 days, source plus 30 days, same day for source plus two languages then 30 days for the remaining languages, etc. It makes success appear more probable to all of the other players whose support you’ll need.

So, hop onto your RipStik and give simship a try, but keep in mind one important dissimilarity between these two endeavors: I’ve realized that, like many activities that involve balance, it’s best if you keep your head up and focus on your progress, but not on how you’re making your progress. In simship, that’s a luxury reserved for upper management. You need to keep tabs on everything all the time.

Sooner or later, someone may ask you, “We’ve got a new release coming up. Why don’t you give us a presentation on what you’ll need to localize it properly?”

After you’ve recovered from the shock, will you have a ready answer?

I received this request last week from one client, and turned it into an invitation to present at the regular meeting for all of the leads – software, Web, documentation, project management, QA, release – and some people in upper management. It’s meant to be a very brief (10-15 minutes) presentation, which felt like a limitation at first, but which now strikes me as an advantage because it will help me focus better.

They’ve stapled me to a slide presentation, and I made the most of it.

• Slide 1: Hello! I’m the Localization Guy and I live to pester people. (Maybe I don’t say it in quite that manner…)
• Slide 2: Scope of Work – These are the software, Web and documentation bits we’ll need to localize, and the parts that are already in TM.
• Slide 3: Timing of Work – Let’s hand off anything we can as soon as it’s stable, even if the localized releases aren’t for several months yet.
• Slide 4: Help Wanted – Here are areas of the project outside of my control, where a little localization-mindfulness will save some time, money and headaches. This includes tagging XML files for text that should not be translated, handing me early software builds for internationalization testing, and thinking about the stable files we can hand off ahead of product release.

I think this will suit their desire for information. They don’t want to know the details of how I do what I do, but I want them to know what I need from them.

You too should have a presentation like this in your desk drawer or on your hard drive. Just in case they ask.

“There are still a zillion people who don’t know about localization,” the sales representative of the localization company told me. “Can you believe it? After all these years?”

Yes, I suppose I can. We can make sales calls and deliver presentations on the most efficient ways to localize until we’re all ready to retire, and there will still be executives, companies and entire industries that haven’t gotten the memo.

It’s refreshing in some ways, and it keeps us from getting lazy. It reminds me of the ISDN craze around Internet access back in the mid-1990′s, before cable and DSL made our choices simple (at least in the USA).

ISDN, or Integrated Services Digital Network, was a high-speed alternative to dial-up, but the phone companies were not very successful in taking the service from the early adopters to the early majority. The acronym became redefined as “I still don’t know,” because most people couldn’t understand the service well enough (or afford it, for that matter) to see how it would benefit them.

The upside: There are still, and will be for a long time, opportunities to sell translation and localization services. As soon as all of our customers know about localizing products and how to do it efficiently, they’ll turn to The Next Thing, such as John Yunker’s Web Globalization Report Card threshold of localizing the Web site into 20 languages. We won’t run out of work, provided we stay a few steps ahead of our customers’ requests.

The downside: We may spend a little less time educating new clients, but we’re not completely out of the hand-holding business yet. Salespeople will still need to update their presentations and drag an engineer or project manager to that second-round meeting with the prospective client.

Just be sure to stay on top of localization developments and techniques so that you don’t have to answer a prospect’s question with “ISDN” (I still don’t know).

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?

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.

[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.”

If you have not yet tested the waters of offshore LSPs, consider making 2008 the year in which you take the plunge. You know you are going to do it sooner or later, and if you don’t, your successor will, so you may as well learn the lesson for yourself.

In 2007, one of our clients embarked on a localization project with a Chinese vendor. This brought me, in my role as consulting localization project manager on the client’s side, onto the leading edge of the project. Misgivings? Yes, I had a few:

· The company had no visible qualifications as a localization vendor, though they had devoted lots of Web space and marketing to testing, data analysis, application development, sustaining engineering, payroll processing, helpdesk and data mining. How can you be very good at anything when you specialize in everything?

· Against the same request for proposal, the company’s bid on the project was about 25% lower than that of two other Western LSPs. It didn’t help that they misread the RFP and omitted a big chunk of work, but even if they’d included it, they would still have been 15-20% below the other vendors. What kind of quality would we get for a price that low?

· The target language was Korean, not Chinese, which meant that, as low a price per word as they were offering me, some vendor in Korea was almost certainly offering them an even lower one. What caliber of linguistic talent could we expect?

· Our client imposed a project deadline bordering on the preposterous, which annihilated precious time I wanted the vendor to devote to editing and QA. Midway through the project the deadline changed to allow some more time, but it had already introduced a great deal of stress.

· The lingua franca of the project was English (because I don’t speak Chinese). While the vendor’s efforts were valiant, their English was weak, and I foresaw this as a problem even before we had awarded the project.

· Replete as the Western news media were in 2007 with recalls on Chinese toothpaste, toys, cots, tires, medicine, pet food and other products, it was easy to tar this company/industry with the same brush and worry about their level of quality assurance.

Despite these carefully articulated misgivings, our client’s decision-makers had already made up their mind (and corporate direction) to award the project to the Chinese vendor. So, since it was my charter to make it work, we built checkpoints into the project to detect problems as soon as they arose.

I’ll describe these checkpoints and the upshot of the project in next week’s post.

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