Article for translators: Because Knowing Is Not Preferring

By Kenneth (Sandy) A. McKethan
PMP® and Globalization Project Manager, IBM/Tivoli Software
smcketha@us.ibm.com
&
Volkmar Burke Siegemund
Internationalization Engineer, IBM/Tivoli Software
vbsiegem@us.ibm.com

The mere mention of “globalization” these days is sure to stir a variety of emotions. While the term conjures up images of bad press on world economic summits, protesters and job migration, it also heralds exciting new business frontiers.

In the economic sense, globalization is the trend toward an integrated worldwide economy. Contributing factors center on the confluence of a number of worldwide developments in the fairly recent past, not the least of which is the dizzying proliferation of the internet. Regardless of its merits, economic globalization is definitely here to stay. UN Secretary General, Kofi Annan, has correctly asserted, “…globalization is ‘an irreversible process, not an option.’ ”

That is economic globalization. However, it is not to be confused with software globalization, which is the immediate subject of this article.

The process of developing, manufacturing, and marketing software products that are intended for worldwide distribution. This term combines two aspects of the work: internationalization (enabling the product to be used without language or culture barriers) and localization (translating and enabling the product for a specific locale).

Globalization is the process by which an organization builds strategies and competencies that operate seamlessly across national boundaries. It requires a focused integration strategy among people, languages, economies, nations, cultures and technologies, and must be considered from the very beginning of any project.

Software globalization actually begins with software product design, involving a process that is known as internationalization. A globalized software product must be able to accommodate a variety of languages and cultures, i.e., not only must their different character sets be supported, but their cultural conventions as well. These include address, date, time and currency formats, along with many other aspects.

The original product design should also accommodate seamless integration of bi-directional languages such as Arabic and Hebrew and ideographic languages such as Chinese, Japanese and Korean, if the product is to be successful in those markets. Basically, internationalized software is culturally neutral in the sense that it is designed in order to be easily modified to fit the needs of targeted markets. This includes its documentation, packaging, sales and marketing materials, etc.

For reasons of cost and efficiency, this functionality is ideally integrated into the initial product design, rather than added later as a retrofitted afterthought. It becomes clear, then, that providing software in different languages involves far more than translation.

Only after the product has been properly internationalized does it offer a suitable platform to which different languages, with their individual conventions, can be added as needed. The latter process – referred to as localization – describes the actual implementation of different languages with their locale-specific conventions. The locale concept encompasses more cultural aspects than just language. As an example, while Spanish is spoken in both Spain and Argentina, the two countries use different currency formats. A user in Argentina should be able to select the Argentine locale which uses the $ symbol to represent the peso, while a user in Spain should be able to choose the euro symbol.

Perhaps even more important, properly globalized software means that cultural preferences for the presentation and layout of information have been taken into account. For example, some people look to the upper-left-hand corner to begin reading/scanning; others look to the right or the middle. Some cultures expect certain types of information to be delivered mostly in graphical form, rather than in paragraph after paragraph of words. And in some of the world’s main languages, paragraphs don’t even exist.

Service delivery happens in different ways in different regions, e.g., Amazon may deliver its products by mail and courier in certain parts of the world, while by bicycle in other parts. Payment systems vary all over the world. All of these preferences need to be researched, designed for, marketed and supported to enable a product/service to be successful in any given market.

The term globalization can even include the ability of a software product to support multiple locales simultaneously. However, until the underlying operating systems catch up, this entire process is still complex and costly. It continues to represent quite an investment of specialized talent, time and money on the part of software publishers.

The end result is that once the software is finally globalized, users can interact completely with the product in their own language with all its familiar locale-specific conventions. To the user, globalization is transparent, as if the software had been created in their language rather than in some other language (usually English). Users can interact with their computers, can input and view data as well as generate output, and share data with other systems, all in their own language.

Web pages are a great example of this. Browsing, for example, the BBC World Service home page, the visitor is offered a wide variety of languages (43, to be exact) in which to view the site. Users can select their language, assuming that their browser software and operating system are globalized, and that they have made the appropriate locale selection. The page will then be displayed with complete cultural correctness, right down to the level of the topics chosen for coverage, the layout of information, date and currency formats, etc.

In the world of software, internationalization plus localization equals globalization. For a very enlightening discussion of why GLOBALIZATION = N * LOCALIZATION, please read GILT: Globalization, Internationalization, Localization, Translation, by Pierre Cadieux and Bert Esselink.

So, why (software) globalization? The answer will depend on who takes the question.

It takes money to make money. Since software publishers are in business to make money, this should be reason enough for them. For some years now, major North American-based software publishers have generated well over half of their revenue outside their home turf.

And those “overseas” markets continue to grow, some exponentially. For instance, IT spending in emerging markets saw a growth rate of 10.5% in 2003/2004 -- more than double the worldwide average in this sector.

While such representative statistics are exciting in and of themselves in terms of software sales, they still do not tell the whole story. What do they mean for software globalization? There are several answers; however, we will focus on two major reasons for the globalization imperative: user preference and legal requirements.

Most software – regardless of its country of origin – is originally developed in English. This means that left in its native state, almost all software products would inconvenience someone, somewhere, language-wise. And yet, more than 90% of the world’s population prefers a language other than English for business purposes. [Source: LISA Localization Primer 2003, page 12]

