本地化，2009 年 10 月 26 日至今，已经和我一起四年半时间了，这些日子从坎坷到平坦再到坎坷，作为一段历程，我想我也有资格说两句，仅发自内心地想说说。
我的本地化生涯伊始，跟着第一任组长 Michael Zhang 从零开始，慢慢接触了这个原本陌生的环境，一段时间后，基本了解了这个行业，或者说我自己，处在当前的位置渐渐清楚了需要做的东西，明白了一个本地化工程师的职责。起初的本地化只局限于 Trados，后来到了 World Server，等到 Michael 离职后，又有了 SDLX，按理说应该是有越来越充实的感觉，但随时间这么过，不但没有充实感，倒是更多了一份压抑和委身的感觉，觉得就像是在一个魔爪中。其实 Trados 被 SDL 收购前，它的开放文档格式 .ttx 已经很符合本地化的需求，并且针对这个格式开发出来的工具已经很能符合翻译需求，或者这是一个良好的利于翻译过程的格式，这种基于 XML 的格式无论任何方面都能被轻松接受，尤其是后来我加入到针对 .ttx 格式开发自动化脚本的过程后，我已然能体会到这种格式的优越性。但随着收购的完成，SDL 将 Trados 并入到一个集成翻译环境中，这就意味着这种开放的格式慢慢地被遗弃了，即便后来又有了高版本的 .sdlxliff 开放格式，我的感觉也只认为这只是一次不疼不痒的升级，纯粹是为了升级和垄断，号称免费的 SDK 也只能被注册用户拿到，这是翻译界的事，为什么要我注册？罢了，我还就不做有关 SDL 的自动化了。
现在，对于工具当然还是 SDL 的稍有优势，不过分，只是稍有，随着这款工具的不断升级，授权费用也越来越高，对于企业来说尚且需要衡量购买，更别说翻译了，在版权越来越被尊重的今天，盗版软件的使用越来越被行业所不齿，并且日常的本地化生产过程也因此严重受限。这种情况下，大部分本地化企业都在着手自己的本地化翻译流程化平台，基本都是基于开源翻译软件，如 OmegaT，在此基础上对功能进行扩展和完善。这样做的的坏处就是对于本地化这个行业来说，工具碎片化严重，难于制定行业规范，好处是避免了某些企业的垄断，防止一家独大，用竞争为行业发展提供了氛围。依我个人的观点，我定然不会倾向于 SDL，现在是一个多元化的时代，尤其在技术领域更是如此，最基本的操作系统平台就能体现出来，需要承认并且毫无争议的是，翻译的工程一定是在图形用户界面下进行而绝非命令行，在这一点上 Windows 平台具有得天独厚的优势，但是随着 Apple 的东西越来越受欢迎，已经近年来桌面 Linux 的更多普及（主要因为成本原因），几乎所有的平台都具备了做本地化翻译的条件，尤其前几天看到 Linux Deepin 的本地化翻译共享平台，觉得和 Ubuntu 所用的 LaunchPad 很相似，这也说明了本地化的一个最行之有效的途径，就是：谁要做本地化，谁来主导整个流程。
现在的本地化企业号言拼技术，客户说我要翻译什么什么文件，你们能不能做，然后各个本地化公司就开始从技术层面上去迎合，当然，依现在的技术发展没有什么是做不了的，之后就是各个本地化公司拼报价了，谁低谁来，说到底还是谁的技术更“先进”，看上去一切很正常，很符合市场经济，很良性，但我认为这就是问题所在。客户来了文件，我最带抵触的就是 PDF 格式，想必大家都知道 PDF 只是一种很随性的输出（打印）格式，从根本上这种文件需要由对应的源文件来生成，所以可以说我们对这个 PDF 做本地化就是对源文件（也是必须）做本地化：一来因为 PDF 文件从根本上不能视作有序的规格文件，是可以和图片等归到一类的可视化文件而已，即便把它转成 PostScript 格式，也能清楚的看出它的内部结构是多么不可理喻，甚至不如 Photoshop 的 PSD 文件；二来对这类文件做的本地化毫无意义，对于企业本身毫无可留存性，只是临时抱佛脚的应付态度，这样的本地化不如不做，何况对源文件的本地化会为甲方节省很多成本，所有的输出格式做起来都不是那么简单，往往是费力不讨好，并且认为是对本地化这项工作的一个歪曲、逆流。
除了上面所说的情况，现在本地化公司遇到的另一个难点是软件（更精确说叫“应用程序”）的本地化。我认为这方面遇到的问题和长久以来软件开发过程中养成的陋习有关，软件工程中最重要的一步叫“需求分析”，产品开发初期需要对产品未来的定位有清楚的认识，既然说本地化，那就只关心本地化。产品是不是需要推向国际市场，这就意味着是不是要为软件保留 i18n (Internationalization 的简称) 和 l10n (Localization) 的特性，也就相当于要不要为软件留下这个可扩展接口以便日后多语言化，其实对于本地化特性，软件开发本身已有这个概念，如利用 .resx 文件来存储多语言信息，这些特性当然是体现在软件设计阶段，这样的话对于本地化来说只是面向了这些多语言信息文件而可以暂且忽略其它，在本地化后只需要进行测试和 UI（用户界面）的调整。但是如果在软件设计阶段没有考虑到本地化事宜，那么到了后面就要想别的办法了，这就不得不说类似于 Passolo、RC WinTrans 这些号称”强大“的工具了。万一不幸用到了这些工具，那就说明这已经是个失败的工程了，这些工具固然处理能力强，但已是有了死马当活马医的感觉，一个完整的本地化流程中永远不需要出现这样的步骤。站在本地化的角度，文件类型只有两种，文本文件和非文本文件，其它的都是浮云。我们最终要处理的只需是文本格式，其它的所有都需要想方设法转化到文本层面，因为这是面向自然语言最正确和稳妥的方式，也是计算机辅助翻译的根本（说深了就是 0 和 1 的各种序列，跑远了......），所以这些软件的产生和使用更把流程化带入了歧途。
无论怎么说工具已然发展到这个程度，给人们提供了更多的选择，重要的还是人对流程的控制，说到这儿，瞬间觉得这么多年的技术白学了，因为相当一部分关键的东西不是技术来决定的，而是怎样分配技术资源。
目前的状况很明白，虽然市场很混乱，一套流程下来是以客户为目标的辐射，离客户越远那么客户对整个流程的控制力就越弱。或者你们觉得挺扯的，需要本地化的文件交付到服务提供商手里，那客户应该就不用管什么了，这样职责也显得很分明，客户负责原始文件提供，服务提供商负责文件本地化，但是这也太不负责任了。从目标上来说，我们面向的是文件，文件谁最有发言权？客户，当然是客户最熟悉自己的文件，本地化服务提供商的任务即从文件由客户交给提供商开始，在保证所有语言之外的东西保持原有的前提下对文件进行处理和还原，也就是说最终客户购买的就是翻译，这和本地化的任务正好吻合，既然如此，那么其中文件处理这些中间过程实际上是不该由客户买单的，实际上也本该如此。
这样的话，那么这个行业的发展就要遵循这样的方针：１、本地化的范围需要包括应用或文档的创建，处理，翻译，多语言版本生成，也就是说从产品设计开始就要考虑是不是要本地化，而不是有了产品再想要不要，这个和产品的大小和潜力无关，只是“要”或者“不要”的问题。这个过程是要客户控制的，因为产品是客户的，他们最有决定权，一切由于产品设计不适合本地化造成的后果属于产品漏洞，应由客户本身承担；２、对于过程中收到的客户方面不合理的文件，本地化服务提供者有权力拒绝这些不利于产品本身后期发展和维护的因素，并且可以把向客户阐述和提醒可能造成的后果并为止建议作为一项义务。这不是苛刻，而是真正本着对客户负责的态度；３、本地化公司就是拥有技术底蕴的翻译公司，最终面向的还是翻译，而为了保证翻译过程顺利进行的文件处理步骤需要尽可能减少（包括项目管理时间）。要做到这一点需要做的是提高翻译的某领域专业知识，还有第１点所说的保证文件对于翻译过程的适用性，另外连接这两者有一个最重要的东西------计算机辅助翻译（CAT）工具，依我看来，CAT 工具的发展可以到此为止了，已有的工具无论在功能还是适用性上都已完全胜任，纵观所有的失败项目，都是由于客户文件本身的不合理以及翻译质量差劲引起的，另外提醒一下，CAT 工具的过度发展带来人们对它门的盲目信任和乐观也是一个重要因素。
我来做本地化不是为了混饭吃，对于所有从业者来说它都是生命里不可避免的一段经历，甚至占据着你这段青春最多的时间，尤其是每天昼夜铺在上面的项目经理们。或者这些话不会有什么大的作用，但在我的脑子里这些问题可能带来行业的逆生长，不是越做越好，而是失之千里，每个本地化从业者也有自己的权力，我们需要像尊重自己一样尊重这段青春。“客户至上”，这种和最终服务质量没半毛关系的宗旨，也不知道是谁给服务行业贴上的卑贱标签。
我想我还会有话要说，暂且就这么多了。向依旧在岗位上忍气吞声的 Production 们致敬，向没日没夜苦苦熬着的 Project Manager 们致敬。
评论