# 本地 RSS 标题翻译高速方案（DEVONthink 版） > 本文公开全文。 原文：https://utgd.net/article/20659 速度是阅读的决定性因素之一。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 老师讨代码。大体步骤是： - 取出当前所选 RSS 文章的标题，统一存储到桌面的临时文件中； - 将上述文件转换为 HTML 文件，以便调用浏览器的自带翻译功能（我选用 Safari）； - 将翻译结果存在新的临时文件中，并逐行取出译文，添加到 RSS 文章的元数据中； - 删除前几步生成的临时文件。 除去设置元数据外，使用前还需注意两件事。其一，为避开 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 中最需要好钢的刀刃呢！ --- [前往标准阅读页](https://utgd.net/article/20659?audience=web)