界面上一堆看不懂的外文菜单，右键菜单、设置项、错误提示全是外文，但网页本身显示中文毫无问题——这种"半生不熟"的状态，是不少人第一次接触 Yandex 浏览器时最典型的困惑。它用的 Chromium 内核本身对多语言支持做得相当完整，汉化失败几乎从来不是"没有中文"，而是语言包没被加载、加载了但版本对不上、或者界面语言和网页语言被混为一谈。这篇就把 Yandex 浏览器的汉化路径掰开讲：从 Chromium 内核的资源打包机制、locales 目录的命名与回退规则，到界面语言切换的几个入口和优先级，再到汉化不彻底时怎么一步步倒推根因。不管你是只想把菜单变成中文的普通用户，还是想搞清楚 Chromium 本地化链路到底怎么跑起来的开发者，下面这些内容都能直接拿去用。

1. 汉化卡住的从来不是翻译，而是三套并行的语言系统

很多人对"汉化"的理解是：把外文替换成中文。在这个认知下，一旦界面还是外文，第一反应就是"中文包没装"或者"翻译不全"。但实际动手之后你会发现，装是装了，设置里也确实有中文选项，界面却依旧纹丝不动。问题的根源在于，现代浏览器内部并不是"一种语言"，而是至少三套彼此独立、各自有独立配置项和独立加载路径的语言系统，任何一套没配对，表现出来的症状都不一样。

1.1 界面语言、网页语言偏好、内容翻译，三者互不相干

第一套是界面语言，也就是按钮、菜单、设置项、对话框上那些文字。它由浏览器进程在启动时加载的资源包决定，改它必须重启，且改的是"程序自己说的话"。

第二套是网页语言偏好，对应 HTTP 请求头里的Accept-Language，以及页面里navigator.language、navigator.languages返回的值。它影响的是网站服务器决定给你返回中文版还是英文版页面，跟浏览器自己的按钮写什么字毫无关系。

第三套是内容翻译，也就是地址栏右侧偶尔弹出的"是否翻译此页面"提示。它是页面加载完成之后，由语言检测组件判断页面语种、再调用翻译服务完成的，跟界面语言、跟请求头都不是一回事。

这三套东西在配置界面上被塞进了同一个"语言"页面，视觉上像是同一个开关，实际背后是三份不同的配置。我见过不少人把界面语言设成中文之后，发现访问某些站点还是英文页面，就断定"汉化没成功"——其实人家界面早就中文了，只是那台服务器根据Accept-Language返回了英文内容。把这三件事分开看，后面所有的排查才有意义。

提示：判断当前到底卡在哪一层，最快的办法是看"外文出现在哪里"。出现在浏览器自己的按钮和菜单上，是界面语言问题；出现在网页正文里，是请求头或翻译问题；出现在某些设置页的局部区域，那多半是下面要讲的 WebUI 本地化通道问题。

1.2 为什么设置了中文，设置页还是一半英文

这是最常见的"汉化不彻底"投诉。左侧导航是中文，点进去某个面板，标题是中文，下面的说明文字、按钮、下拉选项却还是英文，甚至同一个页面里中英混排。

原因在于 Chromium 的界面文字并不是从同一个地方取的。传统 C++ 绘制的界面（比如右键菜单、原生对话框）走的是编译进.pak资源包的字符串；而设置页、历史记录页、下载页这些用 HTML/JS 写的 WebUI 页面，走的是另一条完全不同的本地化链路。两条链路的资源来源、编译时机、加载方式都不同。当其中一条链路的中文资源缺失或不完整时，就会出现这种"一半一半"的诡异状态。

所以看到半汉化，先别急着怀疑"翻译质量"，大概率是资源包不完整。第 2 节会把这两条链路拆开讲清楚。

2. 语言包在 Chromium 内核里的真实形态

要理解汉化为什么有时会失效，得先知道"中文"在磁盘上到底长什么样。它不是一堆散落的文本文件，而是被编译成二进制资源包，以整数 ID 为键，程序运行时按 ID 查表取字符串。这个设计决定了：语言包必须和主程序严格配套，错一个版本就可能全盘失效。

