Rookie Story: Where to Start with Localisation Management?

Congratulations! You aced that interview a few weeks ago, and this morning you strolled into the office with a spring in your step! You had the HR induction and were introduced to your new colleagues. Now you’re logging onto the network, the company handbook reassuringly lying on the corner of your desk, or saved on your desktop.

Time to get started! The Company hired you to bring under control this thing almost mysteriously referred to as “Translations”. Your objectives are simple: reduce cost and improve quality. You are their first ever Localisation Manager, and you know the keys to your success will be the   standardisation and centralisation of all Localisation activities.

So what do you need to consider from a technical and organisational point of view?

Getting to Know your Internal Customers

If there have been Translations in your Organisation, there are existing processes and linguistic assets you should be able to build on. You need to quickly learn about them by focussing on:

1. Who are your allies? Each Department, Local Office etc. probably has at least one “Translation person”. Find out who they are and what they have been doing. Determine whether they will remain involved once you’ve established the new structure, or if they expect to be relieved of Localisation duties. All going well, you may be able to enroll some of them in an inter-departmental Localisation team, even if it’s only a virtual team.
2. What is the inventory of current processes? Meet the current owners and document everything. No need for anything fancy since you are going to change these processes, but you need to have it all down so that when the inventory is finished you have an accurate and complete picture.
3. What are the points common to all? Which of those processes work well and which don’t? The successful ones will be the building blocks for your future world.
4. What are the specificities of each one? Which are worth keeping? Can they be used by other parts of the Organisation? Do they need to remain specific? Your new processes will need to achieve a balance between harmonisation and flexibility.
5. Do any of those existing processes use technology such as CAT Tools, Content Management Systems, Translation Management Systems? If so should they be upscaled and shared across the Organization?
6. Do any maintain linguistic assets like Glossaries, Style guides, Translation Memories or even just bilingual files which could be used to create TM’s?

Understanding your product lines

You need to understand what you are going to localise thoroughly before you can develop the processes. The question to answer are:

1. What types of content: marketing, commercial website, Software, Help systems, self-service technical content, user-driven content like blogs etc. all those use very different registers, vocabulary, address etc. Moreover the choices made will differ again from one language to the next. Some content types require high volumes at low cost, such as Support content or product specifications. Some require high quality and creativity like Copywriting and Transcreation and you may even choose not to use TM’s for some of those. Some will be specific to parts of your Organisation while other will be global material. You will need to ensure a consistent Corporate identity across all these, in all languages.
2. What are the fields: automotive, medical, IT require linguists with different backgrounds and specialisation. Make sure you know all the areas of expertise to cover during Translation and Review. For some you might to add Subject Matter Expert (SME) review to the more common step of Linguistic Review. Review changes will need to be implemented, communicated to Translators, fed into the TM’s, but the process will need to let SME’s take part in the process without having to learn CAT Tools.
3. From a technical point of view you will also need to work with the content creators to determine the type of files you will receive from them and those they expect to receive back.
4. Start a war on spread sheets as soon as possible. You probably won’t win it but the more you root out, the better. Teach your customers to understand how parsing rules protect their code by exposing only Localisable content during translation. Promote Localisation awareness during Development and Content creation. Document best practices such as avoiding hard-coded strings, providing enough space in the UI to accommodate the fact that some translations will be up to 30% longer than source text, at least if that is English.
5. Your aim should be:
   • to receive files that can go straight to Translation with minimum pre-processing
   • to deliver files that your customers can drop into their build or repository for immediate use.
6. No one should be doing any copy-paste engineering, manual renaming or file conversion.

Designing your Workflows

This can start with a pen and paper, a white board or whatever helps you think quicker, but it should end with a flowchart or set of flowcharts describing the process you’re setting up.

1. Collaborate with your internal customers. You need to agree a signoff process, and avoid multiple source updates during or after the Translation process.
2. Enumerate all the stages required and determine the following:
   • How many workflows do you need to describe all scenarios? Try to find the right balance: fewer workflows ensures efficiency, but too few workflows will lead participants to implement their own sub-processes to achieve their goals and you will lose control and visibility.
   • What stages do you need? The most common are:
     1. Pre-processing
     2. Translation
     3. Linguistic Review
     4. Post-Processing
     5. Visual QA
3. Who are the owners of each step? Are they internal or external (i.e. colleagues or service providers)? How will you monitor progress and status? How will you pay?
4. Is there a feedback loop and approval attached to certain steps? Will they prevent the workflow from advancing if certain criteria are not adhered to? Is there a limit to the number of iteration for certain loops?
5. What automation can be put in place to remove human errors, bottle necks and “middle men” handling transactions.

Choosing your Vendors

Once you’ve determined which of your workflow steps need to be outsourced, you will need to select your providers. Linguistic vendors will likely be your most important choice.

Translation

In-house translators are a luxury rarely afforded. When choosing Translation vendors, first decide between Freelancers and Language Service Providers (LSP). Managing a pool of Translators is a job in itself, so most will hire the services of an LSP which will also be able to provide relief in terms of Project Management, Technology changes, Staff fluctuations depending on activity or holiday periods etc.. Having more than one LSP can be good strategic choice: it gives you more flexibility with scheduling and pricing. You can specialise your vendors according to content, region or strength. A certain amount of overlap is necessary for you to be able to compare their performance and benefit from a bit of healthy competition.

