本地 RSS 标题翻译高速方案（DEVONthink 版）

速度是阅读的决定性因素之一。Kindle 并不是电子阅读器的发明者，SONY 和马斯克都早已涉足，但 Kindle 赢在速度：借助内置无限流量的移动网络（Whispernet），你可以随时随地阅读世界上多数的出版物——这一神奇的功能如今已被取消——而不需要等回家时再连电脑导入资料。速度是 Kindle 点燃（kindle）的星星之火。

类似的，速度的量变也可以引发 RSS 阅读方式的质变。在阅读外文 RSS 时，翻译功能必不可少¹，尤其是标题翻译，相当于给你制作一份译文版的文献摘要清单，可大大缩短筛选文章的时间。相应的，人们提出了服务器翻译²和本地（本机）翻译³两类方案。但 RSS 本就是一种寄生物，苟在 RSS 之上再外接其他服务，就好像一根用几段管子拼接起来的排水管，随便哪个环节都有可能出错，因此我一直坚持本地翻译。

但翻译速度确实是本地方案的阿喀琉斯之踵。在线方案²的主要工作都在云端完成了，你就像去报刊亭买当天的报纸，到手就可以打开阅读，不需要自己再排版或者校订。而本地方案需要自己承担翻译工作，就好像购回了异国的绝版书籍，打开包裹后先让私人助理帮你处理一遍。一边是几乎为零的时间成本，另一边则是漫长的等待，导致本地方案令人望而却步。而且，多数人都有购买报纸或杂志的“开箱即用”体验，但我相信基本没有哪位读者请过私人助理，这种经验上的鸿沟也导致在线方案更符合绝大多数人的直觉，是一种正向的习惯迁移。

我虽然坚持本地翻译，但也只是苦中作乐，在短则十几分钟、长则一个小时——视 Apple 服务器的心情而定——的翻译工作中，刻意离开书桌做点别的事。然而，2024年初的某次系统更新后，Shortcuts 的离线翻译彻底废弃，我不得不转向在线翻译引擎——但绝不是专用的 RSS 翻译工具——趁此机会，也重新设计了翻译工具，以期提升翻译速度。

结果出乎我的意料：翻译速度从几刻钟压缩到几秒钟，和专用服务别无二致，而且摆脱了这些随时可能倒闭的服务，也让整个阅读流程更加持久可靠。

Keyboard Maestro 动作下载

方案对比

旧方案之所以慢，盖取道逐篇翻译，如果所用的翻译引擎本身慢（例如我用的 Shortcuts）或者网络不畅（例如 Google Translate），则翻译速度自然大受影响。即便在最理想的情况下，一秒钟或许也只能翻译两三篇文章。易言之，翻译是所有操作中最耗费时间的，且不管翻译量多少，每翻译一次保底就要零点几秒，而一般人每天可能有几百篇文章，导致最终总耗时很不乐观。

而新方案虽然最终也要逐个处理（套用标题），但将翻译工作统为一步，一次性提交给翻译引擎。鉴于本方案旨在翻译标题，总字符量不大，在不少翻译引擎中或可一次性解决。当然，为了避免依赖 API，我实际选用的是浏览器自带翻译功能。

打个比方，原方案就像派了一群人去肩挑手提，而新方案则相当于直接搞了一个集装箱。

顺予指出，API 不仅让旧方案苦恼，也是在线服务的瓶颈，如果你食量较大，免不了要为此掏钱，或者考虑自己搭建开源 RSS 翻译服务——购买服务器又是一笔开销。无论如何考虑，API 都像消费税一样无法避免，或许最好的办法是从一开始就不适用 API。

如何使用

本方案的实例针对 DEVONthink，基本思路系将译文写入文章元数据，并呈现为类似 Excel 的多列清单视图，并不替代原始标题，尽可能翻译造成的破坏。关于如何为 DEVONthink 增加自定义元数据，请参阅前文《用 DEVONthink 批量翻译外文 RSS 标题》。由于要用到多种脚本语言，且需要模拟键鼠操作，我选用 Keyboard Maestro 作为自动化载体，虽说理论上也可以完全脚本化，以便移植到几乎任何自动化工具中——请找 GPT 老师讨代码。大体步骤是：

