It seems like ancient history to mesometimes, but I entered the world oflocalization just over ten years ago. In 1993I joined International Software Products inAmsterdam, a small and specialized local-ization vendor that still exists under thesame name. I had recently graduated as atechnical translator, using an article on thelaunch of Windows 3.1 as my thesis sub-ject. The seemingly incompatible marriageof language and technology has intriguedme ever since. Still, this is the core charac-teristic of what today we have come toknow as localization.

In a nutshell, localization revolvesaround combining language and technologyto produce a product that can cross culturaland language barriers. No more, no less.

In this article, I will explore the fun-damentals of localization: what it is, whereit started, how it progressed, what it istoday and what it may be tomorrow.Against this historical background I willdiscuss developments in the localizationservices business, translation technologyand general trends.

WherWhere It All Stare It All Star ted: ted: The 1980sThe 1980s

Desktop computers were introducedin the 1980s, and computer technologyslowly started to make its way to users whodid not necessarily have a background incomputer programming or engineering.The early 1980s also saw the first interna-tional ventures of US-based computerhardware and software firms. Sun Micro-systems, for example, began operations inEurope in 1983, expanding to Asia andAustralia in 1986. Microsoft had startedinternational operations earlier, openingits first overseas sales office in Tokyo inNovember 1978 and beginning its expan-sion into Europe in 1979.

The shift of computer hardware andsoftware use away from corporate or aca-demic IT departments to “normal” users’desks called for a shift in product featuresand functionality. Not only did desktop

computer users now need software thatwould enable them to do their work moreefficiently, but the software now also hadto reflect business processes that reflectedlocal standards and habits, including locallanguage. Word processors, for example,now needed to support input, processingand output of character sets in other lan-guages; language-specific features such ashyphenation and spelling; and a user inter-face in the user’s local language. The sameexpectations applied to hardware. Forexample, in 1985 the Spanish governmentdecreed that all computer keyboards soldin Spain should have the ñ key.

Internationalize to localize? The inter-national expansion of software and hard-ware developers automatically triggeredthe need to localize the products for inter-national markets. Initially, software ven-dors dealt with this new challenge in manydifferent ways. Some established in-houseteams of translators and language engi-neers to build international support intotheir products. Others simply chargedtheir international offices or distributorswith the task of localizing the products. Inboth cases, the localization effort remainedseparated from the development of theoriginal products. Development groupssimply handed off the software code andsource files for supporting documentationto those responsible for localization.

This separation of development andlocalization proved troublesome in manyrespects. Microsoft, for example, asked itsthen-distributor ASCII in Japan to localizeMultiplan (predecessor of Excel) intoJapanese. According to a Microsoft direc-tor responsible for localization at thattime, “we’d finish the product, ship it inthe United States, and then turn over thesource code library to the folks in Japan,wish them luck and go on vacation.”

Not only was locating the translatabletext embedded in the software source codequite difficult, but the requirement for addi-tional language versions of the code madeupdate and version management increasinglycomplex. Moreover, the localizers often had

to return the products to the developmentteams to first build in support for localizationor international computing standards. Withthese requests, the concept of international-ization was born.

Internationalization refers to theadaptation of products to support or en-able localization for international markets.Key features of internationalization havealways been the support of internationalnatural language character sets, separationof locale-specific features such as translat-able strings from the software code baseand the addition of functionality or fea-tures specific to foreign markets. Withoutinternationalization, localizing a productcan be very challenging.

Outsourcing localization. Initially, manysoftware publishers, such as Microsoft andOracle, established in-house localizationteams who had to adapt the products forkey international markets. A large portionof this effort was obviously the translationof the software product itself and support-ing documentation. US companies oftendecided to place the localization teams intheir European headquarters, many ofwhich were based in Ireland.

Even though it seems that localizationvendors are now moving activities to manylocations across the globe, Ireland estab-lished itself as the leader in the localizationindustry during the 1990s. Over the past10 to 20 years, the Industrial DevelopmentAuthority (IDA), a semi-governmentalbody, had the mandate to move Irelandforward industrially by attracting foreigninvestment. In the 1980s, a high concentra-tion of manufacturing companies startedin Ireland, including some high-tech com-panies. The Irish government providedwhat it called turnkey factories, where alarge multinational was offered a certainamount of government subsidy per em-ployee, plus facilities, grants and a corpo-rate tax rate of 10% as an incentive toinvest in Ireland.

After some failed investments and theincreased competition from manufacturingin cheap labor markets, the Irish government

44

GETTINGSTARTEDGU

IDE

LOCALIZATION

The Evolution The Evolution of Localizationof Localization

