北京
为什么一行按钮文字从开发完成到上线，要花上整整三四天？这笔账我算了很久，最后发现问题不在翻译本身，而在这条流水线上的每一个交接点。
每个月付给Transifex 150美元，说真的，这笔钱不是最要命的。真正让人心疼的是时间。一个翻译功能怎么上线的？先看看标准流程：开发者在网站上加一行新字符串——可能是个按钮、一条通知或者错误提示，英文的，提交到开发分支。这行字会自动出现在Transifex的后台面板上，标记成“待翻译”。接着业务部门里会说阿拉伯语的同事登录后台，把它翻译好。Transifex的机器人再抓取译文，通过GitHub的拉取请求把内容注回我们的代码仓库。到这一步，阿拉伯语版本才算真正交付。
数一数中间的交接次数：开发者、后台面板、业务同事、机器人、代码仓库。问题出在哪儿？产品同时支持英文和阿拉伯语，但工程团队只会说英文。团队里没一个人能自己写阿拉伯语，更别说校验了。所以每一条阿拉伯文字符串都得等团队之外的人来处理。如果一口气提交了一大串需要翻译的内容，那个人就得专门腾出整块时间来消化。实际体验下来，这个过程通常需要三四天。哪怕只是一个单词的按钮标签。并不是翻译一个单词有多难，而是这个单词得穿过一个付费软件、一个后台面板、一个人、一个机器人，最后才能落地。
说句公道话，Transifex本身是能跑通的。有人类把关这件事，质量确实不差。你总不想把没经过母语者确认的阿拉伯语直接推给真实用户。可问题是，我们每个月花150美元租了一条来回的路，就为了拿到一个我们完全能自己跑的检查点，代价是每次改动都要付出好几天的时间延迟。
那为什么一直没动手改？最直接的回答是：从前自己搭翻译管道的性价比太低了。放在AI还没兴起的时候，你想想得做什么——写代码解析XLF文件，搞清楚占位符的语法规则，处理好各种动态数值，最后你还得找个懂阿拉伯语的人来做翻译。那个最慢的环节根本没省掉，你只不过在它上面又堆了一堆需要维护的解析代码。对于一支只有四个人、只做英语和阿拉伯语两种语言的团队来说，这笔账怎么算都划不来。所以大家耸耸肩，继续付那150美元。
顺便交代一下XLF文件的事，后面还会提到。XLF是XLIFF的简称，就是一种翻译用的XML格式：一长串单元列表，每个单元把英文源文本和阿拉伯语目标文本配对。比如一个id叫“save_btn”的单元，源文本是Save，目标文本是حفظ。前端构建工具会自动从应用里生成源端内容，目标端则由人工填入，或者现在也可以用智能体来完成。结构干净、没什么花哨。在字符串还只是普通单词的时候，这套东西一直平稳运行着。
这门差事从来不算难题，而这点本身就是核心。做翻译的不是什么上百人的团队，也不是那种涉及三十种语言、有合规流程的大型本地化业务。就是英语和阿拉伯语两种。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
