把网页、输入框和视频字幕都做成双语对照（kiss-translator）

整页翻译大多会把原文替换掉，译文读着顺，原文的措辞和排版就没了。需要对照着看的场合，这种形态不顶用。kiss-translator 把双语对照当作默认形态：原文留在页面上，译文插在旁边，网页正文、输入框、划词、悬停、YouTube 字幕都按这个方式显示。

kiss-translator 是一套用 JavaScript 写的浏览器扩展与油猴脚本，把网页正文、输入框、划词和 YouTube 字幕翻成双语对照，可接入 Google、微软、DeepL、OpenAI 等翻译服务。

放在同类里看，它属于功能面铺得最宽的那一个：网页翻译之外还有划词、悬停、输入框、字幕翻译和英文词典，跨设备同步、规则订阅、自定义接口也在其中。仓库在 fishjar/kiss-translator，GPL-3.0 许可证，主要语言 JavaScript，Star 12761，Fork 631，开放 Issue 203 条。

这几个项目分别在解决什么

kiss-translator 把多个翻译入口收在同一个扩展里，共用一套接口配置。网页翻译有两种模式：自动识别文本模式，绝大部分网站不用写规则也能翻完整；手动规则模式针对特定网站做精细控制。规则优先级是个人规则 > 订阅规则 > 全局规则，全局规则相当于兜底。呈现方式可以调，支持自定义译文样式、仅显示译文、富文本翻译并尽量保留原文里的链接和文本样式。

安装上它优先推荐浏览器扩展：Chrome、Edge、Firefox 都有商店页，Thunderbird 从 Releases 页下载，Kiwi 和 Orion 分别对应 Android 与 iOS。油猴脚本是另一条路，README 里写明扩展的功能更完整，脚本版会遇到更多跨域问题和脚本冲突。开发环境用 pnpm：

git clone https://github.com/fishjar/kiss-translator.git
cd kiss-translator
git checkout dev
pnpm install
pnpm build

翻译结果直接显示在被翻译的页面或悬浮框里，划词翻译的英文词典与收藏词汇在翻译弹窗内，设置页面地址是 https://fishjar.github.io/kiss-translator/options.html 。常用快捷键如下：

Alt+Q 开启翻译
Alt+D 打开独立翻译窗
Alt+K 打开设置弹窗
Alt+S 打开翻译弹窗/翻译选中文字
Alt+O 打开设置页面
Alt+I 输入框翻译

Traduzir-paginas-web 的定位更单一：用 Google、Bing 或 Yandex 实时翻译整个页面，Star 6029。它没有把划词、输入框、字幕这些入口一并收进来，也没有跨设备同步和自定义规则体系，只做整页翻译这一件事。

chinese-novel-translator 和 niconico-danmaku-translator 是同一种思路的另一头，都是油猴脚本，各自只服务一个垂类场景。前者把中文网络小说翻成英文和其他语言，Star 2；后者把 Niconico 的弹幕实时翻成中文，Star 1。两个项目的社区规模都很小。

ChinaGodMan/UserScripts（Star 2073）、lkytal/GM（Star 229）、nkmr-jp/userscripts（Star 8）属于脚本合集，里面是一批修改或收集来的油猴脚本。它们跟 kiss-translator 的关系在于分发形式同为油猴脚本，功能上并不对标。

逐项对照

差距出现在哪

拉开距离的地方在覆盖范围。kiss-translator 把五六个翻译入口塞进同一个扩展，共用同一套接口配置和同一套规则；配一次接口，网页、输入框、划词、悬停、字幕都能用。Traduzir-paginas-web 只做整页翻译，chinese-novel-translator 和 niconico-danmaku-translator 各守一个站点的场景，换场景就要换工具。代价落在配置量和问题数量上，203 条开放 Issue 里，接口配置与规则理解占了大头。

另一处差距是对翻译服务的态度。kiss-translator 把接口当成可替换的插槽，内置 Google、微软、腾讯、火山、OpenAI、Gemini、Claude、Ollama、DeepSeek、OpenRouter、OrcaRouter、Requesty、DeepL、AzureAI、CloudflareAI、Chrome 内置 AI 等多家，还能通过自定义接口接入几乎任何服务。这份广度也带来不稳定：v2.0.29 的记录里微软翻译失效，默认接口临时改成腾讯翻译；到 v2.0.32 又把默认翻译接口切回微软，并补充免费翻译接口的选择。依赖免费接口的用户，要准备跟着版本更新换配置。

它不如同类的地方同样明显。接口配置是门槛最高的环节，千问模型添加失败、无法使用 New API 提供的 Gemini 系列模型这两条 Issue 目前仍是待解决状态，报错信息也不友好。Thunderbird 里第一次按 Alt+Q 结果会 Double、YouTube 给视频翻译时电脑卡成 ppt 这两条也在待解决清单里，前者影响邮件客户端的使用，后者出现在字幕场景。油猴脚本版还有额外限制，README 明说脚本需要给域名加白名单才能发出请求，跨域问题比扩展版多。许可方面它是 GPL-3.0，想把它嵌进闭源产品，得先看清这份许可证的条款。

什么情况下选它

三种情况值得选。读外语资料时你需要同时看到原文和译文，而且会在多台设备或多个浏览器之间切换，它的同步支持 KISS-Worker 自建服务与 WebDAV 两种方式。你手上有自己的 AI 接口，想用术语词典、上下文会话记忆、流式输出来提升翻译质量，并让划词、悬停、网页翻译共用这套配置。你经常看 YouTube 外语视频，需要字幕双语显示，能接受内置的字幕合并与断句算法，要更好效果时再开 AI 断句。

这几种情况下不适合选。只想一键把整页翻掉、不想碰任何配置的，用 Traduzir-paginas-web 这类方案更省事。只翻某个特定站点，比如中文网文或 Niconico 弹幕，对应的单点脚本更轻。要把它嵌进闭源商业产品复用代码的，GPL-3.0 会挡住这条路。

用它之前要清楚一件事：翻译请求会把页面文本发送到你配置的翻译服务。翻公开资料没有负担，翻仅限内网访问的系统、含个人信息或未公开材料的后台页面时，先确认这些文本会不会离开你的设备，本地部署的服务除外。把自己账号下的接口转给他人使用，也可能违反该接口的服务条款。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.3 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。