BerBert Esselinkt Esselink

switched its focus to research and develop-ment and the high-tech, blue-chip compa-nies, that is, a more long-term strategy. Mostlarge software and Web companies now havea presence in Ireland, with the bulk of theirlocalization being managed from there,including Microsoft, Oracle, Lotus Develop-ment, Visio International, Sun Microsystems,Siebel and FileNET.

The key benefits they offered these com-panies included a certain amount of money peremployee, a 10% corporate tax rate and exemp-tion from value-added tax (VAT). All products,including software, exported to Europe areexempt from VAT in Ireland. In addition, com-petitive labor costs, with social costs at approx-imately 12% to 15% per employee, mean that itis cheaper to employ people in Ireland than inmany of the European Union countries. Com-pared to the United States,development costs are stilllower in Ireland. And Irelandoffered a young, well-educat-ed, motivated work force.Approximately 50% of thepopulation was under 25 atthe beginning of the 1990s.

The Irish governmenthas invested a great deal ofsubsidy in education. Therenow is a strong push to offeradditional computer coursesto cope with the growingdemand for IT and localiza-tion staff. This, combinedwith the fact that Ireland is anEnglish-speaking nation onthe edge of Europe that servesas a gateway to Europe andthe Euro zone, made manyUS-based companies decideto base their European head-quarters or distribution cen-ters in Dublin.

Translators, localization engineersand project managers were recruited fromall over Europe to be trained and employedas localizers in Ireland. For most transla-tors, it was their first introduction not onlyto computers, but also to the concepts ofsoftware localization.

Although Dublin in the late 1980s andearly 1990s was a very attractive place forlocalization experts, with many job opportu-nities and a strong social network, softwarepublishers began to doubt the validity of thein-house localization model. Not only did newrecruits face a steep training curve, but therapid growth of products sold internationallyand the content explosion also created largelocalization departments that were difficult tosustain. Business fluctuations — very busy just

before new product releases, very quiet after— contributed to this problem, as did thedifficulty of keeping translators in anothercountry for a long time because localizationreally wasn’t very exciting (imagine twomonths of translating on-line help files) andnot always well paid.

Software publishers increasingly real-ized that localization was not part of theircore business and should ideally be out-sourced to external service providers.

One of the first companies to realizethere was a service offering to be built aroundthis need was INK, a European translationservices network established in 1980. INKbecame one of the first companies in theworld to offer outsourced localization servic-es. In addition to translation into all lan-guages required by software publishers, this

service included localization engineering anddesktop publishing and, most importantly,the project management of these multilin-gual localization projects.

Translation technology. INK was alsoone of the first companies to create desk-top translation support tools, called theINK TextTools, the first technology com-mercially developed to support translators.As a historical note, the present companyLionbridge was “spun off from StreamInternational, which itself had emergedfrom R.R. Donnelley’s acquisition of INK,”said Lionbridge CEO Rory Cowan in 1997.

In 1987, a German translation compa-ny called TRADOS was reselling the INKTextTools and a year later released TED, theTranslation Editor plug-in for TextTools.

Shortly thereafter, TRADOS released thefirst version of its Translator’s Workbenchtranslation memory (TM) product. TRA-DOS continued to establish itself as theindustry leader in TM technology through-out the 1990s, boosted by Microsoft takinga 20% stake in 1997.

Initially, TM technology could onlydeal with text files. Hardly any technologywas commercially available for the localiza-tion of software user interfaces. Most soft-ware publishers built proprietary tools,which were tailored to their own sourcecode format and standards and used bytheir internal teams. Development of thesetools was often quite ad hoc and un-structured. As a result, early generations ofsoftware localization tools were usuallyquite buggy and unreliable.

1990s: An Industr1990s: An IndustryyEstablishedEstablished

Throughout the 1990s, alarge number of localizationservice providers were born,many of which were little morethan rebranded translationfirms. For the IT industry, thesky was the limit, the globe wasits marketplace, and the local-ization industry followed close-ly in its footsteps.

After the initial pioneer-ing efforts of translation com-panies adapting to the newparadigm of localization, the1990s clearly saw the establish-ment of a true localizationservices industry. Software andhardware publishers increas-ingly outsourced translationand localization tasks to focuson their core competencies.

The need for outsourced full-service local-ization suppliers was growing rapidly.

Within a localization services compa-ny, localization teams would typically becoordinated by a project manager oversee-ing schedules and budgets, a linguist tomonitor any linguistic issues, an engineerto compile and test localized software andon-line help and a desktop publisher toproduce translated printed or on-linemanuals. A typical localization projectconsisted — and often still consists — of asoftware component, an on-line help com-ponent and some printed materials such asa getting started guide.