2.1 从 .grd 源文件到 .pak 二进制包

源码层面的字符串写在.grd（XML 格式）或.grdp（分片）文件里，每条字符串有一个唯一的名字，比如IDS_SETTINGS_APPEARANCE。不同语种的译文放在同目录下的.xtb文件里，以名字为键对应。构建时，grit 工具会把这些内容编译成二进制.pak。

.pak的结构非常朴素：文件头记录版本号、条目数、别名数，后面是连续的条目表，每条记录一个 16 位资源 ID 和一个 32 位文件内偏移。取字符串时，程序拿 ID 二分查找偏移，再读出 UTF-16 编码的正文。正因为是"ID + 偏移"这种硬绑定，语言包和主程序之间不存在任何兼容性协商机制——版本对不上，取到的就是错位的数据。

下面这段脚本可以自己解析.pak的头和条目表，用来做语言包完整性对比。字段布局依据公开的 data_pack 格式编写，不同大版本可能有细微演进，以实际文件为准：

import struct def read_pak(path): with open(path, 'rb') as f: data = f.read() version, count, alias_count = struct.unpack_from('<III', data, 0) entries = [] off = 12 for _ in range(count): rid, foff = struct.unpack_from('<HI', data, off) off += 6 entries.append((rid, foff)) return version, count, alias_count, entries v, c, a, ents = read_pak('locales/zh-CN.pak') print(f'版本={v} 条目数={c} 别名数={a}') print('前5个资源ID:', [e[0] for e in ents[:5]])

拿它分别跑一遍zh-CN.pak和en-US.pak，对比条目数。如果中文包的条目数明显偏少，那基本可以断定这个包是残缺的——常见于被精简过的分发包，或者手动替换时拿错了文件。两边条目数接近、但界面仍有英文，那问题就在 WebUI 那条链路上，接着往下看。

2.2 locales 目录与语言标识的回退顺序

安装目录下的locales文件夹，就是所有界面语言包的老家。文件名遵循 BCP-47 风格：en-US.pak、zh-CN.pak、zh-TW.pak、ja.pak等等。程序启动时，会把配置里想要的语言标识翻译成对应的文件名去加载。

这里有个容易被忽略的细节：加载失败不会报错，而是静默回退。假设你指定了zh-CN，程序先找zh-CN.pak；找不到就退到父级zh.pak；再找不到就退到en-US.pak。整个过程用户无感知，界面直接变英文。这就解释了为什么"我明明设了中文，它就是不变"——设置是生效了，只是文件没找到，默默退回了英文，而界面上那个中文选项还好好地待在那儿。

回退链的存在也带来一个副作用：如果你把en-US.pak删了想强制中文，结果可能更糟——连回退目标都没有，某些版本会直接显示空的菜单文本或者资源 ID 原文。所以任何情况下都别动en-US.pak，留着它当兜底。

注意：locales目录里的.pak文件必须和主程序来自同一个版本。从别处拷来的、版本不同的语言包，轻则部分文字错乱，重则启动即崩。判断版本是否匹配，最省事的办法是看文件的时间戳和体积是否与主程序安装时间一致。

2.3 三条独立的本地化通道

把前面提到的现象串起来，Chromium 的本地化实际上有三条独立通道，各自独立又互不干扰：

第三条通道常被忽略：即使浏览器本体完全汉化，装了没带中文语言文件的扩展，扩展自己弹出的面板照样是英文。这不是浏览器的问题，也没法通过改浏览器设置解决，只能找带中文的扩展或者换一个。

而前两条通道虽然都打包进.pak，但编译来源不同。精简版分发包有时只保留了第二条所需的资源，导致原生菜单中文、设置页英文；也可能反过来。所以排查时先定位"哪一块没汉化"，能直接锁定是哪条通道出了问题。

3. 切换界面语言的四个入口及其优先级

搞清楚语言包在哪之后，接下来的问题就是"怎么让它加载我想要的包"。Chromium 提供了不止一条路径，不同路径之间存在明确的优先级关系，搞错优先级就会出现"我改了配置文件，怎么一点用都没有"的挫败感。

3.1 设置页里的语言列表选项

