A Question of Geography
When Spanish-speaking users call an automated telephone system in the United States, the resulting conversation might not be entirely in Spanish. This is especially true when the system speaks proper names. How should a customer-service system present the names of cities, states, and foreign locations? Should it translate names to Spanish? When it keeps a name in English, how should it pronounce the name?
For geographical locations, an automated system might choose to translate all proper names, but this strategy quickly runs into problems. Should Salt Lake City be Ciudad del Lago Salado when no Spanish speaker would call it that? System designers quickly learn to make decisions on a case-by-case basis, speaking some names in Spanish and others in English depending on the most useful forms.
How should the remaining English names be pronounced? Should there be a Spanish accent? Should Miami be spoken as the Spanish mee-ah-mee or the Anglicized my-ah-mee? Users who share a level of education or ethnicity can identify strongly with specific pronunciations. Yet those preferences can have negative connotations for other groups. A pronunciation might have political ramifications; it might be culturally insensitive, disparaging, or naïvely discriminating.
Some pronunciations generate strong responses in users, while others have subtle effects. System designers must find a middle ground to ensure optimal results. By manipulating the subtle effects, a designer can refine communication and project a desired image.
In deciding whether to leave a word in its original language or to find an equivalent in the target language, a responsible designer should consider many factors and balance their sometimes seemingly contradictory effects:
Origin of Callers
The U.S. is a country of immigrants. According to 2000 census data, 15 percent of the total U.S. population is of Hispanic origin, and 40 percent of Spanish-speakers in the U.S. were not born there.
The country of birth influences the way people pronounce city names. A person raised in a border town of northern Mexico is probably more familiar with the English names of U.S. cities than a person raised in Chile. He may be more comfortable referring to North Carolina in English and not as Carolina del Norte.
Generations
Recent immigrants may not be familiar with the English names of cities. They might feel confused or inhibited, and this reduces the effectiveness of the system. A Spanish speaker who has lived in the U.S. for only a few years might prefer Nueva York, while a second-generation immigrant is probably more familiar with New York City.
Culture
American television and movies seem omnipresent in Latin America; in some cases, the English parlance becomes the de-facto language for city names. This effect is generally limited to commonly depicted cities, like when saying L.A. instead of Los Angeles, while lesser-known cities are unaffected.
Social Status
Using English names can be trendy and viewed as a sign of a person’s higher educational level or social status. For these users, English has a positive connotation that can elicit greater cooperation with the automated system. Conversely, these same users might perceive Spanish translations as condescending or prejudicial.
Political Correctness
Language choice has ramifications when users are highly politicized. As such, using an English word instead of a Spanish one, or vice versa, can elicit cooperation or complaint.
Corporate Image
Companies generally want to portray a certain image to their customers. A distinctly Hispanic image can stimulate the nationalistic pride of customers, and vocabulary choices are a tool for projecting this image. Which is more compatible with the corporate idea: a pure Spanish word choice, a Spanish word assimilated from English, or a Spanish-accented pronunciation of an English word?
Geographic Scope
The geographic scope of the system influences the decision to use English or Spanish names. A broad geography has more location names and a greater opportunity for ambiguity. For example, a system might use the translated Londres (the city of London in the United Kingdom) and the untranslated London (a city in upstate New York).
Translation Feasibility
Some locations translate more easily than others. When assessing a word, these categories emerge:
• A location that has no translation, as in, Boise, Idaho.
• The translation does not change the pronunciation. For example, Brazil (English) versus Brasil (Spanish).
• A location that has an awkward translation. Watertown is one of the most common city names in the U.S., but no Spanish-speaker would refer to it as Pueblo de Agua. In cases like these, overzealous translations can lead to comically stupid names.
• A location, especially one known for its economic, political, cultural, or historic significance, that has a commonly used translation. For example, Rome translates as Roma, and referring to that city in any other way could be awkward for Spanish-speakers. However, there is also a Rome in Georgia that does not benefit from the same global heritage. This lesser-known Rome might be better left in English.
• Country names that can be markedly different in English and Spanish. For this reason, they should always be translated to Spanish. Examples include Estados Unidos for the United States and Suiza for Switzerland.
When a location name is not translated, possibilities for pronunciation arise. Should the system say English names with English pronunciations and accents, with English pronunciations and Spanish accents, or with Spanish pronunciations (for example, ee-dah-ho for Idaho)?
There are various combinations to consider, and decisions can depend on whether the location is inside or outside of the U.S. For example, a system might pronounce Monterey, California, in English with an English accent, and Monterrey, Mexico, in English with a Spanish accent.
Many locations should keep their common English pronunciations. Saying Idaho with a Spanish pronunciation sounds grotesque to Spanish speakers. Locations like this can only be recognized by Spanish speakers when pronounced in English. Forcing names to sound like Spanish risks sounding silly and unrecognizable.
For location names in countries where Spanish is the official language, Spanish pronunciations are the best choice. The system wouldn’t translate names like Buenos Aires or Granada (Good Airs and Pomegranate are uncomfortable translations); it would leave them in Spanish and pronounce them in Spanish.
Many U.S. locations have names that were originally Spanish. This is especially evident in the South and Southwest. No translation is needed for Texas, Colorado, Arizona, or California, but system designers must still consider the pronunciations of cities in this region because using legitimate Spanish pronunciations could confuse Spanish-speakers. For example, Amarillo, Texas, is pronounced amareelow tehksas in English. The Spanish pronunciation amareiyo te-has is not as popular among Spanish-speaking people living in Texas. Other locations invite more subtle decisions: Palo Alto, for example, has similar pronunciations in both English and Spanish, while the English pronunciations for cities like Las Vegas, San Antonio, San Francisco, Los Angeles, and San Diego have been partially Anglicized.
Cities located outside of the U.S. or Spanish-speaking countries represent an interesting challenge for pronunciations. Some names allow a choice, while others do not. For example, for "Leipzig" you can choose lah-ee-ptsihk (German), lah-ee-pzihg (English), or leh-ee-psig (Spanish). In contrast, you would use nees for the city of Nice in France since the English pronunciation nah-ee-s is comical and unrecognizable.
Whether pronouncing a city name in its original language can result in a recognizable word depends on user exposure to the source language or the name of the particular city. For example, someone who knows something about Sweden would naturally refer to a city like Norrküping by its Swedish pronunciation.
On the other hand, people in the U.S. would more easily recognize Paris pronounced in English, and not pah-ree with a French pronunciation.
Using a Spanish pronunciation for English words is sometimes innocuous. For example, in many situations, you can get away with adding a Spanish accent without harm. For words like Washington, pronounced wach-ee-ngtone in Spanish, the difference is mostly cosmetic, and people will recognize either pronunciation. In fact, adding a Spanish accent can sometimes significantly improve the comprehension of some names. Consider the city of Ottawa, where adding the hard "t" of Spanish makes the word significantly easier for a Spanish-speaker to recognize.
However, words like Tahoe become unrecognizable if pronounced in Spanish (ta-o-eh), and Curacao (coorah-sah-o) becomes grotesque when pronounced coorah-k-aho with Spanish phonetics.
When an automated, U.S.-based system supports Spanish interactions, the choices for presenting location names are not trivial decisions. The problem is more complicated than a broad decision to translate every name to Spanish or to keep the Anglicized pronunciations for all names.
System designers should use combinations of Spanish, English, and foreign words. Sometimes, they should use Spanish pronunciations for English words, and sometimes they should say English words with Spanish accents. In all instances, they should make determinations on a case-by-case basis. Designers must assess each name, consider its derivation and common usage, and then make the best choice to encourage their Hispanic customers to continue using the systems.
The critical factors to consider include:
• Caller background, understood in terms of demographics and cultural preferences;
• Name derivation and adaptability to the Spanish language;
• Common knowledge for well-known city names;
• The purpose of the system; and
• The general philosophy of the provider company.
System designers must understand the desired relationship between the application and the customer, and from this make decisions about translations and pronunciations. With each choice, designers refine the projected image and underlying message of both the company and the system.
Jose Elizondo is senior manager for multilingual design at Nuance Communications' North American Professional Services Unit. Peter Crimmin is a documentation manager at Nuance.