More, Faster, Better!

The overriding fact is that as the business is maturing, the stress levels of those involved are definitely increasing. The problem until recently was just getting the localizations done. Now the pace has accelerated for scheduled product releases and the releases aren't in just the native language of the developer: the pressure is there to release all planned versions simultaneously. The time allotted to do this hasn't been increased to allow for the extra workload. On the contrary, development cycle times are being shortened unrelentingly by the management team that recognizes that the product has to be out there to sell in a market where shelf life is becoming increasingly similar to that of fresh vegetables. Can quality slip when time might be the overriding factor? Get real--in a dwindling market with more and more competitors, quality is even more critical than it used to be. So, QA is finally becoming sexy, sort of.

For markets like Japan, the developer might as well just burn the money he plans to spend on product development if his emphasis isn't on a quality product because the Japanese, while accustomed to paying extremely high prices for almost everything, have also become inured to quality. And, they won't pay less for "cheaper" (i.e., inferior) products because they're perceived as bargains, regardless of the fervent wishes of a developer--Japanese customers just won't buy them.

Expanded Scope

Meanwhile, the projects are changing on us as well, both in scope and type. There are clear indications that many projects are going to be extremely large. In Heidelberg, José de Hoyos of Novell spoke to this when he described a typical project there as having 10x the average UI length of 30 kb and 6x the average online help length of 50 kb. In addition, while the typical industry project consists of 100-200 kb of documentation, Novell produces 1.8 MB! As more and more networking and client/server-based applications become available, more and more projects of this scope are going to need internationalization and/or localization. The engineering aspects for this are mind-boggling and the thought of trying to manage the other aspects of the localization like translation and formatting could easily cause one to lay awake in the middle of the night.

Multimedia

Multimedia applications, including those on CD-ROM, are here to stay. Although text can be a very small part of the process, in addition to the "normal" localizing team of translators, proofreaders, editors, DTP people, programmers, QA testers and so on, the localizer of a multimedia application has to manage--or at least work with--a team that can include actors, animators, narrators, sound engineers, graphic artists and director/project manager. Intellectual property laws are complex. For instance, who owns a particular sound in a sound library? CD-ROM by their very nature hold vast quantities of data that needs to be adapted for the global end user (someone somewhere else). Everything in the preceding paragraph holds true, including the fact there may be just a small amount of text actually involved. However, there can be dozens, scores, hundreds of screen shots, snippets of sound and/or narration, etc., that need to be examined for acceptability. Everything must be inspected in order to do a thorough job. This in itself can be difficult, tedious and time-consuming. Besides the scope of the amount of data needing adapting, the reintegration is challenging. All the original-but-adapted information must be there-- and it must retain the prior hypertext links, both within the application and with the platform upon which it is running (e.g., Windows Help files). Obviously, word counts can be almost totally irrelevant but the costs for the equipment, which quickly becomes obsolete, and the talent (professional fees)--are extremely high.

Network Publishing

Another voice to listen to when we are trying to discern trends is that of Bruce Kahle, founder of WAIS, Inc. His company has developed what he calls "network publishing", enabling the distribution of "words to people in 45 countries with only a computer and a telephone. That's all it takes!" ("WAIS--a new vision of publishing" April, MicroTimes, April, 1994). WAIS (Wide Area Information Servers) helps people deal with information overload on the Internet by helping users navigate through the information online. The other widely used tools for this are Gopher and World Wide Web (WWW). Up until now, this basically worked with freeware and the major user was the U.S. government, along with some major corporations who used it to publish internally. With more commercially-oriented programs and more globally distributed companies, the meaning of "internal" is evolving--trying to keep all employees everywhere informed is going to be problematic. How in fact will this be done? Will corporations choose to localize only certain types of information (on spreadsheets, for example) internally with filters?*

Government and Piracy

Piracy issues have never been resolved, unless the decision simply not to sell in a particular market can be called a fix. Part of the problem is lack of commitment from the governments representing the developers. They talk tough and carry a feather. Sometimes they don't even talk tough. For instance, the Clinton administration decided on April 30 to delay its expected ultimatum to China over piracy issues that included software. Companies in the PRC copy and export over US$800 million of intellectual property annually. Because of concerns about the impact of designating China as a "priority offender" on human rights talks, Clinton decided to hold off for now. Meanwhile, Argentina and India, also leading violators of U.S. intellectual-property rights, are not being acted against because theses countries are addressing the problem and appear to be making progress. (San Jose Mercury News, May 1.)

Governmental Investment and Its ROI

Sometimes government support is a two-edged sword, or as we say in the U.S., "There's no such thing as a free lunch." An example of this was shown in Heidelberg. While the Glossasoft project is funded by the CEC and is definitely a valuable contribution from government sources, DGXIII made clear that it is important that internationalization must be balanced by concerns for European cultural diversity. Most companies that have any sensitivity at all struggle with this issue because the bottom line is always the bottom line, and decisions about ROI can be brutal indeed. The question here is: what if the EC doesn't think that cultural diversity issues are being given enough attention, with a satisfactory number of resulting politically correct packages ...?

