1. 双语对照到底解决了什么痛点1.1 普通翻译工具的三种“翻译腔”先讲一个我自己的场景。有段时间我需要啃某个开源项目的英文技术文档内容本身不复杂但我始终在两种工具之间来回切整页翻译工具把原文全部替换成中文想核对一个术语在原文里的准确写法就得切回去划词翻译又太碎一段话要划好几次句子之间的逻辑关系完全断掉。最崩溃的是整页翻译之后页面排版经常乱掉表格错位、代码块混入译文关掉翻译重新加载又是另一个样子。这种体感很常见。传统翻译插件本质上做的是“替换页面内容”它没有考虑一个基本事实人在阅读外文资料时很多时候不是看不懂而是对关键词、对长句结构、对上下文不够确定。这时候最需要的不是把原文“变成”母语而是让母语译文和原文同时可见、一一对应。一个句子我不确定的扫一眼中文译文再回到英文原句核对一下结构马上就能确认。这种“来回扫”的过程才是真正意义上的辅助阅读。我管上面这类问题叫“翻译腔”——不是指译文语言生硬而是指工具的使用体验割裂、死板、不贴近真实的阅读节奏。做这个项目之前我顺手列了一下市面上工具的不足整页替换型原文不可见上下文丢失排版容易被破坏。划词弹出型只能看碎片长文阅读需要反复划词很累。纯双语并排型在浏览器里实现得好的不多实现差的只是左右分栏没有建立段落、句子级别的对应关系读者还是要自己找“哪句对哪句”。实时性不足很多工具是基于整页静态翻译遇到动态加载的文章、SPA页面、无限滚动列表翻到一半新内容加载出来却没有译文体验断裂。1.2 双语对照的三种典型使用场景先明确这个插件的目标场景。它不是给“完全不懂英语的人”用的也不是给“精通英语的人”用的而是给“能读但读得慢、读得累”的人用的。我自己归纳了三个典型场景后面所有功能设计几乎都是围绕这三个场景来的。第一个场景是技术文档与开源项目阅读。这类文本的特点是术语密集、句式固定但很怕误译。比如看到一段配置说明如果只看译文你很难确定某个参数名的原文拼写必须对照原文才能放心复制。双语对照正好解决这个问题参数名、命令、路径在原文里高亮说明文字在译文里对应出现。第二个场景是学术论文与行业报告。这类文本长句多、从句嵌套深单看译文往往觉得“每个词都认识但连起来不像人话”。对照原文阅读时读者可以按从句切分逐段比对译文的结构拆解理解和记忆效果都远好于纯译文。第三个场景是海外资讯、社交媒体讨论和商品评论。用户不需要完整翻译整页只想在浏览过程中偶尔停下来确认某段话的真实含义。这时候如果有一个浮动按钮点击某段就展示双语卡片阅读动线不会被破坏。1.3 我定下的三条产品底线动手前我给自己定了几条原则所有架构决策都优先满足这三条避免做到一半跑偏。第一条原则原文始终可见且不改变原有排版。译文只能以“附加层”的形式出现——注入浮动标签、悬浮卡片、或与原句相邻的独立行绝不能直接替换原文文本。这样即使翻译效果不理想用户退回原文也没有任何成本。第二条原则实时性要有但以不打断阅读为前提。我理解的“实时双语对照”不是每个字都即时蹦出译文而是用户视线移到某个段落时译文在几十到几百毫秒内出现不需要手动一个个点。这涉及视口预取、批量请求、缓存命中率等一系列工程问题后面细讲。第三条原则必须支持句子级别的锚点对应。也就是说译文不是整段甩出来而是逐句对应鼠标移到原句上译文高亮鼠标移到译文上原句高亮。这强依赖DOM节点的稳定标识和渲染跟踪也是这个项目里工程量最大的部分。这三条底线决定了后面的技术选型为什么选浏览器扩展而不是桌面软件为什么在提取层做了那么多过滤为什么要把锚点机制单独做成一整套模块。2. 功能拆解与技术选型先把要做的事想清楚2.1 核心功能清单整个项目的功能我拆成了四层每一层独立开发、独立测试最后再串起来跑真实页面。第一层是内容提取层负责从当前页面拿到干净的、可翻译的文本块。这里说的“干净”非常重要——页面上有导航菜单、侧边栏广告、页脚、隐私声明这些都不该翻译。更麻烦的是有些文本被写在script标签或style标签里有些是隐藏元素有些用了无障碍阅读的sr-only类提取时必须做全面过滤。第二层是翻译调度层负责把文本块合并成合理的请求批次调用翻译引擎处理限流、失败重试和超时。这个模块要解决的问题是一个页面可能有几百个文本块如果每个块都发一个请求翻译引擎大概率限流而且速度极慢。所以必须合并、并发控制、缓存命中三级处理。第三层是锚点与渲染层负责把译文挂回页面上并且和原文建立位置对应关系。原句在文档流中的位置会因为滚动、缩放、动态加载而变化译文必须跟随。我还要支持译文的三种展示形态行内悬浮、句末卡片、侧边对照栏用户可在设置里切换。第四层是交互控制层包括popup设置页、右键菜单、快捷键、语言切换开关、站点白名单/黑名单。别小看这一层翻译插件最容易被用户卸载的一个原因就是“在不需要翻译的页面上总是弹译文”所以默认关闭、按站点开启的设计很重要。2.2 为什么选浏览器插件而不是桌面应用我一开始也想过做成桌面应用比如独立的阅读器把链接放进去解析。但推演之后否掉了。原因很简单这个工具的价值在于“不离开原页面”。用户是在自己的浏览上下文里阅读加了书签、表单、登录态、个性化推荐这些内容只有在原页面里才有意义。桌面阅读器相当于让用户多走一步复制链接、打开应用、等待解析。这一个步骤就足够让90%的潜在用户流失。浏览器扩展可以做到“感知当前页面在页面内叠加工具层”这是它最大的优势。另一个优势是跨平台——同一套代码在主流浏览器里都能跑不需要针对操作系统单独打包分发。开发成本也低掌握JavaScript、HTML、CSS就能完成全部工作。当然也有代价。最大的代价是浏览器的安全模型限制扩展不能随意读取跨域接口需要申请host_permissionsManifest V3 下后台脚本从常驻页面改成了事件驱动的Service Worker意味着你不能在后台维持一个长时间的连接DOM被页面脚本恶意修改时扩展也可能被干扰。这些限制在设计中都得提前规避后面踩坑部分我会详细说。2.3 翻译能力从哪来云接口与本地模型如何取舍翻译引擎选型是整个项目里第一个要决策的事。主流选项大致分三类云厂商的通用翻译API、自建的翻译服务、以及本地运行的开源翻译模型。云厂商通用翻译API优势是质量稳定、接入简单、支持语种多缺点是按量计费、有并发限制并且文本要发送到外部服务存在隐私顾虑。自建翻译服务适合对数据安全敏感的部署环境但机器成本、模型维护、工程复杂度都上了一个台阶。本地模型下载体积大、CPU推理速度慢好处是完全离线、零成本、隐私无泄露。这个插件的第一版我选的是云厂商通用翻译API理由很简单翻译质量优先级最高而且它的自动语种检测能省掉语言识别这一步。我预留了自定义接口配置项用户可以在设置里填入自己的翻译接口地址和密钥这样可以绕开插件本身的密钥管理也方便隐私敏感用户把请求转发到自己的服务。本地模型我留到后续版本再做先作为可选的离线兜底因为它解决的是“断网也能用”的场景而不是核心阅读场景。关于密钥问题多说一句写过浏览器扩展的人都知道打包进扩展里的任何密钥都会被扒走。所以绝对不要在扩展代码里内置一个全局翻译API密钥否则你就是在替所有用户买单而且很快会被盗刷。正确做法是让用户自己在设置里填密钥或者引导用户注册后绑定自己的配额。这个小设计救过我很多次。3. 实现过程从零搭起一个可用的双语翻译插件3.1 插件骨架与权限模型项目采用Manifest V3规范。之所以直接上MV3而不是老版Manifest V2一方面现在主流浏览器对新扩展的审核要求都向MV3靠拢有的已经开始逐步禁用MV2另一方面MV3的Service Worker模型长期看更省资源也更贴合未来浏览器的安全要求。基础的manifest.json结构大概是这样的{ manifest_version: 3, name: Bilingual Reader, version: 0.1.0, permissions: [storage, activeTab, contextMenus], host_permissions: [all_urls], background: { service_worker: background.js }, content_scripts: [ { matches: [all_urls], js: [content.js], css: [content.css], run_at: document_idle } ], action: { default_popup: popup.html, default_title: 双语对照 }, options_ui: { page: options.html, open_in_tab: true } }权限申请我给得很克制storage用来存用户设置和翻译缓存activeTab用来在用户点击按钮时获取当前标签页权限contextMenus用来支持右键菜单调用。host_permissions这里我写的是all_urls因为翻译工具需要在任意网站工作但后面加了一个限制翻译开关默认关闭用户进入某个页面后手动开启或者把站点加入白名单才会真正注入和提取。这里有一个容易被忽视的问题run_at选什么时机。document_idle意味着页面已经基本加载完毕此时DOM结构相对稳定提取文本不会遇到大量未渲染节点。但如果选document_start虽然能更早监听请求和DOM变化也会更早遇到动态加载的空白期反而增加复杂度。第一版我建议直接用document_idle省心。3.2 文本提取如何拿到页面里“真正值得翻译”的内容提取模块是整个项目的地基。如果提取出来的文本是碎的、脏的后面所有环节都会受影响。先写一个遍历DOM的递归函数找出所有“叶子文本节点”也就是没有子节点的文本节点。遍历的时候要跳过这些情况script、style、noscript、template、textarea、code、pre标签内的内容。不可见节点display: none、visibility: hidden、宽高为0等。“纯功能性文本”比如aria-label、title、alt这些属性值虽然有可读文本但不适合作为页面主体内容翻译。已经包含译文标记节点的子树避免重复提取。核心提取逻辑大致是function getTextBlocks(root) { const walker document.createTreeWalker(root, NodeFilter.SHOW_TEXT); const blocks []; let current null; while (walker.nextNode()) { const node walker.currentNode; if (!isVisible(node.parentElement)) continue; if (shouldSkip(node.parentElement)) continue; const text node.textContent.replace(/\s/g, ).trim(); if (!text) continue; if (!current || current.parent ! node.parentElement) { current { parent: node.parentElement, text: }; blocks.push(current); } current.text text; } return blocks.filter(b b.text.length 2); }注意这里几个细节。第一\s会被压缩成单空格这是为了把换行、缩进带来的碎片空格去掉避免出现“句子中间莫名断开”的情况。第二同一个父元素下的多个文本节点会被合并成一个块这是为了避免因为HTML书写格式导致的一句话被拆成两三块。第三过滤掉长度小于2的块这些一般是单个标点、单个字母没有翻译价值。但这里有一个更深的问题父元素级别的合并还不足以恢复完整的句子。比如一个p段落里既有普通文本又有span包裹的重点词还有a链接提取的时候如果只看父元素会把一句话拆成好几个块。所以我后来又加了一步“块级合并”向上递归查找最近的块级元素p、div、section、article、li、blockquote等同一个块级元素内的多个文本块在翻译前会先合并译文按比例切分后再映射回各自的块。这个机制后面在断句错误那一节还会详细展开。3.3 双语对齐的核心DOM锚点定位与MutationObserver提取到文本之后真正的难点来了怎么把译文挂回页面并且保证原文和译文随时一一对应。我的设计是这样做的遍历提取出的文本块时为每个块生成一个唯一ID然后在原文节点上做一个标记属性比如>{ text: {{TEXT}}, source_lang: {{SOURCE_LANG}}, target_lang: {{TARGET_LANG}} }插件会把每批句子的文本拼接后替换{{TEXT}}目标语言替换{{TARGET_LANG}}。响应解析则通过一个用户可配置的取值表达式默认从data.translations里取数组。这个设计让插件不依赖任何单一厂商也从根上规避了“密钥被盗刷”的风险。6.2 本地小模型的离线兜底离线翻译不是核心场景但实际使用中我确实遇到过几次让人抓狂的情况在飞机上、在地铁隧道里想查一段英文说明却没有网络。于是我在计划里给本地模型留了一个位置。思路不是让本地模型承担全部翻译而是让它作为“网络不可用时的兜底”。我测试过一些开源的小型翻译模型尺寸在100MB到300MB之间加载到页面里用WebAssembly或者WebGPU推理CPU模式下翻译一段话大概需要2到5秒GPU模式下可以到1秒左右。速度远慢于云接口但作为离线兜底完全可接受。实现上我把本地模型和云接口放在同一个翻译适配层后面。请求翻译时先检查navigator.onLine和存储的离线模型状态。有网络且配置了云接口就走云没网络就切本地模型。这个切换对上层透明锚点、渲染、缓存机制完全不用改。如果你想把离线模型也做进来我个人的建议是先确认模型格式和运行时兼容性不要太早优化模型精度先把“能跑、能出结果、不卡死页面”跑通再慢慢迭代质量。本地模型的接入成本主要是工程性的不是算法性的只要推理是异步的、不阻塞主线程体验就不会太差。6.3 这个项目做完之后我的几点体会整个项目做下来我最深的一个感受是翻译插件这类工具真正的分水岭不在翻译模型选哪个而在上下文呈现做得好不好。同样一个翻译结果展示在原文旁边和叠加在原文上用户的信任感和阅读效率完全是两个量级。很多人说“AI翻译已经很好了为什么还需要看原文”但做过精读的人都知道译文永远只是辅助原文才是信息的锚点。如果让我给想复刻这个项目的人一条最直接的建议先花足够多的时间在文本提取和锚点机制上翻译引擎反而是最好替换的部分。提取做得不干净译文再准也是错位锚点做不稳缓存和性能优化都无从谈起。另外一定要做默认关闭、按站点开启的设置让用户自己决定在哪里启用这个工具这种克制能换回很多好评。这个项目后续我还在考虑加字幕翻译、PDF阅读模式、以及基于原文语境的段落级语义翻译。每一个方向都仍然围绕同一个核心——让外语内容在用户的阅读流里变得透明而不是制造一个新的工具负担。