在发这篇文章之前，我也想了多少次该不该把“本地化”加到这个编程爱好者的地盘上来，而决定把它加进来之后，又想是不是应该为它单独建一个分类，结果我都这么做了。在我进入这个行业之前，真是一无所知，进门之后发现原来也是高利润产业，并且和 IT 息息相关，虽然不是短时间内认识到，但是依旧是认识到了，我想把我对这个行业的看法说说，有同行尽可能指正一下不妥之处，毕竟我的理解不代表大众。
本地化是运用各种计算机软件技术把各类可用于交流的文件格式多国语言化的一个行业：那不就是翻译吗？自从干上这个，我从未这样想过，因为身在其中，我的的确确知道我不是做翻译的，但是翻译是最重要的一个环节。本地化的最终目的就是把一种语言格式的文件翻译成其它一种或多种语言文件以使更多的人能够用自己精通的语言来学习和认知，其中最重要的就是翻译，这是本地化最核心的部分，翻译的质量决定着整个任务的成败，但是大多数情况下“翻译人员”并不是某一方面的专家，他们只懂语言而不懂要翻译的文件的背景和特殊之处，最要命的就是他们在大量的翻译任务面前需要并且只能使用快捷的计算机辅助翻译工具（CAT），而辅助工具并不能直接或者根本就不支持原始要翻译的文档的文档格式，所以在送给翻译之前，这些原始文档就需要通过某种手段转换为计算机辅助翻译工具所能处理的格式，而这些大量的多种多样的原始格式和单一的受限被支持文档格式之间就需要我们想办法转换一下，翻译前把原始文件转换为翻译工具支持的格式，翻译后再转换回原始的文件格式，正是由于原始文档的格式太多，几乎包括了所有包含可阅读信息的文件格式，所以需要有些人专注于文件格式转换方面的工作并保证转换的健康性和可靠性，而这些人就是“本地化工程师”。
通常所说的本地化工程师大多数情况下是指上面提到的这些专注于文件本身和之间联系的面向机器的人，还有一种是面向人文的，也就是“排版工程师”，他们的工作在社会上各个行业都应用广泛，类似于图文设计和版式调整。如果被翻译文档是最终供人们获取信息的，比如演示文稿、网页、广告页、宣传册、书籍，或者软件界面也算，那么我们就需要排版工程师对其进行版式调整，因为把一种语言在一个界面上变成另一种语言的时候，由于语言之间表达同样意义的文字的长短不同（比如一个中文标题要占一行，而翻译成英语后可能在固定宽度内一行就放不下所有的文字），就需要对版式进行调整或者重新规划，而最终调整成什么样子，或者中间怎样调，这些都没有标准，因人而异，而且客户最终关注的也不是你是怎么做的，只要最终结果是令人满意的，让人看上去很合理、很舒服就行了，所以就是在考验此人的审美能力。
一份业务需要一个良好的组织结构，需要什么人，需要怎样协作，不同的企业组织有不同的方式，一般来说他们都需要另外一类人来管理整个项目的运作---“项目经理”，当然了，这个项目经理和软件开发中的那个不是一个概念：一个偏向于人文语言，一个偏向于编程语言；一个负责项目中工程师和客户之间理解和需求的无隔阂沟通，一个负责项目中工程师之间的无隔阂沟通并把握整个项目的架构和走向；一个不太需要技术背景，一个必须是个技术强人。在此文章中我想说的不是沟通的问题，所以关于这个项目经理我不想多说了，只不过想告诉：翻译人员、本地化工程师、排版工程师和项目经理，从目前来看是组成本地化行业必不可少的元素，也是一般企业的结构体系（不排除一人多角色，如果有精力和能力）。
本地化项目类型我喜欢从机器和人的角度来分：机器，也就是说所要本地化（主要目的就是翻译，下文将按狭义地以翻译替代）的文件类型是供计算机程序读取和使用的，对于人的感官来说，文件没有任何用途，不能用来看，不能用来听，只有与计算机程序统一起来才有意义，比如 XML（可扩展标记语言，用于数据存储和交互）、程序设计语言源代码（如 C、C++、Python、Perl、Java、C#、Basic、JavaScript 等编程语言的源文件）、文本文件（以特定编码存储的一组数据）等，这些东西只是用来记录数据的，而这些数据日后的用途是供应用程序调用来完成其他功能，对于人来说毫无意义；而另外的一些文件类型，例如 HTML（网页）、演示文稿（如 Microsoft PowerPoint 和 LibreOffice Impress）、PDF 文件（Portable Document Format）、广告宣称页（可由 Adobe InDesign 和 Scribus 等软件完成）、图片（可由 Adobe Photoshop 和 GIMP 等软件完成）、书籍和帮助文档（可用 Adobe FrameMaker 或直接使用 DocBook 编写，Docbook 根本是 XML）及视频动画（用 Adobe Flash 或 Pitivi 等完成）等，这些东西日后用途是供人们来视、听、欣赏的，必须需要人为进行后期处理以符合大部分人的审美习惯，而这些任务不是计算机程序所能完成的，就如同机器人不能取代人一样，排版人员的工作集中在这类文件的后期处理上或者是前期创作上（实际前期创作人员和排版人员应该是有不同的，因为创作人员创作，需要“无中生有”，而排版人员只需要按给定的架子保证其它文件与原创格式和风格的高度一致），而前面提到的机器用文件本地化的任务就需要本地化工程师来介入了。
但是在本地化世界里，除了必须要人为来处理的那部分排版、调整之类的任务之外，其他的东西都是殊途同归的：那就是计算机软件。在我们所处的信息时代里，所有东西都需要借助计算机来完成，当然本地化也不例外，翻译需要使用辅助翻译软件，排版人员需要使用排版软件，项目经理需要项目管理软件，本地化工程师几乎需要掌握需要所有软件（包括操作系统），而他们之间需要使用通信软件（邮件系统或者是即时通信软件）来交流信息或交换文件，即便是只做本地化，软件？文件？这些要究其根本，明白趋势，这样才能深入领域之中。
上面所述的尽是实际，下面我也该对于本地化的发展说说自己的观点了。
本地化行业可以说是跟随计算机潮流比较紧的了，从技术角度，说得窄一点儿，它是面向文件格式的，其中最关键的技术就是实现来自客户的多样文件格式和翻译人员所用的辅助翻译软件的文件格式之间的无损转换，若是有一种文件格式能被大多数类型文件接受那不就能轻松实现转换了吗？这种格式需要满足这样的条件：跨平台（在任何计算机平台都体现无差别性），轻量级（尽可能少的存在附属信息，把大部分存储空间留给数据本身），可被人为编辑（人们能自由改变里面的内容而不需要懂得太多的专业计算机知识），到了这儿你们是不是都想到文本文件了？对了一半，因为还需要另外其它条件：结构化（有清晰的结构，无论是人还是机器都能够按照一定的规则对其进行处理），可编程（在一个程序搭起来的计算机世界里，总不能让程序处理不了吧），好吧，这就是 XML。
其实 XML对于本地化界来说已经不是很陌生的东西了，或者说是相当基础的，.tmx 和 .ttx 这两种本地化里（尤其是 .tmx，可以跨平台）最重要的格式都是 XML格式，所以我们在处理起来比较方便，便于扩展，Trados 本身对于它们之间的相互转化无疑也是基于 XML 操作的，这是最安全、最稳妥、兼容性最好的一种交互方式，并且 SDLX 进行它的固有格式 .itd 和 .ttx 转换的时侯当然也是通过 XML，虽然 .itd 是封闭格式，但是两者只要有一种是开放格式，那么一切都好办了，从现在的情况看来，SDL正在把翻译工具向它原有的 SDLX 上发展，也就是说在未来，在 Windows 平台做本地化如果企业不能有话语权的话，那么一切细节都将被蒙在黑夜里，一切都将要被 SDLX 牵着鼻子走：我们在遇见不可知的错误时将不能用文本编辑器直接打开文件去找问题，因而也就不能用正则表达式这个利器快速完成自己的预期任务，不能自由地把所需的内容抽取到自己熟悉的开放的格式里进行其它操作，并且我发现 SDLX 用来交互的格式也往往是封闭格式的，其中的 Excel 看上去可以转为 XML格式，但是 Excel 本身并不是跨平台的，如果是你想操作 Excel 文档，你会首先想到把它转为开放格式吗？不会，我们往往会并且应该直接用 Office 去处理它，那才能发挥这个格式的真正威力，当然了，这也是 SDLX 想垄断的野心吧。而现在，这一切都被“盗版”牵绊着。
自由软件之父 Stallman 说过，自由软件才能带来自由社会，但是现在我们没有，尤其是中国，盗版是合法的，难道不是吗？管理机构的不作为就是说这个东西是对的，就如同见了老人摔倒不扶是对的，公款吃喝是对的，城管欺压小贩收保护费是对的，我们的政府没有建立这个机制去监管，因为他们不敢像俄罗斯政府和白宫一样在某年某月之前把我们的政府软件全部正版化、全部换为开源软件，他们没有这个本事。现在，我在我的行业里已然是感觉颇受侵害，因为使用闭源或者是盗版软件引起的问题无法解决，无从查起，但是由于工作需要还必须要解决，我们需要为生计考虑不得已要拿别人施舍的狗粮，因为没有自由，大部分人都变得下贱了。言归正传，正是在这种情况下，我本人才急于通过自己的努力改变一些东西，所有的客户文件格式尽可能转成开放文档格式，对于开放的文档格式尽可能用开放的程序开发工具用程序实现批量化处理，难道我们不该这样吗？Python、XML、C#、正则表达式、Notepad++，并且对于 C# 我使用的开发工具都是 Visual C# 2008 Express Edition 这个功能稍弱但的的确确用之无愧的软件，谁能说我哪里不对吗？我说了这么多就是希望更多的人一起努力“自由”地本地化，在国际化这么普遍的世界本地化有相当的机遇，但是我不希望用一种很脏的手段来做这属于全人类的事业。
我们需要自由！自由！Freedom！حرية！vrijheid！liberté！Freiheit！ελευθερία！자유！свобода！เสรีภาพ！özgürlük！
评论