Several years ago, I was called by a recruiter to interview for a job with a major Canadian manufacturer of airplane components. It seems that the hiring manager had spotted the keyword globalization in my online résumé, and because the company was embarking on a globalization initiative, he thought I might be an ideal candidate for the position. I went to the interview.
In short order, we determined that in their corporate universe, globalization meant imprinting the stamp of how things were done in the mother ship organization on all associated organizations around the world. I quickly explained that in my international software development and marketing universe, globalization meant reaching out to understand what users in cultures other than my own desired and then to evangelize incorporating those attributes in products destined for those markets. Needless to say, it was a short interview!
The attitude displayed by the hiring company may be useful in some situations, but to me, it embodied much of what has given globalization a bad name. It also pointed to another issue that I have observed closer to home: even in our relatively knowledgeable and harmonious world of software localization, substantial discrepancies exist in what industry participants understand about how globalization differs from internationalization, and how both of these two differ from localization (Figure 1).
Globalization
My definition of globalization stems from an experience I had while serving as director of globalization for a large software company. When I took the job, one of the first things I was told was that Japan was a problem. Exactly why it was a problem was not clear to the hiring manager, since the company had recently completed a localization of the flagship product at great expense, and shouldn’t the office be pleased?
So, as one of my first tasks in my new job, I set about contacting the Japanese office to find out what was wrong with the product. After a relatively short delay, they responded with a list of 1,600 issues! I found this to be somewhat overwhelming, so I tried to focus in on prioritization. Due to some factors outside the scope of this article, the prioritization effort took some time, so the next actual event in the saga turned out to be a visit from two representatives from the Japanese office to our headquarters.
After we had gotten acquainted, they asked, “The document set for this product consists of 24 manuals, correct?” “Yes,” I replied. “And you have localized five of the 24 books?” “Yes,” I again replied, “in order to keep costs contained, our product management group decided that we would localize only those five.” “And the Reference Manual is not included in the five?” they asked. “Correct!” I confirmed. “Why not?” they asked. “The Reference Manual is the only one that we want in Japanese!”
It was immediately apparent to me that our product management team had made a decision that was based on insufficient due diligence. While the decision to localize the five manuals may have been appropriate for some target locales, it most certainly was not for Japan. In fact, the result was a double whammy. Not only was dissatisfaction created, but a substantial sum of money was wasted translating unwanted manuals. As it turned out, the missing manual was the one and only issue of importance; the remaining 1,599 identified deficiencies could have been lived with, for one release anyway, if only the desired manual had been translated.
This anecdote illustrates my point that globalization must, to some extent at least, involve a degree of investigation into what foreign markets require and, conversely, that international product development without globalization at its foundation is a recipe for failure. For this reason, globalization builds the bottommost and widest tier in the pyramid that is the mental model described in this article. But globalization does not only consist of offshore market research. Rather, it should be considered more closely synonymous with overall corporate investment strategy. By this, I mean investment strategy in the widest sense of the concept — not only investment in the financial sense, but the effort that employees invest in everything they do. Globalization should be considered a mindset as much as a task set.
I once was asked to prepare a consulting proposal to evaluate localization processes for a well-known and successful company in the telecom space. My proposal was not accepted at the time, however, because the company decided to purchase a content management system (CMS) for its English content prior to exploring its localization practices. It never occurred to management that handling localized content and adapting to localization workflows might be a critical factor in its choice of CMS, and thus globalization was not in the forefront of the decision-makers’ minds as the company considered this investment.
Based on the notion that globalization is a mindset, international market research is only one piece in a much larger mosaic and should not be carried out in isolation or “thrown over the wall” to another department, as is sometimes done with program code. Quite to the contrary, regional market considerations should be treated as an integral part of marketing plans created by a centralized marketing organization. Target locales should be grouped in tiers based on quantitative analysis, and a business case mentality must prevail, especially in the case of emerging markets. This will promote product planning with diverse markets in mind.
Creating a business case for product investment requires additional layers of support in the finance or accounting departments. It has always amazed me to learn how many companies do not track their revenues with sufficient international granularity to know whether the criteria set out in business case justifications are actually met. In my experience, it is sadly typical that companies do not know how much revenue can be attributed to localized products. At best, they may know how much revenue comes from products sold in certain regions, but there is no distinction between English and localized products sold. This simply is not tracked, nor is there any infrastructure for tracking or mining such vital data. Most companies either “fly blind” based on imperfect, unverified assumptions, or they employ the “localize for whomever screams the loudest” method of decision-making. This is partly an offshoot of the practice of sales personnel being compensated by revenue rather than profitability, and it may be considered an unnecessary burden during periods of robust business growth. However, in leaner times such as we have as of this writing, it is a shortsighted policy.
An additional attribute of the globalization mindset is the conceptual treatment of English product offerings as a subset of a generic, locale-neutral product. This is a tough mental leap for most North Americans to make, although there is hope on the horizon. The growing influence of the Hispanic population, for example, has caused numerous US-based businesses to consider Spanish as a language with an importance and personality of its own approaching that of English. This, by definition, requires a whole new level of awareness on the part of strategic planners.
In the software world, target markets are generally farther afield, and companies are represented by offices located abroad. These offices are valuable sources of information but, all too often, the information flow is in one direction only — from headquarters to the field. This is counterproductive. In a world where information is power, the globalization-oriented company cultivates a culture of ongoing and extensive liaisoning with resources all over the world, intelligently leveraging information gleaned from that interaction by folding it into up-front product planning.
The choice of representation in foreign markets is also very much a part of globalization. There are many options; channel strategy is a long-term decision with many implications. One company that I know of has blithely opened and closed offices in Japan multiple times based on short-term results, apparently unaware that each vacillation in policy further undermined their credibility with local partners. While companies presumably never enter markets with the intention of failing, they frequently do fail to proactively consider an exit strategy in their up-front planning. Even this pessimistic, risk-oriented activity belongs to due diligence activities of globalization.
Internationalization
Internationalization, the act of making a company’s products localizable, is sometimes called localization engineering. This latter term is unsatisfactory for several reasons, most prominently because it implies that the task set is different than core development and, by extension, done by different people and, perhaps, at a different time. But it is also not broad enough. Internationalization need not only refer exclusively to coding practices as localization engineering implies; it might also be applied to such tasks as allowing sufficient white space in source documentation for text expansion or architecting a website so that localized content can be easily added.
When performed proactively, internationalization is conceptually very similar to a real option. A real option is the right or the ability, but not the obligation, to do something at some point in the future. One purchases this future advantage through a current investment, and hence it has a calculable dollar value. Think of an entrepreneur who purchases a plot of land alongside a country road where, someday, residential development will occur. She builds a small service station and car dealership. She doesn’t invest too much money in the current facility because she doesn’t know exactly when the development will occur and, of course, there is always some risk that it might not. But what she does do is buy an option to purchase a parcel of land next door at a predetermined price at some future date. This guarantees that she can expand the facility if she wishes, but does not obligate her to purchase the land if the development does not materialize.
Within the context of product development, proactive internationalization simply provides the option for a company to cost-effectively localize at some future time. Future localization of proactively internationalized products becomes much more cost-effective because product components do not have to go through a disruptive and time-consuming retrofitting process to support a decision to launch sales in a new market. Avoidance of the disruption causes turnaround time from decision to delivery to be substantially shorter, and therefore revenue gains occur sooner.
Internationalization of software consists of three basic task types, each supported by numerous subtasks. The first of these is the removal of cultural assumptions from software design. The second is architectural separation of the presentation layer from the business logic layer. The third is implementation of support for global norms such as character sets or accounting procedures.
Removal of cultural assumptions is somewhat easier said than done. Such assumptions are not made by software developers out of malice but, rather, through understandable ignorance, albeit also sometimes out of time pressure. Many North Americans are unfamiliar with norms in other countries. For example, developers trained at US institutions simply may not realize that decimal separation is actually indicated by commas in much of the world. Unfortunately, few university computer science departments teach the principles of internationalization, so one can hardly fault the graduates of those institutions. Another highly prevalent category of cultural assumptions are those surrounding generic linguistic issues. Lack of understanding of text expansion is one of these, as is how unresolvable grammatical paradoxes can be created by string concatenation.
There is a plethora of issues here but, for simplicity’s sake, let it be said that the goal of internationalization is to create a locale-neutral product. This is done by creating virtual “layers” of program code that are discrete from one another. These layers have different functions. The “presentation” layer is that which the user sees and interacts with. The “business logic” layer is the area of code that is the functional “guts” of the program. In simple words, that’s where the program does whatever it does. There may also be a “database” layer, where data is stored and from where it is retrieved. In most programs, data is transferred back and forth between these layers, so it is not only the program code that defines operations within these layers that is important, but also the transport mechanisms between the layers that require scrutiny for internationalization support.
One problem occurs when these layers are not cleanly separated from one another. Symptomatic of this kind of problem is when localization of the presentation layer causes malfunction within the business logic layer. An example I once encountered was the usage of the terms high, medium and low from the presentation layer which were taken into the business logic layer for comparison with the volume settings that modems reported using those same English words. One can easily imagine what happened when the presentation layer was translated: the comparison test failed every time because the presentation layer used different words, resulting in the inability of the user to accurately determine or set the modem volume.
An example of problems resulting from poorly internationalized transport mechanisms is another issue I recently encountered. The product consisted of a Windows client that drew its strings from a UNIX back-end server and also used a similar UNIX server to store data. The developers failed to realize that there are character encoding differences between the two operating systems. The code that transferred data back and forth between these two platforms therefore failed to properly convert strings pulled from the UNIX server to populate the user interface (UI), resulting in a nonsensical UI. It also failed to properly store and return data entered by the user. Since some of the data entered was the user’s password, logging on to the application failed when the user name or password contained characters corrupted by the transport process.
Fortunately, many of these kinds of functional problems can be easily exposed by pseudo-localization. This technique involves using software tools to simulate translation of presentation layer program code that is then sent for testing. This brings up the subject of when, in the development process, testing for international support should be carried out and how extensive it should be. Many companies push this into the functional area of localization, but it does not belong there. Even companies that do not localize may wish to sell their products in non-English-speaking locales. Therefore, the products should fully support the functional requirements of those locales.
Pseudo-localization is one strategy to proactively test for international support, but it cannot cover all cases. Functional requirements need to be derived from the globalization strategy, as previously described, and then tested against during the core code development process.
One such example from my past involved 128-bit data encryption algorithms that were built into a product my employer produced at the time. Among other markets, the product was intended for sale in France. At that time, 128-bit encryption was illegal in France, so internationalization in this case included building in the capability to suppress this feature for French as well as for English product builds shipping to that region. While this example is somewhat exotic, internationalization of core products may come up in many other more mundane contexts, such as currency format support, date and time formatting, business logic rules such as application of value-added tax and a wide range of other product attributes that have nothing to do with localization in the linguistic sense.
It is highly disruptive, time consuming and therefore expensive to go back and retrofit program code to be internationalized after a product is released. This generally involves branching the code. One branch will contain developments of new features and bug fixes to currently available versions, and may not be internationalized. The other branch contains changes to enable internationalization support. Then, at some point, the code must be merged and regression tested. Many companies follow this pattern, as pressure to release quickly to home-turf markets supersedes longer-range vision. But this is really akin to offloading development debt to the future. A far better and, in the long run, less expensive and more flexible practice is to accept a small amount of ongoing overhead to internationalize from day one in the development cycle. This ensures two vital factors: flexibility to localize quickly at any time and a gradual lessening of the internationalization learning curve as developers incorporate best practices into their daily work.
So far, we have discussed internationalization primarily in the context of software coding, but a quick detour to other areas of product development is worthwhile. One that comes to mind immediately is allowing sufficient white space in documentation to absorb language growth without causing pagination changes. This is rather like UI design. It is sometimes hard to convince technical writers that white space is their friend, but it is definitely the friend of the localizer and the CFO. Desktop publishing is expensive; a lot of time and money can be saved if translated documentation does not require repagination. Not having to repaginate can mitigate another unfortunate phenomenon that sometimes occurs: the separation of screenshots from descriptive text. In recent years, we have moved away from extensive documentation sets, but in the “olden days” when I cut my localization teeth, hard-coded page references were a big problem. These always had to be double-checked and adjusted in the final localized books because language growth caused the original page references to be inaccurate. Better authoring software, topic-based authoring and the migration to electronic documentation in recent years have largely eliminated this problem in today’s localization arena.
And, finally, internationalization can be carried into such areas as collateral material. I remember one graphic design product that had an extensive tutorial whose central theme was about creating a poster promoting aluminum can recycling. Our Nordic office had to completely replace this tutorial because aluminum cans were not sold in its region; hence, customers would have no idea what the tutorial was about. Choice of a more internationally generic central theme might have saved the company, or at least that regional office, a substantial amount of money. Then there is the whole area of advertising, whereby comparative ads are forbidden in some locales. Whether this kind of issue falls into the category of internationalization or that of localization is less clear, and there are many associated questions, not the least of which is who owns corporate identity: headquarters or the regional offices.
Localization
This brings us to localization. It is no accident that this area of the pyramid is the smallest. If globalization and internationalization as previously discussed are thoroughly executed, then a foundation is built that ensures that the effort required for localization is minimized. But let’s look at what localization is. I prefer the following definition: localization is the process of adapting products and accompanying materials to suit a target-market locale with the goal of making the product transparent to that locale, so that native users interact with it as if it were developed there and for that locale alone.
Given that globalization defines a product’s requirements and internationalization makes a product localizable, localization simply becomes a matter of imposing regional context upon a locale-neutral product. By definition, this usually involves translation, but it may not. For example, the creation of Microsoft Money 98 for the Canadian market required authoring of content that was relevant to Canadian wealth management, many attributes of which are different from its American counterpart. In this context, content creation was localization, not internationalization, although no translation was involved. Internationalization was the product design that allowed effortless substitution of Canadian content in place of the original American content.
Localization may involve imposing functional constraints on products. Earlier in this article I mentioned a case involving 128-bit encryption. The generic, internationalized version of the product could have either 128-bit or 64-bit encryption enabled. The localized version had only 64-bit encryption available to the user, and most of the product shipped to the locale was also translated into French.
The notion held by many a senior manager is that localization is excessively expensive. This is because cost generation in the globalization and internationalization layers of the pyramid is not readily visible. But inefficiencies created by poorly executed upstream activities adversely affect those downstream, resulting in greater overall cost (Figure 2). If company management complains that localization costs are too high, then the first place to look is not at the localization activities or unit prices but, instead, at the bottom and second layers of the pyramid. Unfortunately, this is far too frequently not well understood by C-level management.
Client-side localization project managers and solution architects at larger technology and linguistic service vendors tend to be the corporate resources that have the broadest viewpoint and greatest understanding of how the layers in the pyramid model affect one another. There are numerous strategies that may be employed to evangelize the relationship between the model’s layers.
I envision the localization manager in a fragile canoe paddling upstream from a sea of localized deliverables, straining against the prevailing corporate current of conflicting goals and budgetary constraints, navigating through rapids and narrows of internationalization, all the way to the distant peaks of globalization decisions that reside in some faraway corner office. Indeed, a lot of effort is necessary and the journey can be daunting. It can require perseverance and patience. But it can be equally fascinating if one is not afraid to get wet once in a while! Along the way, the pyramid model can be used as a secure anchor as well as a powerful, easily understood metaphor for charting direction and progress. May it serve you well!
This is an updated version of an article that was published in MultiLingual’s April/May 2009 Getting Started Guide
