UPDATED: May 3, 2012: Apple added 10 new languages! This post has been brought up to date.

Apple has already increased the languages iPhone supports to over 30 as of iOS 5.x:

English, British English, French, Italian, Spanish, Portuguese (Brazil), Portuguese (Portugal), Catalan, German, Dutch, Danish, Swedish, Finnish, Norwegian (Bokmål), Russian, Czech, Slovak, Polish, Croatian, Romanian, Turkish, Ukrainian, Hungarian, Traditional Chinese, Simplified Chinese, Korean, Japanese, Vietnamese, Arabic, Thai, Greek, Hebrew, Indonesian, and Malay.

Developers often ask which languages iPhone supports, but more critically, which languages should they support in their own iPhone apps? Obviously supporting all of Apple’s language choices above is costly and time-consuming, so you want to begin with the largest markets. An even more important consideration is that you’ll only be able to market your app effectively in the languages supported by App Store.

Yep, the iTunes App Store supports a different set of languages than the iPhone itself.

The App Store speaks a different language

Through iTunes Connect you’ll be able to localize your app description, keywords, screenshots and other meta data for the App Store. I’ve previously discussed how to write an insanely great app description. Once you choose to localize, those critical texts are equally necessary for users to search and find your app in Apple’s App Store. It goes without saying, Google Translate won’t cut it!

The latest addition of the iTunes Developer guide lists these supported iOS languages for localization:

These are the languages iPhone supports in the App Store

Note that the languages iPhone supports include variants of English, Spanish, Portuguese, and Chinese.

UPDATE 3-May-2012: Apple has now added support for: Traditional Chinese, Norwegian, Turkish, Finnish, Danish, Indonesian, Malay, Thai, Vietnamese, and Greek.

Apple currently supports just 21 languages (plus 7 additional variants of English, Spanish, Portuguese, and Chinese) for the App Store, compared with 30+ languages on the iPhone itself. This may narrow down the list of languages you want to support in your app.

Which languages should I support and localize my iPhone app into?

I’ve answered this question in a separate post, but it bears repeating that Apple is clearly focusing its App Store on specific markets—and so should you. Unless you have reason to do otherwise, the most popular languages supported by the App Store are: Spanish, French, Italian, German, Portuguese, Japanese, Korean, and Simplified Chinese.

Ready to localize your iPhone app? Contact Babble-on for a free quote.

What are the languages iPhone supports for localization? | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

Facebook succeeded in turning “Likes” into a noun and simultaneously revolutionized the speed at which we build social relationships and destroy grammar. What about Twitter?

Twitter has also introduced new “words” into English. Even for native speakers it is difficult to know how to use them. Stephen Colbert famously “twatted,” but the more popular past tense of “tweet” has settled upon “tweeted.”

For translators and localization engineers, words like “Follow” have become important for many applications. Instead of watching a discussion, we now follow it. But how should we translate Follow into the rest of the world’s languages?

TO TWEET OR TWITTER BY ANY OTHER NAME…

Here is a glossary of the most common Twitter vocabulary localized into some of the languages Twitter currently supports. This “cheat sheet” will be helpful for translators localizing websites and apps that want to maintain consistency with Twitter terms.

Will tweet for food

This glossary was created by reading through Twitter’s pages in the target languages, but they aren’t perfect. There are cases where one Twitterism might work, and others where local grammar or common sense precludes a term. For example, note that “following” in English is translated in at least two ways for some languages, depending on whether it is the button (“I am following”), or a list of users you are following.

Use the comments to help keep this list updated. I’ll add any languages you need.

Localizing Twitter vocabulary like “Follow” and “Tweet” | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

One question I’m often asked by software developers is why they should go with an independent translator or indie translation provider instead of the “big guys”—traditional agencies—or factory translation companies like icanlocalize or mygengo.

I can think of a million reasons, but here are my TOP 5