图形界面里最直观的入口是语言设置，里面有一个"以此语言显示浏览器"的选项，把中文加进列表并设为默认之后，提示重启。这个操作的本质是往配置文件里写一个"应用语言"字段，下次启动生效。

它的局限在于：这个列表里出现的选项，是由安装包在构建时声明的可用语言决定的，不一定和locales目录里实际存在的文件一一对应。见过一些精简分发版，列表里中文选项还在，但对应的zh-CN.pak早就被剔除了。你选了中文，重启，界面还是英文，而且毫无提示。这时候回看第 2.2 节的回退逻辑，一切就说得通了。

另一种情况是设置页改完之后没有任何反应。这通常是因为浏览器还有后台进程在跑——托盘常驻、后台应用继续运行之类的。配置文件在退出时才落盘，如果主进程没真正退出，改动会被覆盖回去。改语言之前，务必确认任务管理器里相关进程已经清空。

3.2 命令行开关的实际写法

命令行参数--lang的优先级高于配置文件，是排查时最有用的手段：它不改任何持久化状态，随用随弃，非常适合做对照实验。

三个平台的写法差别不小，直接抄：

# Windows：新建快捷方式，目标末尾追加（注意前面有空格） "...\browser.exe" --lang=zh-CN # macOS：首次启动传参 open -a "应用名" --args --lang=zh-CN # Linux：同时给环境变量和参数，避免只认其中一个 LANGUAGE=zh_CN.UTF-8 ./browser --lang=zh-CN

Windows 上更稳妥的做法是写一个批处理启动器，把参数固定进去。快捷方式有个坑：程序自动更新时经常会重建快捷方式，附加参数被一并抹掉，用户第二天打开发现又变回外文，还以为设置没保存。.bat或.cmd文件不会被更新流程动到，长期用更省心。macOS 上--args只在本次启动传递，不会写进配置，下次从 Dock 点开又是原样，所以要改持久化设置还是得回到设置页或者配置文件。

Linux 那行特意同时给了LANGUAGE环境变量。这块在不同发行版上行为不完全一致，有的版本优先读环境变量、有的优先读命令行参数，两个都给上能少走弯路。另外注意LANGUAGE用的是下划线加区域后缀的写法（zh_CN），而--lang用的是连字符（zh-CN），写成一样反而可能不生效。

3.3 直接改配置文件的姿势与风险

配置文件是 JSON，理论上可以直接改。位置在各平台的用户数据目录下，应用级语言偏好通常落在全局配置里，网页语言偏好则在每个用户档案目录下。具体字段名和位置随版本可能变化，改之前先备份。

直接改文件的收益是快、可脚本化、批量部署方便；风险是浏览器运行时会用内存里的状态覆盖磁盘，改完不退出等于白改。正确顺序永远是：完全退出 → 备份 → 改 → 启动 → 验证。

还有一个隐蔽的坑：JSON 文件末尾多一个逗号、少一个引号，浏览器读失败后会静默重建一份默认配置，你之前的书签栏设置、主页设置一起没了。所以改完先用编辑器的 JSON 校验功能过一遍，别嫌麻烦。我个人习惯是用脚本做字段级修改，改之前cp一份带日期后缀的备份，出问题三十秒回滚。

3.4 怎么确认到底哪个入口生效了

改完之后别靠肉眼猜，打开chrome://version这类内部信息页，看"命令行"那一栏。如果你是通过参数启动的，能看到完整的参数列表；如果参数没出现在这里，说明启动方式不对（比如快捷方式指向的不是真正的可执行文件，或者被更新程序重置了）。

同一页面还能看到用户数据目录的实际路径，这对判断"我改的配置文件到底是不是程序在读的那一份"极其关键。多用户档案、便携版、绿色版共存时，很容易改到一份根本没人读的配置上。我一般是先从这里抄出真实路径，再回头去改，能省掉大量无效试错。

4. 汉化不彻底的排查链路：从现象倒推根因

前面讲的是"怎么改"，这一节讲"改不动的时候怎么查"。汉化失败的形态其实很有限，把它们分个类，基本就能对着症状找到对应原因，不用一通乱试。

4.1 现象分型与对应根因

