• 译者：颜玉祚（北京大学计算机辅助翻译专业）
• 源文链接：http://www.gala-global.org/GALAxy-article-how_can_we_better_educate_our_clients-6992.html

“我现在要去度假，我离开期间请你完成这个本地化项目，好么？” 这一幕你是否感到似曾相识？当你正要开始自己的假期前两分钟，你的一位重要客户开启了一个他称之为“该公司有史以来最重要的一次发布”的本地化项目——将一个软件套件本地化为14种语言。当你正要开始自己的假期前一分钟，你接到一个准备得极差的文件分发包，里面包括需要翻译的软件、文档、帮助系统、营销资料等等。更糟的是，你的客户联系人忘了指定一位暂时联系人——结果，你只好孤军奋战了。

本地化软件到一半的时候，你的团队告诉你上次本地化过程中报告给客户需要修改的大部分语言缺陷依旧存在。用户界面的第一页，软件和文档之间诸多的不一致性问题已经有一个跃入眼帘了。而这正是要写入帮助文档的文本！最后，当你开始本地化营销资料的时候，你发现客户方的营销人员和软件开发人员对新功能Acme PowerSoft'n'Easy的命名不同。这样的故事还在上演着……客户和多语言服务提供商（MLV）都为此颇感受挫。

当然，以上的情形有些许夸大，但不管怎样，它还是有值得认可的方面——即便在2007年。

在一次全球化和本地化协会（The Globalization and Localization Association，缩写为GALA ）成员会议上，我们简单地讨论了关于如何更好地教育本地化客户的问题。但是我们需要教育客户“什么”呢？我们不是已经开发了各种各样的翻译记忆工具、术语管理工具、理想的工作流系统、风格指南、流程等等来帮助我们的客户以及我们自己的公司更有序、及时地完成本地化工作吗？此外，为了在市场中看起来更具吸引力，我们不是已经提供了非常、非常优惠的折价了吗？

答案是：是呀，是呀，是呀。

事实上无论我们开发和使用的工具多么先进，无论我们的价格多么低廉，到最后，我们仍旧要面对的常常是同样的问题。

本地化大多位于产品开发和发布阶段的最后阶段，遗憾的是，这常常是瓶颈问题出现的时候。产品开发的最大压力通常出现在包含测试和缺陷修复的验证阶段。传统上，由于多数的质量反馈和缺陷都是在这最后的阶段中提出的，本地化也被包含在这个阶段内。而这让客户和本地化公司都感到沮丧。

因此，作为多语言服务提供商（MLV）的我们或许可以在准备阶段提供更多帮助。

公司本地化策略

很多的多语言服务提供商（MLV）为客户提供项目管理工具、术语管理工具、以及本地化流程咨询服务。但首要的障碍还在于客户似乎不愿意投入必要的时间和精力以使事情运转顺利，而对本地化的规划工作也常常得不到重视。举个例子: 在TLT Ducumentaion AsP （作者所在的本地化公司），我们曾建议客户推行术语管理工具。一年半多过去了，他们的技术写作员仍旧没有开始使用它。

很多的公司只是把本地化看做一件不愿意做但又不得不做而且要越快完成越好的事情。有些客户把所有的责任都推给本地化公司，然后就往椅子上一靠，期待所有事情都会“自动”解决。然后，当多语言服务提供商（MLV）带着诸多语言错误、不一致性问题、空格和格式等问题来找他们时，他们又露出一脸的惊讶。

有一件可以教育本地化客户的事情，即：拥有我们说的“公司本地化策略”是很重要的。客户需要慢慢理解本地化需要遵循的原则和它的流程。提高本地化意识将促进客户准备需要本地化的产品的能力，从而减少常见的本地化过程中易犯的错误。同样，多语言服务提供商（MLV）可以在提供公司本地化策略问题上发挥比现在大得多的作用。

相关人员

多语言服务提供商（MLV）可以帮助客户理解为何本地化是软件行业这幅更大的图画中的一部分。他们在初始阶段（产品开发之前）做出的小小决定也许会对10个月后的本地化产生重大的影响。他们需要考虑IT产品的整个开发过程——从软件开发的需求说明到本地化。在客户方，这些开发过程包含很多拥有不同背景和个性的人员：软件开发工程师、系统架构师、项目经理、营销人员、技术写作员，等等。如果本地化是商业计划书中的一个核心目标，那么所有这些人都必须了解一个可靠的方法有多重要。