1. Quality. Doing an outstanding job is everything to us. It’s our reputation and our livelihood.
2. Accountability. When issues crop up—and they do in complex localizations—you can bet that an independent translator will listen to the problem and help you find a resolution instead of passing the buck.
3. One price doesn’t fit all. If you think that all translations can be reduced to a single per-word rate, you’re fooling yourself. Factory translation companies make money with add-on pricing: it looks cheap but you end up paying more and more to get the quality you deserved in the first place. You always get what you pay for.
4. Answers. Unless your question is listed in an FAQ, chances are a factory translation company won’t bother to help you. Indie translators will—every time.
5. Because you care. You care about your software. You put a lot of work into it and you genuinely want people around the world to use it. Why would you trust your baby to a website?

How do today’s cloud translation companies compare?

Click to enlarge

The death of Traditional Agencies

I don’t talk a lot about traditional agencies, because honestly there isn’t a lot to say. They are outmoded and outclassed in the localization world: high prices, low quality and response time, and problems handling new localization formats. They don’t “get” software and they never will.

Disagree?

Tell me in the comments!

What’s wrong with a factory translation (“cloud translation”)? | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

If you haven’t checked out Bad Translator, you don’t know what fun you are missing.

Original text:

“I think I’ll use Google Translate to localize my website so that everyone can understand it.”

…50 translations later Google gives us:

“You know, if you use Google, I think all the ingredients.”

Bad Translator does something quite simple, but demonstrates a great point. It asks Google and Bing to translate a phrase from English into another language and back again. Repeating this process dozens of times is reminiscent of the “Telephone” game we used to play as children: whisper a few words into one person’s ear, repeat it to the next, and by the end of the line you get something totally wacky. Often, the results are hilarious.

But if you’re using Google Translate or Bing to translate your company website, the results are often less funny. You quickly lose control of your message and have no idea how you are presenting yourself to foreign audiences.

Google and Bing Team Up to Make One Bad Translator | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

When Naim Cesur, developer of the iKamasutra app, contacted me about doing some copywriting I was thrilled. It’s not every day that I am able to involve my girlfriend in “copywriting research.” After a good stretch, however, it was clear that Naim had an issue typical of all mobile developers: how do you write App Store descriptions?

Today’s App Store descriptions are not only the marketplace version of an eHarmony profile, they serve as the basis of user reviews and press articles; often they serve as the only user manual a customer will ever read.

Your App Store Descriptions shouldn't read like creepy online dating profiles.

App store descriptions might be the first words a person reads about your app and—if you do it wrong—it could be the last. They are very, very important.

For iKamasutra, the stakes were even higher. Because of the content, iKamasutra is age-restricted to 17+ in the App Store, which puts its app store descriptions under added scrutiny. Then there are the words. By Apple’s definition, extremely potty-mouth and racy words like “sexy” and “sexual,” which you might only hear in a shady underground sex dungeon or PG-rated movie, may be used solely at their discretion.

Triggers an automated Apple warning:

A very sexy app!

Won’t trigger an automated warning:

I wanna sex up your mom, pal!

Apple’s views on word choice make for insanely great reading.

App Store Copywriting Deconstructed

Since Apple has had *reasonable* success with their storefront, let’s agree they know a thing or two about selling these apps. Take a look at how they construct their App Store descriptions and you quickly see a common pattern:

Introduction about being the best at what it does.

Short, clever title about what it can do.
• Key feature detail one.
• Key feature detail two.

Second, clever title about what else it does.
• Key feature detail one.
• Key feature detail two.

That’s it. And it is true whether you look at Pages, iMovie or their simplest app, Remote. (If you look at Apple’s website product pages, ultimately it is an identical pattern with better design and photos.) Now have a look at other Top Grossing apps, like Angry Birds for instance, and you’ll see a similar structure. “It just works.”

Many third-party developers have put forth additional app description ideas that are worth considering, too. These include: Twitter and Facebook links, quotes from major press outlets, and awards (Best of 2011, Top Grossing, etc.). While Apple doesn’t do this, these are great inclusions for most app developers.

An App store description for iKamasutra

