Localization Project Management Log

I said it a few months ago and I’ll say it again: Nobody needs Lua resource files.

Just when CAT tools, parsers and SaaS implementations give us new features and functionality to simplify life for translators, new formats like this creep up to bite us. This is particularly true in mobile apps, since that is the new frontier in software development.

So when a mobile apps client decided to change the format for resource files from XML to a roll-your-own format designed for the Lua scripting language, I foresaw difficulties between unsophisticated translators and the format and advised the engineers on a plugin that would smooth the process of getting translatable strings into a format translators could use.

The client hasn’t yet released the plugin for its development platform, but it’s coming shortly. It takes this:

ModRsc {
--
 name  ="IDS_EXITCONFIRM_HDRSTR",
 id    =1800,
 type  = 1,
 data  =EncStringRscData(0x03, "Exit Application?"),
}
ModRsc {
--
 name  ="IDS_EXITCOFIRM_BODYTXT",
 id    = 1801,
 type  = 1,
 data  =EncStringRscData(0xff, "Are you sure you want to exit?"),
}
ModRsc {
--
 name  ="IDS_PRIVACY_POLICY",
 id    = 1802,
 type  = 1,
 data  =EncStringRscData(0x03, "Privacy Policy"),
}
ModRsc {
--
 name  ="IDS_RATINGSINFO_HDR",
 id    = 1807,
 type  = 1,
 data  =EncStringRscData(0xff, "Ratings Info"),
}
ModRsc {
--
 name  ="IDS_THANKYOUFREE_TXT",
 id    = 1808,
 type  = 1,
 data  =EncStringRscData(0xff, "Thanks for your download!"),
}

- which you really don’t want to hand off to a translator and which could be parsed if an engineer wrote a good enough regular expression for it – and turns it into this:

Not a very big deal for five strings, but quite a time-saver once you reach 50, 100, 200 strings.

You hand this .xlsx file off to translators, they translate into column D, they send it back to you, and the plugin takes the translation and round-trips it into the Lua resource format. That’s a great deal more accessible to translators, and it’s important to make them happy; otherwise, they can’t localize your software.

So, why am I still not content?

I’m not content because it takes a lot of software to perform this conversion:

• Microsoft Visual Studio
• Visual Studio Office Runtime
• software development kit for this mobile app platform
• .NET Framework

You may find these on the computers of software developers, but not likely on the computers of most of the people who would normally be tasked with handing off strings to translators: program managers, QA leads, tech writers, even localization project managers. And few translators would invest in all of this, let alone be interested in configuring it as needed.

Still, it’s inherent to the beast. Since this industry began, tools have been tying the Gordian knot between the necessary complexity of making text display in software and the necessary simplicity of letting translators perform their work.

If there were a solution located right in the middle of these two extremes, we’d have come up with it by now.

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

photo credit: David Kitching / CC BY-SA 2.0

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.

Your prospect says, “How do I know that you can really do a good job localizing my product?”

Well, how are you going to convince him?

I’m writing a paper for a small localization vendor right now, and we’re coming up against that issue. The vendor has identified a prospect in a specific vertical industry – real estate development – that needs to get its translation act together, but the prospect is new to translation. And when humans don’t know very much about a new product or service they need to buy, they tend to look for high-level things in common with vendors: common friends, common industries, common schools, common playgroups.

So the prospect will be comfortable if it can see the names of some big, flashy players in the real estate vertical for whom the vendor has done work. Unfortunately, the vendor does not have those names on its client list.

The vendor does, however, have a long track record of solving exactly the kinds of workflow and translation quality problems that afflict this particular prospect. Still, the prospect wants the warm fuzzies that come from knowing somebody else in its industry has been through this with this vendor before.

We’re hoping that the paper will – in plain language – distract the prospect from the name-game and get it to focus on the fact that its hair is on fire, and demonstrate that the vendor has the workflow, the technology and the global reach it will take to fix the prospect’s translation problems. (It also has the translation expertise, and we’re going to mention that as well, even though we in the industry know that just about every vendor can reach just about every translator.)