Linguistic review

Whichever setup you have for Translation, you will need linguistic review in order to ensure the integrity of the message is kept in the target languages. You will also need to ensure consistency between Translators or Agencies, check Terminology, maintain TM’s and Style guides.

Marketing and Local Sales Offices often get involved with that. However using internal staff removes them from their core tasks, unless you are lucky to have dedicated Reviewers. More than likely in-country colleagues will find it difficult to keep up with the volume and fluctuations of the Review work and ultimately will prove an unreliable resource. The solution is to hire the services of professional Reviewers. Many LSPs provide such services.  Some ask their competing providers to review each other, but that often results in counter productive arguments. A third-party dedicated review vendor will be the best to enforce consistency, accurately measure quality, maintain linguistic assets, and even manage translator queries on your behalf.

Selecting Technology

Translation Memory technology is a must. Which one you go for may be determined or influenced by existing internal processes, particularly if there are linguistic assets (TM’s and Glossaries) in proprietary formats. Your vendors may also have a preferred technology or even propose to use their own. If you go down that road, make sure you own the linguistic assets. The file format is another choice that needs to be made carefully from the start. Open source formats may save you from being locked into one technology. However technology vendors often develop better functionalities for their proprietary formats. It can be a trade-off between productivity and compatibility.

The good news is that conversion between formats is almost always possible. This means migration between technologies is possible, but avoid including conversion as a routine part of the process. Even if it’s automated, having to routinely output TM in several formats for example, will introduce inefficiencies and increased user support requirements.

Translation Management Systems have become so common, some think they are on the way out. You will at the very least, need a Portal to support file transactions, and share your linguistic assets with all the participants in your supply chain. Emails, preferably automatic notifications, should be used to support the transactions, but they should be avoided when it comes to file swapping. FTP is a common option, easy to set up, learn and cheap to run, but it can soon turn into a mess and gives you zero Project Management visibility. In order to achieve efficient status monitoring, resource pooling and any type of automation, you should consider a Translation Management System.

Whether you go for the big guns like WorldServer or SDL TMS, or for something more agile like XTRF TMS, you will reduce the amount of bottle necks in your process: handoffs will go straight from one participant to the next. The Project Managers will still have visibility, but no one will have to wait on them to pass on the handoff before they get started. TM’s will be updated in real-time and new content will become re-usable immediately.

A few things to look out for in your selection:

1. Less click = shorter kickoff time. Setting up Projects in a TMS is an investment. It is always going to be longer then dumping files on an FTP and emailing people to go get them if you look at an isolated Project. As soon as you start looking at a stream of Projects TMS makes complete sense. Still, a TMS’s worst enemy is how many clicks it needs to get going.
2. Scalability: you need the ability to start small and deploy further, without worrying about licenses or bandwidth.
3. Workflow designer: demand a visual interface, easy to customise which can be edited without having to hire the services of the technology provider. Don’t settle for anything that will leave out at the mercy of the landlord.
4. Hosting: weigh your options carefully here again. In-house is good if you have the infrastructure and IT staff. But letting the Technology provider host the product may a more reliable option. This is their business after all, maybe you don’t need to reinvent the wheel on that one.
5. User support: the cost and responsiveness of the Support service is essential. No matter how skillful you and your team are, once you deploy a TMS to dozens of individual linguists there will be a non-negligeable demand for training and support. Make sure this is provided for before it happens.

Once you’ve made all these decisions, you will be in good shape to start building and efficient Localisation process. Last but not least, don’t forget to decide whether to spell Localisation with an “s” or a “z”, and then stick to it! 🙂

 

Related articles:

Crowdsourcing in Localisation: Next Step or Major Faux Pas?
Globalization – The importance of thinking globally
SDL Trados 2007: Quick Guide for the Complete Beginner
Which comes first, Globalization or Internationalization?
Who’s responsible for Localization in your organization?

 

Advertisement

SDL Trados Studio 2011 Preview: Can It Convince Trados 2007 Faithfuls?

SDL have been drumming up interest for SDL Trados Studio 2011 through the summer. Eventhough the successor to SDL Trados Studio 2009 is announced to release at the end of September, I must admit that I have been slower to turn my attention to it than I was with Studio 2009.

This is in part due to my current occupation which brings me to spend more time using Translation Management Systems than CAT tools. But it is also because SDL Trados Studio 2009 was such an exciting breakthrough: the idea of fully integrating SDLX, Trados and Synergy was a major shift. The technology behind the new Studio file formats (.sdlxliff bilingual files, .sdltm Translation Memories, and .sdltb Term database) was also quite promising. Lastly, the productivity improvements were many thanks to the entirely new xml-based TM engine, which allows multiple TMs look-ups, AutoPropagation™, AutoSuggest™, QuickPlace™, Real-Time Preview etc.

Reading through those posts about SDL Trados Studio 2009 reminds me how attractive it seemed. But there was also a distinct possibility that this substantial innovation would not necessarily cause a mass migration of Trados 2007 users. Budgets were tight due to the worldwide recession. The prospect of migrating entire Localisation production chains seemed like an unnecessary overhead. Users would have to be re-trained, Enterprise and LSP proprietary automation redesigned in order to work with those new file formats. Above all, SDL Trados 2007 was delivering perfectly acceptable services.