Let’s apply some of those lessons to iKamasutra.

Click to read full description at iTunes

App Store Descriptions checklist

Here’s what works in this App Store description for iKamasutra. Bring some of these ideas to your own app description and see how many more satisfied buyers you can get.

• The first line sells. 5 million users, great press, and a sense a humor. Of course you want this app! Don’t forget that you see just these first couple of lines above the “More…” button when viewing an app description in the iTunes store on your computer.
• Stand-out features really stand out. Our second paragraph tells us all the best stuff we have to know about iKamasutra, including a highlight reel of key features and advantages over the competition, including exclusive Kama Sutra descriptions and Apple-approved sex images.
• Intriguing titles describe and delight. Just by glancing at titles like “There’s a position for that” and “Email just got exciting again” you have an idea of what the app does with enough appeal to make you read the details. Just don’t call it “sexy,” because that word is an Apple no-no.
• Details do sell. You’re interested by titles like “Shake it, baby” but when you learn the details of what it does, you’re really ready to hit BUY. Each essential feature is listed in precise and succinct detail. It’s part marketing and part Quick Start guide for the app, ensuring users take advantage of everything iKamasutra offers, so that they are fully satisfied with the purchase. Remember, no one reads help texts until they are already disgruntled.
• Honesty pays—handsomely. iKamasutra offers an excellent feature set built in, with extra positions available for purchase if that’s what you want. If your app relies on in-app purchases for revenue, it is in your favor to be upfront with buyers. Tell them what is free and what isn’t. This avoids disappointment, angry reviews, and entices shoppers to become loyal customers.
• Don’t take my word for it. Reviews, both from your users and from online and print sources, are incredible sales tools. iKamasutra has glowing reviews and we highlight them for potential buyers to see.
• Show them how to push your buttons. Unfortunately, App Store reviews are anonymous and you can’t follow up with individual users. We give them Twitter and Facebook links where we can take the conversation to a personal level.

Your app descriptions need some love too

It has paid off to get the “positioning” of iKamasutra just right. But every app is different, and should be treated that way. The App Store descriptions you write shouldn’t be afterthoughts. They should be front and center in importance, since that is exactly how your customers are going to view them.

* Benjamin Zadik is a copywriting expert and iKamasutra novice. He wishes it were the other way around.

Writing iTunes App Store Descriptions | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

Website localization is the answer, and website localization costs have never been lower. Let me explain how website localization costs are calculated and how to save money on localization for your site.

How to calculate website localization costs

Here is the simple formula:

Cost $.$$ = words x price-per-language

No matter which website localization company you go with, the bottom line depends upon how much text you have and which languages you choose. A solid number for budgeting purposes is $0.15/word, although the price will vary depending on the language, the complexity, and the services you need.

This will save you money.

Determining the word count of your website will quickly help you budget your project. You can paste your website texts into Microsoft Word and use its “Word Count” feature (available in the Tools menu) to get a fair idea of the size of your website localization project. Delete anything that is duplicated, like headers and footers and menus. This exercise will also force you to decide which pages of your website you want to localize. Often there is no need to translate everything.

In fact, there hardly ever is a good reason to translate everything. I always suggest localizing only the pages you expect a foreign audience to read. If you look at the localizations of the Babble-on site (www.ibabbleon.com), which is already in 12 languages, we chose to translate only the pages that a foreign audience would read. In our case, these were pages about translation services and copywriting in English. You certainly want your product and checkout pages translated, but perhaps your job listings and Help texts can wait. Cutting down the word count is the single best way to lower localization costs.

This will save you even more.

One of the most time consuming parts of website localization is not translation. It is making sure all the translated text appears in the right places in the HTML document. That is why it is important to go with a website localization company that understands the process. If you have your webmaster deal with inputting the files, you may save some money (unless your webmaster charges you by the hour). However, having the translator do this inputting helps ensure everything is put in the right place.

At Babble-on we use the latest website localization tools to make this process fast and accurate, and we pass the savings on to our clients. Make sure your preferred translator does the same.