1. 取出当前所选 RSS 文章的标题，统一存储到桌面的临时文件中；
2. 将上述文件转换为 HTML 文件，以便调用浏览器的自带翻译功能（我选用 Safari）；
3. 将翻译结果存在新的临时文件中，并逐行取出译文，添加到 RSS 文章的元数据中；
4. 删除前几步生成的临时文件。

除去设置元数据外，使用前还需注意两件事。其一，为避开 API 而借用浏览器自带翻译——几乎无限量——本方案需要将标题集中的一个 HTML 文件中，途中还会产生其他临时文件，我将其暂时置于桌面，其中的路径也是对应了我的电脑，你需要改为你的实际位置。写死路径是为了预防 macOS 更新后自动化工具无法识别相对路径（我遇到无数次了），很不幸，在底层细节更新并不透明的今天，方便分发和确保可靠似乎是水和油一样难以相容。

其二，请检查你的 Safari 浏览器设置。Keyboard Maestro 触发 Safari 网页翻译的原理是模拟点击菜单栏，故需要填对翻译功能的路径，如果界面更新或者使用英文以外的语言，则要对应修改，无法直接使用我提供的 Keyboard Maestro 动作。

若有兴趣，可更换其他浏览器或者引入 API（不推荐），更换浏览器的方法可参考《一种几乎永不失效的网页中英对照翻译方案》，不过恕我无法一一测试所有工具。

已知的问题

尽管本方案足够低技术，且稍加修改后还可用于 Zotero 或 Calibre——似乎 TiddlyWiki 也可以——但仍有一些问题需要交代。

首先是 Apple 的字符编码问题。除非直接在网页中运行 Javascript 或在脚本编辑器中运行 AppleScript，否则，网页中只要出现 Emoji 符号——严格来说不是 Emoji 本身的问题，而是在翻译过程中，Emoji 会被 Safari 转换为不可打印字符，进而导致错误——此后的内容就会被截断，后续文章将无法翻译。

在技术上，可以考虑外挂脚本、模拟键鼠操作直接在网页上跑代码、过滤 Emoji 符号、删除不可打印字符等方向，但均会让整个方案变得冗长无比，因此我实际上选择：一次不行，就多几次。考虑到本文方案的速度如此之快，我愿意在出错时略过出问题的文章，选中剩余部分再次翻译。或许是我订阅的文章本就比较规矩，每天遇到的 Emoji 只有一两个，易言之，最多重复操作两三次，总共耗时十几二十秒，恐怕比多数服务的刷新时间还短。

其次，如果你同时订阅多种外语的文章，可能也要分几次翻译——视你的浏览器而定。Safari 本身似乎无法一次性翻译多种外语，希望其他浏览器可以。当然，对多数人来说，多语种支持可能是个不成问题的问题，但对我来说确实有些麻烦，因为我同时订阅了美国、日本和意大利作者的食谱。多语种支持将是本方案未来的改进方向之一。

复次，浏览器本身的翻译功能通常也要联网，故网速也会影响翻译速度，甚至只翻译一半。若出现此类问题，可适当增加 Keyboard Maestro 步骤中翻译模块后的等待时间，或者插入 prompt 模块以供手动确认是否继续，不要过度自动化。

此外，在根本上，本方案是直接修改本地的 RSS 文章，而非提供翻译好的 RSS 源，因此你无法将翻译成果像普通 RSS 链接一样分享给别人。本方案的社交属性为零，高度自闭，极其乖僻，非常偏激。

不过，多数人估计也不识货，一瞧见没有全文翻译，立马就拍拍屁股走人。谁能想到，标题翻译才是 RSS 中最需要好钢的刀刃呢！