The Watchmaker Localizes Mobile Applications

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?

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?

Is Your Localization Expertise Really Vertical?

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?

If it isn't broken...break it!

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.

Web Localization and the Cobbler's Children

"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?"

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.

Translators and instructions - hit or miss

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

WWMSD?

"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?"

Have you cleaned behind your glossaries?

Don't take this question too personally. After all, I'm not asking whether you've cleaned behind your ears, or behind your couch. But last week I asked the digital question, "Where do your glossaries live?" and this week I'm asking about the state of their hygiene.

One of my client-companies is quite proud (and justifiably so) of the considerable work they did a couple of years ago in building out a 600+ entry glossary in ten languages. They (or their language vendor, really) have hosted it on the Web, with read-only access to any translator who does work for them.

This model of glossary has the inestimable benefits of being universal, up-to-date and centralized - there is only one glossary - instead of being a patchwork of spreadsheets and tables on several different hard drives in several states of accuracy. It's set up for alpha-listed browsing and search, although the search function is not fuzzy unless you use wildcards, so some translators will not derive full benefit from it and may in fact miss terms.

While managing a sample translation for the client, I wanted to export the glossary to review it all at a glance, so I mentioned that. "Nope. That's not possible," the client told me, with more than a hint of pride. "We designed it so that there would be only one glossary in one format in one place. We don't want it exported or circulated unnecessarily."

Now, I'm in business to see my clients succeed, but that kind of mindset is just a tempting challenge to me, and as I managed the sample translation I deliberately looked for reasons why a hermetically sealed glossary like this was a bad idea. Naturally, I found one: The client had not cleaned very well behind their glossary.

Several industry-specific terms occur in the sample, and I knew the translators would be obliged to use the glossary. For instance, terms like "drive" occur in various combinations ("link drive," "offset drive," "drive mechanics," "rack-mount drive," etc.) in the glossary, and as I poked from one entry to another I noticed inconsistencies and contradictions in how "drive" was translated, notably in German. One entry gave "Laufwerk" as the translation, and another entry bore the note that "'Laufwerk' is obsolete."

The online model for hosting this glossary is a good one for several reasons, but it's not amenable to the healthy, periodic scrub that such databases should undergo. If the glossary were exportable, or at least visible in row-and-column format, these inconsistencies would be easier for translators to spot and address.

Interested in this topic? You might enjoy another article I've written called "Where do your glossaries live?"

Where do your glossaries live?

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?

Localization in the news

Have you ever stumbled onto something in the course of localizing a product that was private, or maybe even a bit compromising? Here's a news item from telecoms.com that falls into that category:

This time round, Apple is supposedly prepping its iPhone to be a portable gaming machine, wading into a market already dominated by the likes of Nintendo and, to a lesser degree, Sony.

Although the 'official' iPhone applications market is noticeably void of any games at the moment - mainly due to the fact that Apple has banned third party apps from running natively on the device - some hackers claim to have found tell tale signs that games are indeed on the way.

Apparently, the iTunes localisation code makes some reference to a string asking the user if they want to remove the games in question. Naturally, this gave way to rumours that Apple has had a games developer partner lined up for some time and plans to offer gaming products via iTunes. [emphasis mine]

Some alert hacker (or maybe even a translator) must have lobbed a note about this string into the blogosphere, or otherwise publicly asked the question, "Why would they want to remove games?"

Who says there's nothing proprietary or confidential in software resource files?

Localization on the Cheap - Get Students to Do It

Maybe you read this and became encouraged to have your products and Web pages translated over the Internet by college students in other countries:

"In April and May 2007, Palex held an English translation contest for Microsoft software and documentation. It is the second translation contest organized by the company with the purpose of stimulating interest in translation and freelance work and selecting new full-time and freelance employees. With more than a hundred applications submitted, over 70 participants - most of them students and young professionals - completed the off-site translation assignment. Those who delivered the 20 best translations participated in the final stage.

"For the final assignment, the competitors had to translate an HTML page and correct 11 localization errors in a dialog box. Although translation quality was of the highest priority, the technical background of the participants - such as the ability to handle HTML correctly and the number of localization errors found - earned additional points.

"Andrey Cherkovsky, a freelance translator, was selected the winner. The second prize was awarded to Sergey Plotnikov, a chief specialist at Tomsk Regional Energy Commission, and Rostislav Romanovsky, a third-year student at the Chemical & Chemistry Engineering Department at Tomsk Polytechnic University. Neither has ever been a professional translator. Mark Lesun, a newcomer to freelance translation, ranked third. [emphasis mine]"