Beyond budget

Localization is no easy task, and you want translators that are professional and knowledgable, ones that will tell you when something will be misinterpreted or misunderstood in their language. Besides budget, be sure to go with someone you trust and you can talk to any time and receive honest feedback. Check Yelp or other online reviews. Localization, after all, is not simply translation, but adapting text to a new audience with different sensitivities and needs.

Getting your site localized can be one of the best things you ever do for your business. It is relatively inexpensive and—assuming users in another country (or speaking another language in your own country)—are interested in what you do, you’ll gain back your investment tenfold in the long-run.

How much does website localization cost? | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

IT’S NO SAN FRANCISCO TREAT

It turns out Google isn’t much help in finding a copywriter in San Francisco. Neither is Yelp for some reason, even though it would make a whole lot of sense for people to write reviews about copywriters. Nobody does, though, so you check YouTube instead. There aren’t any copywriters there, but you are distracted and watching videos of a baby falling out of his highchair. You sort of chuckle, but it feels somehow wrong, even though the baby seems perfectly fine. You are afraid you will have to flip through the Yellow Pages to locate a copywriter in San Francisco, but you have some dignity left. Anyway, that would make your fingers dirty.

You find a copywriter in San Francisco the old-fashioned way: you asked someone else in the company and she gave you the email address “of a real pro.” Just imagine discussing your copywriting needs over an informal lunch and a glass of the only wine on the menu you are confident in pronouncing. Copywriters are all tremendous conversationalists; on this point you are certain. This one might prove to be an adequate after-work buddy or happy hour companion, and would definitely know a darling of a pickup line you could try out on that cashier from Whole Foods. This is going to be fantastic.

Excitedly, you’ve sent your first email to the fog-city wordsmith. Don’t be modest—your message is pretty awesome, and you spent an inordinate amount of time preparing its four short sentences. (Wisely, you deleted the words “fog-city wordsmith” at the last minute.) It is imperative for the copywriter to understand immediately that you “get it”—you get it good, in fact—so much so, you could probably write this advertising copy yourself. But you’re a busy man and, hey, it’s not your job. Actually, your life right now would make a mildly thrilling short story, or at least a post on a blog, if you had one. Do copywriters write short stories? You might want to ask that during your first lunch meeting.

A copywriter in san francisco is busy

You’ve hit your first snag. A copywriter in San Francisco is much too busy to meet you out in the open, diddling over an open-faced sandwich and a mediocre Chardonnay. He prefers to send brief missives over email like this:

Awesome product. Ping me later in the wk. —CSF

The first time you received such an email, you were impressed. Admit it. You are convinced this SF copywriter must be pretty damn, well, cool—a modern-day Shaft with a keyboard. Ladies are attracted to him like…like…. You’ll ask him for an appropriate simile at the meeting; it will serve as a fitting ice breaker.

He fails to reply to your follow-up messages for several days. At last, upon receiving his belated response, you have nearly lost your crush.

Apologies. Been slammed ALL week. Let’s regroup Mon. —CSF

Forgivable, surely, but disheartening nonetheless. Hiring a San Francisco copywriter isn’t as simple as expected. Why is he such a bastard? Forget the lunch meeting; they stopped making the portobello burger you liked anyway, and having wine at noon makes the rest of the workday seem so much longer, especially when that marketing intern keeps interrupting your web surfing to ask for advice about grad school programs at Stanford. Who is she kidding, right?

This copywriting thing can’t be hard

It is clear that you are equally capable of writing the necessary blurb, this marketing hogwash wrapped in balderdash, as good as any twaddle scribbled out by a professional copywriter in San Francisco. First, you proceed to brainstorm, which you assume is what writers do, but sooner than you expect you are back to jotting down one-liners to impress that girl at Whole Foods. Asking her out was a BIG mistake, and now you have to find a new location in San Francisco to purchase coconut water in a can rather than that oversized young coconut with a straw on top the way the Mexican deli sells it. It would never have worked out anyway, you tell yourself, because she has three tattoos—one over your limit. This life experience has made you grow as a person; you may even one day learn to have a serious conversation with someone while holding a young coconut with a straw on top. Lamentably, that day is not today.

