项目详情
AI Translator
一套围绕网页双语阅读与 macOS 选区翻译构建的轻量翻译工具。
Chrome 端保留原文与译文的对应关系，macOS 端则通过快捷键把译文放回正在编辑的位置。
当前形态：个人 Chrome 网页翻译入口 + 个人 macOS 选区翻译入口｜长期自用｜通用 Chrome 版已开源
真正需要解决的是两条路径
我日常真正依赖的翻译主要发生在两个地方。阅读英文网页时，我希望译文直接出现在原文附近，既能继续沿着页面阅读，也能随时核对原始表达。写邮件、处理文档或在其他 macOS 应用中编辑文字时，我需要的是另一种结果：选中内容后快速翻译，再把译文放回正在处理的位置。
这两条路径都很明确，却发生在不同环境里。网页阅读需要保留双语关系，跨应用编辑更在意译文能否直接接回当前动作。AI Translator 因此形成了个人 Chrome 与个人 macOS 两个日常入口，各自处理一种清楚的使用场景。
让翻译留在动作发生的地方
个人 Chrome 端主要用于网页和长文阅读，也是我目前使用频率稍高的入口。启动翻译后，中文译文会出现在对应原文附近，页面原有内容仍然保留。我不必在网页与独立翻译窗口之间往返，译文对应哪一段也始终清楚。
macOS 端面对邮件、文档和其他需要继续编辑的场景。在当前应用中选中文字，按下 Option + T，翻译完成后，译文会回填并替换原选区。它不保留同屏双语对照，重点是让我继续完成眼前的编辑。
两个入口没有被放进同一个界面。个人 Chrome 端处理网页里的段落位置，个人 macOS 端处理系统选区和原位回填。不同环境各用一个入口，操作会更直接。
小而清楚的功能边界
成熟翻译产品还会覆盖 PDF、字幕、术语库和整站翻译等场景，这些能力对许多使用者都有价值。它们没有进入 AI Translator，是因为我的高频需求集中在网页双语阅读与 macOS 快捷翻译。
这套工具没有追求一张接近成熟产品的功能表。判断它是否成立，看的只是两个入口能否稳定、顺手地完成眼前的动作。这里所说的“替代”，只指它已经取代我原先用于完成这两类任务的翻译方案，不代表它能够全面替代成熟翻译产品。
高频工具，等待也会影响使用
翻译工具进入日常后，我也尝试过能力更强、但响应更慢的方案。翻译往往嵌在连续阅读和写作里，等待一旦反复出现，就会不断打断当前节奏。
当前个人版本固定使用 DeepSeek V4 Pro，并关闭 Thinking。这只是针对我现有场景作出的选择，不说明它更适合所有人。对这类高频工具，等待时间会直接影响翻译能否自然接进阅读和写作，因此我也把响应速度视为核心功能的一部分。
个人入口与通用开源版
我日常使用的仍是 Chrome 与 macOS 两个个人入口。后来，我把网页端整理成了可以自行配置接口、模型和 API Key 的通用开源版。GitHub 仓库只包含 Chrome 扩展，没有固定绑定我的个人配置，也不包含 macOS 工具。
无论个人版还是通用版，待翻译内容都需要发送到相应的模型服务，项目本身没有自建翻译后台。通用版将接口、模型和 API Key 配置保存在浏览器本地，使用者仍需自行管理密钥，并留意所选服务商的数据处理规则。
AI Translator 目前仍在我的日常阅读与写作中使用。通用 Chrome 版已经开源，但项目首先仍是一套服务个人需求的工具；至于它是否适合更多人的工作方式，目前还没有经过外部验证。
公开仓库：GitHub（仅通用 Chrome 版）