用英语写一次，自动翻译以触达更多读者

公开写作是学习一个主题的较好方法之一，而其影响力通常止步于一种语言的边界。你花一个晚上用英语写了一篇文章，而一个用韩语或日语思考的读者却永远也发现不了它。解决方法不是手动再写四篇文章，而是编写一个源文件，让一个管道来翻译和发布其余部分，这样你只需维护单个文件，而同样的想法就能触及更广泛的受众。这篇文章是关于该设置如何工作，它对你的写作有何要求，以及何时不值得费这个功夫。

为什么公开写作值得付出努力

第一个回报是给你的。要发表一篇解释，你必须一次性在脑海中完整地梳理清楚，并将其整理成序。当想法还只存在于你的笔记中时你一带而过的那些漏洞，在你试图写第三段的那一刻就会变得显而易见。教学这一行为会暴露你并未真正理解的部分。最终你会学习这个主题两次，一次是在私下里学得不好，另一次是在公开场合学得透彻。

第二个回报是给那些遇到你刚刚解决的那个确切问题的读者的。大多数技术搜索都是某个在晚上11点陷入困境的人，在寻找那个描述他们错误的页面。一篇关于你发布的真实修复的简短、诚实的帖子，对那个人来说比一篇精美的概述更有价值，因为它与他们问题的形式相匹配。

第三个回报是纠正。当你在公开场合写了错误的东西，懂行的人往往会告诉你。这既令人不适，又很有价值。私人笔记永远不会错，因为没人读它。一篇公开发表的笔记会受到那些与你没有相同盲区的人的压力测试。

所有这三种回报都受限于能读懂这些文字的人数。这个上限就是本文余下部分将要讨论的问题。

一份源稿，多方读者

这个想法很简单。你用一种语言（这里是英语）写作，并把这个文件当作你唯一拥有的东西。在你保存之后，剩下的一切都是机器的工作：解析 Markdown，将其翻译成你支持的其他语言，然后将每个译文作为独立的页面，以其各自的 URL 发布。你从不修改译文。当你想修正一个句子时，你在英文源文件中修改它，下一次运行时就会重新翻译和重新发布。

这个博客正是以这种方式运行的。一篇文章就是一个英文 Markdown 文件。在 push 时，一个引入步骤会将其翻译成韩语、日语、简体中文和繁体中文，然后将每个版本作为单独的页面提供。我写的一个文件，最终产出了五个语言的页面。这种倍增效应是显而易见的。如果你的英文文章能触达一定规模的读者，那么另外四个语言版本也各自能触达规模相当的读者，而额外花费的写作时间几乎为零。

这件事值得自动化而不是手动去做的原因是，手动翻译经不起修改。一旦你修正了英文版中的一个拼写错误，四个手动翻译的版本就会开始不同步。而要让一个动态文档的五个版本始终保持一致，是没人能坚持做下去的工作。一个从单一源头重新生成所有译文的流水线，从结构上就消除了这种偏差。真实来源只有一个，而译文是派生出来的产物，就像编译的输出一样。

写作时要利于机器翻译

自动翻译的质量取决于提供给它的句子。模型可以清晰地翻译简单、直接的句子，但会搞砸巧妙的句子。因此，为翻译流程而写作，意味着要采用一种本身就是优秀写作风格的方式。

规则是，要移除任何依赖于读者已经用英语思考的内容。习语、双关语、文化笑话和一长串的代词都很难翻译，因为模型必须猜测字面意思之外的含义。使用具体名词、重点前置的清晰句子则很容易翻译，因为需要猜测的内容更少。

习语问题的一个具体例子：

Before: We finally moved the needle on cold starts.
After:  We reduced cold start time.

“修改前”的那一行迫使模型在呈现含义之前先解码一个比喻，而四种译文可能会对比喻的含义产生分歧。“修改后”的那一行只有一种含义，每次都会被同样地翻译。你会失去一点个人风格，但同时在四种语言中获得了正确性。对于一篇技术文章来说，这是一笔划算的交易。

代码和技术术语需要特别注意。你希望产品名称、API 标识符和保留字能够保持原样，而不是被翻译成本地的近似词。一个好的翻译流程会保护围栏代码块和内联代码不被翻译，并维护一个应保持英文的小型术语表。如果你写下 goroutine 并期望它在每种语言中都保持为 goroutine，那么术语表就是强制执行这一规则的工具。没有它，一个“善意”的模型会很乐意地将关键字本地化，从而破坏其原意。