Focus. You know the company and the product better than anyone. You hash out some fantastic headlines and even a squiggle you’ll send to graphic design to turn into an infographic or sidebar, whichever one these things are supposed to have. It would have been nice to work on this with a professional copywriter, but he is too busy and, sort of a jerk really. At least you think he is, though you haven’t met him yet, you just have this feeling about him from his emails. Just then you receive another one:

Sorry, bro. Your project is my first priority now. Let’s talk about it over lunch? —CSF

The question mark at the end of the last sentence has you imagining his profound remorse. Has this ego-driven SF copywriter hack come crawling back to you? Things are looking up, the tables have turned, and you cooly remove your rose-colored glasses from the desk drawer. Maybe it is time to go back to Whole Foods and give the cashier another chance. At the very least, you could grab some coconut water in a can so that the marketing intern will have one less thing to comment about.

meeting a copywriter in san francisco

Your hands are sweaty. He is late. You’ve already finished your bottle of Sierra Nevada (there were no pronounceable wines on the list) and all but two bites of your avocado and buffalo mozzarella focaccia. This is a disaster. Why didn’t you use that phrase you’ve been meaning to insert into your speech and instruct him to “swing by” the office?

When he arrives you see he is small and underwhelming, a disheveled pretender with vintage glasses and untended clothes. He smells like cloves. There is no way this man gets girls. The rest of the conversation goes downhill. He writes mostly for search engine optimization, articles about women’s clothing that contain the keyword Brazilian. There is no portfolio for you to consider, and his website is under construction, though he assures you his friend, a web designer and DJ, is making it “killer.” You are confident that the school he says he attended is a women’s college. Worst of all, he isn’t even from San Francisco—he lives in Fremont.

copywriter in san francisco, reprise

Like lassoing in just the right unicorn, finding a brilliant copywriter in San Francisco requires sweat and tears, as well as a professional-grade lasso. You have to love your copywriter, not like your significant other, but with unbridled affection and trust. You have to read everything the copywriter writes, and love that too. If you don’t love something on first blush, you must squint your eyes and beat your chest until the writing seems at once somehow both light-hearted and profound. Headlines must make you laugh, excerpts must cause you to weep uncontrollably, like a babe in his arms, but all of it—all of it, without fail—must make you read until the very end.

And when that happens, you know you’ve found your copywriter.

— Benjamin Zadik is a copywriter in San Francisco. He has never been to Fremont.

Copywriter in San Francisco | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

These are some common issues we face as translators that developers are advised to keep in mind.

Word choice, not word AnythingYouLikeItToBe-ify!

Not a word, not a sentence — I care a lot about accuracy in translation, so one of the biggest show-stoppers for me is what we call the “untranslatable” phrases. Usually, this is stuff creative programmers and marketing gurus have pulled from out of their proverbial “backend,” and inevitably involves multiple words pushed together into one. Here I’m talking about things like:

• SuperSelectiveSync
• Re-undelete
• Mysticgel

Unless you are Goethe, it is not recommended to combine multiple words into SuperAwesomeWords, even if you capitalize each one. Translators won’t know whether they should repeat your Germanization of the user interface, why it was done in the first place, and in some languages (Chinese, Arabic, etc.) it is not possible to do anyway. One typical resolution is to translate literally (i.e. “Sync that is very selective; Undo the delete command again”), but this often leads to confusing or just plain incorrect translations (“jelly of magic”?). This literal decoupling of words also results in very long translations that, in the English version, may have been purposefully shortened for whatever reason.

Not in the dictionary — A solid piece of advice is also to steer clear of one-word gems like these:

• Capturize
• Solarify