Sure enough, two years later, empirical evidence suggests Trados 2007 is alive and well. It is apparent in my daily interaction with Localisation professional around the World. All Trados users are aware of Studio by now, but I’d venture to say all of them still have Trados 2007 installed, and that it probably even remains their SDL tool of choice. Assuming the hits on Localization, Localisation have any statistical value, it is a telling sign that SDL Trados 2007: Quick Guide for the Complete Beginner continues to be the most frequently visited post in these pages, 2.5 years after being posted. But then perhaps that’s my own fault, for not making a beginner’s guide to Studio 2009…

So let’s now turn to the future and look at SDL Trados Studio 2011’s prospects. New comers to the CAT tools market will inevitably consider Trados as one of their options; which new features it offers does not matter much. As for existing Studio 2009 users, I doubt any amount of innovation can make them upgrade if they haven’t already a budget or subscription plan which allows for systematic upgrades. The real measure of the impact of Studio 2011 will be whether it can convince the remaining Trados 2007 users.

What does SDL Trados Studio 2011 bring to the table to meet the needs of this demographic?

Some New Features

All the great advances made with Studio 2009 are of course still available, although some of them have matured. The main highlights in terms of novelty are the return of Perfect Match and the focus on productivity during review cycles.

Perfect match 2.0

Perfect Match makes a return to Trados: it existed in Trados 2007 but was absent in Studio until now. It now co-exists with Context Match, and together with Terminology and Sub-Segment leveraging make up the concept of Total Leveraging.

The differences between Perfect and Context Matches are:

• Perfect Match can run on a batch of files (right-click a bilingual file to pre-translate and select Batch Tasks > Perfect Match) and is good for Project rather than document updates.
• SDLXLIFF, TTX and ITD are all supported.
• Context Match runs on successive versions of the same file, file names have to match.
• They are marked as PM and CM respectively in the resulting bilingual files. Both segment types are locked.

Track changes

Studio 2011 uses a change tracking technology which is fully compatible with Microsoft Word. Thanks to the SDL XLIFF Converter, an SDL Open Exchange add-on now included in Studio, changes and comments made in Trados can be viewed, accepted etc. in Microsoft Word and vice versa.

This makes it easy to collaborate with users who do not have Studio during the review process. Whether they are linguists using other CAT tools or Subject Matter Experts not familiar with any CAT tool, they will all be able to input their feedback using Word.

The versions of Word officially supported are 2007 and 2010; 2003 should work but this is unconfirmed for now. Track Changes can be turned on or off for different parts of the process such as Translation, Review or Signoff under Options > Tools.

Display Filters

In Trados Studio, segments can be filtered to show only those relevant to the current task. The filters in this list are another way Studio 2011 helps productivity during review, with new options such as Segments with Comments or Segments with Track Changes. These filters can also be applied during export using the SDL XLIFF Converter.

Improved Spell Checkers

Trados Studio 2011 brings the Microsoft Spell Checker back. Hunspell is still available but users can now configure which checker to use for each language. This is to resolve issues present in the Studio 2009 Spell Checkers which were not fully accurate for certain languages, notably Scandinavian ones.

QA Checker 3.0

QA Checker 3’s claim to fame is the interactive dialog box which makes reviewing and implementing reported issues a much clearer process. It is reportedly also a first step in longer term plans of adding grammar checks.

Enhanced File Filters

Studio 2011 includes new filters for:

• OpenOffice, Libre Office, StarOffice and IBM Lotus Symphony.
• INX and Java properties.
• improved FrameMaker MIF support.
• bilingual Word files which can now be edited directly.

Other novelties to discover in Trados Studio 2011 include pseudo-translation, for testing parsing rules and settings before the launch of new Project Types. Character, rather than just wordcount is now also available.

An Evolving Image

Lighter Ownership Experience

First impressions tend to last, and the installation and activation process are a big part of how a new application is experienced by users. In Studio 2011 the installation is made simpler. One single installer enables compatibility with Trados 2007 file formats (.ttx, .itd, TM upgrades and alignment tasks). With TTXit!, freely available on SDL Open Exchange, users should no longer need a copy of Trados 2007 in addition to Studio.

Because the user interface and technology in Studio 2011 are so similar to Studio 2009, no big learning curve is required. Any time and effort invested in learning to use Studio will just give users a head start in being proficient at the new version.

Starting a project itself is a simpler process, with only 3 files needed (source, bilingual and TM), and no associated folder structure in the background.

The standalone License Manager has been replaced. Activation is now fully integrated into Studio, and borrowing licenses are supported.

Finally, the SDL Multiterm Widget is being pushed into the limelight. This taskbar tool lets you browse Terminology from external applications like Microsoft Excel, Powerpoint etc. at the touch of a button. It also provides a handy shortcut to searches in Google or Wikipedia and is now included in Trados Studio.

Expanding the Trados Community

Technology webinars have been an SDL strength for a long time now. Call it free education or a carbon-conscious alternative to business trips, they are an efficient way for any technology vendor to showcase their goods.

