If you are one of these organizations, please know that you are not alone. However, finding out how much your company spends can be extremely difficult, depending largely on how localization is currently managed. Most organizations who struggle with this question run localization in a highly de-centralized manner. Each region or business unit is responsible for managing the cost of their translation needs, and there is little documented process or symmetry in how each performs the task. This blog will focus on these types of organizations, since a majority of them are the ones struggling to find out their annual spend. For example, one region may send work out to a localization vendor that is contracted, while another may request translation ad-hoc when the need arises. Still further, some regions may have in-house staff perform translation as part of their normal duties, so not to incur any cost for their translation needs. If this sounds like your company, then here are three things you can do to go about collecting an idea of the “spend” your organization does as a whole.

First, ask the regions/divisions/business units how they are currently handling translation. Find the main translation stakeholder in each and ask them for their process. Specifically, ask them:

• How do they bill for localization?
• Do they have written processes?
• Do they maintain existing contracts with translation vendors?
• Do they use a specific code on POs for translation?
• Do they use existing staff for translation, or are their specific FTEs designated?
• Do they maintain any assets?

What these questions will help you discover is how each group operates, and where to start looking for the money they spend on translation. In some cases, you might find a relatively well-managed process and determining the specific spend will be much easier. In others, especially where there are no processes, or dedicated FTE count the “spend” will be much more difficult to determine.

Second, look at the products that are from each group, and in what markets they are currently engaged with. Ask these questions:
• Do you translate written material for each market your products are in?
• What written material do you put in to each market? Do you have a document/page count of what each group in your division creates and sends to the markets you currently engage?
• If you are not translating content currently, do you have plans to start in the next FY, and if so, for what markets and which content.

What these questions will help you determine is where the translation is coming from for each group. This is helpful when a group has no documented process and/or uses existing FTEs for their translation services. Additionally, it gives you an idea of what content is going out the door to end-users in a localized format.

Finally, you can just do the math. While each company’s localization “spend” will vary significantly there are constants in localization that can be used to determine a rough idea of localization “spend,” such as:
• Typical translators can translate 1500-2000 words per day, not including leverage
• Quality Review is normal accomplished at a rate of 10,000 words per day
• Desktop Publishing is normal performed at 5-6 pages per hour
• Web content normally has 200-250 words per page
• User documents average 250 words per page

If you have done your due diligence in the first two steps, you have an idea of what documents were translated in which groups. Knowing this will let you find the amount of pages and the number of languages for each. For groups that use existing FTE count to translate content on the side, the first two metrics will give you and idea of how much time is truly spent translating content. Now you have a better idea of what your company translates, ask the localization vendors for the average cost to localize each language on a per word basis. Put the numbers together and you have a rough estimate to deliver to the executives. While this process is not the most efficient, it is effective in providing numbers and equally effective in showing the executive team members exactly how inefficient the localization process really is at your company.

The problems for these organizations are localizing content for the target audience and the intention of the survey or research getting “lost in translation.” This is because the nuances of translation are far-ranging. A literal word in one language, for example, may have no equivalent in another language, or could have a completely different “meaning” or effect in the translated language. This is why translation is an part-art not all science. No literal translation can be expected to convey perfectly the “meaning” of what consumers meant to convey in their own language. All the good work of a focus group moderator in not “interpreting” verbatim comments can be wiped out by a careless translator.

Back translation is instituted by organizations to improve the reliability and validity of research in different languages by requiring that the quality of a translation is verified by an independent translator translating back into the original language. Original and back translated documents can then be compared. If there are discrepancies, then the translated content has to be re-reviewed and necessary changes are put in to the document.

Due to its high cost, back translation is not overly common, but in organizations where there is a high risk-high reward component to target market success it is considered another “cost of doing business.”

The question is, “Is there a more efficient way of managing these risks than have back translation performed?” To answer the question, we need to understand the main driving point of the back translation, which is to ensure the quality of the initial translation.

Are their alternatives to back translation?

Translation quality can be impacted by a number of factors.

First, the content you are creating has to be managed properly. Authoring is essential. Especially in fields where there is heavy regulatory compliance, such as the pharmaceutical or biotech industries where the penalties for failure can be far greater than monetary costs.

For heavily regulated industries the assumption is that all source content created has enough rules around it from the compliance requirements, so additional scrutiny is unnecessary. That is far from true. An overall translation and localization management strategy has to take every part of the supply chain in to consideration and incorporate active practices for managing each of them. Source content creation (Authoring) is the first step in localization, and mistakes here can exponentially drive up costs as the process continues.

