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

Translations for Facebook Connect is a new program FB has implemented to get its user interface translated into other languages, according to a write-up in the New York Times by Brad Stone.

Google has been known to do this with machine translation, using technology to automatically translate Web sites and text. FB’s approach will differ, in that:

The translation tool works by asking users to submit possible translations of phrases, and then soliciting their votes on which is the most accurate.

Facebook can get away with this for a few reasons:

• It has the traffic. Large numbers of visitors will yield large numbers of willing translators.
• The traffic is social-minded, instead of hunched over in research mode. Most people spending time on Facebook are in helpful/social mode, instead of trying to get work done. They’ll take the time to work on this and consider it another dimension of customer engagement.
• It has figured out that the best translation is the one the customer wants – or in this case, the largest number of customers wants – so it’s going to give it to them.

It’s open-source translation, after a fashion, which is not that different from open-source software coding, except that the translator community raises a hue and cry when somebody tries to take away potentially paying work, whereas software developers just do it for the crack and to make a better product.

Localization by vote could even help clean up some of the Microsoft-imposed software idiom that users (and translators) in several countries have complained about for years. Your chance to get this vocabulary back on track.

What do you think? Would you help Facebook out?

Have you had to localize mobile applications yet? What’s your favorite part?

They’re a breed apart, these mobile app developers. The familiar model of handing off pure resource files, localizing them, then building them back into the executable doesn’t appeal to them somehow, at least not in my experience.

They are fond of pulling the strings out of resource files, placing them in a spreadsheet with copious comments, and asking us to put the translations in Column B. It doesn’t matter much to the localizers, but I think it results in more work for the developers.

These projects put the translators at something of a disadvantage in other ways:

• In the ancient days of static, 80-character line lengths, translators often had to ensure that their strings contained no more characters than the original text. Mobile applications are similarly starved for UI real estate, but this time, length is measured more often in pixels than in characters, a metric difficult for most translators to work with.
• There is still no context for a translator working on a batch of UI strings. What’s worse now is that the text in many mobile apps is sparse to begin with, and it’s rare that the translator can run the app to get the context for strings like “Up” and “Done”. We pester our clients to provide screenshots, functionality descriptions, requirements documents, and anything else to help the translators.
• The studio isn’t easy to work with yet. With PC-based applications, localizers figured out how to build and test resource DLLs themselves to shorten the L10n QA cycle, instead of bugging clients’ engineering teams all the time. It will be a while before localizers adopt the studios and toolkits used by mobile app developers, because there are lots of them.
• Phones and mobile devices are in scant supply, and the localization process is at the bottom of the food chain. How can the localizer perform proper L10n testing on the device, when the client only has one phone – or none at all – and everybody else needs to use it? (Shameless plug: Our client NSTL performs L10n testing for situations like these.)

We’ve done several mobile app projects for a couple of clients since 2002. They’re rather labor-intensive – especially before and after the localizer gets involved – and it always feels like making a watch: lots of small parts, small tolerances and high demands.

How do you get along with mobile app localization?

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?

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?

What’s the most effective way to bump up your translation costs unnecessarily?

Probably by localizing something that nobody will ever want in a foreign language, of course. But nobody would ever approve an expense like that, so it wouldn’t have the opportunity to affect your translation costs.

There’s a much sneakier, more pernicious way of wasting translation money: Tinkering with the original text (for example, English).

Suppose you localized your product or documentation from 2002 through 2007. You’d have five years’ worth of translation memory (TM) economies and glossary entries going for you, with thousands of exactly matched words that incurred no translation cost from one version to the next. Then suppose that someone decided in 2008 to go in and “clean up” the original English text to make it more “readable” or “user-friendly.”

What do you think would happen the next time you handed off this content for TM analysis? Suddenly, non-matches would pop up where exact matches used to be. Among the causes:

• Combining short sentences together
• Breaking long sentences apart
• Making stylistic changes to common terms (e.g., changing “phone” to “telephone” or “handset”)
• Standardizing disparate terms (e.g., selecting one of “Proceed as follows,” “Perform the following steps,” “Following is the required procedure” and propagating throughout the documentation)
• Typographical or grammatical corrections

You might tolerate these modifications in the interest of improving your product in all languages – not just English – but the sad truth is that you may find that they make no difference in the localized products. You’d pay for words that the translator did not need to touch. This is an unfortunate artifact of the way in which translation jobs are estimated, but the analysis software cannot predict that the changes will make no difference to the translation; only the translator sees that.

Note that re-organizing content should not cost you additional translation money; as long as the sentence is the same (i.e., an exact match), it doesn’t matter where it’s located in the product.

So, are you better off leaving errors and other undesirables in your original-language content? No. It would be a mistake to let concern for translation cost impede your product improvement effort, like having the tail wag the dog. Still, to the extent you can control it, you should try to avoid purely stylistic changes that make no difference in how your customers use your product. A good editor can make a hundred such changes per hour, not realizing the ramifications on translation costs.