There are other ways SDL share information about Trados like the Studio 2011 Series on the SDL Blog, or the SDL Trados Youtube channel. SDL are certainly not the only language technology provider to use new media but I think it’s fair to mention their consistent effort to meet their user community and ensure information is widely available.

SDL OpenExchange is also used to promote this spirit of community with Developers (look out for prize competitions!) and has produced a number commercial as well as free Apps which efficiently respond to very specific needs.

The connectivity with SDL’s Enterprise applications is also kept up to date. Studio 2011 can connect to WorldServer or TMS Translation Memories for Concordance just like it would with local TMs. An Express Edition of Studio 2011 will be released for users who need Studio only for WorldServer projects.

SDL TMS 2007 Service Pack 4: Love and Hate

I always find it challenging to get a fair idea of what Enterprise tools can do before making a purchase decision. There is so much involved in setting them up that even if a trial version is available, the efforts required to perform meaningful testing are prohibitive.

Many such applications do not come ready out-of-the-box and require extensive customisation before they can be tailored to fit a specific business model.

This is why many purchase decisions are executive decisions, based on ROI reports and presentations showing what the software does. A demo might be setup for you on a dedicated server by the sales person, and you’ll be left thinking “hum…surely it’s not that simple”. This is also why 10 times out of 10, these pieces of software come with a Support package which lets you install regular and much needed updates and bug fixes.

It doesn’t have to be this way!

If you have the opportunity, go knock on a few door and try to find a company nearby which uses the software in a production environment. Contact them, ask to visit, get an independent demo. From my experience (not based on TMS that time) most people will be more than happy to tell you how much effort it took to setup, how many features still don’t work, but also how much their productivity has really increased and perhaps even how many of their employees have done a thesis on the subject! Bottom line: get real-life advice!

SDL TMS, or Translation Management System, is one such behemoth application. Trying to find independent information about TMS on the web is a challenge. In fact, even finding official information can prove frustrating. As for Special Interest Groups… those I found were for customers-only. It seems it’s buy first, we’ll talk later.

So what’s the big deal exactly? Well I’ve been working with TMS 2007 for about a year now and I have a few things to report: some good, some not so good.

What it does well

Let’s start with positive thoughts.

TMS is a workflow tool, designed to connect a customer directly to it localisation vendors and all their armies of sub vendors. It handles big volumes and short turnarounds really well, and is reasonably good at supporting your Translation Memory and Terminology Management needs. It also offers the reporting facilities necessary for all members of your localisation ecosystem to invoice each other, and you.

TMS automates part of the role of the middle men, and is ideal for localisation consumers with a constant stream of translation, especially if they come in the shape of numerous small projects.

Multiple alternative workflows can be set up, depending on vendor selection, TMs to leverage against, TMs to update, need for Linguistic Review etc. Once the correct workflow is selected at the job creation stage, you can be sure it will go through all the steps required. There is little or no human error possible, at least not in scheduling and assigning tasks to the right participant.

TM updates are handled automatically, literally seconds after the last human input in the workflow.

Where it lacks

So are all the vendors really gathering orderly around the assembly line and localising thereafter like a happy family?

Not exactly. There are a few snags.

My main grief is around TM Maintenance or the lack of it. Because TMS automatically updates the Translation Memories at whatever stage of your workflow you told it to, manual editing of the TMs has been neglected. A user can perform a Concordance search, but it is impossible to edit the Translation Units found. One cannot use TMS to fix inherited inconsistencies or any error found in legacy TUs.

This makes implementing Global changes a very untidy task: one needs to connect to the TM Server (hosted by SDL in most cases) using SDLX 2007 Professional. This, to me is total non-sense and here is why:

1. increasingly, the business model in Localisation is outsourcing.
2. once localisation is outsourced to agencies, these subcontract Single Language Vendors, who themselves might only be sub-contracting to freelancers.
3. less and less Localisation consumers employ in-house linguists.
4. their remaining in-country staff is Sales and Marketing, and has much more pressing matters to attend than editing TMs.

Now which version are these freelancers more likely to have? SDLX 2007 Professional (€2,995) or SDLX 2007 Freelance (€760)? I think you probably guessed it. SDL’s licensing model prevents linguists from maintaining TMs in TMS and seemingly forces corporations which bought TMS to support their outsourcing setup, to fix TMs in-house!

There are some workarounds to this, but for a piece of software of this caliber, I think this is a pretty shocking limitation.

The integration with MultiTerm has similar issues: only some of the functionality are available through TMS, the rest including editing Term entries has to be done using MultiTerm Online or Desktop.

Performance issues also tend to drive a lot of linguists offline! Depending on their setup, a lot of them find it more efficient to download jobs, translate offline in SDLX and upload the finished work back into TMS. While there is technically no difference in the end result, this is a disappointing interruption of the workflow.

Service Pack 4: An End to the Suffering?

Squeezing under the gate at the last second, like Bruce Willis in a classic movie, TMS 2007 Service Pack 4 sneaks in before the long-awaited SDL TMS 2010 and comes to the rescue.

With TMS 2010 now possibly slipping into 2011, it is a welcomed addition particularly due to the improvements it brings. Here are the most significant end-user facing features:

Browser support: IE 8 support added (IE 6 removed in future)

TM import: ITD, zipped ITDs, MDB (SDLX TMs). This is a partial solution to the lack of TM Maintenance feature I’ve talked about in this article.

Continued lack of support for TMX is attributed to the fact that this open-source format has too many proprietary specifications.

Reporting formats added: CSV, Excel 2007, PDF, RTF, Word 2007.

Branding and Fonts are customisable (by Professional Services).

TMS 2010 is expected to have end-user customisable reports.

QA Models

This all-new feature in SP4 is crucial if your workflow includes Linguistic Review. All changes made by the Reviewers are now recorded, and the Reviewers can tag them using customisable Error Rating and Categories.

1. Error Ratings and Categories: support for LISA model, SAE J2450, TMS classic out-of-the-box.
2. User-specific models can be created. Number of points deducted can also be specified in the QA Model.
3. Records can be retained at segment (for feedback to translators) or project level
4. Scoring methods: absolute or percentage
5. To apply a QA Model: add it to a Configuration (i.e workflow), and it will be available to Reviewers working on jobs passed through this config.
6. Reviewer usage: click Star at segment level to open the QA model window and enter Category and Rating.Pass/Fail status does not prevent reviewer from submitting or rejecting a job.

Globalization – The importance of thinking globally

Crouching Tiger, Hidden Dragon…

In essence, Globalization (Internationalization in MS speak) is your Kung Fu. Bear with me, I have a point here, either that or this is a thinly veiled attempt on my part to get you to read further. 🙂

Globalization represents more than just an all-embracing term used simply to describe the sub-processes of Internationalization and Localization, it is in fact both an ethos and strategy that describes how your organization needs to position and prepare every facet part of its being.

Those familiar with Chinese martial arts or who have spent too much time watching Kung Fu movies will understand the fundamental difference between the Tiger fighting style and the Dragon fighting style. The Tiger style relies on sheer strength and the memorization of moves, whereas the dragon style is based on the principal of a deeper understanding of movement. It’s about anticipating more than simply acting upon and reacting to events.

Staying on the fortune cookie philosophy theme, if you adopt the Tiger approach to Globalization you may make all the right moves, correctly identify your target global markets, prepare and push forward with Internationalization of your product with vigour and determination, and skilfully and swiftly execute product localization, but even this is not sufficient if you want to ensure your business is ready to go global and prepared for the effects of going global.

You need to adopt the dragon Style. In addition to the above actions, you should seek a deeper understanding of the impact that these actions will have on your business and anticipate this reaction. After all, every action has an equal and opposite reaction. Once you have decided to go global with your software offerings, you will have to consider how this decision will subsequently impact all areas of your business such as Programme/Project Management, Development & QA, Sales & Marketing, Legal, Accounting, Distribution, Support, etc.

Thinking out loud – So who does what?

Product Management: will need to coordinate with all groups to ensure that localized releases are part of any global product roadmap and are approved by and communicated to all stakeholders.

All global product release schedules need to recognize that the Development and QA teams will have to work in “harmony” with Localization Engineering and QA, and therefore core Development and QA time and resources will have to be allocated to addressing I18n, Customizability and Localizability issues.

Failure to factor these tasks into any global project scope will mean that a simship will be impossible, Developers and QA alike will be frustrated by having to potentially allocate additional time to deal with unplanned for I18N defects, Localization will be stalled until defects effecting Localizability and Customizability are addressed, and regional sales channels will suffer from late availability of localized product.

Development & QA: As mentioned above, these core groups, usually charged with domestic software releases, will now need to work in-synch with their Localization counterparts; the frequency and format of handoffs to the Localization team need to be agreed, I18N exit criteria will need to be established  for design and development phases, pseudo-localized software builds will need to be created for I18n testing, code freeze dates will need to be agreed to allow for the extra volume of i18n defects that will be logged during I18n/L10n testing, the workflow and management of i18N defects through the core defect tracking system will need to be established, and core Development and QA resources will need to be allocated to resolving and regressing i18N, Localizability, and Customizability defects.

The Localization team will mainly be focussed on addressing L10n issues, so the majority of I18n and Localizability issues will need to be resolved by the core Development team.

Even prior to Internationalization, it is essential that those at senior levels within an organisation understand the impact of going global on their core Development and QA teams.

As highlighted in my first post, assuming that the creation of localized software releases is the sole responsibility of a single Localization team is imprudent and unrealistic. Globalization means a significant investment in core Development and QA time and resources and cannot happen in isolation of these groups or without their involvement.

Sales and Marketing: Sales and Marketing teams responsible for the target regions need to be made aware of strategic plans regarding localized releases. Often these groups will be the ones who identified the business case/requirement for a localized software release.

Regional Sales and Marketing teams will have an insight into the features that are important to their markets and any customer issues with in-market localized product that need addressing as a matter of priority for subsequent releases. They will also be able to advise on any region specific customization of software features that will be required. These customizations will need to be considered during design and development under the heading of “Customizability”. Furthermore, it is important for Programme Management to work closely with these teams when formulating the localised product roadmap, ensuring they are involved in any beta program review of the software and they have sign-off as part of the localized product review process. This may all seem fairly obvious and simply requires clear lines of communication, but I have often witnessed a certain disconnect between regional offices and global Programme Management.