The second factor is asset management. Global organizations have long used Translation Memories to store previously translated content for re-use. However, it is more than just having assets behind your translation. It is about managing your assets intelligently and incorporating their care and upkeep as part of your overall strategy.

For TMs, that means more than just using them. An organization should invest time in a TM strategy that includes the maintenance, collection and “scrubbing” of all language assets on a regular basis. Whether you use “in-house” translators, freelancers or language service companies, you must have a strategy.

However, just as important as TMs are style and terminology guides for the target languages. Earlier in the blog, I mentioned there are times when a literal word in one language does not have an equivalent in the target language. Even worse, literal translation of a word or product name has negative connotations in the target language. A perfect example was the Chevy “Nova” when it was sold in Spanish markets.

Style guides and terminology have to be part of a asset management strategy to works in conjunction with you production (translators) strategy.

A third factor is the training and skills of the initial translator. The translator needs to not only speak English and the target language fluently, but implicitly understand the target market. The best way to ensure this is by having in-country, native speakers handle the initial translation of the content. No argument can be made that a person residing anywhere but in the target market can localize properly.

Finally, having a quality control process that ensure each of these three items is fully checked will further ensure the quality, accuracy and consistency of localized content.

Incorporating all four of these into a single over-arching strategy for approaching local markets will provide better, more cost-effective results than hiring “independent” translators to back translate content for review. When hiring an independent translator to back translate your content, at a minimum you have doubled the time and cost of your translation. The actual translation or content is the most expensive part of the localization process by far. It is also the most time-consuming part. Putting in a corporate strategy, opposed to using back translation will drive efficiencies in reducing cost, improving quality and speeding up time-to-market. More importantly though, it will guarantee that those surveyed in the local market are having the information provided to them with all appropriate local nuance, thus driving up their comprehension and minimizing their risks.

Conclusion

Back translation was created in the absence of a full localization strategy. Many compliance organizations, such as ISPOR (International Society for Pharmacoeconomics and Outcomes Research) instituted back translations as a requirement in the mid-to-late 1990’s. Here we are almost 15 years later and it has not changed. However, the localization industry has grown exponentially more advanced and in both technology and the understanding of local market nuances.

Of course, for a generalist to work better the translation management process should include at least a reference glossary, a specialist reviewer and a minimum review process to make sure that the final translation is completely accurate in terms of subject matter.

The problem is that many translation agencies or companies do not consider investing in reviewing a translation worth it, since they usually base their competitiveness only on the quick turnaround/deadlines and profitability/prices.

I couldn’t agree more with Ivete here. Translation companies have to take responsibility not just for the project management of localization but for ensuring that translators have everything they need to perform their tasks.

Most of my work with is with global companies who routinely translate our to 10, 25, 50 or more languages. The problems Ivete highlights are exacerbated in global-scale localization where the same terms are to be translated by so many translator teams spread around the world. For this type of localization the translation company should be providing complete documentation on all the terms and concepts for each of the translators involved along with all the other supporting materials. If they don’t, the likely result is inconsistency between languages since each translator will need to perform their own research and come to their own conclusions.

Obviously there are software products that can help – SDL’s MultiTerm is a good example but for anyone who is in the process of assessing vendors – especially if the candidate pool includes some of the smaller players – I always recommend questioning the capabilities for central research and distribution.

I will certainly be looking out for Ivete’s next Sacred Cows entry!

How to define the total cost of ownership for localization?

I define Total Cost of Ownership, or TCO, as the complete cost of translation based on the current strategy weighted by ratio’s quantifying overall quality and time-to-market targets. This can be expressed in a formula as shown below.

TCO=(c×qr×tr)

Total cost (c) multiplied by quality ratio (qr) multiplied by time-to-market ratio (tr). Once you know the total ownership you can begin to understand the efficiency (E) of your translation environment, and make decisions on how to make improvements. To caluclate this simply divide TCO by the total number of translated words (w):

E=TCO÷w           or           E=(c×qr×tr)÷w

We know how to calculate TCO and the efficiency of the environment, however with localization, to quote that old saw, the “devil is in the detail”; each of the component variables needs to be carefully and consistently calculated. This is not an easy task of we are to get an accurate answer for either TCO or E.

Calculating Total Cost (c)

c (cost) is the total cost of the strategy including internal, external (vendor), technology and overhead. This can be tricky since most organizations don’t track these items under an umbrella category (or even track them at all). Sometimes it can be easier to use cv (external spend to vendors) but this will provide misleading assumptions.

Calculating the quality ratio (qr)