告知读者译文由机器翻译

机器翻译很好，但并不完美。如果假装它完美无缺，那么当读者第一次读到别扭的句子时，你就会失去他们的信任。诚实的做法是在页面上说明这一点。

每个翻译版本都应该带有一条简短而显眼的注释，说明它是自动翻译的，并附上返回原始英文版本的链接。这样做有两点好处。它设定了正确的预期，因此奇怪的措辞会被理解为已知的局限性，而不是草率马虎。而且，它为双语读者提供了一个“逃生通道”：当翻译的句子不清楚时，他们可以打开源文，查看你的本意。原文是权威，而你正在告诉读者权威的出处。

这种透明度也保护了你。如果译文在某个技术细节上出现细微错误，带有标记的原文就是你所言内容的记录。你并不是声称机器一字不差地代表你发言。你是在声明，英文内容是你的，而译文是尽最大努力搭建的通向原文的桥梁。

实现多语言的成本

这一切都不是免费的，坦诚的说法是需要付出代价的。

第一个成本是翻译质量控制。散文的翻译效果很好。对于包含大量代码、表格和精确术语的帖子，模型最有可能出现偏差：修改标题、本地化关键字或悄悄地删掉一行。你需要为此设置护栏，这意味着保护代码、维护术语表，并设立一个验证步骤，可以在发布前拒绝或回滚错误的翻译。构建和维护这套机制需要付出实实在在的努力。

第二个成本是多语言 SEO。一篇文章的五个语言版本意味着五个 URL，搜索引擎必须理解它们是不同语言的相同内容，而不是重复内容或内容贫乏的页面。这需要 hreflang 注释、正确的规范化处理，以及每种语言都有足够多的真实内容，从而使分类页面值得被索引。如果做错了，你最终可能会与自己竞争，或者导致所有版本都被降权。这种复杂性会随着语言数量的增加而增加，并且不会消失。

第三个成本是管道本身。你正在用静态文件的简单性换取一个能够解析、翻译、验证和发布的系统。必须有人来负责这个系统。当翻译任务在凌晨 2 点失败时，这也成了你博客的一部分。单一源的原则确实是一个真正的优势，但你为此付出的代价是，将源文件转换为页面的所有环节都带来了运维负担。

综上所述，这些成本意味着，只有当跨语言的覆盖范围对你来说确实有那么大的价值时，多语言设置才是值得的。

当一种语言就足够时

如果你的读者已经使用同一种语言，请跳过所有这些内容。如果你是为某个团队、本地社区或英语阅读能力良好的市场写作，那么再翻译成四种语言会增加成本，但几乎不会带来新读者。这个流程是额外的开销，其另一端并没有受众。

当你的文章时效性很短时，也请跳过翻译。版本说明、状态更新和时效性强的公告只会被阅读一次，然后就过时了。翻译的回报会随着一篇常青文章的生命周期而复利增长，这样的文章多年来会一直被搜索到。对于下周就无关紧要的内容，翻译几乎不会产生任何影响。

并且，要尽早跳过翻译。如果你只发布了三篇文章，并且仍在寻找自己的风格，那么还不要建立翻译流程。先用一种语言写作，直到你拥有了人们确实会阅读的作品集，然后在触达范围成为一个真实而非假设的限制时，再增加语言。行之有效的顺序是：第一，写作；第二，受众；第三，翻译。在拥有读者之前就构建这套机制，是在优化一个仍为零的数字。

粗略的测试方法是：将你对一篇文章生命周期内读者数量的最佳猜测，乘以其中无法阅读你源语言的读者人数。如果这个数字很大，并且你的文章能长期保持相关性，那么这个流程就是值得的。如果这个数字很小，那就用一种语言写作，把节省下来的精力投入到更多的写作中去。

值得保持的习惯

在工具的表象之下，真正重要的东西并未改变。你通过解释来学习一个主题，并通过发布解释来帮助他人，而不是将其保存在私人文件中。自动翻译并不能取代这个习惯。它只是拓宽了大门，让你原本打算用一种语言写的同一篇文章，可以悄然触达另外四种语言。

它所要求的准则——简明的句子、一次一个观点、具体的词语、明确的术语——正是能让与你使用相同语言的读者清晰理解文章的准则。无论如何，你本就应该那样写作。翻译流程只是提高了不这么做的代价，并在你这么做时，让更多的人受益。