我的一家客户的高级技术写作员把他所在的公司比作抓住老虎的尾巴（一松手就可能被老虎吃掉）…… 由于规则混乱，导致完全失控，情况岌岌可危。这家公司是我们的客户，10年前就已经开始本地化它们的产品了。然而时至今日，协调他们的软件开发员和技术写作员仍旧很困难。我们必须教育我们的客户紧密合作的重要性——不仅仅是客户和多语言服务提供商之间，还有客户方所有相关人员之间的协作：技术写作员、项目经理、营销人员、软件开发员，等等。

敏捷本地化……

去年，在巴塞罗那举行本地化世界大会上，F-Secure公司的麦卡·培克嫩（Mika Pehkonen）展示了一个“敏捷本地化”模型。使用这个敏捷本地化系统，译员将成为软件开发过程的一份子。在母产品开发的每一天，本地化都在进行。术语库和翻译记忆库在晚上进行自动更新。

这样成本不会更高吗？是的，的确如此。但是根据麦卡·培克嫩自己的计算，传统本地化过程中每发现和修复一个语言缺陷要花费公司大约1000欧元的内部成本。因此，使用“敏捷本地化系统”实际上能够为他的公司节约最终成本。

我们可以从中学到什么呢？

报价过低的讽刺

这让我想到了一件极为讽刺的事实。客户过于关注价格本身，而没有去了解价格背后的原因。他们关注价格，因为他们知道利用这点可以拿到最低的价格，这对他们对自己有利——却造成多语言服务提供商之间相互竞价。这就是我们教会他们的。

但是为了节省0.005欧元每字的成本，得到的却是蹩脚的产品，从而导致本地化过程中大量的缺陷修复工作，总的内部成本随之狂飙，这对客户意味着什么？

成功的本地化开始于技术写作

IT产品开发过程涉及的众多人员中，我认为本地化产业必须首先关注技术写作员。他们拥有语言学知识，应该成为公司本地化策略的起点。作为语言工作者（而非技术人员），技术写作员能够成为多语言服务提供商的拥护者，从而帮助阐明很多可改进的领域。我提出这一观点是基于我自己作为一位技术写作员的工作背景以及我在本地化行业十年的经验。技术写作员和多语言服务提供商（MLV）处理的是同一件事情： 文字！

在努力使项目成功的过程中，技术写作员可以扮演一个中心角色，因为他/她：

• 可以实施语言标准
• 常常起到软件测试人员的作用
• 可以在不同的开发团队和营销团队之间起到语言协调员的作用
• 关注一致性
• 关注可用性
• 可以起到与多语言服务提供商（MLV）的联系人的作用
• 能够在潜在问题出现之前对其进行查找和处理，例如为译员编写解释性的注释或者其它的指导。

因此公司本地化策略需要技术写作员拥有定义清晰的责任范围——要么是单独一人，要么是位于商务中心的管理者和决策者。最重要的是，为了在组织内部实施本地化策略，技术写作员需要来自管理层的支持。

如果我们希望找到更好教育客户的方法，我们就不能忽视技术写作员。告诉你的客户这点！

关于作者

托马斯·德伯杰格，文学硕士，是TLT Documents ApS公司（位于丹麦Hvidovre市的一家本地化供应商）的合伙人和文档部经理。您可以通过这个地址联系他：thomas@tlt.dk 。

How Can We Better Educate Our Clients?

Halfway through localizing the software, your teams report that the client neglected to implement most of the linguistic bugs you reported during the last localization cycle. On page one of the user guide, the first of multiple inconsistencies between software and documentation emerges (and this is the text that will go into the help system, too). Finally, when you get started on localizing the marketing material you find that that the client's marketing people managed to name the new innovative Acme PowerSoft'n'Easy functionality something different from what the software developers named it. And so the story goes… Great frustration on both the client and the MLV side.

This situation is of course a bit exaggerated, but nevertheless it has some recognizable aspects – even in the year 2007.

At one of the past GALA member meetings, we briefly discussed the aspect of better educating clients. But what do we need to teach our clients? Haven't we developed all the fancy translation memory tools, the ideal workflow systems, the terminology management tools, the style guides, the processes, etc. that will help our clients and our own companies get the jobs done in good order and in good time? On top of that – haven't we offered our very, very discounted word rates for each update in order to make ourselves attractive to the market?

The answers are yes, yes and yes.

The fact is that no matter how advanced the tools we implement and use, no matter how much we lower prices, we still often end up facing the same problems.