To localize a software application,localization engineers receive a copy of thesoftware build environment, extract the

55

GETTINGSTARTEDGU

IDE

LOCALIZATION

A translator’s-eye view of XLIFF

resource files with translatable text, preparetranslation kits and support the translatorsduring their work. Post-translation, theengineers merge the translated files with thebuild environments and compile localizedcopies of the software application. Thisalways requires some level of bug-fixing,user interface resizing and testing. A simi-lar approach is taken to produce localizedversions of on-line help systems. Thesource files, mostly RTF or HTML docu-ments, are translated, and a compilationand testing phase follows. Most on-linehelp systems and printed documents con-tain screen captures of the software, soincluding pictures of the localized softwareapplication can only be done once theapplication has been fully translated, builtand tested. These dependencies and manyothers have always made the managementof localization projects quite a challenge.

Consolidation and outsourcing. Oneof the developments that characterized thelocalization industry throughout the 1990swas consolidation. Localization serviceproviders merged with others in order to“eat the competition” or to add serviceofferings, to reach a wider geographical

spread — or they could merge simplybecause they had some money to burn. Thelist of companies that were acquired seemsendless. From at least a dozen large multi-language vendors in localization, we arecurrently down to a handful, with the mainplayers being Bowne Global Solutions,Lionbridge and SDL International.

Consolidation also manifested itselfin the emergence of a relatively standardproduction outsourcing framework. Thelarger multilanguage vendors (MLVs) tookon multilanguage, multiservice projects,outsourcing the core translation servicesto single-language vendors (SLVs), one ineach target country. SLVs normally workinto one target language only, from one ormore source languages, and either workwith on-site translators or contractors.

Throughout the 1990s the localizationindustry further professionalized, includ-ing industry organizations, conferences,publications, academic interest and gener-ally increased visibility. Obviously, theincreasing number of companies jumpingon the localization bandwagon resulted infierce competition and increased pressureon pricing. As a direct result, benefits andcost savings from the use of TMs, forexample, quickly shifted from the transla-tor’s desk to the localization vendor andeventually to the customer. Today, nolocalization quote is sent out without adetailed breakdown of full matches, fuzzymatches and repetition discounts throughthe use of TM database technology.

FrFrom TM to GMSom TM to GMS

TM technology plays a dominant rolein localization for various reasons. First ofall, most software companies aim for“simship” (simultaneous release) of all lan-guage versions of their products. This meansthat translation of the software product andsupporting on-line documentation has tostart while the English product is still underdevelopment. Translating subsequent devel-opment updates of a product is then greatlysimplified by the use of TM technology.Moreover, after general release, most soft-ware products are updated at least once ayear. These updates usually just add featuresonto a stable base platform, making it all themore important to be able to reuse — orleverage — previously produced contentand translations.

Another type of translation technologycommonly used in localization projects issoftware user interface localization tools.These tools are used to translate software re-source files or even binary files and enable the

localizer to not only translate but also resizeand test the user interface. Examples oflocalization tools are Alchemy’s CATALYSTand PASS Engineering’s PASSOLO.

By the end of the 1990s the Internethad changed many things in localization,such as the introduction of globalizationmanagement systems (GMS). Riding thedot-com wave, various companies offeredrevolutionary new ways of managingtranslation and localization projects, stor-ing and publishing multilingual contentand fully automating localization processes.Although this new technology had someimpact on existing outsourcing modelsand processes in the localization industry,it became rapidly clear that although aGMS could be useful for content globaliza-tion programs (for example multilingualWeb sites), the world of software localiza-tion still required a lot of “traditional”expertise and dedicated teamwork.

With Web sites containing more andmore software functionality and softwareapplications increasingly deploying a Webinterface, we can no longer make a cleardistinction between software and contentwhen we discuss localization. The tradi-tional definition in which localization onlyrefers to software applications and sup-porting content is no longer valid. Today,even producing a multilingual version ofan on-line support system, e-business por-tal or knowledge base could be defined as alocalization project.

In other words, the turn of the centuryalso introduced a new view towards localiza-tion and translation.

What Lies AheadWhat Lies Ahead

So, what is so different now in localiza-tion compared to what we got used to duringthe 1990s?

Not as much as you might expect. Afterall, many localization projects fit the profilethat we’ve grown accustomed to over the pastyears: Windows-based desktop softwareproducts with some translatable resourcefiles, basic engineering and compilationrequirements, HTML files to use for the on-line help and possibly some product collater-al or manuals to be printed or published inPDF format.

