Speech Technology Magazine

Webinar -  Everybody's Talking: The Path to Conversational Customer Care

Register now for this September 26, 2017 Event!

When in Rome...

To successfully launch a speech system in Italy—or any other part of Europe—translations should be done at the local level.
By Leonard Klie - Posted May 3, 2010
Page1 of 1
Bookmark and Share

The European Union is an economic and political bloc of 27 independent countries, with a combined population of 501 million. While many of these nations share common policies on trade, agriculture, the environment, and regional development; joint actions on crime and terror; a central Parliament, bank, and court of justice; and even a single currency, they are far from sharing a common language. In fact, among the countries that comprise the European Union, there are 23 official and working languages. There are also about 150 regional and minority languages, sublanguages, and dialects spoken by as many as 50 million people.

Add to that the 25 or so other countries—many of them former Soviet republics that formed the Commonwealth of Independent States (CIS)—that are part of the continent but have not joined the European Union, and the numbers probably double.

For all of their diversity, across all of these countries one point is universally true: If customers are going to spend their hard-earned money on a company’s products and services, then they expect the company to deliver information in their preferred languages. For companies doing business in Europe, appealing to customers in their own languages can lead to happier customers, more sales, and a better return on their marketing investments.

But with such linguistic diversity among countries—and sometimes within different parts of the same country—designing a speech system for the European market is certainly a daunting task. Communicating to such a diverse audience truly is as complex as it seems. 

“You can’t assume that you’ll be able to reach an entire population with one application,” says Jose Elizondo, senior principal of multilingual voice user interface design at Nuance Communications.

“The only thing you can assume is that everything you assume is absolutely wrong,” adds Sue Ellen Reager, CEO of @International Services, an Atlanta-based translation and localization firm.

Meeting the Locals

Nonetheless, many companies that try to expand their systems into Europe make the process harder than it has to be. But a number of things can be done to make the process less painful. The first, and most obvious, is enlisting the help of the local community.

“If you’re going to sell a product in Europe, particularly a voice product, you have to do the translation over there,” says Marcus Graham, CEO of GM Voices, a provider of professionally recorded voice prompts for telecom applications worldwide. Though it’s based in Alpharetta, Ga., the company has produced recordings in 90 languages using voice actors from all over the world, and it recently inked a deal to provide the voices for all of SpeechStorm’s IVR demos and customer deployments in Europe.

“If people are going to use it in Germany, you need to do [the translation] in Germany,” Graham says. “It’s not trivial. You’ve got to talk the language and be embraced by the local community if you’re to have any chance of success. If it doesn’t sound local, people just won’t buy it.”  

Making an application “local” implies so much more than just the language and its intricacies, which can be daunting in their own right. “There are very specific cultures about how people use technology, what’s been available to them, and their attitudes toward it,” Elizondo says.

Such applications need to be designed with political, economic, social, and behavioral factors in mind, as well. “You need to know the full composition of the people you’re trying to reach,” Elizondo says.

As an example, he says an airline can’t assume the person calling its IVR to check the status of a flight is the passenger. “In the U.S., I make my own calls, but in Europe there’s much more of a family, communal experience, so you’ll get daughters calling on behalf of their parents, wives calling for their husbands, etc.,” he states.

Tradition also dictates the types of questions an IVR can—and should—ask. What you’re asking for should be relevant to the country involved. For example, you wouldn’t ask someone in Iceland for his Social Security number because that’s not something he would have. Furthermore, he’s likely to feel uncomfortable giving out his phone number, but wouldn’t hesitate to rattle off his bank account digits, according to Elizondo.

“You have to do your market research,” Elizondo says, “because you’re dealing with language, culture, caller behaviors, caller relationships, etc. You have to look at your customer base. You need to be able to understand caller demographics and be aware of them so that your grammars can understand what they’re going to say.”

Automation’s Out

The experts universally agree that getting an IVR script to sound local cannot be done with an automated translation program. Although such programs have improved greatly—they might be adequate for some projects, such as knowledge-based articles, online training materials, FAQs, forums, and product alerts—they’re still far from perfect and are unlikely to put human translators out of work any time soon. Information like advertising copy, high-profile Web content, and key messages delivered via an IVR should be sent to human translators because the information contains a lot of nuances and is intended to influence decisions. 

In the case of an IVR script, automated translation becomes even less effective because the application has two parts: pre-established prompts and responses the caller is likely to provide.

“Translation engines are not even ready for anything like this—not for something that requires customer interaction,” Elizondo says. “There are a lot of instances where just translating a prompt will not cut it. It’s not just a matter of how to say something in Spanish. It’s more a matter of how to ask this question to get this response.”