Local Markets, Global Headaches

Working into Asian languages offers its own set of challenges and rewards. We've all heard of double-byte enabling, scripts that include 7000 characters, etc. Another challenge will be translation-related. In Europe and North America, the general literacy level is high and the populations are used to a fairly high level of technology. Personal computers are widely accepted, for example, because people can afford to buy them. In third world countries this is not the case. Translators who speak very good English because of schooling may still be totally unfamiliar with the context of computer terminology.

The markets are small but growing, yes, but the basic pervasiveness of technology in daily life is just not there--no microwave ovens, no programmable VCRs, no modems (and maybe no telephones, either), no personal laser printers, maybe no automobiles. Hence, an innate problem in getting good and accurate translations exists. Extensive education and editing for these regions will be crucial because these will be big markets someday and a commitment to quality now can make a big difference in market share later.

Even in Japan, surprisingly, this is still somewhat of a problem. Because personal computing is still fairly new there and until recently, most software was custom written, there wasn't much experience with translating software manuals into Japanese. Because the users don't tend to be translators (most translators were using dedicated word processors called "wapuro" rather than personal computers), it is still difficult to get good translations into Japanese, even in-country. Even so, the Japanese still tend to insist that all work be done there because they don't trust anyone else to do it right. It can be very wearying to localize anything into Japanese for other reasons as well, including the need for continual patience and communications that they require. This can be very frustrating for a developer but does pay off.

Are there Solutions?

Given all these situations, what's a developer to do? Core Competencies & Strategic Partners. One of the answers discussed at the Globalization Symposium was a 4-step program:

1. Acknowledge that you can't do it all by yourself.
2. Identify your core competencies.
3. Once you've identified those strengths, ask for help: establish strategic partnerships with those companies whose core competencies complement your own.
4. Get ready for a bumpy ride.

This does seem to make sense, since not everybody can do everything well. The large companies like Microsoft have centralized their localization teams, mostly in Dublin, and the smaller companies are relying less on distributors (who never seem to have been that good at it anyway) to localize their products. Instead, the trend is to let the distributors distribute. The localization teams decide how to break up the work and assign it to partners. The latest thinking is that the partners are for the long term and as such are an asset worth developing. The localization teams handle:

• Project management, which can be a nightmare with even a small undertaking
• Localization tool development
• QA
• Glossary development and terminology standards

These teams tend to subcontract the following out to partners they've developed or are trying to develop long-term relationships with:

• Translation (in-country only seems to be the standard)
• DTP and formatting (with the new definition of WYSIWYG: what you structure is what you get...)
• Testing

There are definitely opportunities here to define evaluation standards for vendors, partners, etc., both before and after work begins. Also, since this is fairly new thinking, indicating a stab at restructuring the business-as-usual model, there are no guarantees that this will work in real life. It is difficult to maintain partnerships. However, it will be interesting to see the results and evaluations at future symposia.

Tools, Glorious Tools (or Please, May I Have Some More?)

The development and availability of tools for almost every part of the localization process, from terminology management, translation leverage, project management, etc., is an ongoing concern for everyone in the industry. Commercial enterprises claiming that they can do all of the above are out there. Very often, from companies like WordPerfect and Novell, we hear that they've examined the existing tools and decided to develop their own. The advantages of this are customization and the chance to constantly reengineer and upgrade that tool. Most companies, however don't have the resources to do that and are looking at various commercially available tools.

Speakers at the March conference were primarily concerned with project management tools, not so much with the more prosaic technical localization-based string extraction and translation tools, although those are still considered extremely important. This is probably a reflection of how complicated projects are getting, and also a result of working with partners--just trying to keep track of things, in other words.

Another concern was the difficulty of exchanging information between non compatible databases, which is tied in with infrastructure and networking capabilities. Huge data files need to be managed and rechecked constantly, up until delivery. Many localizers fervently wish for a quick solution to this.

Prix Fixe

Suites have appeared on the scene and have been firm about not leaving. A suite is a collection of applications, often unrelated, sold by a developer for a set price. Customers love them. Localizers hate them. This is because they present a unique adventure in sim-shipping. As a big contribution to the bottom line, they represent a solution (as well as a problem) in the otherwise dwindling market for many apps.

Where Do We Go From Here?

On either the problem or solution end, the timing is right for cooperative effort to ensure that the wheel is not constantly reinvented, to enhance the hybridization of ideas that has made Silicon Valley such a success, to set standards for our industry because standards work for the benefit of everyone (eventually). The whole market can change so quickly that it's all but impossible to just stay informed about what's going on, much less being able to move fast enough to do something about it. For developers trying to expand into different markets or to stay competitive in their own, LISA is a good source of information. Especially at times like this (when I foresee articles that explain "Why Our Strategic Partnership Didn't Work"), it is comforting to know that an organization like LISA is here to help us build our businesses in an intelligent way.