(These are real examples, by the way.) On the surface, this may seem like a non-issue to a developer, even reasonable or, dare I say, “necessary” word choices. Once we’ve returned to planet earth, however, we all realize this doesn’t make sense to anyone, including English speakers. Combine with a lack of context, and you may as well have punched the translator in the face and told him to “Suck it up, and deal with it.” The often desirable solution, equally for developers and translators, is to assume users will just “figure it out.” In my opinion, this is not a solution, and good communication with developers, and good forethought, can really help. You may just have to change the “English” (I use the term loosely here), or at least explain your particular addition to the good folks at Merriam-Webster.

Not in my recollection — A related category of phrases are those that just don’t make much sense at all—even to the developers who wrote them. It is not rare for me to have a discussion with a programmer who, months earlier, coded abominations like these:

• The — By itself, “the” is meaningless, and doesn’t even exist in many common languages like Japanese and Russian, but developers often have this string lying around to combine with other strings, like “The 5th of December”
• ’s — The possessive apostrophe s (“Ben’s cup”) in most languages we deal with is translated very differently (e.g. la copa de Ben).
• to the forum! — Half a phrase is the worst kind of phrase. Unless a translator knows the other half of the string, they have trouble translating it. Even after you reveal to us what it might be, the multiple possibilities might have to be translated in completely different ways and with different word order in other languages.

Developers sometimes cannot even recall why they wrote such things, where it appears in the user interface, or what reason they had for coding such still-born, half-mutant strings. The resolutions here are more difficult. It is always preferable to use multiple strings rather than dividing them up and assuming they can be recombined just like in English.

Not my way of doing things — That said, there are other, often more difficult issues, regarding the syntax and word order of English versus other languages. English does not have word gender or cases, we write dates differently (wrong?) compared with others, we adore measuring things by the length of the king’s foot, and so on. When localizing, these issues inevitably arise. A common pitfall is to assume the English way of dealing with numbers:

1 page
{quantity} pages

Developers do this all the time because they know that, in English at least, if there is more than one “page” they have to add an ‘s’. But in a language like Russian, where nouns have both gender and case, the {quantity} will change the noun “page” in many more ways:

and so on…
(It’s the last character in each that changes.) These problems have both precedent and solutions, but the key is to become aware of them. After all, developers long before, in the decades of sin we call the 1980s and 1990s, already faced these same issues and found workarounds. Unless a developer proactively includes such internationalization solutions, we will have to discuss them after the fact and add them in like patchwork.

Not from this world — That brings us to by far the biggest “gotcha” in localization: a lack of context. Professional translators are, more often than not, given a long list of words and phrases to translate without knowing anything about them. Context is key. Just try to decipher things like:

• Archive — Is it a verb (“Archive the file”) or a noun (View the Archive”)? In most languages, these translations would be different.
• New — A new what? Since gender is often critical in languages other than English, translators want to know if this is a “New file…” or a “New window” so that the gender of adjectives and nouns are correct. More interestingly, in some languages a literal translation of “New” might not be the best word choice. When a “New!” message arrives in your inbox, in some languages it might be preferable to translate “Arrived”.
• Create Day — Only God can create a day, so if you meant to say “Creation Date” you probably should write it that way, or at least specify it in the comments. Otherwise, translators facing 10,000 lines of code will quickly translate “Create” as a verb here and move on.

Developers are not wrong in asking for these strings to be translated, and they are not to blame for failing to foresee the repercussions word choice might have for dozens of other languages. However, offering a little context can aid translators in resolving these issues. Ideally, developers can help out by writing text that is very clear, which is helpful for English-speaking users anyway. They should also be adding a comment string as they write code. However, if that is too much to ask, even making your keys and placeholders descriptive (e.g. ArchiveMenu.CreateNewArchive) can go a long way to describing the text “New”.

The one true word

Although my job is generally focused on making sure translators deliver a localization project completely, accurately and on time, there are clearly many aspects out of my control. As the above attests, a few of these have to do with the original English we receive. By English, I mean both the kind we humanoids use when communicating with each other in the United States, Britain, Australia and the like, but also what developers like to call the English they use when writing strings that will appear in software, on a website, or an iPhone app.

