There is a world where Harry Potter’s arch enemy is “Du-weißt-schon-wer,” Facebook users click the “Me gusta” button, and the Dude is named “le Duc.” This world is a translated world.
We—the people who make websites—now study almost every aspect of our trade, from content and usability to art direction and typography. Our attention to detail has never been greater as we strive to provide the best possible experience. Yet many users still experience products that lack personality or are difficult to understand.
They are users of a translated version.
When we pledge to embrace the adaptable nature of the web—to make our websites responsive and even future-ready—we’re typically talking about diversity of devices. But the web’s diversity also comes in the form of different languages and cultures.
Translation affects users’ experiences—and our organizations’ success. It’s time we consider translation part of our jobs, too.
Waiting for C-3PO#section2
“Do you want your forum clean like this?”
I had just set up a user forum in French when I stumbled upon this rather bizarre banner. “What makes the forum so clean?” I wondered. “Do they tidy the code every day?” I had to change the language back to English to understand it: “Do you want your own forum like this?”
In French, “propre” means either “own” or “clean,” depending on how it’s used. The rule is simple; any translator would know it. More precisely, any human translator. Google Translate, the system behind the French version of the forum, obviously wasn’t so sure.
It’s not just Google Translate, either. In the 1950s, Alan Turing, the father of computer science, devised a test to evaluate machine intelligence through conversations. The biggest Turing test ever was held last June to celebrate what would have been Turing’s hundredth birthday. The winner was probably the most advanced chatbot ever created, yet Eugene Goostman—as this bot is named—failed to fool the judges 70 percent of the time. When will machines pass the test? In the year 2029—maybe.
This should come as no surprise. Languages are amongst the richest and most complex systems humankind has ever produced. When machines gain the ability to really speak (and therefore translate), it will be possible to use Google Translate in a professional context—and no doubt we’ll also have Google Design and Google Copywriting by then. But today, Google Translate is to translation what the auto mode is to photography: a quick-and-dirty solution. It comes in handy when you need to get an idea of what’s being said about your project on Weibo (China’s version of Twitter), but it isn’t a good option when you need to translate your website into Spanish.
While we’re waiting for C-3PO, we need professional translators. We must also acknowledge their creativity and recognize them as peers.
Great design deserves great translation#section3
Translating is a respectable, valuable, creative and worthwhile use of a human brain.
Le Big Lebowski is a masterpiece. I would even argue that it surpasses the original. Everything is just perfect: the dubbing, the humor, the dialogue. The translators retained the essence of the film while adapting it for an audience that has no idea what a “dude” is. They managed to translate not just the words, but the Coen brothers’ genius as well.
E-mail service provider MailChimp is a masterpiece, too. Aarron Walter’s UX team has succeeded in creating a unique personality. Much of this personality manifests itself through copy: the greetings from Freddie, the company’s joke-cracking mascot; the always-relevant error and help messages; and—above all—the “funny but not goofy, informal but not sloppy” voice and tone used throughout the application.
Now, if MailChimp were to be translated into Spanish, Russian, or Chinese, what would become of this personality? What does it mean to be “informal but not sloppy” in Japanese? Should the mascot’s name still be “Freddie Von Chimpenheimer IV” in German, or could that be misinterpreted? Can you greet an Indian user with “Hi. You could be a part-time model”?
There are no easy answers to these questions. Translating is walking a tightrope. The challenge is to remain faithful to the original design while adapting it for a new audience, for a different culture.
If you think a machine can do this, take a look at this Google translation of MailChimp’s success message, “High fives! Your list has been imported”:
Cinco años de alta! Su lista ha sido importado.
Show that to a Spanish-speaking friend and you’re sure to get a bewildered look.
The road ahead#section4
The web is home to plenty of innovation. But when it comes to translation, other industries are far ahead.
If we want to reap the benefits of translation, we must learn what it takes to do it well—and why it matters. Let me give you two examples.
Linguistic validation#section5
The pharmaceutical business may not seem to share much with web design, but it has one best practice that could inspire us: linguistic validation.
Introducing a new drug into the market is a complex and controlled process that includes a long series of trials and reviews. Some of these tests involve the patients themselves, such as Patient-Reported Outcomes questionnaires, which assess whether a drug has actually improved a patient’s quality of life. These questionnaires are written in English by clinicians and then translated into hundreds of languages.
Ordinary translation is usually a two-step process: translation then proofreading (some even skip the proofreading). The linguistic validation of patient questionnaires has a few more steps, such as doing both forward and backward translations and pilot testing.
Why such a complicated and costly process? Two reasons: First, the original version is a precise research instrument. Nothing has been left to chance. Second, it is essential for patients to perfectly understand the questions, because what they report will serve as scientific data. The questionnaire must therefore be intuitive and patient-friendly.
Thoughtfully designed products, user-friendly interfaces—aren’t these what we aim for? If we care equally about all our users, it’s time we start thinking of translation as something slightly more complex than a word-to-word job.
Cultural expertise#section6
Raving Rabbids is a humorous party game designed in Ubisoft’s Paris studio. The development team includes a localization specialist in charge of the game’s eight localized versions. She works hand in hand with designers to ensure their jokes, references, and altogether craziness are translatable. For the U.S., Rabbids’ biggest market, a duo of Americans from Nickelodeon even gave the team a little extra cultural insight.
It costs millions of dollars to produce a major video game, and even more to target international audiences. Because playing a game is such an immersive experience, the teams behind Rabbids and many other games have found that localization specialists are critical. They are not given a finished product to adapt—they take part early in the project, as their feedback on cultural matters may profoundly change the game’s design.
The game industry prefers the term “localization” to “translation” because the latter is too often restricted to text. This says a lot about how seriously game studios take cultural expertise. Because they know a cultural misfit can stall a game’s chances of success—and they know for every dollar invested in localization, there’s a $25 return.
Because they know that translation—sorry, localization—is UX.
Translate early, translate often#section7
Most startups employ what could be called the lemonade tycoon approach: Start in your neighborhood, amongst the people you know; this is your best bet. Get it right at home before expanding into far-off lands.
I’m not saying you shouldn’t start in your own country. Local knowledge is priceless. But why wait to internationalize? Unlike lemonade selling, the web is international by nature. From day one, your website will be accessible to any person on this planet.
What’s more, procrastination has a cost. According to Smartling, a translation software company, “it can take companies 12-18 months to internationalize their code and launch their first foreign language site, absorbing much of the company’s engineering resources.”
Companies face the same problem when they develop a mobile version of their site afterward. Good thing many now adopt a “mobile first” process.
Perhaps they should consider “foreign first,” too.
It’s a big world out there#section8
When you come from a non-English-speaking country, as I do, a “foreign first” approach is very likely to mean “English first.” But what if you’re based in New York, Manchester, or Auckland? Which language should you go for?
The answer is actually not to think “language,” but rather “opportunity” and “culture”—as these three companies have:
- Wufoo is a popular form builder from Tampa, Florida. At the beginning of 2012, it launched Wufoo Español, its first foreign version. You won’t find the Spanish version at wufoo.es, but at wufoo.com.mx—because it saw an opportunity in a neighboring market, and language was a means to reach that market. Besides, Wufoo doesn’t mix up language and local culture: It plans to roll out additional localized versions for Spain and Argentina.
- CanaDream is a Canadian RV rental company whose website is available in three languages. English and French are obvious choices, but the third one is trickier: German. Again, the company saw an opportunity—Germans love RV travel. But German people generally speak good English, don’t they? Yes, many do—but they will still prefer a company that attends to them in their own language.
- Bla Bla Car is a car-sharing service born in France. Here we can see that “English first” isn’t always the rule. Bla Bla Car’s first foreign version was in Spanish. The car-sharing market was less competitive in Spain than in other European countries, which gave Bla Bla Car the opportunity to test-run its internationalization before moving on to other markets—which it eventually did. Car sharing is getting more and more popular in Europe, and Bla Bla Car aims for leadership in the region—and in a multilingual area, this has required translation to seven languages and counting.
Bargain-basement market research#section9
Most startups can’t afford international market research. That’s why they focus on their home market. But just as Paul Boag taught us about bargain basement usability testing, we can find affordable market research techniques, too.
Once you’ve settled on a country to target, go to ProZ and look for a translator or agency based there. Brief her about your project and send your prototype or an access to your beta. Ask her to translate the key screens. Even at this stage, you can get lots of feedback: “Are you aware your app name can hardly be pronounced—let alone remembered—by Brazilians?” “I’m sure having Acme Inc. as a client is a great reference in the U.S., but nobody knows them here.” “This photo of a blond-haired, blue-eyed guy probably won’t resonate with a Turkish market.”
Then ask your translator to run a user test using her network of proofreaders. You don’t need hundreds of people—with only ten participants, you’ll uncover any major cultural faux pas. You’ll also gain a general understanding of whether people are interested in the project, what their main questions are, and whether they like the visual design.
Finally, discuss your personas with the translator: Maybe Harriet should be renamed María and relocated to Valparaiso. And what about adding Hugo, the typical backpacker from the Netherlands? With localized personas, all your users will be given equal consideration throughout the design process.
Of course, you’ll need more precise data eventually. But this quick-and-dirty research is enough to get you started. You’ll iterate from there.
Your new teammate#section10
When you start translating early, you make the translator part of your team. Chances are this will be a very rewarding experience. At Novius, my company, it’s changed the way we work.
For major projects, we now create and feed a glossary—or as I like to call it, a “style spreadsheet.” CSS stylesheets are understood by both designers and developers and guarantee style consistency across an entire website. Similarly, glossaries are by and for the whole team and ensure the consistency of content. Just like you want a color scheme that’s thoroughly followed, you also want to make sure “module,” “plugin,” and “extension” aren’t all used to refer to the same concept. Le fond et la forme.
We have also learned that a quality translation begins with the code. Developers strive for reusable code, and strings are no exception. Depending on how a developer handles them, he could make the translator’s job straightforward, or virtually impossible.
When dealing with sentences like, “1 person has this question” and “X people have this problem, including you,” translators are often asked to translate strings like: “person has,” “people have,” “this,” “question,” “problem,” and “including you.”
Even with context, deconstructing these sentences is a translator’s nightmare. For languages with gender, the string “this” is untranslatable (e.g., esta pregunta and este problema in Spanish). In many languages, like Russian, plurals take several forms (e.g., for the plural “persons,” you would say four челове́ка, but five челове́к). And the list goes on.
Since language isn’t code, developers and translators have a lot to learn from each other. Translators will tell them the software they use has translation memory, so there’s no need to avoid repetition. They will discuss how to handle variables in text. They will also decide together which internationalization system (such as gettext) and text file format (like XML or PO) to use.
Not a one-off thing#section11
I won’t lie to you. Once you’ve translated your website, you’re in for good. People don’t care that they’re using a translated version. For them this is the only version. So you’ll have to keep translating.
They will hate being considered “second-rate” users. Once you’re out of beta, 90 percent translated is not OK. How would your users feel if every website update resulted in a buggy mobile version? Users of translated versions experience this all the time, with English text suddenly popping up out of nowhere. To make it worse, the newest features—proudly announced and long-awaited—are usually the ones left partially translated. Users do get the message: You’re not important enough for us to prioritize translation quality.
While good localization boosts conversion rates, bad or partial translation may ruin a user experience, giving users an uneasy feeling about the whole company: If they can’t even get their website right, how bad will the customer support be?
In fact, I recently chose not to purchase a service because of a pricing page that proclaimed, “Give a price to these ladders with your growing company.”
Guess what it was selling? Translation software.
A multilingual web#section12
If I am selling to you, I speak your language. If I am buying, dann müssen Sie Deutsch sprechen.
The language of the web is English as much as HTML. If the web had a capital, it would be somewhere around San Francisco Bay. Web professionals worldwide use English expressions in almost every sentence: Like, browser, responsive, Tweet, SEO, etc.
However, 73 percent of internet users don’t speak English, and their numbers are growing. We now enter the age of glocalisation.
In our move toward universal design, we must not forget languages and the people who master them. “Translating is writing,” said French writer Marguerite Yourcenar.
Today we can also say, translating is designing.
Fantasic article. Localisation is truly a discipline within web design that needs more attention and respect. Native English speakers can often forget the annoyance that is associated with untranslated content and design.
With Mandarin set to overtake English as the most prominent Internet Language in the next two years and most of the worlds Internet users originating from Emerging markets by 2016 It’s time to taking localisation more seriously.
This is an excellent article and points out the single most important issue facing any organization reaching across a border: communication.
I’ve learned several things managing the roll-out of multiple international sites.
First, geo matters. Spain Spanish is not Mexican Spanish; France French is not Canadian French. Whenever possible, we localize for _regions_, not language. This annoys many people who think “wtf … it’s just spanish” but there is no quicker way to alienate an audience than to promise to speak their language and then literally do not speak it correctly.
Second, many companies need to change their focus from “translation” to “localization”. Large translation houses like SDL or Lionbridge focus on mass-quantity, glossary-driven translation that goes sentence by sentence (or string by string for software). For error messages, this is acceptable — but so is Google Translate. For persuasive content or anything involving concepts or abstractions, this is the road to failure.
Proper localization is culturally sensitive. It takes time, and it usually requires native speakers. It is, at its heart, copywriting, because often entire sentences/paragraphs need to be rewritten to have good narrative flow.
One final point. While good translation is good UX, good localization is good accessibility. Making websites consumable to all users is as much about language as it is the technology, and moving from language to another is the single biggest point of failure.
Great article. Best I’ve read on ALA in a long time.
Shame it doesn’t deal with how to decide which language to show a user by default—something so many sites get utterly wrong (I’m staring at you, Google, you idiots).
Look to the web community in places like Belgium where they’ve been creating sites in 3-4 languages by default for years.
A lot of the lesson have already been learned.
It goes beyond language though. Often services that need to be integrated into a site ( e.g. certain payment processors ) simply aren’t available locally.
Excellent article. I’ve developed an iPad app for a local dental system in the Milwaukee WI area, and part of the requirements was to provide three to four language options. Aside from English, this also has to cater to Spanish and Hmong (which, if anyone has had to translate, is not the least bit straight-forward).
Thankfully for me, as the developer, most of the translations are handed to me in the customer-provided data, but it’s my responsibility to ensure that I have all the translations and once translated that “Remember, you can tap the ‘Next’ button to advance to the next available question” still fits in the same help box, no matter how the tablet is oriented.
The application was launched with three languages, with support available for a fourth.
@all Many thanks for your kind words. I’m glad we can talk about translation and localization amongst web makers.
@Kevin Yes, I do agree, translation is an accessibility issue. In some multilingual countries or areas, you may even be required by law to make your websites available in several languages (e.g. EU language legislation), the same way legislation exists to enforce accessibility—for people with disabilities (e.g. RGAA in Québec).
@Gilbert Thank you for pointing this out: Europe and countries like Belgium have a lot to teach us about multilingual design. When on a daily basis you’re exposed to several languages, you begin to see translation as something natural, a requirement rather an commodity.
Like other commenters above, I also think localization is ignored too often and could use more attention (much like security, by the way!)
Your article really helps to draw attention to these issues. However, I’d really like a more technical in-depth article too; as a programmer, I’ve seen a few systems for translations, but most of them are annoying or awkward in some way or other.
If you could point out some examples or best-of-breed libraries available for various languages, I’d much appreciate it.
Also, what advice can you give to small shops who need to deal with localization? In the past, we’ve sent out texts to a professional translation agency to be translated to English (we are Dutch), but the results were so horrible we could’ve done better ourselves! Furthermore, this company didn’t know how to handle GNU Gettext .po-files (perhaps not many translators need to work on software translations?), so we had to mess around with Excel sheets and such. This was definitely a bad experience.
@Peter Bex. Using an agency (that isn’t specialised in what you do) is generally a bad idea (I’m a translator who works for agencies: I know).
Your list of strings will arrive, without context, in the inbox of a random translator. They’ll do their best, no doubt, but asking the client questions is generally discouraged because everything has to be mediated by the agency, and they’re typically dealing with dozens of translators and hundreds of orders: they don’t have time for that shit. And the next order will likely end up with a different translator who has no idea about the first.
Agencies are very rarely the right solution, unless you need a ridiculous amount translated in short time.the translation will.
If you want a high-quality translation, you really have to find yourself a translator that understands what you’re doing and provide them with sufficient context to make a meaningful translation. And, most importantly, you need to have your own list of translations: if you don’t send your translator a list of the terms you’ve already had translated, you’re going to end up with an app with multiple terms for the same thing.
It’s extremely hard to communicate to a (monolingual) client the difficulty and subtlety of translation.
An example that sticks in my mind is Macromedia’s horrid translation of Flash into German: both “layer” and “level” were translated as “Ebene”. Very clearly a case of the client failing to engage meaningfully with their translator.
I wholeheartedly agree that translation is UX. What’s also true is that the *business of translating* is largely dependent on UX.
Different types of collaborators in a given translation workflow need a different UX for each to do their own specialised task.
Think about:
* *Software developers* who need to manage keys and strings
* *Content owners* who need to craft the original message and set the rules for the translations
* *Translators* who need to leverage glossaries & memories & context to deliver the perfect translation
* *Proofreaders* who need to see what’s changed, by whom, and why
The challenge is to design the UX of translation workflow tools to cater for these disparate needs without cluttering everyone’s experience.
Many err in favour of one particular group of users while penalising, burdening or compromising the others.
“Locale”:http://www.localeapp.com is a workflow tool attempting to solve these problems for *Ruby & Rails apps*. Delivering a UX that facilitates the translation process is the most challenging aspect.
Here’s a great blog post by Jeff Casimir entitled “Avoiding the Tar Pits of Localization”:http://blog.localeapp.com/2012/11/21/avoiding-the-tar-pits-of-localization-with-jeff-casimir/ which deals with some of the problems and best practices when internationalising and localising Rails apps.
Cheers
Martin
This is simply a brilliant article. For me however, it underlines the need to collaborate on a large scale to make the whole process a lot easier and even, perhaps one day, enjoyable.
Also I wanted to reply to @Peter Bex, @deanishe and @LocaleApp about what is technically wrong with the localization process/tools (comments 7 to 9)… Of course I’m completely biased since I’m part of a team that made Langur, a new software i18n system… That said, as far as we’re concerned, the elephant in the i18n room is *context*.
As so eloquently stated by deanishe, it is simply impossible to produce quality translations without the context of use of whatever it is you’re translating.
We believe the future of localization / internationalization is allowing translators to translate _in context_, in the app itself. This means translators see the _when_, the _where_ and the _why_ of the strings they are translating, in the exact same way end users will see them when they use the application.
By doing this, you eliminate a lot of the hassle related to translations, you augment quality dramatically and you avoid things like untranslated stings and layout issues.
I would say this is a great article and discussion as well , I have learnt a lot here .
Hope to keep writing such a good article.
This is a very interesting discussion indeed!
I wanted to add a few things regarding outsourcing and software.
*Outsourcing translation* is not much different than outsourcing graphic design or development. Say you need to hire someone to design a logo, are you happy with just sending a brief, not talking to the designer and receiving a logo with little room for change? This is called low-cost graphic design and you’ll find plenty “your logo for $100” offers.
Likewise low-cost translation is widely available: you send a document, you don’t talk to the translator and you get a translated document in return.
Is this the level of quality you’re aiming for?
At Novius we prefer to build lasting relationships with both designers and translators. If you choose to work with an agency, chances are you won’t have much interaction with the translator. Which is a shame as good translation—like good design—starts with team work.
*About localization software and platforms*, we have used and tried many different solutions. Yet we still haven’t found THE perfect solution which would offer all the following key features:
* Collaborative translation and workflow. Translation like coding is a social activity. We need GitHub-like functionalities: comments, issue-tracking, version and quality control.
* In-context translation, as discussed above by Langurius.
* Translation memory. Don’t be mistaken, TM is not a translator thing. This is an important asset for your business. You want to be able to share it across different projects and export TMX files (Translation Memory eXchange).
* Translator-friendly UI and developer-helping tools (e.g. APIs)
Further readings on “deconstructing these sentences is a translator’s nightmare”: “Working with Composite Messages”:http://www.w3.org/International/articles/composite-messages/Overview and “Re-using Strings in Scripted Content”:http://www.w3.org/International/articles/text-reuse/Overview
BTW, there are no accent marks in Russian language (except in dictionaries for non-native speakers). 4 ????????, 5 ???????.
I have been a translator and have worked with clients who run multi-lingual sub-domains using the Google translate app. No one it seems has the budget or the time to speak to anyone in their own language and yet they demand to have a web presence and the ability to collect payments. There is a big difference in speaking with one voice and having to use the only voice. Using proper, idiosyncratic local language increases ROI because it automatically shows respect and when someone is treated with respect…they tend to buy the product.
Great article. My other half is a translator and has often received spreadsheets of terms that are completely out of context and nigh on impossible to provide reliable Japanese translations for. And Japanese sentence structure works differently from English, so it’s not as simple as string replacement.
The suggestion to work directly with translators would be music to my partner’s ears: it would make the work much more interesting while cutting out the greedy middlemen agencies (if you find a good translator, re-hire them privately).
Excellent article. I was almost cheering along with you at times, because you said things that I’ve thought for years. And you said it in an extremely accessible way–one that I hope to share with stakeholders to help them understand my localization concerns.
Antoine: Your ‘wish list’ for collaborative language-focussed content multipurposing tool already exists. Our solution (qarto.com) is one of them, but there are a few others out there too.
Get in touch if you’d like to know more.
What an amazing article, Antoine. I subscribe 101% of what you said. Having a localization specialist in the early stages of the development cycle is just essential nowadays.
Keep up the good work!
Cheers,
Pablo
Great article! All good UX is contextual. Language included. Context of course, is an issue faced, ironically by both the UX and L10n domains… http://www.slideshare.net/uvox/context-of-use-and-use-of-context-localization-and-ux However, the L10n industry can help itself by promoting techniques such as L20n, moving with the times instead of far too often demanding dumbed down strings devoid of any real meaning for any language…
Vraiment interessant, on est en plein dedans avec notre soft. Etant le seul francais dans la boite je suis devenu le traducteur officiel. Je bosse avec l’IT, et on se creuse la tete pour trouver la meilleure solution. Mais toutes tes remarques sont tres interessantes. Merci pour l’article.
Large scale thinking like this is important, but we still have a long way to go in terms of communication even within our own community. For example, What do you call those text boxes that have the little up and down arrows to the right or left? I just got done doing some research on the trending names for those little widgets. Here are my research findings…
http://uxfindings.blogspot.com/2014/06/is-numeric-spinner-best-name-for-this.html
…and what I learned is that with each step forward, we potentially introduce yet more communication hurdles. Example: The “spinner” can be interpreted as “an animated icon that communicates to the user that a page is loading”, or it can be interpreted as the the infamous “numeric up/down widget”.
ugh… commend you on the great article, but I feel like the more I look at the topic of communication, the more flabbergasted I become at how we are able to even really make it through simple conversations.