For that, “machine translation will not work at all,” GM Voices’ Graham adds. “There are too many nuances and variables that it will not work. You can’t do automated.”

Hannah Grap, director of corporate marketing at Language Weaver, a machine translation provider based in Los Angeles, agrees. “IVR scripts are highly localized content,” she says. “You have to make sure that your menus are right. Some really bad things can happen if you have an error and people get routed wrong.”

With localization, user expectations play a big role. “It’s difficult to do with a machine,” Grap adds. “It’s best left to a human translator.”

Still, plenty of people have tried—and failed miserably—to use just machine translation technologies. “I can easily see people saying to do everything in English, run it through a translation engine, and have it spit out with [text-to-speech] in Italian using prerecorded segments that they string together. But I want [the IVR] to sound like I’m in Italy, and I need something better,” says Moshe Yudkowsky, president of Disaggregate Consulting.

Whom to Hire

When hiring a translation and localization expert, it’s important that the person is a native speaker, and ideally he should live in the area where the application will be used. “You could use people from there who are living in the U.S., but over a period of years you could lose your edge if you’re not using the language every day,” Graham warns. “If they’ve been removed from the culture for a few years, it could erode their ability [to provide an effective translation].”

The accent should also be considered. “You might have a fantastic, technologically superior system that sounds like a joke,” Elizondo cautions, noting the wrong accent can put off a caller more than anything else. He equates it to a company using a southern U.S. accent as representative of all Americans.

It’s also advisable to find someone who understands both the language and the speech technologies involved, “someone who knows how certain things affect the grammars, and how they can change the script and call mapping,” Elizondo adds.

“The only way to do it right is to get someone who knows the language inside and out, and get him involved right from the start when you’re developing your application,” Yudkowsky suggests.

Help is also available from the European Union, which supports emerging speech and translation technologies by providing grants to developers. Additionally, the European Union maintains a language database, called InterActive Terminology for Europe, which contains more than 8.7 million terms in the 23 member languages and Latin. The database, which can be accessed via the Web at www.iate.europa.eu, allows users to type in their terms and source and target languages, and even gives users domain choices, such as politics, economics, or education. The entire EU database of dictionaries is donated free of charge to any company striving to improve automated translation. 

Another helpful tool is a localization engine developed by Reager’s firm, @International Services. The Web-based System Localizer allows developers of Web, speech, and kiosk applications to automatically plug in certain linguistic elements, such as date, time, and number configurations, pronouns and possessives, plurals, proper names, phone numbers, currencies, addresses, and about 110 other linguistic headaches that can vary from one language to the next. The tool, which contains a localization library with 200 languages and dialects, pulls the source code, converts it for the new languages chosen, and reinserts it back into the programming layer.

Bank on It

Jan Smith, a strategic program manager at Bank of America, has used the System Localizer for translating her company’s applications into other languages.

“Playing out a date or amounts is where you can really run into trouble,” she says. “Then there are cultural things that you have to bring to bear and intricacies to each language.”

Sure, running an application through a localization engine adds another step to the process, but the costs of not doing it are far worse, according to Smith. “The whole point of internationalization is reaching out, and if you do it without the sensitivity that’s required, you can wind up looking really bad,” she says.“It ends up being a lot more than people bargained for, but it doesn’t have to be terrifying if you have the right people with you.” For Smith, @International Services filled that bill. “@International Services really understands concatenation issues and how IVRs are designed,” she says.

That’s an important point, no matter whom you trust with your translations. “The company should understand how to design an IVR and how IVRs are pieced together,” Smith says. “If you’re working with a translation agency and they’re not asking those questions, they’re just not doing their jobs.”

But that responsibility does not rest solely on the translation company. Smith says you need to know and understand your own application first, and should be able to fill in for the translator what comes before and after any prompt to be translated. Doing so provides the translator with a context, “so they have the complete thought, not just a single phrase for translation,” she explains. “The more research and organization you can do before going into a project, the smoother the outcome will be.”  

Mounting Costs

But as with any speech-related project, budgets are always a top concern, and correctly translating and localizing an application can be expensive. When all of the elements—translation, localization, application coding and recoding, voice talent, etc.—are factored in, costs for a bank-by-phone application, for example, in multiple languages can mount to between $250,000 and $1 million in a hurry. 

Giant enterprises with operations around the world and smaller companies trying to go global are all being drained by the costs of producing international versions of their speech applications, often in dozens of languages. Many wind up skipping a lot of languages, or drop translation altogether, because of the costs. 

So if you’re thinking of including multiple languages in your IVR, it behooves you to sit down and make a plan early. There is a difference of opinions, though, regarding whether it is better to code for each language separately or to do them all at once.