In any localization project, the long list of random English phrases can present a real challenge. Working together, however, developers and translators can go far in making their word choices spread into more languages and regions than even the Queen’s English.

In which I explain how the word choice of developers affects translation and localization | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

A translator fluent in two languages may never need to consult a dictionary to translate a simple text: a letter, a web page, etc. However, most good translators will ponder and rethink a few words on the page, especially key words and adjectives that appear in a text, in order to get the “best” choice. Interestingly, translators consult the thesaurus almost as much as the dictionary. Often we know what a word means, but we’re looking for just the right connotation in the target language. A thesaurus, in this case, can be even more invaluable than a dictionary. After all, which word would you choose to describe a sunset? Wonderful, magnificent, delightful, pleasing, brilliant, superb, fantastic, marvelous? Sometimes it’s helpful to consider your options for those final touches to convey the author’s style and intention more than relying solely on dictionary definition number one.

There are other tools that modern translators use. These include “translation memories” — glossaries built upon previous translations, as well as online sources. Modern translators tend to be “plugged in” to the Internet. There are websites such as proz.com and wordreference.com where translators discuss difficult or country-specific terminology. The sum of all these discussions is an invaluable treasure trove of language information that is often more useful than a standardized dictionary.

I am fond of saying that a good translator knows what he or she doesn’t know. You need to be able to spot phrases that might have a double meaning or an idiomatic reference so that you can consult the dictionary, the Internet and native speakers in order to find just the right meaning.

If you see a dictionary in a translator’s hand, it doesn’t mean trouble. It means the translation is about to get one step closer to success.

Do translators use dictionaries? | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.

Another question from Quora:

How far are we from an accurate machine language translation service?

As a professional translator, this is a topic that interests me greatly. I agree with Steven’s assessment of what a machine should be able to do, and I believe all of us in the linguistic field believe that machines will be able to do this. The question remains: when?

It is amusing to go back and review science fiction in the past 60 years, which, since the advent of computers, has always believed that we are on the cusp of this breakthrough. “Within a decade” seems to be a common response, but it has been wrong every time and will continue to be for the foreseeable future. Advances like IBM’s Watson are encouraging, and show that a computer that is well trained and given copious amounts of data can decipher “what” we mean in most cases. This is half of the battle for translation.

The other half is correctly translating into a given context, and as Steven shrewdly points out, even humans cannot do it properly every time. However, we are good at putting ourselves in the user’s context and deciding to change English units to metric, fixing mailing addresses, and even explaining terms that make no sense in another country. For instance, imagine you are a rental car company in the US: how useful would it be for me to tell you that I have 26 points on my driving record in Italy? Points are good in Italy, with a maximum of 30. You often need a translator or a native to point such things out.

One thing I often tell translators is that the key to translating is not just what you know, but being able to see that you don’t know something. Idioms often make some sense when translated literally, but it takes someone well versed in a language and in their own abilities to identify a phrase that might have a second or third meaning. In these cases, translators research in specialized glossaries, search for examples in articles and search engines, etc. Computer architects will need to teach machines this same skill of double-checking their work.

An interesting circumvention of typical thought on translation is Google’s online translator. In large part, it works like any other translator. However, Google is also trying to gather proper translations (from humans) for everything in every language. For instance, recently it acquired rights to the European patent catalog. Using such information, Google continually improves its translator with the hopes of one day offering translations based on what it “knows” is correct. Even this has its limitations and seems a ways off. Notwithstanding, it does show, of course, that lots of computer power and human intellect is trying to tackle the problem. Ask Google, and its engineers might tell you they’ll be there “within a decade” but we all know this is unlikely.

When will machines be able to translate for us? For getting the gist of something, online translators are already there. They will be much better in 10 years time, and perhaps good enough for many more common uses. But to do a professional-quality translation, where we truly rely on the computer: that might take a lifetime.

How far are we from an accurate machine language translation service? | the babble-blog — | the babble-blog — - All about writing, translating and everything else with words in it.