Think about your sales presentations, your marketing collateral and the content on your Web site. Do you bother to tell a different story from one industry to the next? How do they differ? Do prospects accept it, or are you still losing projects because you don’t have the names?

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.

The experienced project manager with your localization/translation vendor approaches a new client/project by asking you, “Has this ever been translated before?” Her big goal is to discover whether there’s a translation memory database floating around, to help her translators do their work more quickly and keep your costs low, and her background goal is to find existing documents with key terms already translated and approved.

Smart companies maintain these key terms in a “glossary” or terminology list. Glossaries are far less comprehensive than translation memory because they serve a slightly different purpose: Instead of proposing a fuzzy-match translation for an entire sentence, they serve as a reference for the translators. Good translators know how to find translations for generally accepted terms like “closed-loop servomechanism” and “high-definition multimedia interface,” but if the sales manager in your Shanghai office has already told you how he likes to see the word translated, everybody will be happier if that preference is observed.

So where do your glossaries live?

“Live” is the important word, because glossaries change and grow with time. Most glossaries I’ve seen are in a spreadsheet or word processing document. While that’s better than nothing, it can suffer from decentralization, since updates don’t always make it to everybody involved in the project, and some translators run the risk of using old terminology.

One of my more localization-savvy clients makes its glossary available on its partner portal, requiring a login and password. The php-based application, which is actually hosted by a translation vendor, allows searching in multiple languages. My client deliberately does not make the glossary available for download or export; this ensures that everybody is using the same version with all updates.

I like this model. The assets reside on the client/owner’s site, and the terminology “lives” with the linguistic experts, who can easily modify it. It’s a bit more work for the translator, who would rather have a flat-file document, but overall it serves linguistic interests well. It’s tried-and-true technology built in to most computer-aided translation tools.

What are you doing with your glossaries?

Have you ever gone to the extent of developing acceptance criteria for a localization vendor’s deliverables? Beyond that, have you ever sent a vendor an acceptance letter summarizing these criteria, and grading the vendor on each point?

After years of my simple handshake-and-phone-call approach to acceptance, one of my enterprise clients asked me to develop and communicate these criteria formally. It didn’t require too much effort, since I knew what I had liked and disliked about the vendor’s performance all along. Here are the points I drafted:

PERFORMANCE

• Responsiveness: You attended all conference calls and apprised me in a timely manner if you were unable to attend. You responded to e-mail very quickly.
• Delays, schedule: You reported only a couple of delays on the project, none of which was more than two workdays in length. In the main, you maintained your schedule day to day and week to week.
• Weekly reports: Your weekly reports were punctual and informative. They helped me to communicate accurately the status of the project to other members of the team at BigCorp.
• Issues, questions: Your process for moving the translators’ questions and my answers back and forth was simple but adequate.

TRANSLATION

• Quality: Preliminary reports show that our customers were satisfied by the translation work.
• Bug fixes: You incorporated feedback from the reviewers and me as we requested.

DELIVERABLES

• On-time delivery: You delivered all files to us in a timely manner. You delivered the final files 2-4 calendar days ahead of the final deadline.
• Project files: After giving us the main deliverables on time, you performed housekeeping on the supporting files and delivered them to us.

Frankly, I left out a few things, like the fact that conference calls were arduous because of their phone system, and the rather attention-getting directory that appeared on our FTP site one morning labeled “Trados_crack”. But the point of the message is to convey acceptance, and it serves that purpose well.

Did I leave anything out? Let me know.

Changing localization vendors can be stressful. It’s an entire “getting to know you” process you would rather avoid, but sometimes you have no choice. Like having wisdom teeth removed.

Here are some points for evaluating the fit of your new vendor.

On the downside:

1. Are there truncated strings in the software they send you? They should have reviewed these and should not send you software with such an easy problem to resolve.
2. Do they speak and write good English? Conference calls with people who don’t (or won’t) speak English are frustrating and unproductive.
3. Are there any “oops” moments early in the project? One new vendor focused on my detailed description of the changes in a document, and assumed that they were the only difference in the new version. They had overlooked 8,000 words in new files I had handed off in the localization kit. Oops.
4. Are you customers (internal or external) satisfied with the quality of the translation from the new vendor? If not, you need to address this in a hurry. I pointedly asked our Korean office what they thought of the quality of the new translations compared to the old, and they replied, “The quality seems to be about the same as before.” Perhaps a bit less than eloquent praise, but it was important for me to know.

On the upside:

1. Are they finding mistakes in the original English version and sending them to you? Sometimes these take the form of “This sentence seems corrupted, please explain.” If you have the bandwidth and patience for it, you’ll see that these are actually prefabricated bug reports that cost you almost nothing to submit, with the benefit of improving your product (especially the documentation, which is where most such problems lie).
2. Are they helping you think about long-term improvements to your international product process? Vendors are in a position to suggest internationalization (I18n) techniques for your product that will prevent you from maintaining several code bases, for example. Does the new vendor have the perspective and degree of experience to tell you, “You know, if you make each of the control labels the size of your largest language, you can use the same dimensions universally, and we don’t have to charge you so much for resizing them each time.”
3. Are they cleaning up pre-existing messes? Old messes die hard, and you can be sure that your translation memory databases have plenty of them. A new vendor comes to them with a fresh perspective and can help you clean them up, especially if it helps them to do their work better.

The more experience you have with new vendors, the bigger your own list of evaluation points will be. The sooner you deal with them, the less trouble your project will be for you and for the vendor.

Like wisdom teeth.

Take this short True-or-False quiz:

1) You think your localization company is much too expensive.
2) Your other contractors or in-house teams cannot work with your localization company.
3) Your in-country offices are complaining about the translation.
4) Your overseas customers are complaining about the translation.

If you scored 2 or more True, you might look into peeling off a language and trying a new vendor out. If you scored 1 True, you should have a chat with your vendor and work out the problem. If you scored 0 True, you are in the localization minority and should count your blessings.

Making a vendor switch involves a lot of re-plumbing and re-education. If your vendor is charging a fair price for good, steady, reliable work, and they’re making you look good (or at least, they’re not embarrassing you), there’s plenty to be said for that.

Keep in mind also that this is a relationship. The vendor won’t necessarily get it right the first time–neither will you–but if they show improvement, and they’re willing to work with you on making things better, you have the beginning of a beautiful friendship.

Do you know the difference between localizing and internationalizing? Most people can go their entire lives without knowing it, but there is a useful distinction.

You localize your product when you customize it to the needs of a particular market, usually on geographic and linguistic bounds. So if you’re Toyota, and you want to sell cars in California, you need to equip them with the more robust emission control systems required by law there. Or, if you want to sell them in UK, you need to build them with the steering wheel on the right-hand side.

What you soon discover, though, is that it’s prohibitively expensive to create and maintain separate production lines for California, UK and other foreign markets, not to mention your domestic market. The challenge then becomes to properly internationalize your product so that the changes needed for each market cause as little disruption as possible to your production process. You design your cars so that there is some irreducible core that is the same, no matter where the car will be sold.

This is easier said than done, but in a technology company, where production lines move extremely fast – because it’s all just software – it’s important to bite the internationalization bullet early and often. The alternatives are multiple, straggler code lines; separate Web sites; and unintegrated, unwieldy sets of documentation.

So, when all about you are losing their heads over localization (L10n), you can be the calm voice of reason, asking whether the product is really ready for localization yet, or whether your colleagues should pause and think internationalization (I18n) first.

(Note: The term g l o b a l i z a t i o n is also used to describe the overall process of creating products for worldwide markets. The problem, in our search-engine-optimized day and age, is that the same term applies to the assimilation of national character and identity into the worldwide market, with undesirable ramifications to the disenfranchised. It’s not wrong to talk about g l o b a l i z i n g your product, but if you go searching for information on localization, don’t use the g-word.)