企业官网建设流程全解析

上周朋友发来一张截图，Yandex 浏览器装好之后，菜单栏一半俄文一半英文，他上来就问：“汉化包是不是没装对？是不是得自己找语言包？”我第一反应也是骂这软件抠门，但把安装目录整个翻了一遍之后发现，中文语言包其实就躺在locales目录里，真正不显示中文的原因，是 Yandex 对语言环境的判定逻辑跟 Windows 系统语言并没有完全绑定。这篇就把我这次折腾 Yandex 语言包汉化的过程完整写出来，从文件格式到提取翻译，再到回填生效，每一步都说清楚。

先说明一下，这篇文章说的“汉化”，不是指给网页内容做全文翻译那种，而是把 Yandex 浏览器或相关客户端软件本身的界面语言资源改写成中文。Yandex 桌面产品线基本都复用 Chromium 那套本地化框架，学会处理这一套，以后遇到 vscode、figma、postman、eclipse 这类工具的汉化需求，思路也完全通用。

1. 先搞清 Yandex 的语言包结构，再谈汉化

1.1 界面显示俄文，不一定是语言包缺失

很多人遇到 Yandex 界面不是中文，第一反应就是“这软件没带中文包”。实际上多数情况下，中文语言资源是存在的，只是加载优先级问题。

Yandex 浏览器基于 Chromium，它的语言选择顺序大致是这样的：

1. 优先读启动参数里的--lang。如果启动时没带这个参数，它就会往下找。
2. 读用户偏好设置文件里的intl.app_locale字段。你在设置页里手动切过语言，这个字段就会写进去。
3. 继续往下走，根据系统区域设置或者 IP 归属区域做猜测。

问题就出在第三步：如果 Windows 系统区域是英文或者俄文，Yandex 启动时会直接采用猜测结果，这时候就算安装包里带着zh-CN.pak也不会主动加载。所以，很多情况下不是“没有中文包”，而是“没让它用中文包”。

1.2 安装目录里哪些文件算语言包

Yandex 的语言资源大致由三部分构成，在修改之前必须先分清谁是谁。

其中locales目录是最重要的。正常安装的 Yandex 浏览器里，这个目录下会有一堆.pak文件，包括zh-CN.pak（简体中文）、zh-TW.pak（繁体中文）、en-US.pak、ru.pak等。你可以先去这个目录检查一下，确认zh-CN.pak是否存在。如果存在，说明语言包资源完整，问题大概率出在配置；如果不存在，那就需要走完整的提取和回填流程。

1.3 判断“缺包”还是“没启用”的笨办法

在动手改文件之前，我建议你先做一个最小验证：用命令行方式强制指定语言。

找到 Yandex 的安装路径，复制一份快捷方式，在目标末尾加上：

"<你的安装目录>\yandex.exe" --lang=zh-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 语言包拆开后，字符串数量可能达到几千条甚至上万条，如果一开始就想全部翻译完，大概率搞到一半就放弃。我的经验是先做“用户看得见”的部分。

优先级从高到低排下来大概是：

1. 主菜单、右键菜单、标签页标题、地址栏按钮。
2. 设置页、扩展管理页、下载管理页。
3. 弹窗通知、错误提示、内部页面文字。
4. 隐藏较深的帮助文档和开发者工具。

实际操作时，可以先用文本编辑器打开拆包后的主要字符串文件，用“查找”方式定位关键词，比如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-CN

4.1 直接替换 .pak 文件

翻译完成后，关键一步是把翻译后的内容重新打包成.pak文件，然后覆盖回原目录。

具体流程是：

1. 用 pak 工具重新打包翻译后的 JSON 文件，生成新的zh-CN.pak。
2. 备份原文件。
3. 用新文件覆盖Application\<版本号>\locales\zh-CN.pak。
4. 完全退出 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。修改前先退出浏览器，否则退出时配置会被重新写回，你改的东西就白费了。

第二步，在启动快捷方式里加上参数：

--lang=zh-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，可以避免九成以上的乱码问题。