Localization is most commonly situated in the final stage of the development and launch of a product, and sadly, this is often when bottleneck issues arise. The greatest stress on product development is usually on the validation phase when the testing and bug fixing occurs. Localization traditionally adds to this by creating most of the quality feedback and bugs during these late stages. This is frustrating for both clients and localization agencies.

So perhaps it is in the preparation stages that we as MLVs have something extra to offer.

A corporate strategy for localization

Many MLVs offer custom project management tools, tools for terminology management, and counseling on localization processes. But the prime obstacle still seems to be the client's unwillingness to invest the necessary time and effort to get things working, and thus planning for localization often receives a low priority. Let me give you an example: at TLT we recommended that a client implement a terminology management tool – over 1½ years ago – and yet the technical writers still have not started using it.

Many businesses simply view localization as a necessary evil that needs to get done as quickly as possible. Some clients cede all responsibility to the localization agencies and then lean back, expecting everything to be resolved automatically. Then they are surprised when the MLVs return with issues such as linguistic errors, inconsistencies, spacing and formatting issues, etc.

One thing clients could be taught is that it does matter to have what we might refer to as a corporate strategy for localization . Clients need to take the time to get to know the principles and processes of localization. A heightened awareness will improve the client's ability to prepare the product for localization and to avoid the usual pitfalls of localization. Likewise, MLVs could be the providers of corporate strategies for localization to a far greater extent than we are now.

The people involved

MLVs can help clients understand how localization is part of the bigger picture. Minor decisions they make in the initial stages – prior to developing the product – might have a major impact on localization ten months later. They need to consider the whole development process of an IT product –from the requirement specifications to software development to localization as a whole. On the client side, these development processes involve many people with different backgrounds and personalities: engineers, architects, project managers, marketing people, technical writers, etc. If localization is a core objective in a business plan, all of these people should know the importance of a solid approach.

At one of my clients, the key technical writer has compared his corporation with holding a tiger by its tail… anarchy rules. This client company has been localizing their product for 10 years, and yet still today, their software developers and technical writers find it very hard to coordinate. We need to teach our clients the necessity of working closely together – not just the client with the MLV, but cohesion among all players involved on the client side: technical writers, project managers, marketing people, software developers, etc.

Agile localization…

At the Localization World conference in Barcelona last year, F-Secure's Mika Pehkonen presented a model of agile localization . In agile localization, translators are part of the actual development of the software. Localization happens on a daily basis as the mother product is being developed. Term databases and translation memories are automatically updated during the night.

Is this more expensive? Yes it is, but Mika Pehkonen's own calculations showed him that each linguistic bug that was discovered during traditional localization cost his company about 1000 Euros in internal costs to fix. So the move to agile localization actually saves his company money in the end.

Could we learn from this?

The irony of underbidding

This brings me to an ironic fact. Clients focus more on word rates than knowing the reasoning behind the rates. They focus on word rates because they know they can use this to their own advantage to get the cheapest prices – make the MLVs compete on pricing. That's what we have taught them.

But what is it worth to a client to save 0.005 Euro per new word if the combined internal costs sky rocket due to an ill-prepared product that causes immense internal bug-fixing during localization?

Successful localization begins with the technical writer

Of all the people involved in developing an IT product, I believe our industry must address the technical writer. He/she has linguistic knowledge and should be the starting point for a corporate strategy for localization. As a linguist (not a technician) the technical writer can become an advocate for the MLV and help to elucidate a number of areas for improvement. I base this view on my own background as a technical writer and my ten years in the localization industry. The technical writer and the MLVs deal with the same thing: Words!

The technical writer can play a central role in making a project successful, because he/she:

• Can implement a linguistic standard
• Often functions as a software tester
• Can function as a linguistic mediator between the different development teams and marketing
• Has a focus on consistency
• Has a focus on usability
• Can function as the contact with the MLV
• Is able to locate and deal with potential problems before they arise, for instance by writing explanatory notes or other guidelines for the translators

So a corporate strategy for localization requires that the technical writer has a clearly defined sphere of responsibility – either as an individual or as an administrative decision-maker in a central unit of the business. Most importantly it requires that the technical writer has the backing of the management to implement the strategy across the organization.

If we want to find ways to better educate our clients, we cannot afford to ignore the technical writer. Go tell your clients this!

Thomas Deibjerg, M.A. is co-owner and documentation manager of TLT Documents ApS , a localization vendor based in Hvidovre, Denmark . He can be reached at thomas@tlt.dk .