The following excerpt from Beyond Borders – Web Globalization Strategies by John Yunker (2003) is a good example of how poor communication and planning within an organization can ensure a rather embarrassing false start on the journey to global domination;

“The marketing director of a professional society wanted to expand the subscriber base in other countries. The society already had many international members, but because none of the publications had been translated, members needed as least a moderate grasp of English to reap the benefits of joining. So the marketing director decided to translate the society’s membership form into Chinese, in the hopes that it would make joining the society much easier for Chinese speakers and increase membership.

Within a few weeks, the society received its first completed Chinese form by fax, the membership directory, unaware of what the marketing director had been up to, looked at this form, filled out in Chinese, and said, “What the hell am I supposed to do with this?” The membership director didn’t understand Chinese. No one of her staff understood Chinese. Even if someone on her staff did understand Chinese, their membership database didn’t accept Chinese characters.

So this person in China completed the membership form and subscribed to a couple of publications and the organization could do nothing about it. The professional society didn’t even know what publications were selected because the publication names were translated to Chinese – and they had no English template to compare it against. It may seem obvious that you shouldn’t create marketing materials in a language your company can’t support, yet companies that jump into global markets too fast frequently repeat this scenario.” (Yunker, 2003, p.82).

Branding and cultural customization are also important considerations that also require input from regional Sales and Marketing groups. Some may favour regional branding and cultural customization over global branding with a universally consistent user-experience. This allows regional Sales and Marketing the flexibility to better connect with their target audience. It is all too easy to alienate your customers if they get the impression that your organization’s software products, website, support etc were not developed with their region in mind. However, others would argue that allowing such distinct and unique branding combined with a high level of customization on a region-by-region basis, simply serves to dilute global brand power, resulting in a confusing and inconsistent user-experience. Additionally, by allowing diverse and inconsistent localized content per region, the global management of this content can be troublesome and costly.

The whole area of cultural customization is vast and there is a lot of information as well as misinformation offered on this topic, and it can be hard to discern urban legend from truth. On the theme of colour and cultural significance of colour in the global marketplace, one publication I read recently would lead you to believe that red cars are illegal in Brazil and Ecuador because of the perception that they cause more accidents. This is in fact absolute bunkum. So approach cultural customization with caution and seek the guidance of local contacts.

Legal: There are a variety of laws governing software being sold in different regions of the world, many of these laws pertain to language and support for the official languages in these regions; such as the Toubon law in France, GB18030 certification for China, and the charter of the French Language in Quebec (Bill 101).

For translation of End-User License Agreements (EULAs) and software warranties, your organization will require the services of legal translators and a review of the EULAs by your in-country operations centres/partners to ensure compliance with local legislation.

Legal regulation on the sale of software worldwide is unlikely to become any more lenient. To the contrary, with proposals such as the EU’s two year guarantee for software (games), which would allow users who are unhappy with “buggy” software to return their purchase, the situation will only become more complex. This is another reason why a well thought-out Globalization strategy combined with a strong focus on I18n is of paramount importance.

With poor I18n, your localized software will inevitably contain more functional and cosmetic defects than the source release, and that could be a real headache when faced with a future where customers are within their rights to simply ask for their money back on the basis of these defects and are not compelled to wait for a hotfix as may currently be the case under the terms of existing EULAs.

Accounting: Your accounting team must be ready to provide pricing in the local currencies of the regions your software is to be sold into. Accordingly, they will also need to be ready to accept payment in these currencies. Ensure you have a clear understanding of how royalties and revenues from localized software sales are distributed throughout your organization.

Distribution: You will of course need to consider your distribution channels, competition, and how you will physically deploy your localized software to your customers. For hosted solutions, automatic updates etc; existing data centres serving your domestic customers may not offer sufficient connectivity/speed to customers in other regions.

Support: Before you have localized software in-market, your organization will need to be ready to support these target markets. It is an all too common mistake to simply expect that this will somehow take care of itself and that existing support channels for domestic product will be sufficient. This is yet another way to disaffect the customers in new markets you’ve worked so hard beguile with your digital wares.

You need to consider the mechanisms for localized support; knowledge base, email, phone etc. What level of support will your in-country operations centres/partners can offer, if any? How are support issues with localized software escalated? Do your call centre representatives have the necessary language skills and knowledge of the localized software to handle calls/emails from all the regions you sell your software in? Do you have a Content Management System (CMS) behind your existing website/knowledge-base? Does the functionality of this CMS lend itself to the management of global content in multiple languages?

Once the knowledge-base route has been exhausted, there is a common preconception that it is a good idea to heard customers to email support, like cows being shoved into a cattle crush, as opposed to presenting them with the option of phone support. This is based on the logic that email support is far more cost-effective than phone support. Whilst it makes sense to encourage customers to avail of email support over phone support, I do not believe it is a good idea to completely eliminate phone support as an option.

Many organizations prefer to remove any reference to phone support from their site. For me, this represents a false economy, whilst you may be saving on call centre costs, you will probably be losing customers, and any chance of repeat business. This is particularly flawed strategy in new markets where you are fighting for market-share.

