Published 1998-08-11.
Time to read: 8 minutes.
Dr. Lawrence Schoen, Director of the Klingon Language Institute, offers the following Klingon philosophy of galactic sales and marketing:
- Kill the competition (literally). They can’t compete if they are dead.
- Don’t offer product choices, instead show your users why your products are superior to their desired modifications. If they don’t agree, kill them and seek out new users.
- Enforce the Klingon saying “Buy or die!” which is intended to strongly discourage window shopping and price negotiation.
In case you have not heard of Klingons, they are an imaginary warlike species featured in the Star Trek series of television shows and movies. According to Dr. Schoen, 25% of all Americans confess to being Star Trek fans.
The world is a big place – and the galaxy is much, much bigger. As Dr. Carl Sagan often said, “billions and billions...” One must speak the local language and honor local customs if one is to be accepted by the people living in any given culture. Obviously, Klingons would have much to learn in this regard.
Dr. Schoen points out that “Americans have been arrogant about pushing the English language on the rest of the world; they tend not to be multi-lingual. Europeans are more apt to be multi-lingual. English has become the “lingua franca”, almost a trade language. Like a Pidgin or a Creole, it is useful for negotiations and transactions, but there is a limit. Realistically, short of expecting the rest of the world to become reflections of the U.S., once the deal is done, products and support must be available in the local dialect and follow local customs, or they risk never being used, let alone accepted.”
As we approach the brink of the new millennium, a methodology is emerging that allows for a manageable means of simultaneously releasing multiple localized versions of software using a single code base. Be warned that the technology for internationalizing and localizing software is very much a work in progress, and the state of the art is advancing rapidly.
Definitions
Before we go any further, let’s establish two acronyms and definitions:
Internationalization (I18N): Rules and guidelines which provide for language-neutral software. This extends to text strings (supporting different languages such as Chinese and Arabic), date and time formats, currency format, sort and collating sequences, and may even imply differing process flow from the point of view of local users. The result of I18N is a code base that can be localized with minimal additional engineering and a localization kit containing all strings to be translated and the corresponding contextual information.
Localization (L10N): The process of adapting the user interface, online help and documentation to a locale, or different language environment. This will likely impact the look and feel of the software such that it no longer resembles or behaves like the US English version (or the version used in the locale of the developer.)
Trends
It has become self-evident that to survive software firms must localize their products. Mark Homnack, president and CEO of Simultrans, L.L.C., a localization and internationalization firm based in Mountain View, California, provided the following interesting observations:
- US exports double every five years.
- Over 30% of US jobs are export related, triple the number of 15 years ago.
- If a major U.S. manufacturer is not receiving over half of its revenue from abroad, it is probably doing something wrong.
- The software industry leads all other industries in the adoption of localized products. The telecommunications industry typically lags the software industry by about five years, and the health industry typically lags the telecommunications industry by another five years. Most other US industries tend to trail further behind.
- Venture capitalists putting together business plans for new companies now target international markets right away, increasing the demand for localization among both smaller and larger companies.
- Directors of multinational companies increasingly realize that sales to the entire world are important and that less than 7% of the world’s population speaks English as a native language.
- Microsoft has an acronym – EJAL, which stands for “English is just another language,” that is used by its developers to emphasize the need to consider the entire world as its market.
Sybase, Inc. has been working on adding internationalization support to their database products. The pie chart below on the left is their breakout of global software sales by language. Rose Lockwood, a leading analyst in the localization industry, responsible for the Ovum Report and other definitive market analyses, tracks the growth of this industry and related fields. The graph below on the right is a graphic representation of some of her data.
Microsoft and IBM have the first and second largest software internationalization and localization budgets, respectively, dwarfing the next tier of companies, which includes Sun, Netscape and Oracle. The pie chart to the right shows this graphically, using data from Mark Homnack. This pie chart is a bit unusual in that it segments companies by the total dollar value they spend on localization. The total of each sector is graphed. For example, you can see that Microsoft and IBM each spent US$200M, whereas the next two largest companies each spent only US$20M. Only 26 companies fall within the labeled pie slices – localization expenditures of all the other 403 companies had a combined total of US$189M (not broken out on this graph.)
Hershel Harris, Director, IBM Database Technology, explains IBM’s motivation for I18N: “At IBM we don’t work up a business case for localizing to each locale we sell product into. Our products are localized for the locales that our international clients want to do business in. To slight a language or language group that does not produce much revenue (such as Cyrillic) would weaken the overall attractiveness of our product to our customer.” Hershel also adds that IBM’s country managers for each product determine the degree of localization they feel is necessary to support, ranging from merely storing data in the native language, to translating the screen text and images, to translating all the hard copy documentation.
In the 1980s it was common practice for software companies that wished to localize a software product to provide a distributor in the target market with some or all their source code. This was quite unsatisfactory for several reasons both from the point of view of both the end users and the software company:
- The quality of work done by the distributors was quite uneven, since software development was typically not their core competency, and they were unfamiliar with the code base.
- Quality control by the original software company was completely impossible.
- Bug fixes in the original code base could not easily be propagated to the localized versions, and the localized version frequently had new bugs.
- There was a significant lag between the release of a new US English version and the localized versions, and this impacted sales of the localized versions dramatically while end users waited for the latest version to become available.
When software companies realized that these timing and quality problems were costing them revenue, they pursued another model, outsourcing their work to localization houses. During the eighties, this outsourcing was often problematic because the vendors were not technically and professionally trained; however, consolidation in this industry and ten years of practice have made localization houses a more reliable solution, often managing the localization of product lines into ten or more languages simultaneously.
Mark Son-Bell, Javasoft International Engineering Manager explains that “Unicode made it possible to have a single source for localized versions of software. The biggest effort now goes into producing a language-neutral code base, and the localization effort per language is now much smaller than before. This means that multilingual versions can be released simultaneously using the same code base, so that any bug fixes that are not specific to localized features are automatically built for all versions simultaneously. This has had tremendous impact on reducing costs for generating and maintaining localized code.”
Managing I18N/L10N
Converting a completed monolingual program that is already in use to an internationalized code base is messy and much more expensive than to design for I18N/L10N up front. Internationalizing a program should be considered to be an integral part of regular software development, not a separate function.
Every software company should have at least one internationalization architect. Hershel Harris describes how IBM organizes the development of internationalized software. The scale is larger than that of other firms, but the role requirements of the people involved don’t vary much between IBM and other firms engaged in this activity.
Andrea Vine, an internationalization consultant with Sun Microsystems, deals with smaller clients. Andrea has some specific recommendations: “A company of 200 people, 70% of whom are engineers, could afford one internationalization architect. That person would take responsibility for the technical side of the localization product handoff to the translation teams. Don’t divide up the internationalization personnel; keep them together in a central team. Larger companies might have specialized internationalization people, but they should report back to a manager of internationalization.”
Andrea offers the following organizational information: “Internationalization marketing personnel make a requirements specification. Smaller companies often skip this step to their detriment. Working from the requirements specification, an internationalization engineer architects the linguistic, cultural and user interface aspects of the product and provides the localization manager with a localization kit. The localization manager liases with a localization contractor, who should be used for subsequent releases for continuity. Using a single contractor for translating all languages has the advantage of consistency of translation and lower overhead. Testing should be done internally. US customers tend to be more tolerant of poor usability than foreigners.”
Localization may not be restricted to just translation, Andrea points out. “The financial industry is very sensitive to local norms. In North America we work from the general to the specific; for example, first select a customer, next show related records, then choose a record. In Japan, the tendency is to go straight to the specific item and then generalize. Intuit had German engineers rework the structure and functionality of their tax product so it worked in the German market. The program was completely torn down, kernelized and re-modularized for optimum localization.
“Localization personnel (vendor and client-side) tend to be more scattered, since they are typically assigned to specific products,” Andrea explains. “Daily pressure for these less-technical people is considerably more intense, since they are usually on the critical path.” Andrea describes what it takes to work in the field: “It is easier to learn internationalization programming details than to learn internationalization sensitivity issues, which change over time. There is not much public training available for people who want to work in this field.”
Klingons need not apply.
About the Author
Michael Slinn, P. Eng., is a software engineer and journalist who has produced localized software for English, French, German and Spanish.