Reager leaves no doubt about which side she takes: “There is a way to program [an application] once and have it move across languages, but that’s not what’s being taught,” she says. “The first reaction is to go from English to Spanish, then English to German, and each requires new languages and new programming. Then the bills mount and the chaos mounts.”

The biggest part to reining in costs is limiting the number of people involved. “The more people involved, the more detrimental it will be to the company,” Reager says.

At the very least, it wouldn’t hurt to have a native speaker of the language review the script for any glaring errors. “It makes sense to have a native speaker look at and debug the script,” advises Aneeq Hashmi, lead telecom engineer at Pronexus, which has developed a toolkit for building IVRs.

The issue of cost is also directly tied to the amount of content that has to be translated. Here, most companies can’t afford to scrimp, but that’s precisely what many do. When customers decide to purchase a product and enter into a relationship with a company, they expect their needs will be met in the same way when they require additional information about the product, or should they have problems using the product after the sale. But many companies translate only their presales content into several languages; then, once the customer is on board, he has to navigate the technical support IVR in a language other than his native tongue. Not only is this frustrating for customers, but it can also prevent them from fully enjoying the company’s products. This leads to a slowdown in repeat business, fewer referrals, and more work for marketers. 

Take a Test

Efforts toward localization also need to go well beyond the application development stage. Even after an application is complete, it’s not enough to accept the translation and move on. “Regardless of whatever method you used to create that first draft, you have to subject [the application] to usability testing, letting real users interact with the system to see where they get stuck or don’t understand something,” Elizondo suggests.

Waiting until after the system goes live is too late. “Most times, companies only learn about a problem after the system is done, and then it’s expensive and time-consuming to fix,” Reager says. “It slows down system deployment so much.”

In the end, translation and localization efforts often come down to a decision to offend the smallest number of people. “It’s really up to [the company] who it wants to communicate with and what kind of budget it has,” GM Voices’ Graham says. “You can do one language that most people in a country will understand, or you can go more granular if you have the budget.”

Graham points out that even in the U.S., there are a number of types of Spanish spoken. “You come up with one version that most people will understand and will not offend too many people.”

So how do you come to that conclusion? “It’s not an exact science, and you have to make compromises because of the uniqueness of each language,” Graham says. “You have to look at your potential in a market, and the upside versus the investment.”

And above all else, be respectful of the end user, Elizondo says. “He shouldn’t be made to feel like a second-class citizen,” he says. “As long as you approach it from that angle and you’re not just pushing people aside based on percentages,” success can happen.

Sidebar: Localization Lacking

The story of Chevy’s difficulty in the 1970s in selling its popular Nova model in Mexico because the car’s name translates to “it doesn’t go” in Spanish is well-known, but here are some other past marketing foibles that are just as amusing:

  • A past Coors slogan, “Turn it loose,” was translated into Spanish to read “Suffer from diarrhea.”
  • Clairol introduced its Mist Stick curling iron in Germany, only to find out “mist” is German slang for manure.
  • Colgate introduced a toothpaste in France called Cue, which is also the name of a notorious porn magazine.
  • An American t-shirt maker in Miami printed commemorative shirts for the pope’s visit to Spain. Instead of saying, “I saw the pope” (el papa), the shirts read, “I saw the potato” (la papa).
  • In Italy, a campaign for Schweppes tonic water translated the name as Schweppes toilet water.
  • Frank Perdue’s slogan, “It takes a strong man to make a tender chicken,” was translated into Spanish as “It takes an aroused man to make a chicken affectionate.”
  • Scandinavian vacuum manufacturer Electrolux used the following in an American ad campaign: “Nothing sucks like an Electrolux.” 

Source: GM Voices

Sidebar: English-to-English Translation

Taking a system built in U.S. English and translating it into U.K. English presents its share of problems. The same catchy turn of a phrase used in an application for a New York audience might be lost on someone in London. Similarly, a slang term in Kent, England, is likely to mean something entirely different to a horse farmer in rural Kentucky. 

“Americans assume that U.S. English products can be transported to England, and that’s just not the case,” says Sue Ellen Reager, CEO of @International Services, an Atlanta-based translation and localization firm. “Our approach to things in the U.S. is so much different.”

As an example, she notes how the British are more rigid with grammar and verbs and prefer less hype and showmanship in their marketing and training materials. “In the U.S., things can be peppy and high-energy, and in England they’re more formal,” Reager says. “Then there are features that Europeans expect that Americans do not even think about.”

Also, there are many word differences between U.S. English and U.K. English: In the U.K., for instance, the term hash key is used for what Americans call the telephone’s pound key. 

Even how the British structure their dates is different—in the U.S. the norm is month, day, and year, while in the U.K. it’s day, month, and year. 

Page1 of 1