So, they got lucky. Don't forget, though, that out of 70, only 20 qualified as "good," and out of those 20, only 3 took prizes, and one of them was already a freelance translator. Can you find the 3 out of 70 that won't embarrass you?

From Pseudo-translation to Pseudo-localization

Do you like having teenagers handle your medical insurance problems?

Why would you have college students localizing your product?

I've posted several articles on pseudo-translation, which is a science. Pseudo-localization, or the practice of pretending you have good localization processes in place when you're really having exchange students review or--ack!--translate your product and Web presence is not science. It's short-sighted.

I can't say for sure, but I think it has to do with what most people perceive as a black box around foreign languages, especially in the U.S. We're not xenophobes, but we are by and large linguaphobes, and most of us freeze like a deer in the headlights when the prospect of dealing with a foreign language arises.

Frankly, though, it's easy to fall into the practice of pseudo-localization, especially in technology companies. Young employees for whom English is a second or third language are becoming the norm, and while their cultural diversity and mental models are a boon for product development and global reach, are they really suited to translating?

No.

Inside that black box is what people have to do to become accredited translators, and to build and maintain their reputation. They're not fussing about Web-based translation portals and fast, cheap, young translators because they want to cling to their jobs. They're fussing about it because the product quality is lousy, and most Americans don't care.

You're an American localization project manager: Have you ever been in a company for more than three months without hearing, "Why don't they all just learn English and save us this headache? Har, har, har."

Better-cheaper-faster is a triangle, and you can't cover all three corners with the same solution.

So, by all means hire that French exchange student or that Chinese H-1B to work on your localization project. But make sure you get at least one other pair of accredited eyes to review it.

Localizing Declarations of Conformity

Does your documentation contain Declarations of Conformity with European Community standards? If it does, here is some due diligence you should undertake before having the docs translated.

The EC has promulgated a long series of directives on a variety of industries ranging from aerospace to toys. Some of these directives describe industrial policy and consumer protection. If your product falls into the category of those covered by a set of directives, then 1) the product must conform to the directives; and 2) you must declare that it conforms and list the directives with which it conforms.

This second requirement leads to some of the driest text with which you'll ever fill pages in a user guide; for instance:

Protection requirements concerning electromagnetic compatibility to Article 3(1)(b)

Harmonised standards applied:

EN 301-489-1, V1.4.1 (2002-08); Electromagnetic compatibility and Radio spectrum Matters (ERM); Electromagnetic Compatibility (EMC) Standard for Radio Equipment and Service. Part 1: Common technical requirements

ETSI EN 301 489-25 V2.2.1 (2003-05)

Fascinating reading. And, it makes for even more fascinating translation work.

If you're localizing your U.S. product for sale in Germany, the translation of the names of these standards with which you're declaring conformity should match the German names acknowledged by the EC. You could hand off the English text to a German translator, who could trip through several technical dictionaries creating his own translation. The numbers of the directives would be correct (because not translated), but strictly speaking, the titles would not be correct, unless your translator was extremely lucky.

Fortunately, the EC has made this easy. Depending on the industry, they offer accepted translations of the titles and text of the directives in as many as twenty languages on their Web site. With a bit of digging, your translators can find and re-use approved text. This will not only save them (and you) time, but will ensure you of a better fit for your localized documentation.

Translators - The Tech Writer's Best Friend/Worst Enemy

"Say, Jean, the translators found some problems with the original English documentation your team wrote. Do you want me to send you the corrections?"

"Sure, John. Do you want me to send you a nice cartridge of mustard gas?"

I never find that writers embrace the feedback from translators. It's not that the translators go out of their way to find errors; mostly it's that they don't understand the term/phrase/sentence/paragraph and cannot therefore translate it. This is the fundamental test of documentation usability - are you conveying your idea to the reader? - and most writers get grumpy when they don't pass it with flying colors.

It's also not the case that translators get snooty about the errors they find. In fact it's I, not the translators, who add a thin veneer of snootiness to the comments I send to the writers.

• Why are all of these Copy(1) and Copy(2) files in the RoboHelp project? Do we need them? Should we translate them?
• The FrameMaker files you gave us don't match the PDF you gave us. Which one is correct? (To their credit, most translators won't take for granted that the one with the later date stamp is the definitive source.)
• This training manual is for version 5.3. The last version of the software that we translated was 5.1. What has changed in the software? Do we need to translate the delta first, in order to translate the manual properly?
• We found 136 pages in the online help file with no content in them. Are they meant to be that way, or did something go wrong in the extraction process?
  

Writers don't often like to hear such feedback, but, if it's implemented, nobody can deny that it makes the books better.