If you learned something from this post, you might like to read Improved Docs through Localization or Getting the Writers to Care about Localized Documents.

“Why don’t we have our Web site localized?” my business partner asked. “We’re in the business, and a localized site would show that we’re willing to put our money where our mouth is.”

Excellent question. Why not get our site, or at least the pages that pertain to localization, localized? So I looked into it.

It was going to cost about US$2000 per language, when all was said and done, so I asked my partner if he’d be willing to split the cost with me. Perhaps you can guess his answer.

It was an interesting issue, though. Assume that a prospective customer, who doesn’t know much about the industry, goes shopping for a vendor. She finds a vendor whose site is in only one language, and another whose site is in eight languages. Which vendor has more credibility, especially to somebody who doesn’t know (or even want to know) a lot about localization?

Mind you, I’m not completely representative of the entire industry. I’m not a “language service provider,” so that bit of credibility is of no great advantage to me. Still, it brings up the old chestnut about the cobbler’s children running barefoot: Isn’t it odd to be in localization, yet not have a localized Web presence?

My rationale, aside from the expense, is that almost nobody who would want our services would want to read about them in any other language besides English. That’s probably the case for almost everyone in the American localization industry, where the dominant language conveniently matches the world’s current lingua franca. Other languages just confuse most Americans anyway, so one could argue that it would be a needless distraction in the sales cycle.

What do you think your customers and prospects want to see? Can you get by with your marketing presence (Web, collateral, datasheets) in one language?

If you enjoyed this article, have a look at “Why Localize at All?“

“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.

What do you do when it seems that the translator is ignoring your instructions?

I have boundless respect for translators. I couldn’t do their job as intensely as they do. But sometimes the intensity creeps into artistic license, and we worker bees get burned.

We had a high-pressure rush job last week. The Taipei office had a 30-page report translated from English into Chinese for Taiwan, and wanted a sanity check on the translation. The document was ready after close of business Friday in Taipei, and the reviewed version had to arrive before start of business Monday in Taipei.

We scoped the work as follows: The translator’s job would be to “review the Chinese document for grammar, usage, punctuation, and to ensure that the English meaning is preserved in the Chinese version. All modifications should appear as tracked changes to make them easy to find.” That seemed as clear as I could be about what we expected, and the translator’s manager acknowledged the request.

The translator returned the document on Saturday, one day early, having modified almost every sentence in the entire document. As I looked through it, only a few possibilities occurred to me:

• The original translation had been a train wreck, and the reviewer had to clean up text everywhere.
• Something had gone wrong with change tracking in the document.
• The translator had not received my instructions and had introduced stylistic changes.
• The translator had ignored my instructions and had introduced stylistic changes.

Somewhat tentatively, we delivered the reviewed Chinese document to Taipei on time, mentioning the extensive changes proposed by the translator. Meanwhile, I told the translator’s manager that I felt he had ignored the instructions. The translator replied, “There was a room to improve the readability of original translation. Although some mistranslation existed, the translation generally was still good.”

The translation generally was still good?

Now, I appreciate a thorough job as much as the next person – even if I can’t read Chinese – but this was not the time for it, and my instructions had been quite specific. Nobody in Taipei had the time to go through and accept or reject each change. That’s part of the “rush” in “rush job.” There’s no easy way to go through 30 pages of changes and separate the instances of mistranslation and loss of original meaning from stylistic changes intended to make the document a better read.

How do you get your instructions across to translators?

If you enjoyed this post, have a look at this related article: Instructions to In-country Reviewers

“What would Microsoft do?” What do you do when you need to translate according to the terms Microsoft uses?

Microsoft has a long, storied past of localization, and a correspondingly colossal corpus of translated material. Until a couple of years ago, they made just about every string in dozens of their products available in .csv files via FTP for free download, subject to copyright. No doubt that became laborious for them – it certainly was for those of us who tried to keep up with them – so they’ve since switched from making all of the strings available to making 12,000 key terms available in up to 59 languages in a single, 10MB spreadsheet. The file is at www.microsoft.com/globaldev/tools/MILSGlossary.mspx

The winners in this simplified approach are those linguists creating a term list, or translation glossary, for a specific project that must adhere to Microsoft terminology; e.g., how Microsoft translates “Cross Array Link” in Korean. The losers are linguists who need to know, for instance, how “Completing the Hardware Wizard” or “Windows Security – Verify Publisher” is rendered in Slovak or Pashto.

The term list also takes aim at a long-standing problem with localization at Microsoft (or any large organization); namely, that there was inconsistency in translation among products. While not all translators will agree that these terms are ideal in a given language, at least this is a move in the direction of consistency, and sometimes it’s better to be consistent than to be right. It’s generally easier, anyway.

If you enjoyed this article, you may like another called “Where Do Your Glossaries Live?“