上周朋友发来一张截图Yandex 浏览器装好之后菜单栏一半俄文一半英文他上来就问“汉化包是不是没装对是不是得自己找语言包”我第一反应也是骂这软件抠门但把安装目录整个翻了一遍之后发现中文语言包其实就躺在locales目录里真正不显示中文的原因是 Yandex 对语言环境的判定逻辑跟 Windows 系统语言并没有完全绑定。这篇就把我这次折腾 Yandex 语言包汉化的过程完整写出来从文件格式到提取翻译再到回填生效每一步都说清楚。先说明一下这篇文章说的“汉化”不是指给网页内容做全文翻译那种而是把 Yandex 浏览器或相关客户端软件本身的界面语言资源改写成中文。Yandex 桌面产品线基本都复用 Chromium 那套本地化框架学会处理这一套以后遇到 vscode、figma、postman、eclipse 这类工具的汉化需求思路也完全通用。1. 先搞清 Yandex 的语言包结构再谈汉化1.1 界面显示俄文不一定是语言包缺失很多人遇到 Yandex 界面不是中文第一反应就是“这软件没带中文包”。实际上多数情况下中文语言资源是存在的只是加载优先级问题。Yandex 浏览器基于 Chromium它的语言选择顺序大致是这样的优先读启动参数里的--lang。如果启动时没带这个参数它就会往下找。读用户偏好设置文件里的intl.app_locale字段。你在设置页里手动切过语言这个字段就会写进去。继续往下走根据系统区域设置或者 IP 归属区域做猜测。问题就出在第三步如果 Windows 系统区域是英文或者俄文Yandex 启动时会直接采用猜测结果这时候就算安装包里带着zh-CN.pak也不会主动加载。所以很多情况下不是“没有中文包”而是“没让它用中文包”。1.2 安装目录里哪些文件算语言包Yandex 的语言资源大致由三部分构成在修改之前必须先分清谁是谁。资源类型典型路径内容汉化时是否需要动浏览器内核资源Application\版本号\locales\zh-CN.pak工具栏、右键菜单、设置页、弹窗提示等需要主程序公共资源Application\版本号\resources.pak输入框、按钮、通用组件一般不需要动扩展及组件资源Application\版本号\Extensions\xxx\扩展名称、描述、按钮文案按需修改其中locales目录是最重要的。正常安装的 Yandex 浏览器里这个目录下会有一堆.pak文件包括zh-CN.pak简体中文、zh-TW.pak繁体中文、en-US.pak、ru.pak等。你可以先去这个目录检查一下确认zh-CN.pak是否存在。如果存在说明语言包资源完整问题大概率出在配置如果不存在那就需要走完整的提取和回填流程。1.3 判断“缺包”还是“没启用”的笨办法在动手改文件之前我建议你先做一个最小验证用命令行方式强制指定语言。找到 Yandex 的安装路径复制一份快捷方式在目标末尾加上你的安装目录\yandex.exe --langzh-CN双击这个快捷方式启动。如果界面立刻变成中文说明zh-CN.pak一直就在那里只是之前没有被加载。这种场景根本不需要汉化只需要改配置。如果界面没有任何变化才需要考虑修改语言包本身。2. 把语言包完整提取出来.pak 与 JSON 资源2.1 备份永远放在第一步对 Yandex 安装目录做任何写操作之前先把locales整个文件夹复制一份。比如这样xcopy C:\Users\你的用户名\AppData\Local\Yandex\YandexBrowser\Application\版本号\locales D:\backup\locales\ /E /I /Y这一步看起来多余但改坏语言包之后你会感谢这个备份。我曾经有一次在回填zh-CN.pak时把字符串长度记错导致整个菜单变成了乱码最后就是靠备份恢复的。2.2 .pak 文件到底能不能用压缩软件解开很多汉化新手上来就用 7-Zip 去解.pak文件结果提示“无法作为压缩包打开”然后就开始怀疑工具不行。这里有个误区Chromium 体系的.pak文件不是普通压缩包它是一种自定义的二进制资源索引格式。它的结构大致可以理解为文件头部记录版本、编码方式、资源总数量。中间部分是索引表每一条记录对应一个资源 ID、偏移量和长度。最后才是真正的字符串或图片二进制数据。所以处理方式不是“解压”而是“解析”。解析思路可以用下面这段伪代码表示# 示意逻辑不是完整脚本 def extract_pak(path): data open(path, rb).read() # 读取头部版本、资源数量 version, resource_count unpack_header(data) # 遍历索引表 for index in range(resource_count): resource_id, offset, size read_entry(data, index) # 把这段独立资源导出 export_data(resource_id, data[offset:offset size])实际使用时你不需要从头写解析器可以去找现成的 Chromium pak 处理工具。这类工具通常提供两个命令一个unpack用于拆包一个repack用于回填。拆出来的文件里大部分是.json或纯文本格式的字符串资源这时候就可以正常用文本编辑器打开了。2.3 扩展和组件里的 JSON 语言包浏览器主框架之外Yandex 还有一些自带扩展或插件组件。它们的语言包不在locales目录里而是以_locales目录的形式放在扩展目录中最常见的文件名是messages.json。一个标准的messages.json长这样{ extensionName: { message: Original Extension Name, description: Name of the extension }, extensionDesc: { message: Description text here, description: Used in the details page } }这类文件本身就是明文 JSON不需要解析工具直接用 VSCode、Notepad 或者任何支持 UTF-8 编码的编辑器打开就能改。注意JSON 文件保存时务必保持 UTF-8 编码并且不要带 BOM 头否则扩展可能加载失败。2.4 提取阶段的常见坑不要一次性把整个resources.pak全部解包翻译。这个文件体积很大包含的功能组件特别多汉化成本高回报率低。只处理locales下的zh-CN.pak就足够了。拆包后如果看到大量以IDR_开头的文件名不要觉得奇怪这是 Chromium 的资源命名规则。翻译的时候要对应原文不要改文件名。部分.pak文件内部还有嵌套资源需要二次提取。判断方法是看导出文件能不能被编辑器正常打开如果打开是乱码说明还需要再拆一层。3. 翻译阶段的取舍与占位符处理3.1 不要试图一次性翻译全部字符串一个完整的 Yandex 语言包拆开后字符串数量可能达到几千条甚至上万条如果一开始就想全部翻译完大概率搞到一半就放弃。我的经验是先做“用户看得见”的部分。优先级从高到低排下来大概是主菜单、右键菜单、标签页标题、地址栏按钮。设置页、扩展管理页、下载管理页。弹窗通知、错误提示、内部页面文字。隐藏较深的帮助文档和开发者工具。实际操作时可以先用文本编辑器打开拆包后的主要字符串文件用“查找”方式定位关键词比如File、Edit、View、Settings、Help先把这些高频菜单项翻译掉然后启动 Yandex 看效果。看到自己改的文字出现在界面上比闷头翻几百条有效得多。3.2 占位符、变量和复数规则是翻车重灾区翻译界面字符串和翻译文章最大的区别在于你不能只关心“意思对不对”还要保证程序运行时能正确替换变量。举个典型例子Delete {count} items?中文翻译以后通常写成确定要删除 {count} 个项目问题不大。但如果是这种%1 files from %2 folder翻译成中文时如果按照英文语序写成来自 %2 文件夹的 %1 个文件在某些程序里就会出现变量替换失败因为程序是按照%1在原文中的位置去替换的。有的框架严格按序号匹配有的框架则按字符串顺序匹配转换之后顺序一变显示就容易出错。我的处理原则是变量标识绝对保留不删除、不合并、不改变写法。尽量保持变量在句子中的相对顺序。如果中文语序确实需要调换先确认语言包使用的框架支持“命名变量”或“序号重排”。数字和单位之间注意留空格中文习惯里数字后面不加空格但英文模板里有空格最终效果要靠实测判断。另外还有一类隐藏字符串比如This product is {count, plural, one {# item} other {# items}}.这是 ICU MessageFormat 的复数写法。英文里绕开了单复数问题中文可以简化成共 {count} 个项目但简化的时候一定要把{count}保留在输出字符串里不然界面上就会显示“共 个项目”这样的诡异文案。3.3 翻译工具怎么选我个人的习惯是如果字符串数量少于 1000 条直接用 VSCode 加批量查找替换效率反而更高。如果字符串数量超过几千条建议把拆包后的文件转换成.po格式用支持 gettext 的编辑器比如 Poedit逐条翻译。.po格式天然支持模糊标记、上下文注释、翻译记忆对后期维护特别友好。如果用表格管理翻译导出的文件要反复确认分隔符尤其是英文原文里带有双引号或逗号的很容易把表格结构撑破。翻译过程还要注意术语统一。Yandex 里很多词在官方中文版里有固定译法如果你只是凭感觉翻后期会发现同一个按钮在不同页面出现三种不同叫法。我一般会先列一张术语对照表把“同步”“书签”“账户”“历史记录”这类高频词统一口径。4. 回填文件并强制 Yandex 使用 zh-CN4.1 直接替换 .pak 文件翻译完成后关键一步是把翻译后的内容重新打包成.pak文件然后覆盖回原目录。具体流程是用 pak 工具重新打包翻译后的 JSON 文件生成新的zh-CN.pak。备份原文件。用新文件覆盖Application\版本号\locales\zh-CN.pak。完全退出 Yandex注意不是关窗口而是从系统托盘退出再重新启动。覆盖之后如果启动正常界面出现中文说明打包成功。如果启动闪退多半是打包格式不对或者资源 ID 错位用备份恢复即可。有一点必须提醒直接改安装目录属于对原版文件的修改某些软件会在启动时做完整性校验。Yandex 的校验规则不同版本不太一样有的版本覆盖后一切正常有的版本会出现页面反复加载或者报错。如果你只想给自己用覆盖法完全可行如果你希望后续还能继续收到自动更新那建议改为 4.2 节的方式。4.2 通过用户配置强制语言优先级不覆盖文件也能实现汉化的思路就是让 Yandex 优先读已经存在的zh-CN.pak。这个方案适合语言包本身存在只是默认没加载的情况。操作方法分两步第一步修改 Yandex 用户数据目录下的偏好设置文件。位置通常在C:\Users\你的用户名\AppData\Local\Yandex\YandexBrowser\User Data\Default\Preferences这个文件是 JSON 格式找到intl相关字段把app_locale或类似的语言键值改成zh-CN。修改前先退出浏览器否则退出时配置会被重新写回你改的东西就白费了。第二步在启动快捷方式里加上参数--langzh-CN这两个操作可以同时做让语言优先级最大化。之后每次启动Yandex 都会强制加载locales目录下的zh-CN.pak即使安装包里的中文翻译不完整至少主框架能显示中文。4.3 验证汉化是否生效启动浏览器之后进入设置页或右键菜单看看如果发现中文已经显示就算基本成功。还可以在地址栏输入以下内部页面确认当前语言环境chrome://version这个页面上会显示语言相关设置。如果显示Language: zh-CN说明语言包生效如果仍然显示en-US或ru说明配置文件或者启动参数还没生效需要检查快捷方式里的参数是否写对。4.4 验证阶段容易翻的车要单独点一下Yandex 有多个进程常驻后台用户经常改了配置后没有完全退出软件就直接启动导致修改被覆盖。正确操作是用任务管理器确认所有yandex.exe进程都已经结束再做文件替换或配置修改。另外一个观察点是如果你看到部分界面是中文、部分界面还是英文这不一定是失败了很可能是你只翻译了高频菜单其他深层页面还没处理。先别急着补全把主框架跑通确认整套改包流程没问题再继续扩充翻译范围。5. 不想碰原版文件时的“软汉化”方案5.1 官方设置里切换语言永远是最稳的第一步在所有汉化操作之前先检查一下 Yandex 设置里能不能直接添加中文。路径一般是“设置 → 语言”在里面添加中文并将其移动到列表顶部然后重启浏览器。这一步官方就是支持的也是风险最低的汉化方式。只有当你发现官方语言选项里没有中文、或者加了中文仍然大量显示俄文/英文时才值得考虑手动改包。5.2 用浏览器扩展做界面文字覆盖如果觉得修改安装目录风险太大还有一个折中方案利用浏览器扩展对页面文本进行替换。这种方式适合那些官方语言包确实缺字符串的场景。扩展里可以配置一套“原文 → 中文”的映射表页面加载时自动把固定文字替换为中文。好处是不动原版文件不依赖语言包打包格式缺点是只能替换网页 DOM 里的文字对浏览器原生菜单和弹窗无效。5.3 借用其他 Chromium 系语言包能不能省事有人会想Yandex 就是 Chromium 内核那我直接拿 Chrome 或 Edge 的zh-CN.pak复制过来行不行我的实测结论是不要这样做。虽然两者同源但 Yandex 改了相当多的资源 ID字符串编号和 Chrome 并不完全一致。你复制过来的包大概率会让部分按钮消失、文字错位甚至出现方框乱码。更靠谱的做法是从 Yandex 的旧版本安装包里提取官方zh-CN.pak不同版本之间的通用性会好很多。5.4 给官方语言包“打漏洞”的思路如果你只是想让 Yandex 某一处固定英文变成中文还有一种轻量修改方式把英语语言包里的对应字符串翻译后回填到locales目录下en-US.pak里然后强制 Yandex 使用英文界面。这样做的意义在于Yandex 对en-US的兼容性通常最好出错概率比直接改zh-CN.pak低。缺点是需要自己维护一套被“篡改”过的英文包更新时也要同步调整总体麻烦程度并不低。我自己实测下来最顺手的还是“备份 解包 高频翻译 回填 启动参数强制”这条路线。它看着步骤多但每一步都稳定可控而且不管 Yandex 后续怎么更新版本这套思路都不会过时。最后再分享一个细节打包工具对文件编码非常敏感所有翻译后的文本统一保存为 UTF-8 无 BOM可以避免九成以上的乱码问题。