I have yet to experience an email support system where I have received a (useful) answer “within 24 hours” as promised. Besides, 24 hours may be a long wait depending on the nature of the issue. Even if there is a customer cost associated with phone support, it is better to offer this as an option as opposed to lose customers who may prefer to simply return your software (see “Legal” above) and align themselves with your competitors rather than wait for a delayed response from support.

What happened to Localization??

You may have noticed that I have made no mention of the Localization team/departments specific responsibilities in terms of Globalization. This is a deliberate omission. I will address aspects of Localization in various future posts (after all, the URL for this blog puts me under some pressure to do so!). For now, however, it is more beneficial to recognize that in the grand scheme of Globalization, Localization is actually one of the simplest components. Granted, as “Localization” experts, we are in fact required to be “Globalization” experts and provide guidance in relation to Globalization strategies, but if all other areas of your business are ready to go global, then Localization should be the least of your worries.

Once again, failure to take a holistic approach to Globalization will result in Localization being a tedious, costly, and protracted affair. Localized product quality will suffer and inevitably your organization’s performance in the target region will be poor. Additionally you will have filled the lives of your Localization team with a degree of despair! So for the sake of good Karma, get the fundamentals right and Localization will be a walk in the park.

The above are just some of the areas for consideration when formulating your Globalization strategy. One could certainly write a book on the topic and a number have been written on the topic. Globalization is the broadest and most subjective area when it comes to looking at G11n, I18N, and L10n and is therefore open to the most debate.

What color/colour is the sky in your world?

The Sapir–Whorf hypothesis (roughly) states that through the medium of language, different cultures attempt to define their reality and enforce a structure on the world as they view it. This results in certain perspectives that are unique to particular cultures; this is why Localization and Globalization extend beyond simple translation.

This probably also goes some way to explaining why a Chinese friend and work colleague of mine finds a particular Rice Krispies Squares TV commercial so amusing, whilst I simple perceive it to be mind numbingly boring. Or maybe I just don’t get it! Whatever the case may be, to be truly successful in a particular regional market, your organization will not alone have to speak the language of that region, but also understand the predominant cultural perspectives distinct to that region.

The important thing is to have a carefully considered Globalization strategy that would make Lex Luthor seem nonchalant in his scheming, and to execute the plan in a decisive and coherent manner throughout the organization and without procrastination. Understanding that Globalization is the responsibility of your entire organization and must permeate through every level is a good first step.

This is particularly important in the current economic climate. Whilst many organizations are running home for shelter and scaling back on their global operations, this presents opportunities for other organizations to get traction in emerging markets if their Globalization strategy is sound. It may be a long term investment, but if your competition is busy running for cover, these recessionary times could represent an opportunity to gain market share in valuable new markets. As Warren Buffett said, “Be fearful when others are greedy, and be greedy when others are fearful.” In other words, advance when your competition is retreating from global markets.

In conclusion, you could of course try the Tiger approach and see what happens, but as another icon of our times (Homer Simpson) once said, “Trying Is the First Step towards Failure”. 🙂 So instead I urge you to think like the Dragon and have a deeper appreciation of how Globalization will impact your own organization and how your organization as a whole will need to evolve to meet these challenges.

Which comes first, Globalization or Internationalization?

In my previous blog entry, I covered the limitations of “Localization” as a generic label to describe what we in the software “Localization” industry continually strive to achieve under the headings of G11n, I18n and L10n, as well as the dangers of this branding in terms of how “Localization” can often be perceived as the sole responsibility of a single “Localization” group or department within an organization.

To add to the confusion, there are two separate and somewhat contradictory models used to describe the relationships between G11n, I18n, and L10n. Microsoft’s model and the model predominately used by the rest of the industry! J Naturally you will also encounter subtle variations to both these models within various organizations.

So before examining G11n, I18n, and L10n in more detail, it’s probably useful to familiarize yourself with the key differences and similarities between these two models.

Microsoft’s Internationalization Model

The graphic below (Fig. 1) represents Microsoft’s “Internationalization” Model.   

Microsoft's Internationalization Model

The main thing to be aware of, and where this model is at odds with the model used elsewhere in the industry, is in the terminology. In Microsoft’s model, the terms “Internationalization” and “Globalization” are substituted. “Internationalization” is seen as the overall, high-level process, and “Globalization” is a sub-process that deals with the development of a culture-independent/world-ready application. 

N.B. There is some inconsistency in terminology within Microsoft’s own documentation and content; “Globalization” and “Internationalization” are sometimes interchanged depending on the target audience, author, time of day, weather, etc.

The “Industry Standard” Globalization Model

On the other hand, the rest of the industry typically refers to “Globalization” when talking about the overall process, and “Internationalization” when describing the development of a culture-independent/world-ready application. See the more commonly accepted, “Industry standard” Globalization Model below (Fig. 2). 

The “Industry Standard” Globalization Model

The irony of this inconsistent terminology won’t be lost on anyone working in Localization. J

At first glance you may assume that Microsoft’s model (Fig.1) provides a more comprehensive description of the whole workflow, as there is more detail provided in the high-level model. This is not strictly the case. Whilst the more commonplace model used by the rest of the industry (Fig. 2) is typically only represented by three neat little Globalization, Internationalization, and Localization boxes, there will of course be more detail under each of these headings, but the level of detail/terminology will once again vary from organization to organization. For example, if we expand the model in Fig. 2 further, we would see something similar to the following workflow (Fig. 3) emerging:

Expanded "Globalization" Model

In Fig. 3, I have placed “Localizability” and “Customizability” under “Internationalization”. In my opinion, these are just a few of the more significant component parts of Internationalization. If we were to expand the I18n process still further, one would see the addition of other major I18n considerations such as Unicode. 

Resistance is (sometimes) Futile

There is no right or wrong model to adopt or champion within your organization. Essentially both models describe the same overall process. However, it is useful to be aware of both models, especially if you have the misfortune of having to delve into Microsoft Documentation relating to Internationalization or the Globalization Namespace. Similarly, when talking to people from the Microsoft/.Net universe, I’ve found it can be easier to simply give up trying to stick to the more widely accepted G11n model and speak in Microsoft terms. Otherwise it can be rather like trying to convince the Borg there is an alternative to assimilation (I ‘m already sorry for that reference!) and you may find yourself viewed with the same skepticism as zoologist who just suggested polar bears and penguins could peacefully coexist. J Apologies to my ex-Microsoft colleagues, but you know it’s true! J

In my next few posts (and as previously promised!), l will endeavor to work-around the (at times) conflicting terminology and take a look at the commonality in what these process models are seeking to describe under the headings of Globalization, Internationalization, and Localization.

Who’s responsible for Localization in your organization?

Who’s responsible for Localization in your organization?

Seems like a simple question with a simple answer, right? However, whether they are aware of it or not, most people use the term ”Localization” when they may well be referring to areas under the broader headings of Globalization, Internationalization, Localization & Translation (GILT).

There are historical reasons for this anomaly of course; once upon a time Localization was only considered an afterthought to product development and had no real place in the SDLC (Software Development Life Cycle). GILT is certainly a more accurate and all-encompassing acronym, but even as industry experts in “Localization” we do not typically embrace such broad terminology. Personally I find GILT a somewhat clumsy and uncomfortable acronym. After all, who in an organization would want to say they work in GILT, or are head of GILT! Even if we were to adopt this term within our organizations, I could foresee many blank stares when discussing GILT with those not familiar with what is traditionally known to them as “Localization”. So naturally we default to using “Localization” as an often all-encompassing term to avoid having to give every person we interact with a brief (and most probably unwelcome) history of what is better known as “Localization”.

The problem is, that by accepting our moniker as “Localization” we are also endorsing the view that Localization is still just an afterthought to development and is solely the responsibility of a single department within an organization. I still work as part of a Localization team, as Localization Engineering Manager. Some of you who work in the industry probably have a sign hanging over your little farm of desks that says, “Localization”.

In my experience, this tends to result in those in senior management, in charge of strategic decision making, and those in regional sales offices, believing that by having a Localization department; Localization is taken care of. It’s a black-box. It’s possibly even viewed as a glorified term for translation. Consequently, should any issues arise with Localized product, it’s clear to these groups where the responsibility lies.

So in response to the initial question I posed, who’s responsible for Localization in your organization? The truth is, in the broadest sense of the term, “Localization”, that everyone at every level of your organization is responsible for Localization (If we take it that by Localization we are in fact referring to GILT).

Just because a Quality or Quality Assurance department may exist within an organization, this does not mean that quality is the sole responsibility of this department and is no longer a concern for the rest of the organization. Similarly Localization, or more accurately Globalization, must be a discrete function of every individual within your organization. If not, there will be an inevitable adverse impact on Internationalization and subsequently the quality of the localized end-product will suffer, as will sales in the target region for that localized product.

Each step within the Globalization, Internationalization, Localization chain will have an exponential impact on the next. If you don’t take your Globalization strategy seriously enough, then, in the absence of a firm mandate from the highest levels of your organization, Internationalization will suffer because there will be no development impetus to properly Internationalize your software. If the Internationalization effort is poor, Localization will be painful, perhaps even impossible within certain software features, and you will be looking at a lengthy delta between your domestic software release and your localized releases.

Conversely, if you start with a solid and coherent Globalization strategy that is communicated, in a relevant and contextual manner, to all levels within the organization, then Internationalization will be an integral part of the SDLC, Localization should be a straightforward, finite task, and you will be in a better position to achieve a Sim-Ship of domestic and localized software releases.

Some people may prefer to use the acronym GILT, some may prefer “glocalization”. For me, the answer to this conundrum, and to addressing people’s sometimes limited awareness of what Localization entails, does not lie in changing terms or the invention of new terms and pseudo-techno-babble. It’s too late. The horse has bolted on that one. It would be comparable to Apple insisting that people stop using “iPod” as a brand name and adopt another title for their pre-existing portable media players. Instead, I believe the answer lies in educating all the relevant stakeholders within an organization on the importance of G11n, I18n, and L10n and how these relate to them and various groups throughout the organization in terms of responsibilities.

So with this in mind, in upcoming posts I will take a look at the terms Globalization, Internationalization and Localization in more detail, their inter-dependent relationship, who owns what in terms of responsibilities, what they mean to your organization, and what you should know when endeavouring to sell software in a global marketplace.