如何构建本地化平台(第三部分)。
在深入探讨如何构建本地化平台系列的最后一部分之前，让我们快速浏览一下上一篇文章的要点，并向我们制作的奥斯卡装饰的新电影致敬:
在第一部分中，我的目标是描述创建“另一个本地化平台”所需的痛苦画面，以说服您遵守开放和可互操作的标准，并调整可用和合适的现代TMS和CMS系统。如果你有明确的成本效益分析来证明你需要一个完全定制的系统，并且你有资源来建立一个，你仍然应该考虑问一下迈克尔·基顿在《鸟人》中的角色——“你真的认为你明天就准备好开放了吗？”-他的回答是。
在第二部分，我们讨论了搭建平台和破解Enigma的区别:不要秘密处理，避免试错，确定明确的优先级，从每个人那里得到关于你的优缺点的支持设计。本尼迪克特·康伯巴奇在《模仿游戏》中有一句令人愉快的台词。他解雇了两名队员:“你们都被解雇了...你们是平庸的语言学家和活跃的密码破译者。”没错，来自供应商的贫穷平庸的语言学家是没有能力胜任处理软件开发的。然而，由于你的最终用户不是军情六处的代理人，而是翻译人员，让他们参与设计过程的早期阶段和整个开发过程是非常有价值的。
提供一个公共API。总是这篇文章只有一个信息:为你的平台提供一个公共API。然而，为你的工具和平台提供一个应用编程接口是非常重要的。希望能花时间通过我的亲身经历，逻辑论证，以及业内其他人的意见来支持一下。
当我在1999年开始本地化时，Trados Tran语言学家翻译。公司工作台是事实上的标准翻译记忆工具。如果有本土化的奥斯卡典礼，会在所有类别提名，在大部分类别通过金像。
这是否意味着Trados是完美的？当然不是。它缺乏能够提高生产率的小事情，比如能够回到上一部分并做出修正。它没有更强大的功能来直接提高质量，例如将同一单元中的更改分散到一个文件中，更不用说跨项目中的多个文件了。它不允许您强制执行条款列表。但是有可能让它近乎完美。
释放你的全部潜力因为Trados有一个公共可访问的API，所以我可以编程并发布修改来实现上面列出的所有功能。但是API中的函数比这个更强大。通过开放您的API，您可以为人们提供开启完全范式转变的钥匙，这只是受到他们的想象力和以新方式使用您的功能的意愿的限制。
根据我使用Trados的经验，我可以在一个单用户版本的Trados中，使用API实现跨翻译团队的所有新译片段的实时交换和更新。我怀疑这是厂商有意使用免费版，但这个故事的重点是:你将无法预见别人用你的工具能做的一切，这在我们的背景下是非常好的事情。
这让我想起了包含API的逻辑论点。人们希望你的工具有它没有的功能，它做它做不了的事情，集成到自己的工具和系统中。我说过，是API让别人的可扩展性成为可能。
不要一个人。唯一的选择是，作为工具开发人员，您自己编写所有请求的函数。但是你没有时间和预算去做这一切，所以你必须对大多数请求说“不”，因为你需要你的开发时间去修复bug，实现你的核心产品中的关键问题，而不是可能很棒的服务。通过发布你的API，你实际上是众包开发。
没有一个文档化的开放接口，你就无法实现一些目标，比如将你的平台与厂商工具集成。在上一篇文章中，我提到了在设计阶段划分上游和下游的挑战。在你的平台上会发生什么过程，在平台之外会发生什么步骤？你提供编辑吗？验证者？术语？回收？机器翻译？工作流管理和分发？这些都是艰难的决定。
通过包含API，你可以让供应商画出最适合他们的生产线，这将给你带来最高的效率，质量的提高，周转时间的缩短。
通过模块化设计，你甚至可以混搭最好的作品。也许你的供应商有更好的机器翻译引擎。也许你有一个优秀的翻译编辑，但是他们有更好的语法和风格规则验证器。也许他们擅长微调你的MT引擎或者其他你内部不想做的事情。通过将基于互操作标准的组件构建到系统中，您将能够最大限度地发挥这些优势。
一段美好友谊的开始谈到本地化平台的价值和发展，Sergio Pelino在2014年温哥华LocWorld大会上分享了谷歌开发自己平台的经验。“你的每个供应商都想做一些不同的事情，”他说。“对我们来说，解决方案是创建一个API，以便我们的供应商可以自由构建他们需要的东西。”因此，整体大于其部分之和。
克莱门斯瓦尔德。r和Achim Ruopp(TAUS)比较了流行的网络服务Twitter的API的简单性和它用相对小的指令集实现的强大功能。“Web API提供了简化与翻译资源和服务的交互的能力，”他们在《TAUS翻译API用户指南》中写道，“还允许将复杂的任务分解为几个小而简单的请求。”
所以，不管做什么，都不要忘了提供API，邀请供应商帮忙。他们会很高兴你做到了，他们甚至似乎有了如何(不)建立自己平台的所有答案。这让我想起了奥斯卡电影的结局:“我真的想确定。”没有什么是不确定的。"