But surely, this is different with “computer nerds,” as they are assumed to be proficient in English. It’s now time to dispel the widespread notion that most IT professionals worldwide speak English – it’s simply not the case.

Based on a study performed on behalf of the European Commission in 2001, 35% of white-collar workers in the Europe Union using English as a foreign language consider themselves to have a good command of that language. However, taking into consideration additional evidence from the same study, this figure may actually be slightly optimistic.

Surprisingly, English language skills are low in some major European markets:

Only 39% of Italians and 36% of Spaniards and Portuguese make the same claim.

One should contrast “knowing” a language vs. “preferring” it. It is not uncommon for one to know a second language, but at the same time, for reasons of politics or history or level of proficiency, have developed a strong aversion to using it. Given a choice of available software then, most users will opt for the one that is available in their own language.

The numerous reasons behind local language laws include product quality and safety.

The existence of national translation requirements, for example in France and Quebec, is well known. But the list is long and goes on to include Vietnam, Bulgaria, Russia, Taiwan and the Czech Republic. Typical product material subject to translation includes user’s guides, packaging, operating and safety instructions, warranty terms, e-business information, etc.

Other government legal requirements focus specifically on software globalization issues. Based on the size of its market, China (the PRC) heads this list with its requirement for GB18030 character set support. This requirement ensures that software can correctly display the Simplified Chinese character set. Since this new regulation went into effect in 2001, support compliance has been required of any products aspiring to certification for sale in that country. And since the PRC is the largest emerging market in the world, with enormous sales potential, the software publishing community is happy to make the necessary investments, focusing on compliance from the early design phase.

Global e-business changes everything. In this arena, having a globalized software application is only part of the equation. When such software is applied to a globalized e-business environment, the picture suddenly becomes much more complicated.

A simple but true experience illustrates the point. A person in the U.S. decided to open a side business, so he set up a website – complete with a modest catalog and online ordering capability. Immediately, the new enterprise was faced with various e-business globalization issues when one of its first orders was placed from outside the U.S. Of course, the young entrepreneur never dreamed this would happen.

Seamless globalized backend processes must also be in place to ensure a product’s success.

Since the order was placed in English, localized website and non-English correspondence capabilities were not factors in this particular case. But even without the language issue (this guy was lucky!), the lack of globalized versions of commonplace business processes was felt immediately. Though correspondence was conducted in English, the entrepreneur and his potential customer had to overcome other challenges (just as important as the ones related to language), including

In other words, even if this businessperson had implemented properly internationalized and localized web software, this would not have been sufficient to conduct global e-business. The business processes that back up any product or service are just as crucial to success as what is being sold. Seamless globalized backend processes must also be in place to ensure that the order can be processed from start to finish, regardless of its country of origin.

When to engage globalization? Alluded to above, the point cannot be overemphasized that product globalization must start at product conception with planning and implementing internationalization. Early education of development and test teams is also a must.

This is also the time to assess a critical issue that is often overlooked, i.e., the internationalization and localization of any required prerequisite products or software modules. It is not uncommon for a third-party software component to lack full globalization support, especially when it is manufactured by a small enterprise with limited resources. If this is the case, the impact on product function and quality must be assessed and solutions found.

It follows then that reliance on adding a just-in-time “translated” version in response to late-breaking customer requirements after the original product release is definitely not a good idea in the case of software. Why? There at least two good reasons. First, it is a commonly accepted rule of thumb in the industry that localization costs and time requirements actually double in cases where the product has not undergone adequate prior internationalization. [Source: LISA Localization Primer 2003, page 11]

Secondly, given the short shelf life of most software releases these days, one must also consider the loss of missed opportunities in key markets. Assuming that one were willing to incur the doubled cost and schedule to roll out localized versions, the opportunity window would most likely be long past by the time the product became available locally. In fact, simultaneous release of various language versions (simship) in all key markets is now widely considered a must. Waiting for the perfect business case, at least for one’s key strategic markets, is definitely a losing strategy. Implementing simship releases also addresses the tendency for customers to stop buying local versions of software once a new release is announced.

While economic globalization represents integration on a number of fronts, it is also evident that economic and software globalization are closely interdependent. The former fuels the latter; the latter enables the former.

The business potential from the emerging worldwide economy is nothing short of staggering. However, it is directly dependent on the software tools that make it possible. In turn, these must be globalized in order to be “globalization ready.”

Given this reality, it is imperative that software globalization be viewed not as an option, but rather as a strategic imperative. The question then becomes, “How much revenue will I lose if I fail to globalize?”

Volkmar Burke Siegemund is an Internationalization Engineer at IBM/Tivoli Software. During his eleven years in the industry, he has also been a translator, a verification lead and a tools and build engineer. You can reach Siegemund at vbsiegem@us.ibm.com.

Sandy McKethan is a Globalization Project Manager at IBM/Tivoli Software. During his 30+ years in the industry, he has been an interpreter and a translator, and held marketing, sales and recruiting roles. You can reach McKethan at smcketha@us.ibm.com.

Reprinted by permission from the Globalization Insider,
March 2005
Copyright the Localization Industry Standards Association
(Globalization Insider: www.localization.org, LISA: www.lisa.org)
and S.M.P. Marketing Sarl (SMP) 2005