先上一个对照表，按症状定位会比较快：

这张表覆盖了绝大多数情况。实际排查时按"从上到下"的顺序走，因为越靠上的原因越常见，也越好验证。

4.2 从缺失到版本错位：两级排查

第一级排查是文件在不在。打开安装目录下的locales，数一数里面有几个.pak。只有en-US.pak一个，那答案已经很明显了——这就是个只带英文的分发版本。解决办法是找同版本的完整安装包，把zh-CN.pak拷进来，别从网盘随便找个"汉化包"塞进去，版本对不上一样白搭。

第二级排查是版本对不对。文件在，但界面显示资源 ID 或者乱码，基本就是版本错位。这里有个实用技巧：对比zh-CN.pak和en-US.pak的文件时间戳。同一次构建产出的文件，时间戳通常只差几秒到几分钟；如果两者差了好几个月，那中文包大概率是从别处拿来的旧文件。替换成同批次文件即可。

再往深一层，如果文件在、时间戳也对，界面还是半中半英，那就回到 2.3 节的三条通道去定位。这时候可以拿 2.1 节的解析脚本，把中文包和英文包的资源 ID 集合各导出一次，做差集。差出来的部分是英文包有、中文包没有的 ID，这些 ID 对应的界面元素必然显示英文。这个思路比盲目替换文件高效得多，也能量化出"汉化率"到底是多少。

4.3 字形缺失和乱码是两回事

这两种现象经常被混为一谈，但处理方式完全相反。

字形缺失的表现是：菜单项的位置、宽度都正常，就是文字变成了空心方块，或者干脆一片空白。这说明语言包加载完全成功，字符串也正确读出来了，问题出在渲染层——系统里没有能显示这些字符的字体。精简过的系统镜像、容器环境、某些定制发行版最容易出这个问题。装一套完整的中文字体，重启浏览器，立刻恢复。

乱码的表现是：字符位置有东西，但是一堆毫无意义的符号，或者字符错位。这是数据层面的问题，说明取出来的字节被按错误的方式解读了，根源是语言包与主程序不匹配，或者文件在传输过程中损坏。这时候查字体没用，必须换文件。

区分方法很简单：选中那串文字复制出来，粘贴到别的地方看。粘贴出来是正常中文，那是渲染问题；粘贴出来还是乱码，那是数据问题。这个判断动作只要两秒钟，能省掉大量无效折腾。

提示：还有一种特殊情况——只有某几个字显示异常，其他都正常。这通常是字体回退链在某个字符上没找到字形，退到了下一个字体。换一套覆盖更全的字体，或者调整字体回退顺序即可，不用动语言包。

5. 网页语言偏好：Accept-Language 与内置翻译的独立开关

界面汉化完成之后，还有一大批人卡在第二步：界面是中文了，但常访问的站点还是给英文页面，翻译提示也从来不弹。这两个问题都属于第 1.1 节讲的第二、第三套系统，跟界面语言没有半点关系。

5.1 Accept-Language 到底影响什么

浏览器每次发请求，都会带一个Accept-Language头，告诉服务器"我这边偏好哪些语言，优先级如何"。服务器据此决定返回哪个语言版本的页面，或者干脆返回 302 跳到对应语言的路径。

这个头的值来自网页语言偏好设置，格式是逗号分隔的加权列表，比如zh-CN,zh;q=0.9,en;q=0.8。q是权重，越接近 1 越优先。设置界面里把中文拖到最上面，本质上就是把它挪到这个列表的第一位。

它同时决定了两件事：一是发给服务器的请求头，二是页面脚本里navigator.language和navigator.languages返回的值。有些前端站点不看你请求头，直接读navigator.language做判断，所以两处必须一致，否则会出现"服务器返回中文、前端脚本又给你切成英文"的诡异现象。

配置时有个细节值得注意：这个设置是跟随用户档案的，不是全局的。多档案环境下，每个档案要单独配一遍。这也是为什么有人在主档案里配好了，切到工作档案又是英文，误以为是设置丢失。

5.2 翻译提示不弹的几个原因