qr (a single number representing quality for the time period being measured) you need to have a formal measurement of quality. There are a number of ways to measure quality however I favor a simple count of agreed “bugs” with severity weighting, measured against agreed quarterly target bands. This is shown in the chart where we can easily see that qr for the third quarter would be measured at 5 points since quality was rated “poor”. The heavy lifting here is in agreeing how to quantify, agree and weight each individual “bug” taking a pragmatic view of the preferential nature of translation without losing track of accuracy. There are a number of standards available that can be used or modified including SAE J2450 and a proprietary standards such as the one available from LISA but the amount of effort and the need for pragmatism here shouldn’t be underestimated.

Calculating the time ratio (tr)

tr (a single number representing time-to-market – the time taken from deciding to translate until the content is authorized for delivery) you simply need to choose when to start the count for any given translation job, when to end it and whether to count weekends! Weighting is very important since being one day late on a three month project is very different from being one day late on a security patch that has a 24 hour deadline. Calculating the number of words w (words) is a count of the net number of words translated including 100% matches and machine translation output. If you are using automated environments such as a Translation Management System or have a well-structured vendor strategy this should be fairly easy – otherwise quantifying the total number of words will take a great deal of effort.

Why go to all this effort?

Typically time, cost and quality are the three Key Performance Indicators that are measured in localization, however to be useful outside of simple benchmarking those KPI’s can be used to model and measure strategic and tactical changes to the environment. Our research and experience show that measured steps to reduce TCO and increase overall efficiency have a significant benefit over and above a simple-minded focus on driving costs down.

What is “Agile”?

Originally designed as a philosophy for software development Agile is moving beyond software and is becoming a useful method for managing any cross-functional teams. Long considered a small scale approach, Agile Development is gaining ground as a flexible methodology, scalable to even the largest of projects.

Agile evolved as a reaction to heavyweight software development methodologies – especially “waterfall” methodologies. Agile is not a formal standard but an evolving interpretation of the Values and the more fluid Principles.

Although there are many facets to an Agile project, three concepts illustrate the difference between Agile and other methods; adaptability, iterations and collaboration

Adaptability
Agile teams understand that business requirements change. The Agile methodology is adaptive rather than predictive and is based on that fundamental understanding and Agile development teams must be capable of thriving in that environment.

Iterations
Agile development cycles (iterations) tend to be short (weeks rather than months or years) and focus on delivering working software within that time frame taking into account each stage of the software development cycle within that time frame.

Collaboration
Agile teams are cross-functional and self-organizing, typically operating outside formal corporate hierarchies. This allows the team to decide for themselves how to operate most effectively during a development iteration. Additionally, teams include both technical and business members who work closely together to ensure each iteration delivers working software that meets the business need (for that iteration). To make all this work, there is a huge emphasis is on close-working and constant interaction.

Why does this pose a problem for localization? What can we do about it?

Although many translators and translation companies work successfully with Agile clients that isn’t the same as being integrated with Agile philosophies.

Collaboration between team members is a key element of Agile typically with teams located in close physical proximity. Since localization production is outsourced to teams that are global in nature care must be taken to foster close collaboration opportunities between the Agile development team, the localization project management team and the dispersed translation production team. To be Agile a a centralized “core” of leads have to work in close proximity. The disciplines of Project Management, Localization Engineering, Linguistic Analysis, Testing and Digital/Desktop Publishing as well as QA /QC management have to be managed in a collaborative team fashion. Beyond this core-knowledge team, care must be taken to work on a daily basis with the distributed translation teams in country using whatever means are necessary.
Ideally the core team is co-located with the Agile development team itself, however most Agile development projects are not large enough to host a permanent core-team presence so compromises have to be made somewhere.

The iterative nature of Agile also brings problems. Traditionally localization has been project centric and largely monolithic especially in the larger localization companies. To support Agile the localization team has to become accustomed to short timescales, small drops and relatively small changes within large code bases. In addition to the changes in working practices to support small iterations the localization team has to be able to leverage technology beyond simple application of TMs to discern what has changed and what needs to be localized. Overall the implications for translation are that the translation team must be able to execute smaller incremental changes in strings, prompts and content which have to be completed within the time allowed for successful release of the iteration. Especially significant are the implications for testing – functional testing needs to operate seamlessly within the iteration requiring very close co-working between the test team and development team.

and finally…

Agile has a great philosophy behind it but the way Agile teams work don’t mesh directly with the way localization works. It takes some care and attention – but mostly flexibility – on the part of the localization team but with some creative thinking we all learn how to support Agile customers better and more in line with their development philosophy.

Any posts from those of you experienced in localizing in an Agile world would be most appreciated.