Helping Computers Help Us

As the U.S. product manager or sales representative, life is good. Your product is selling well and has a significant market share and user base. But, on the other side of the world, life is not as good for your Japanese sales team. While your product is reliable, has more features then similar products and has proven itself over the last twenty years, sales in the Asian market are not quite meeting company expectations.

Management in the U.S. wants to know how to improve sales in the Asian market. The reply from Japan is that customers expect a product that meets their cultural expectations, with native language support as the most important item. As Figure 1 below illustrates, an end user may be overwhelmed when confronted with English messages.

Figure 1. Incomprehension and Customer Dissatisfaction

This was the situation Avaya found itself facing with its flagship product, Communication Manager. This product evolved from System 75/85 communication systems, first released in the early 1980’s. In later years, support for Latin and Katakana characters was added to Communication Manager. However, the method to enter non-ASCII characters proved to be cumbersome, so most system administrators continued to use only ASCII. Additionally, Katakana is used for non-Japanese origin words and is not the appropriate script for Japanese names, objects or phrases. Thus, supporting only Katakana was not an acceptable solution for Japanese language support.

Avaya needed a solution to meet the language expectations in all markets – not just in Japan.

To meet customer expectations in Japan, Communication Manager had to support Kanji, Katakana and Hiragana. While supporting Japanese would satisfy our Japanese customers, we needed to look at a solution that would meet language expectations in all markets. Of course, the solution chosen was to support Unicode in Communication Manager and in associated applications and devices.

Since Communication Manager was call-processing software, phones were an essential element of the system sold to a customer. Avaya digital phones were designed to work with Communication Manager. This was a good thing in that Communication Manager supported more than 700 features, but it also meant that language issues were harder to solve due to the complexities and cost involved with hardware changes. Also, a company’s investment in phones had to be protected. This meant that Avaya’s solution could not break existing interfaces to the hundreds of thousands of phones now in use.

Avaya’s solution could not break existing interfaces to the hundreds of thousands of phones now in use.

In order to work with existing phones and with new phones, Avaya designed a Name1/Name2 architecture. Name1 was a generic term used to represent all the existing text fields sent to a phone display. Name2 was a generic term used to represent a Unicode counterpart for a Name1 value. This design meant that all the existing interfaces between Communication Manager and phones that did not support Unicode would remain the same. New phones developed would support Unicode and thus would be able to take advantage of all the Name2 values. Communication Manager would send Name1 or Name2, based on the phone’s script capabilities and the preferred language of the phone’s user.

This design has had a tremendous side benefit in that it supports the Dual Language Caller ID system. Briefly, the Dual Language Caller ID is a system that displays caller ID in a language that does not use the Latin script, along with a transliteration of the name in the Latin script. This feature provides caller ID based on the language abilities of both the called party and the called party’s phone. Using Unicode, the Dual Language Caller ID can be used with any language.

Figure 2 below illustrates caller ID in Chinese, and Figure 3 shows the same call, but with the English transliteration “Hu Jingtao” for the Chinese name. (Please see Is a Person’s Name Really Important? for more details.)

Figure 2. Caller ID in Chinese

Figure 3. Dual Language Caller ID (English and Chinese)

When modifying software that only handled single-byte characters and moving to a multi-byte implementation at the same time, we had to deal with increased memory/storage needs. A Communication Manager system could support up to 36,000 extensions, and each extension name could include as many as 27 characters. Adding a Name2 counterpart, that used UTF-8 in a maximum configured system, increased storage requirements by 3,060,000 bytes. Also, when processing Name2 values, Communication Manager had to use character/string APIs (application programming interfaces) that understood the UTF-8 encoding.

Implementing Unicode support does not happen overnight.

Internationalization of software moves both software and software programmers away from the notion that a character and a byte are synonymous, but implementing Unicode support does not happen overnight. This is particularly true for a product such as Communication Manager that consists of millions of lines of code. As with any long journey, you must create a roadmap to guide all teams involved and to keep them on track.

Our internationalization roadmap at Avaya was created when we first started this internationalization effort. We involved product managers from all of our regions at the beginning in order to create our roadmap. We were able to prioritize fields that would support Unicode and other language features required during internationalization development. Our roadmap has kept us on track and resulted in happy customers and increased sale opportunities. Figure 4 shows the same phone message as in Figure 1 above, but with one very important difference: the message is now available in Japanese.

Currently, Communication Manager supports Unicode for all text messages (approximately 600) and for key text values such as ‘extension name.’ For more details on exactly how we created and implemented our internationalization roadmap, please attend the presentation, Case Study: I18n/L10n of Communication Manager, to be given at the LISA Forum Europe in Paris in October.

Figure 4. Full Comprehension and Customer Satisfaction

Chuck Wrobel has degrees in Computer Science from the University of Illinois and DePaul University. He has worked on numerous internationalization and localization projects throughout his career for Bell Labs and Avaya, including his 10+ years in Tokyo. Chuck enjoys etymology (especially Asian languages) and programming.