内置翻译功能的触发条件是：页面加载完成 → 语言检测组件判断页面语种 → 与当前偏好语言比对 → 不一致则弹提示。任何一环断了，提示就不出现。

最常见的原因是语言检测组件缺失。这类组件在部分构建里是运行时按需拉取的，如果从来没拉到过，检测环节就直接跳过，表现为"什么页面都不弹翻译提示"。可在内部组件页里查看组件状态，缺失的话手动触发一次更新。

第二个原因是站点被加进了永不翻译列表。手动点过几次"不翻译此语言"之后，这个决定会被记住，之后再访问同类页面就不弹了。这时候去语言设置里把对应条目删掉即可恢复。

第三个原因是页面语种和偏好语种相同。这个不用处理，本来就不该翻译。

第四个原因比较隐蔽：某些页面是服务端渲染的，初始 HTML 里就带了lang属性声明了语种，浏览器据此判断，如果声明和实际内容不符（比如声明成中文、内容其实是英文），检测就会误判成"无需翻译"。这种情况属于站点自身的问题，浏览器层面没有太好的办法。

6. 把语言配置固化下来：便携化与长期维护

单次汉化不难，难的是让它一直保持。上面提到的所有"改了又变回去"的情况，根源都是配置没有真正固化。这一节讲怎么把它钉死。

6.1 启动器脚本与配置备份的组合

最稳的组合是"启动器脚本 + 配置文件备份"双保险。启动器保证每次启动都带正确参数，备份保证配置被意外重置后能秒回滚。

Windows 下的启动器大致这样写，注意路径里有空格必须加引号：

@echo off set BROWSER="C:\Program Files\App\browser.exe" start "" %BROWSER% --lang=zh-CN

把这个.bat固定到任务栏或者桌面，日常就从它启动。好处是更新程序不会动它，参数永远在。缺点是任务栏图标会变成批处理的图标，观感差一点，可以用工具改图标或者做一个不带窗口的启动器来解决。

配置文件备份我会写成一个简单的脚本，在每次浏览器大版本更新之后手动跑一次，对比备份和当前文件的差异，发现语言字段被重置就回滚。这个动作一年也就做几次，成本很低。

6.2 升级覆盖导致语言包丢失的预防

升级流程通常会把整个安装目录替换一遍，locales里的非默认语言包如果在旧版本里是手动添加的、原安装包本来就没有，升级后大概率消失。这不是 bug，是升级程序只保证"恢复出厂内容"。

预防办法有两个。一是把locales/zh-CN.pak单独备份一份在安装目录之外，升级完直接拷回去，注意必须是同版本的文件。二是在支持的平台上用符号链接，把locales目录整体指向一个不会被升级流程覆盖的位置，升级后只需替换链接目标里的文件。第二种更优雅，但 Windows 上创建符号链接需要额外权限，普通用户用第一种就够了。

升级之后的第一件事，建议就是打开内部信息页确认界面语言和版本号，顺便看一眼locales目录的文件数量。这个检查三十秒能做完，比等到用的时候发现全是外文再回头折腾强得多。

6.3 多机复用的实际做法

手上有多台机器、或者经常重装环境的话，把语言相关的配置抽出来做成一个可复用的包会省很多事。我把这套东西整理成一个目录，包含三样：同版本的语言包文件、启动器脚本、配置文件的语言字段片段。

新机器上部署的流程固定为：装同版本程序 → 拷贝语言包 → 运行启动器 → 打开内部页面验证 → 备份配置文件。整个流程五分钟以内，比在新机器上现场摸索快得多。关键是"同版本"这三个字，版本号一定要核对，宁可多一步检查，也别拿旧包硬塞。

最后再分享一个小技巧。判断一个语言包能不能用，不用进界面，直接用 2.1 节那段脚本读一下文件头：版本号、条目数、别名数能读出来，且条目数在合理范围内，这个包大概率没问题；读的时候直接抛异常，文件就是坏的。这个验证只要十秒，比反复重启浏览器高效太多。我个人在实际操作中的体会是，汉化这类问题九成以上不是"翻译缺失"，而是"文件放错了位置或者版本对不上"，把排查顺序理清楚，绝大多数情况看一眼文件就能定论，剩下的交给耐心就行。