Even though these typical softwarelocalization projects may still be the bulk ofthe work for many localization serviceproviders, they are quickly being supplantedby new types of localization projects wherethe focus is on programming and publishingenvironments such as XML, Java and .NET.Also, content translation projects are now

66

GETTINGSTARTEDGU

IDE

LOCALIZATION

often considered as localization projects sim-ply because of the complex environments inwhich the content is authored, managed,stored and published. Most of today’s Websites contain so much scripting and softwarefunctionality that Web localization requires awide range of engineering skills. For Websites based on content management systems(CMSs), the story gets even more complex:when content is continuously updated andpublished in multiple languages, the transla-tion process must be truly integrated with theoverall content lifecycle.

Apart from a renewed focus on con-tent localization, we have also seen variousother important developments over thepast few years, such as the growing impor-tance of open standards. Examples ofopen standards in the localization indus-try are Translation Memory eXchange(TMX) and XML Localization InterchangeFile Format (XLIFF). Many TM tools sup-port TMX for the exchange of TM data-bases between different tools, and XLIFFis being adopted by companies such asSun Microsystems and Oracle. A SunMicrosystems manager recently said,“XLIFF allows our interaction with trans-lation vendors to be much more efficient.There is less need for translators tobecome engineering experts in the manydifferent source file formats that are cur-rently being used — SGML, HTML, MIF,RTF and the numerous software messagefile formats. Instead, XLIFF allows transla-tion vendors to concentrate on their corecompetency: translation of words.”

Back to basics? Does the popularity ofXLIFF signal a trend? Throughout the1990s, the localization industry tried toturn translators into semi-engineers. Is itnow expecting them to just translate again?It certainly looks that way. For the pastdecades, content authors and translators

may simply have been “distracted” by thepossibilities and the features the new tech-nologies had to offer — all those file for-mats, all those compilers, all these newtools, all the output formats, all those coolgraphics and layout features! If contentmanagement fulfills all its promises, con-tent creators may in a few years be writingtext in a browser template with fields pre-defined by the CMS, and translators mayall be working in a TM tool interface thatonly shows them long lists of translatablesegments, possibly partly pretranslated.We have come full circle: authors authorand translators translate.

Is this a bad thing? Not necessarily.Throughout the 1990s, one of the biggest“linguistic” challenges was to maintainconsistency with “the Microsoft glos-saries,” but today we see a new apprecia-tion of all the core translation skills anddomain expertise that we often consideredno longer critical in localization. A local-ization service provider translating an ERPsoftware package or an SAP support docu-ment had better make sure to use transla-tors who know these domains inside outand should not rely on translators justlooking at some glossaries. Localizationcompanies now need to face these newchallenges and higher customer demands.

New Kids on the BlockNew Kids on the Block

The year 2002 included one of thelargest mergers in the history of localization,as Bowne Global Solutions acquired BerlitzGlobalNET to become the largest localizationservice provider. Various new localizationorganizations were launched. And on thetechnology side, the main developments canbe seen in server-based TM systems. TRA-DOS, for example, recently released its TMServer product, a new technology that offers

centralized TM for client server environ-ments. Telelingua also introduced T-RemoteMemory, a distributed computing architec-ture using Web services.

Software user interface localization toolsnow all offer support for Microsoft’s .NET pro-gramming environment. According to a whitepaper released by Alchemy Software, “whilefundamental approaches to application designremain somewhat consistent with the approachtraditionally chosen by desktop applicationdevelopers, the localization service providercommunity faces a daunting challenge of up-skilling and retooling their localization teamswhile embracing this new Microsoft technolo-gy. Coming to grips with the new open stan-dards and learning the nuances of translating.NET technology will present both a financialand an educational challenge.”

Based on this comment and other sig-nals from experts in the field, it looks likelythat while translators will be able andexpected to increasingly focus on their lin-guistic tasks in localization, the bar of tech-nical complexity will be raised considerablyas well. This applies not just to softwarelocalization, but also to the wider context ofcontent localization.

So the question remains, what have welearned over the past 20 years of localiza-tion and do the lessons that we have learnedstill apply to today’s new realities of contentlocalization? It almost seems like twoworlds are now colliding: software localiza-tion with a strong focus on technical skillsand technical complexity for translators onthe one hand, and content localization witha strong focus on linguistic skills and tech-nical simplicity for translators on the other.With the Internet increasingly merging plat-form and content, the localization industrywill have to rapidly adapt its processes, qual-ity standards and resourcing approach tothese new requirements. ΩΩ

GETTINGSTARTEDGU

IDE

LOCALIZATION

77