In terminology studies, we talk about standard terms and prenegotiated meaning with respect to specialized terminology we want to use in technical contexts. In an emerging discipline like ours, however, we can’t necessarily depend on words in this way: the terms themselves may be ever more familiar, but the concepts behind them may be vastly different for different people in slightly different environments.

The core concept is, of course, localization (L10N): it is the title focus of this organization, but users are not at all agreed on what it entails. Microsoft’s David Brooks has provided his view:

translating the menus and dialogues in the user interface, the online help file, and the printed documentation and marketing materials for a software product, as well as integrating the individual components of the product into an executable form, adapting the setup program as necessary, testing the product, creating disk images, and releasing the package to manufacturing.

This definition clearly understands localization as translation plus everything else involved in preparing a product for release in a specific local market. The ILE Web page sums this up:

Localization involves taking a product, good or a service and making it linguistically and culturally appropriate to the target country where it will be used and sold. In order to make products marketable overseas, localization involves more than just translation—it requires a knowledge of language, cultural nuances and taboos, linguistic connotations, and other considerations in order to make the product as functional for the foreign user as it is for the domestic user.

Within the LISA environment, the lead-in activity to localization is internationalization (I18N), which KSU’s Greg Shreve characterizes as: the process of generalizing software so that it can handle multiple languages and cultural conventions without the need for re-design or re-compilation. Internationalization is done at the program design and document development level, generally by programmers, program developers, possibly language engineers, and technical writers. These prepare product and documentation that is easily localizable, e.g. with sizable screen boxes, modular program units, flexible interface capability, etc. Well internationalized software avoids cultural references and stereotypes that may be unacceptable or incomprehensible in target cultures.

Globalization (G11N) is the broadest of the three major terms and enjoys considerable currency outside localization. CIBER’s Cheryl Ryan (Ohio State University) describes it from the business standpoint as the extent to which a firm has made its services or products applicable in cultures and regions different than its central or headquarters operation. For the localization environment, Alan Melby casts strict terminological rules by the wayside and defines globalization in terms of localization, drawing heavily on wording from the current LISA forum agenda: Globalization addresses the broader issues associated with integrating localization throughout a company, including internationalization and product design, as well as marketing, sales, and support in the world market.

This view of globalization includes both internationalization and localization, plus a range of other issues, and could thus serve as a superordinate concept (although some might dispute this). Nevertheless, others, such as Brooks’, perception of globalization projects a concept more like what we have defined above as internationalization:

Globalization means building support for non-English locales into the US product. Put another way, a well-globalized product can be used in any foreign location. A well-globalized English word processor, for example, can be used to compose a document in French (with accented characters), in Russian (with Cyrillic characters) or in Japanese (with kanji) provided, of course, the fonts are available from the o/s, a language pack, a DLL or similar source. If the globalized, English app is running on a foreign language operating system and utilizes the NLS (‘national language support’) functions of the OS, the globalized English wp will allow sorting of names, for example, according to the sorting logic used in the country.

Fry and Bonthrone (F&B) account for the different connotations of ‘globalization’ by defining variants at the macroeconomic (i.e. movement toward a single world market), microeconomic (fitting an enterprise to do business on the global scale), and localization levels, where the term can signal ‘internationalization’ or ‘enabling’.

There are other definitions that are not undisputed. At JD Edwards, for instance, what we are calling localization above is split into two concepts: translation (which we hope doesn’t need to be defined) and localization ‑ the non-translatory activities involved in the localization process. JDE is not the only company to try to break up the localization effort into sub-categories. At Microsoft, adding a different language spell-checker or thesaurus is called adaptation, whereas some speakers would reserve this for much broader applications.

Another quasi-synonym for either internationalization or localization is enabling. BYU’s Arle Lommel explains: ‘Enabling’ is a term that some software developers are using as equivalent to our ‘internationalization’. This view is reflected in the F&B definition: ‘enabling’ is the process of engineering a base product (preferably although not always in the course of its development) so that it can subsequently be easily localized. Enabling is a technical term referring more to the internal design and implementation of the product than to its external presentation. This is in line with a broader meaning: Lommel notes that ‘enabling’ is used in contexts such as ‘SGML-enabling’ or ‘Access-enabling’. While internally consistent, it makes the term fuzzy where the user wants to clearly imply internationalization-related enabling.

Enabling, like globalization can obviously have a broader connotation outside software localization. It can also have a very specific focus:

Enabling involves providing a rudimentary level of functionality (commonly called ‘national language support’ or NLS) in a language in an operating system. For example, NT5 will include a locale setting for a huge list of locales — French Canada, Bulgaria, Korea, etc. The difference between ‘enabling’ and ‘adaptation’ is that ‘enabling’ goes into the basic code and ships with every language version, while ‘adaptation’ is market and/or language-specific. (David Brooks)

As if existing terms and acronyms were not enough, the LEIT group has generated another term, which serves e.g. as the domain reference for all these terms in a language engineering terminology database. Dissatisfied with our efforts to find a superordinate concept everyone could agree on, we invented the acronym GIL.

The evolution of terms and their meanings is always a volatile activity in young disciplines, and premature standardization is to be avoided at all costs. By the same token, it is a good idea for us to listen carefully to each other and to be sure we know what others mean when they use a ‘familiar’ term.

Prof. Sue Ellen Wright
Kent State University
Institute for Applied Linguistics
Kent, OH 44242
USA
Tel +1 330 673 0043
Fax +1 330 673 0738
E-mail: swright@kent.edu