 |
||||
 |
||||
 |
WELCOME TO THE RUBRIC NEWSLETTERThis publication is sent to Rubric customers worldwide. The Rubric Newsletter provides business and technical insights from Rubric management about issues concerning product and content globalization. If for any reason you do not want to receive future editions of the Rubric Newsletter, follow the opt-out instructions at the bottom of this message. |
|
||
|
|
We encourage you to forward the Rubric Newsletter to members of your localization team, your product and marketing managers, and to your friends in the industry.
If you are receiving the Rubric Newsletter from a friend or colleague, and would like to subscribe yourself, click here. |
|
|
|
In this Issue: | |
||
|
|
RUBRIC NEWS: Recent news about Rubric.
BUSINESS — Localizing Support: The quality of your localization has profound direct and indirect effects on your bottom-line as well as top-line revenue. Learn about the facets of support from which you can measure the cost savings of localization. TECHNICAL — Character Confusion: The nice thing about standards is that there are so many to choose from. But this makes localizing software and web sites a technical minefield. Learn about the history of computer characters and the standards you should know. |
|
|
|
RUBRIC NEWS
LOCALIZING SUPPORTHow localization adds to the top- and bottom-lineby Ian Henderson, Chief Executive Officer, Rubric During a meeting with Hewlett Packard, their technical support group executive made a not-so surprising comment. "Rubric's work on localizing reduced our help desk support cost 40% in Japan and Korea." Pleased as this fellow was, it was not unexpected. Poor localization of support documents confuses customers and leads to product misuse, problems, and on rare occasion, product liabilities. Good product localization leads to lower support costs and happier customers. The top-line Localizing your products is a requirement for market entry in almost every product category. But today, product acceptance is based not only on how well localized content attracts buyers, but on how well the product is supported. People demand more from all products, including imports. For example, in the 1970's, the term "Jenglish" entered the North American vocabulary. "Jenglish" was a contraction for "Japanese English", and was used to describe the less-than-perfect translations of instruction booklets included with Japanese manufactured goods. For many years Japanese products were unfairly considered as inferior by most Americans in part due to poor localization. This slowed market gains Japanese companies could have achieved in North America — a direct hit on top-line revenues. The same applies when American companies export goods to other regions. Though the number of non-Americans with some English skills is higher than the reverse, English is still a second language and precise product and content localization is required to gain market share. The support bottom-line Top-line localization issues are well understood, but bottom-line customer support issues are not. There are significant direct costs associated with foreign support. These costs can be reduced with effective localization of the following customer touch-points: |
|
||
|
|
User manual: Educating the customer the moment they open the box — and upon occasion,
before they open to box — prevents problems and avoids support needs.
Online support: The cost of self-service support via the web is much lower than telephone support, but not if the content is confusing. Support staff: Once a support call is made, your foreign support staff needs quality information that is easy to understand, search, and communicate to customers. |
|
|
|
The first two touch-points — the user manual and online support — suffer from the same problem,
which is a lack of dialogue. Each form of support is basically static, and prevents the customer
from asking better or more detailed questions.
If there is any ambiguity in documentation, the customer is forced to make a support telephone call, and your costs rise as a result. Conversely, if the localized content is precise and understandable, then your support staff's time is reserved for handling more difficult and unusual calls. Reducing your call load is, of course, the primary objective. Though you can never eliminate telephone support, you must try to reduce it given the staggering expense. Manpower, training, and transcontinental communications with 2nd tier support teams account for the largest part of your foreign support costs. Part of your total cost of poor localization comes from your knowledge base and internal documentation. Your foreign support teams need documentation on products, issues, and support procedures. Inferior localization of these materials will result in high costs as your foreign teams attempt to decipher the documentation. Worse yet, if the documentation is unclear, they might in turn give your customers inadequate support and create unhappy customers. If your foreign support staff is completely dumbfounded by their documentation, they will add to your support costs through frequent communications with your home office. Your 2nd tier support teams and engineers are expensive resources, and their time must not be squandered on remedial, real-time education of your foreign teams. How to minimize the costs To minimize your bottom-line support costs, you should focus on just a few steps. |
|
||
|
|
Product localization: The more care you take in the localizing of your product, the less your
support costs will be since your foreign customers will get full value from your product. This
involves expertly localizing your documentation, and in the case of many products (especially
software), properly localizing the user controls and interfaces.
Content management: For online support, use a content management system that streamlines the posting of knowledge base materials and submitting new materials for localizations. Use an outside firm that has in-country technical and language experts who can properly translate the content. Constant partner: Pick a reliable partner for localizing your content. Having Rubric as your partner provides support for both the product creation and support phases. This creates a uniform level of documentation, which in turn reduces customer and support staff confusion. |
|
|
|
CHARACTER CONFUSIONA BEGINNER'S GUIDE TO COMPUTER CHARACTER SETSby Françoise Spurling, Chief Operating Officer, Rubric In the beginning... ...there was ASCII, and it was good. Computer technology accelerated quickly in the United States, and accordingly so did certain standards. Foremost was the decision to codify the basic unit of data in a byte (1). A byte was large enough to hold all characters in the English language as well as all digits, common punctuation, and still have room left over. In the end, the American National Standard Code for Information Interchange (ASCII) was devised to standardize how computers would store and communicate a, b, c, 1, 2, 3... But anything as useful as a computer could not remain the province of one country or language, so software systems evolved to support people around the word. The big problem was... well... big characters. English has an amazingly compact alphabet — just 26 characters. Double that to allow for capital and lower case, and toss in digits 0 through 9, and you get a whopping 82 possible combinations before including punctuation. Since a byte can hold 256 different representations, ASCII and a one-byte-per-character system worked just fine for Americans, using 1/2 less than space available in a single byte. But it didn't work for the Japanese, Chinese, and a number of cultures around the globe. Depending on the source, the idiomatic Chinese language can have upwards of 80,000 distinct characters. Using basic binary math, we see that instead of one byte for every character, Chinese computers would need to use upwards of three bytes. Add other languages and regional variations, and you had a mess. So different computer manufacturers, standards organizations, and government agencies went forward to solve this problem. Digital Tower of Babble The nice thing about standards is that you have so many to choose from! In the rush to support all possible character sets, several different systems for codifying characters came into existence. This of course meant that if you created software on one operating system, it likely would not run on another. This made exporting software an absurd business since basic functions — like sorting strings of characters — would have to change from system to system and language to language. But time and market dynamics have helped reduce this hodge-podge of character sets to a manageable few, with some obvious choices. Here we document those that really matter. ASCII As noted, ASCII is the primordial character set. It serves all English speaking countries, and with common extensions in the extra storage provided in one byte of data, even local variations (such as the British Pound symbol — £ — or common European characters — ö) can be accommodated. By using the spare either bit, ASCII was extended to include characters for other languages such as Cyrillic, Arabic, Greek, Hebrew. If your product will never be sold outside of the US and Western Europe, then ASCII may be sufficient. Just remember, never is a long, long time. Double byte — a nice concept, but... Doubling the size of ASCII encoding — from one byte to two — would offer 65,536 possible combinations, as opposed to a mere 256. Though this is not enough to hold all possible characters sets of all languages, it would hold enough to make common communications possible (2). But there was a problem, namely money. Not long ago, computer memory and storage was expensive. Computer programmers constantly searched for ways on economizing storage needs. This led to a number of half steps to a universal encoding scheme. Most notable was the multibyte system. Multi-byte Programmers, being the slick people they are, devised a complicated way of using a little space as possible for storing characters, yet allowing for language representation from compact English to the full range of Chinese. However, for the sake of compactness, multi-byte added complexity. A language like Chinese might represent a character in one, two or three bytes depending on its position in a character table. Needless to say, this complicated even simple tasks like scanning text for specific elements, or sorting strings, or even displaying text on screen. This is not to say that multi-byte systems are rare. The UTF-8 standard is common in systems that were born in the age of ASCII (UNIX being an obvious example). Multilingual web sites are often encoded in UTF-8, which provides both flexibility for supporting many languages as well as compactness in transmitting data across potentially slow internet connections. The ideal solution would be one where all characters from all languages could be stored in identically sized units (i.e., the same number of bytes regardless of the language in use). Once again, time and market pressures addressed the problem. Unicode — a double byte standard As computer storage became cheaper (as everything associated with computers do over time), a more direct way of encoding was needed. Having a uniform character size simplified systems software, application programming, and a few grey hairs. Back in the dark ages of computing — around 1986 — some bright fellows at Xerox started to map the relationships between identical Japanese and Chinese characters to quickly build a font for extended Chinese characters. This humble start led other developers and companies (notably Apple) to drive toward a new standard called Unicode. Unicode fixes all characters at two bytes and carries the fundamental characters of most languages. This means one character encoding scheme can store and present text in any language. For example, Unicode contains characters for Latin, Arabic, Cyrillic, (Uni)Han, Hebrew, and more. More to the point, these characters maintain a specific place in character tables, with the original ASCII characters in their original positions (talk about backwards compatibility!). Unicode has become the de facto standard for most software development. Using Unicode allows a company to develop new applications for English speaking countries first, and rapidly localize for other regions without fundamental coding changes. Unicode is so popular, it is supported by all modern operating systems including all commercial versions of UNIX, Linux, Windows, MacOS and the World Wide Web. Take a byte Though the history of character encoding on computers is haggard, the future is clear. Standards have shaken out and your options for new product development are few. It is best to design for internationalization from the start because the effort is little more than if you devolved back to ASCII. (1) Actually, the most fundamental data element is a 'bit', but bits do not by themselves transfer anything that is truly 'information'. (2) Unicode, which we discussed earlier, does just this. By eliminating obscure and infrequently used characters, Unicode compacts all industrialized languages into two bytes. |
|
||