浏览器里的翻译扩展已经很多，而且其中一些产品不仅能翻译网页，也能处理视频字幕等。我开发「只译」，并不是因为这些工具功能不够强，也不是想证明市场上还缺少一个什么都能做的翻译产品。
真正让我不太适应的，是另一种取舍。
一些功能很强的产品，同时包含账号订阅和持续出现的付费推广；另一些产品提供了大量设置和延伸功能，但我日常真正需要的其实没有那么多。收费本身并不是问题，软件持续维护当然需要成本。我也愿意为合适的工具付费，但当一款需要长期使用的阅读工具采用较高的持续订阅价格，并把不少产品注意力放在订阅转化上时，它就不再是我想每天打开的那种工具。
另一方面，免费工具里也有一些足够简单、纯粹的选择，只是功能可能停留在比较基础的阶段。于是我面对的并不是“有没有翻译软件”，而是一个更具体的问题：能不能有一款不被账号和订阅主导、不堆太多我用不到的功能，同时又能认认真真把当前页面翻译完成的工具？
我想要的使用过程其实很简单：打开内容，选择翻译，译文稳定地出现在原来的阅读位置，然后继续往下读。工具不必不断提醒我它还有多少功能，也不必把我带进另一套内容平台。
从给开源项目添砖加瓦，到维护自己的版本
只译并不是从零开始的项目，它基于开源扩展 FluentRead（流畅阅读）开发。
一开始，我更自然的想法是直接在原项目上补充自己需要的功能，再通过 Pull Request 把更新推送给原作者。这样既能复用已有基础，也不必另起一个名字维护新的项目。
实际尝试后，我发现这条路和自己的需求节奏不太一致。
一方面，每个开源项目都有自己的产品定位。某项功能对我很重要，不代表它也符合原项目维护者希望前进的方向；另一方面，规范地拆分改动、解释设计、等待审查、根据反馈调整，再进入上游发布周期，本来就是负责任的协作过程，但对于一款我自己每天都想尽快用上的工具来说，这套流程显得有些漫长。
这不是原作者或开源协作方式的问题。维护者需要控制项目边界和长期成本，而我想要的是更快地试验、修改和发布：今天在实际页面上发现问题，希望尽快修好，确认没有引入明显回归后就能继续使用。
因此，我最终选择在 FluentRead 的基础上维护自己的版本。这样既不需要重复解决已经被妥善解决的问题，也能按照自己的节奏继续添砖加瓦。只译保留并感谢原项目的工作，继续遵循 GPL v3 协议开源。
后来加入的网页识文、视频字幕和本地 EPUB，也不是为了把功能列表越做越长，而是来自我实际遇到的阅读场景。无论内容是什么形式，我希望翻译都尽量贴着原内容出现，让人留在原来的阅读位置继续往下读。
阅读内容，并不等于翻译页面上的一切
「识文」也是在我自己使用和修改扩展的过程中，逐渐明确下来的一个需求。
我大部分时间是在浏览帖子、专栏和长文章。这些页面里，真正需要认真阅读的是正文。至于导航条、菜单、标签、订阅按钮和其他操作元素，我通常并不关心它们是否被翻译。有一定英语基础以后，理解这些短小、重复出现的界面文字并不困难。
真正容易让人疲劳的是连续阅读大段外语文字。单独看一句话或一小段并不一定有障碍，但长时间在脑中理解和转换，会不断消耗注意力，读得越久越容易从内容本身分心。这个时候，我需要的不是把页面上的每个词都换成中文，而是让正文的阅读负担降下来。
因此，只译提供了「识文」模式。它会优先寻找正文、帖子和评论等主要阅读区域，尽量让导航、按钮和侧栏保持原样。它更适合文章、博客和长内容，也更接近我实际需要的“阅读模式”。
但并非所有网页都是文章。有时我需要阅读文档、论坛、后台或信息密集的工具页面，这些页面里的界面文字也可能是内容的一部分。为此，只译同时保留了「全页」模式，用来处理更多可见文字，也可以作为识文出现漏翻时的回退选项。
显示方式同样分为「双语对照」和「仅译文」。需要核对原文或学习语言时，可以让译文跟在原文后面；只想连续阅读时，则可以只保留译文。
这套设计没有试图替用户决定唯一正确的阅读方式。有人希望页面尽量干净，有人需要随时核对原文，还有人正在处理文档或论坛，确实需要覆盖更多内容。与其继续堆叠自动判断，我更愿意保留两个容易理解、可以随时切换的选项。
视频字幕也应该跟着播放节奏出现
视频是第二个被加入的场景。
字幕翻译和网页段落翻译看起来相似，实际面对的问题却不同。网页内容通常是相对稳定的，字幕则会随着播放进度不断变化。如果逐条临时请求，容易跟不上播放；如果一次处理太多，又会增加等待时间。字幕还需要保留上下文，否则同一个词在不同语境中很容易得到割裂的结果。
只译会读取网站提供的原字幕，按上下文分段翻译，并根据播放位置显示双语字幕。本地缓存用于减少重复请求和来回拖动进度条时的等待。
目前主要支持 YouTube、Udemy、Coursera 和 Khan Academy。这里有一条明确边界：只译不负责语音识别，视频必须已经提供扩展能够读取的原字幕轨道。没有字幕的视频，暂时无法凭空生成字幕。
我希望它保持的是“看视频”的状态，而不是把视频内容先导出、处理，再放进另一套工具。翻译应该跟着播放发生，原字幕和译文也应该可以同时核对。
把本地 EPUB 留在本地书架里
第三个场景是本地 EPUB。
网页和在线视频至少有一个天然入口，但本地电子书通常意味着另一套应用、另一份设置和另一种阅读习惯。我后来在扩展里加入了一个 EPUB 阅读器：用户可以导入本地无 DRM 的 EPUB，在浏览器中按章节滚动阅读，并保存书架、阅读进度和位置书签。
进入章节后，可以沿用网页场景中的双语或仅译文显示方式。书架、进度和书签保存在当前浏览器配置中，不需要注册只译账号，也没有云端书架。
这里同样需要说明数据边界：导入的 EPUB 文件本身不会上传，但开始翻译后，需要翻译的章节文本会发送给用户选择的翻译服务。移除图书会同时删除对应进度和书签；卸载扩展或清除扩展数据，也会失去本地书架。
EPUB 阅读器目前仍是 Beta，只支持本地无 DRM 的 EPUB，不支持 PDF、MOBI 或受 DRM 保护的图书，也没有云同步、笔记和 AI 内容分析。我暂时不想把它做成一个大而全的知识管理系统，先把“打开一本书，继续在原文旁边阅读译文”这件事做好。
翻译服务应该由使用者选择
翻译质量、速度、隐私和费用之间很难存在适合所有人的唯一答案。
只译提供微软翻译、Google 翻译和 Chrome 内置翻译等选项，也预设了 DeepL、OpenAI、DeepSeek、Gemini、Claude，以及兼容 OpenAI Chat Completions 的接口。免配置服务可以直接使用；AI 服务需要填写对应的 API Key，并遵循服务商自己的计费和隐私规则。
只译本身免费、开源，不要求注册账号，也不绑定订阅。设置、缓存和电子书书架保存在浏览器本地，项目方不收集扩展使用数据。使用在线服务时，待翻译文本仍然会发送给所选服务商，这一点不会因为扩展开源就自动消失。
我选择开放翻译服务配置，一方面是因为不同内容适合不同服务，另一方面也是希望工具本身不要成为新的账户和账单中心。用户可以使用无需配置的服务快速开始，也可以在更在意质量或术语一致性时换成自己的服务。
它不是一个没有边界的翻译平台
只译目前以 Chrome 为主要支持平台。浏览器内部页面、扩展商店和其他安全受限页面不允许普通扩展运行；复杂网页和持续变化的动态内容也仍可能出现漏翻或排版问题。
字幕翻译依赖原字幕，EPUB 阅读器仍处于 Beta，识文模式也不可能准确理解所有网站的结构。这些限制不会因为宣传文案换一种说法就消失。
在保留 FluentRead 核心网页翻译能力的基础上，我重点补充了视频字幕翻译、本地 EPUB 阅读器、识文／全页范围切换和更精简的设置体验。项目使用 WXT、Vue 3 和 TypeScript。
发展到现在，只译已经基本满足了我工作和日常阅读中的需求。我开始把它推广出来，不是因为我已经想好了一张需要所有人接受的功能路线图，而是想知道，当它离开我的个人使用环境之后，其他人真正会在哪些页面、视频和电子书里使用它，又会遇到哪些我没有见过的问题。
后续功能也希望更多地由这些具体反馈决定。它不一定会接受每一项需求，更不会以功能数量作为目标；我更在意一项改动是否让翻译更稳定、阅读更连贯，或者让原本复杂的操作变得简单。
我不打算把只译描述成其他成熟工具的替代品。它只是从一款免费开源工具出发，逐渐长成了更符合我个人取舍的版本：不需要太多附加内容，不建立新的账号和订阅体系，先把翻译和阅读这件事认真做好。
如果你平时会认真读外语文章、课程字幕或本地 EPUB，也愿意尝试一款仍在完善中的工具，可以从 Chrome Web Store 安装，或者在 GitHub 查看源码和当前限制。
- GitHub：airhunter/OnlyTranslate
- Chrome Web Store：只译
