Is a Person’s Name Really Important?
Become a member of TranslationDirectory.com at just $8 per month (paid per year)
of Avaya Inc. asks how a company can hope to interact
with the customer if it can’t even get the customer’s
name right! His company faced this problem when building
its dual language caller name ID, a patent pending
technology that allows users to choose the language
in which they view names on their telephones. A name
is a name is a name… or is it when it’s transliterated?
A rose by any other name would smell as sweet, or would it? Names connect people with a face, a personality, a culture and even a family line. Especially in Asian cultures, where names are written in Chinese ideograms, every character tells a story of its meaning and history. So would a person’s name be the same when written out in a foreign language? That would change the individual’s name all together. All humans are entitled to their names, their identities and their individual uniqueness.
A Matter of Human Rights
Imagine if your language used a totally different alphabet, and you couldn't use computers at all because of it.
Michael Everson, a typographer who contributes to the Unicode standard, stated recently in an article in the New York Times, “Imagine how you would feel if your name was François, but there was no ‘ç’ available. You would be irritated that your phone bill came addressed spelling your name wrong. Now, imagine if your language used a totally different alphabet, and you couldn't use computers at all because of it. It's a question of human rights, really.” [“For the World's A B C's, He Makes 1’s and 0’s,” September 25, 2003]
International agreements such as NAFTA, GATT and the telecommunications trade agreements have lowered trade barriers, and the global acceptance of ISO 9000 has established the principle that quality must be defined in terms of the individual customer. Today, as trade barriers fall and quality standards rise, cultural barriers have become increasingly important. The people of the world prefer to work in an environment that is native to their own language and culture, and thus internationalization is critical.
As trade barriers fall and quality standards rise, cultural barriers have become increasingly important.
Here at Avaya, we were faced with the situation described here. That is, the Avaya Communication Manager product had limited capabilities for a person’s name. Our system only allowed characters from the Latin, Katakana and Cyrillic Scripts. In fact, entering any non-English character required a mapping function.
The first step in supporting names in any language involves selecting a character set. We decided on the Unicode Character Set (UCS) as it is a standard that supports all the world's languages and can be used on all operating systems. Since the Avaya Communication Manager runs on multiple platforms, we selected the UTF-8 encoding scheme.
Selecting Unicode and UTF-8 were obvious choices. Now, we had to make the appropriate changes to our software to support UTF-8. While we had to do some redesign and development, UTF-8 minimized the development and testing effort since it is ASCII-compatible. The area impacted the most was internal storage. To accommodate UTF-8 strings, we had to triple the size of all internal data structures used for native names. Additionally, the appropriate UTF-8 APIs replaced standard APIs when doing character checks, such as determining the number of characters.
Besides changes in the Avaya Communication Manager, we also had to add Unicode support to our management software. Since our management software runs on the Windows platform, our customers can now use an Input Method Editor (IME) to directly enter native characters. The management software then converts the data to UTF-8 before transmission to Avaya Communication Manager.
In the Avaya Communication Manager product, a person’s name is used in Caller Name ID. The Caller Name ID feature can identify both the calling party and the called party. Details on the format of Caller Name ID are covered in the ECMA-164 standard. ECMA-164 supports UTF-8 for names so the Avaya Communication Manager did not have to do any encoding conversions since it received the native names in UTF-8.
Dual Language Caller Name ID
Telephone calls are not limited to persons that share a native language.
With our Unicode changes, we now were able to support a person’s name in the Caller Name ID feature in a user’s native language. But telephone calls are not limited to persons that share a native language. We now faced a situation where the called party might not understand the script used in the calling party’s name, or where the called party might not have a telephone capable of displaying the called party’s name.
To solve these issues, Avaya developed a system that supports both a native name and a transliteration of that name. Avaya refers to this patent pending technology as the dual language caller name ID, and this feature is a tremendous benefit to our multinational customers.
The Benefits of Unicode and Dual Language Caller Name ID
Dual language caller name ID is a tremendous benefit to our multinational customers.
To illustrate the benefits of using Unicode along with the dual language caller name ID feature, let’s review the extension name administration and some sample calls.
The following table shows the names that might be used in a multilingual call center in Japan.
Table 1. Multilingual Call Center
NAME1 is a generic term that refers to the existing extension name field. As mentioned above, this field only allows characters from the Latin, Cyrillic and Katakana scripts. However, most users only use English in the NAME1 field.
NAME2 is a generic term that refers to the new Unicode extension name field. The goal is to store native names in this field and the transliteration in the NAME1 field as illustrated in this table.
The Unicode standard encodes characters on a per-script basis. Thus, our software checks the characters in the NAME2 name and sets an internal script tag for each extension name (NAME2 scripts). Additionally, when a Unicode-capable phone registers with our system, it informs the system as to the scripts it wants to receive (Telephone Scripts Supported). The administrator, when adding new extensions to the Avaya Communication Manager, sets the Preferred Language.
With the sample data described in Table 1, the following examples show whether NAME1 or NAME2 is transmitted from the calling party to the called party.
Figure 1. Communication Without Language Boundaries
We achieve worldwide communication of names in the user’s preferred language.
This illustration shows that we can support a person’s name in their native language with a telephone feature such as Caller Name ID. A person’s native name is shared with others capable of reading the script used in the native name. A transliteration of the name is made available to those that cannot understand the script being used. Thus, we achieve worldwide communication of names in the user’s preferred language.
The Most Important Name for Your Business
How can you interact with the customer if you can’t even get the customer’s name right?
As you can see, it is not just a matter of human rights — it is essential for a business that wants to compete in a global market to offer native language support to customers worldwide. According to the IBM globalization team, “ When it comes to reaching the consumer, it is critical that the applications interact with them in their own languages and respect their cultural preferences and business conventions.” (Source: http://www-3.ibm.com/software/globalization/newsletters/ext_1003.jsp)
How can you interact with the customer if you can’t even get the customer’s name right? Therefore, not only is a name important to each individual, it should be the most important name to your business. This means a product must support native scripts, and Unicode is a key building block in accomplishing this.
has degrees in Computer Science from the University Of Illiois and DePaul University. He started with Bell Labs in Naperville, Illinois in 1980 and from 1985 through 1995 worked at Bell Labs' Tokyo location. During his 10+ years in Japan, he worked on numerous internationalization and localization projects. Since his return to the US, Chuck has continued to work in the area of Internationalization and Localization. Chuck enjoys etymology (especially Asian languages) and programming.
Reprinted by permission from the Globalization Insider,
18 November 2003, Volume XII, Issue 4.4.
Copyright the Localization Industry Standards Association
(Globalization Insider: www.localization.org, LISA: www.lisa.org)
and S.M.P. Marketing Sarl (SMP) 2004