前几天有个同事跑过来问我，说他们组在做数据核查，环境里只允许装 MongoDB Compass 的 Isolated Edition，界面全英文。刚入行的同学看 Connection、Collection 这些词还勉强，一进到 Schema 分析、Aggregation Pipeline 和 Explain Plan 就直接懵了，问我能不能把界面弄成中文。这事儿说起来不算玄乎，MongoDB Compass 本质是个 Electron 应用，界面文案打包在 app.asar 里，找到语言资源替换掉就行。但真动手做，坑比想象的多得多：解包路径对不上、JSON 编码带 BOM 直接白屏、重新打包后原生模块加载失败、macOS 上签名一改就打不开、升级一次全部还原。
这篇就把 MongoDB Compass Isolated Edition 汉化的完整链路掰开讲一遍。它不是那种“三步搞定”的爽文，而是一套可以反复复现的工程流程：从方案选型、路径定位、拆包、资源查找、术语统一翻译、回填、重新打包，一直到验证和升级维护。适合两类人看，一类是团队里负责搭数据环境、需要让非英语背景同事也能上手的人，另一类是对 Electron 应用结构好奇、想搞明白“桌面软件的字是怎么显示出来的”的开发者。哪怕你只是想改几个按钮上的字，前面的原理部分也值得扫一眼，因为后面所有的坑基本都是原理没吃透导致的。
1. 动手之前先搞清楚：Isolated Edition 到底是什么定位
1.1 它和普通版 Compass 的差别，比想象中更影响汉化
很多人拿到这个标题的第一反应是“汉化一个数据库 GUI 而已，能有多复杂”。真正影响汉化工作量的，不是翻译本身，而是 Isolated Edition 这个特殊版本的产品定位。MongoDB Compass 官方把它定位成面向受限环境的只读型图形客户端，核心思路是把所有可能改动数据的操作全部裁剪掉或者禁用掉，只留下查看、分析、诊断这条链路。也就是说，插入文档、更新字段、删除记录、创建或删除索引、导入数据这些入口，在这个版本里要么根本不存在，要么是灰的。
这个差异对汉化意味着什么？意味着你翻译的文本集合和普通版不完全一样。如果直接拿网上流传的普通版语言包套进去，会出现两种怪现象：一是很多键在 Isolated 版里压根没被引用，翻了一堆用不上的死文案；二是 Isolated 版特有的一批提示语，比如说明当前处于只读受限状态的警告条、被禁用功能的 tooltip，你在普通版语言包里根本找不到。所以我的第一条实操建议是：一定要从你自己机器上那份 app.asar 里提取原始语言文件，不要从任何别的地方复制。源文件只能来自你手上这个版本的安装包，这是后面所有步骤不出岔子的前提。
顺便说一句，标题里的 “lsolated” 是 “Isolated” 的常见手滑拼写，搜索资料的时候两种都试试，能翻到更多结果。这个版本在安装目录命名上和普通版也是分开的，Windows 下是MongoDBCompassIsolatedEdition，macOS 下应用名带Isolated Edition后缀，Linux 下包名同样带isolated。这个细节非常关键，因为网上绝大多数汉化教程写的是普通版路径，你照着抄一定找不到文件。
1.2 为什么值得花时间做一套汉化
有人会问，英文界面用久了不也习惯了。这个问题得看使用场景。如果是个人开发者，天天泡在里面，英文确实不是障碍，甚至查文档的时候中英文术语来回映射反而更顺。但如果是团队共用一套数据核查环境，情况就不一样了：临时来帮忙的业务方、刚转岗的分析同学、只偶尔进来查一条记录的测试同事，他们对 Collection 和 Document 的英文缩写没有肌肉记忆，界面上多一层语言转换，出错概率就上去了。
我在实际项目里见过的典型误操作是：把 “Projection” 理解成“项目”，把 “Explain Plan” 当成“解释计划”，然后在聚合管道里填错参数。这类错误不会报语法错，只会安静地返回一份不对的结果，排查起来特别费劲。汉化的价值不在于让人“看得舒服”，而在于降低术语理解偏差带来的隐性成本。尤其是 Isolated 版这种只读环境，用户往往不是数据库专家，而是来做数据核对和取证的，界面说人话，比什么文档都管用。
当然也要把成本讲清楚。汉化不是一次性的，Compass 每次大版本更新都会覆盖resources目录，你的替换成果会被冲掉。所以正确的心态是：把它当成一个需要跟着上游版本走的小工程，而不是装完就忘的一次性操作。想清楚这一点，后面第七节的维护流程你才会认真看。
2. 四条汉化路线横向对比，只有一条适合长期用
2.1 常见做法的优劣势拆解
在动手之前，我试过或者说评估过四种做法，这里做个横向对比，省得你一条条踩过去。需要说明的是，下表的判断基于 Electron 应用的一般结构和我自己的实测，不同版本的表现可能有细微差异。
| 方案 | 具体做法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 屏幕划词翻译 | 用系统或第三方划词翻译工具覆盖界面 | 零改动、零风险、重启即恢复 | 只翻译看得见的部分，菜单、提示、tooltip 抓不到；遮挡界面；术语翻译质量不可控 | 临时应急，看一两次就走 |
| 注入脚本替换 | 用开发者工具在运行时遍历 DOM 替换文本 | 不改安装包，改坏了刷新就恢复 | 每次启动都要重来，React 重渲染会把改过的文本冲回英文 | 调试期验证文案长度 |
| 替换语言资源文件 | 解包 asar，替换 locales 下的 JSON，重新打包 | 一次生效、全局覆盖、可版本管理 | 破坏签名、升级失效、需处理编码和占位符 | 长期使用，团队环境 |
| 从源码重新构建 | 拉上游仓库，改语言文件后自行打包 | 最彻底，可深度定制 | 依赖链极重、构建耗时长、产物和官方包不完全一致 | 有前端工程能力且要做发行级定制 |
我自己的结论很明确：替换语言资源文件这条路是性价比最高的。它的核心优势不是“改得干净”，而是“可版本化”——你可以把改好的 JSON 放进内部代码仓库，每次 Compass 升级后，用 diff 对比新旧语言包的键变化，只补新增的条目，而不是从头再翻一遍。这个能力在长期维护中价值巨大。
2.2 为什么我不推荐从源码构建这条路
单独说一下为什么排除源码构建。Compass 是一个多包仓库结构，里面拆了几十个独立的 npm 包，构建过程要装一堆原生依赖，还要处理 Electron 的版本对齐。我在一台配置还不错的机器上试过完整构建，光是依赖安装加编译就耗掉了大半个小时，中间还需要处理几次原生模块的编译失败。为了改几十行字符串付出这个代价，实在不划算。
更要命的是构建产物和官方安装包并不完全等价。官方包做过一些压缩、裁剪和签名处理，你自己构建出来的版本体积更大，某些在官方包里被 tree-shaking 掉的模块会留在产物里。这就导致一个尴尬局面：你在自己构建的版本上验证通过的汉化，放到官方包里可能因为文件结构不同而失效。所以我建议把精力集中在“改官方包的资源”上，思路简单，链路短，出问题也容易定位。
提示：无论选哪条路，都建议只在内部自用范围内修改，不要把改过的安装包对外分发。软件许可协议里对再分发修改版通常有明确约束，这一点务必自己确认清楚。
3. 准备工作：路径、版本和备份，一步都不能省
3.1 三个平台上 Isolated 版的安装目录定位
这是整个流程里最容易卡住的地方，因为网上教程清一色写的是普通版路径。下面是 Isolated Edition 三个平台的实际位置，注意目录名里都带Isolated或isolated标识。
| 平台 | 安装根目录 | app.asar 完整路径示例 |
|---|---|---|
| Windows | %LOCALAPPDATA%\MongoDBCompassIsolatedEdition\ | ...\app-1.40.0\resources\app.asar |
| macOS | /Applications/MongoDB Compass Isolated Edition.app/ | .../Contents/Resources/app.asar |
| Linux（deb/rpm） | /usr/lib/mongodb-compass-isolated-edition/或/opt/MongoDBCompassIsolatedEdition/ | .../resources/app.asar |
Windows 上要注意一个细节：%LOCALAPPDATA%下面是按版本号分目录存的，形如app-1.40.0、app-1.41.2。如果你装过多个版本，这里会有多个文件夹，只有当前正在使用的那一个目录才是有效的，另外几个是旧版本残留。判断方法很简单，看目录的修改时间，或者对比主程序目录里的版本信息文件。别对着一个废弃的旧目录改半天，启动起来发现没变化，这种乌龙我见过不止一次。
macOS 上的路径里带了空格，所有命令行操作都必须加引号，否则 shell 会把MongoDB Compass Isolated Edition.app拆成四个参数，报一堆莫名其妙的错。Linux 上如果用的是 AppImage 分发形式，则需要先解包再操作，路径会落在临时挂载目录里，相对麻烦一些，建议优先用 deb 或 rpm 包安装。
3.2 版本号确认与备份策略
动手第一件事：确认版本号。打开 Compass，菜单里找“关于”入口，或者直接看安装目录下app-<版本号>这个文件夹名。把版本号记下来，后面写维护文档要用。
第二件事，也是最重要的一件事：备份。把resources目录下的app.asar复制一份，命名为app.asar.bak放在同目录，或者复制到桌面。这个动作看起来多余，但当你改到一半发现程序起不来、又忘了原始文件长什么样的时候，它就是救命稻草。
我的习惯是双备份：一份原封不动的app.asar.bak放在resources旁边，另一份打包成压缩文件放到项目归档目录，文件名带上版本号，比如compass-isolated-1.40.0-original.zip。理由很实在——原件放在原地有个风险，某些安装器在升级时会清理resources目录，顺手把你的备份也删了。归档到外面那份才是真正的保险。
3.3 Node 与 asar 工具链准备
asar 是 Electron 官方提供的归档格式工具，本质上就是把一个目录打包成单文件。现在推荐的包名是@electron/asar，老的asar包已不再维护，但命令形式几乎一样。
# 安装（建议全局，方便复用） npm install -g @electron/asar # 验证安装 asar --version如果机器上没有 Node 环境，也可以用npx临时调用，省去全局安装：
npx @electron/asar list "app.asar"需要提醒的是，Node 版本不要用太老的。我遇到过 Node 14 环境下 asar 解包大文件时内存溢出，换成 18 以上就正常了。另外 Windows 上如果用的是 PowerShell，路径里的反斜杠和引号处理容易出问题，稳妥做法是cd到resources目录再执行命令，路径只写文件名。
4. 拆包与资源定位：把语言文件揪出来
4.1 解包 app.asar 的正确姿势
先确保 Compass 完全退出。Windows 上光关窗口不够，检查任务管理器里有没有残留进程；macOS 上检查活动监视器。文件被占用时解包会报读取失败，这个错误信息很不直观，容易误判成文件损坏。
# 进入 resources 目录 cd "C:\Users\<你的用户名>\AppData\Local\MongoDBCompassIsolatedEdition\app-1.40.0\resources" # 先看结构，不落盘，速度很快 asar list "app.asar" > filelist.txt # 正式解包到同级目录 asar extract "app.asar" "./app-unpacked"先跑list这一步很有必要，因为app.asar动辄一两百兆，解包要花几十秒，先看看里面有什么能省不少时间。解包出来的app-unpacked目录结构大致是：dist/（主进程和渲染进程的打包产物）、node_modules/（依赖包）、package.json（入口声明）、以及各种静态资源。
注意：
resources目录下可能还有一个app.asar.unpacked文件夹，里面放的是原生模块的.node二进制文件。这个目录在重新打包时不要动，它不是 asar 的一部分，而是与之平级的独立目录。把它误删会导致 Compass 启动时找不到原生模块，直接崩溃。
4.2 定位语言资源的两条实战路径
打开filelist.txt，搜索关键词。这一步的搜索词要选对，建议同时试这几个：locale、i18n、en-US、translation。
# Linux / macOS 下直接 grep 文件清单 grep -i "locale\|i18n\|en-US" filelist.txt结果通常分两种情况，这两种情况的处理方式完全不同，一定要先判断清楚。
情况一：找到独立的语言 JSON 文件。典型路径形如node_modules/@mongodb-js/compass-i18n/locales/en-US.json或dist/i18n/en-US.json。这是最理想的情况，直接改这个 JSON 就行，改完打回去，风险最低，效果最好。
情况二：找不到独立 JSON，文案被内联进了打包产物。这说明构建时把语言包直接编译进了dist/renderer.js之类的 bundle 里。这时候就要用内容搜索来定位：
grep -rn "Explain Plan" ./app-unpacked/dist/ | head -20如果命中的是renderer.js这种几兆大小的压缩文件，说明文案以字符串字面量形式嵌在里面。这种场景下的修改要用精确的查找替换，风险明显更高，因为压缩后的代码里字符串和逻辑混在一起，一个引号处理不当整段就废了。我的建议是：如果是情况二，先评估值不值得做，实在要做的话每次只替换几个高频关键术语，逐批验证，不要一次性全改。
4.3 语言文件结构剖析与占位符陷阱
假设我们运气不错，属于情况一。打开en-US.json，结构一般是扁平或两层的键值对：
{ "Connection": { "Title": "Connect to", "Button": "Connect", "Error": "Failed to connect to {{host}} after {{count}} attempts" } }翻译原则很明确：只动值，不动键。键是程序用来查找文案的索引，改了键程序就找不到对应文本，界面上会直接显示原始键名，比如Connection.Button这种，比英文还难看。
占位符是这里最大的坑。上面那个例子里{{host}}和{{count}}是运行时注入的变量，翻译时必须原样保留，位置可以调整但要完整。我见过有人在翻译时把{{count}}顺手改成{{次数}}，结果界面显示成一个字面量花括号。除了双花括号，常见的占位符形式还有%s、%d、{0}、${name}，翻译前先全文扫一遍，把所有占位符列出来，翻完逐个比对，这是最稳妥的校验方式。
还有一个细节是复数形式。很多语言包用_one、_other这样的后缀来区分单复数，中文没有这个概念，但键不能删——删了程序在特定数量下会找不到文案。正确做法是把_one和_other都翻译成同一句中文。这个处理看起来很傻，但确实能避免边缘场景下的界面错乱。
5. 翻译环节：术语统一是汉化质量的分水岭
5.1 一份够用的 MongoDB 术语对照表
汉化质量高低，八成取决于术语是否统一。同一个 Collection，如果这个页面叫“集合”，那个弹窗叫“表”，用户会以为是两个不同的东西。下面这份对照表是我在自己的语言包里固化的约定，直接抄就行。
| 英文原文 | 统一译法 | 说明 |
|---|---|---|
| Connection | 连接 | 统一用“连接”，不用“联接”“连结” |
| Database | 数据库 | |
| Collection | 集合 | 坚决不用“表”，这是关系型数据库的说法 |
| Document | 文档 | 不用“记录”，避免和关系型概念混淆 |
| Field | 字段 | |
| Index / Indexes | 索引 | |
| Aggregation | 聚合 | |
| Pipeline | 管道 | |
| Stage | 阶段 | 聚合管道里的单个处理环节 |
| Schema | 模式 | “模式分析”指结构抽样统计 |
| Projection | 投影 | 不用“项目”，这个词坑最多 |
| Explain Plan | 执行计划 | 不用“解释计划” |
| Query | 查询 | |
| Replica Set | 副本集 | |
| Sharded Cluster | 分片集群 | |
| Shard Key | 分片键 | |
| Read Preference | 读偏好 | |
| Write Concern | 写关注 | Isolated 版中多见于只读提示 |
| Validation | 校验 | |
| Sampling | 抽样 | Schema 分析场景高频出现 |
这张表的价值在于它是“约定”，一旦定下来就不要随心情改。团队多人协作时，我会把它单独存成一个文件放在语言包仓库根目录，谁补翻译都要对照着来，过不了评审就打回。
5.2 按钮文案和长句的处理策略
界面文案分两类，处理方式完全不同。第一类是短文案，按钮、菜单项、标签页名称。这类文案受布局严格限制，英文 “Disconnect” 翻成“断开连接”四个字，在某些窄按钮里会被截断成“断开连……”。我的经验是按钮类文案尽量控制在四字以内，“连接”“断开”“刷新”“导出”这种动词加名词的精简表达最保险。翻完之后一定要专门跑一遍界面，把每个按钮都点开看看有没有被切掉。
第二类是长句，提示语、错误信息、说明性文字。这类文案的难点不在字面翻译，而在语序和上下文。英文喜欢把条件放后面，中文习惯把条件放前面。比如 “This operation is not supported in the isolated edition” 直译是“此操作在隔离版本中不被支持”，读起来别扭，改成“隔离版本不支持此操作”就顺多了。这类改写不违背原意，但阅读体验差别很大。
还有一类是变量插在句子中间的长句，比如带时间段、带数量的提示。这类句子翻译时要先把中文句子骨架搭好，再把占位符嵌到合适位置，最后通读一遍确认读起来不别扭。不要按英文语序硬塞占位符，否则会出现“在 {{count}} 秒后连接将会被断开”这种半洋半中的表达。
5.3 JSON 合法性与编码的两个致命细节
翻译文件保存时有两个细节能让程序直接白屏，必须记牢。
第一个是编码。必须是 UTF-8，且不能带 BOM。Windows 上用记事本另存为时，默认可能勾上“UTF-8 带 BOM”，这个 BOM 是文件开头三个不可见字节，JSON 解析器看到它会直接抛语法错误。表现就是程序启动后一片空白，控制台也看不到明显报错，极难排查。我的做法是全程用 VS Code 或 Sublime 编辑，右下角确认编码显示为UTF-8而不是UTF-8 with BOM。
第二个是 JSON 语法。中文标点是最常见的问题，逗号写成全角，、引号写成中文引号，都会让整个文件解析失败。还有一个隐蔽问题：译文里如果包含双引号，必须转义成\"，不能直接写。文件改完后先做一次语法校验，这一步能省掉大量调试时间：
node -e "JSON.parse(require('fs').readFileSync('en-US.json','utf8')); console.log('JSON OK')"这条命令跑通，说明文件至少是合法的，可以进入下一步。跑不通的话，报错信息里会带字符位置，顺着位置找过去基本都能一眼看出问题。
提示：翻译过程中建议保留原始的英文值作为注释来源，但在正式的 JSON 里千万别加
//注释，标准 JSON 不支持注释，加了就解析失败。要记录对照关系，单独建一个映射表文件。
6. 重新打包与替换：这一步最容易翻车
6.1 asar pack 的正确参数与检查项
语言文件改好、校验通过后，把整个目录重新打包：
# 从解包目录重新打包 asar pack "./app-unpacked" "./app.asar.new"打包完成后别急着替换，先做两项检查。第一项，对比新旧包的文件数量，数量差太多说明打包时漏了文件，通常是漏了隐藏文件或者node_modules下的深层目录：
asar list "app.asar" | wc -l asar list "app.asar.new" | wc -l第二项，抽查关键文件是否在新包里存在。确认之前定位到的那个语言 JSON 仍然在原路径下，且内容确实是你改过的版本。这两步花不了一分钟，但能挡掉绝大多数“打回去还是英文”的情况。
确认无误后关闭 Compass，执行替换。Windows 上是覆盖同名文件，如果提示文件被占用，回到任务管理器确认进程真的退干净了。macOS 上同样是覆盖Contents/Resources/app.asar。
6.2 macOS 签名与 Windows 权限的额外处理
macOS 上有个绕不开的问题：修改.app包内的任何文件都会破坏原有代码签名，系统会认为应用已被篡改，直接拒绝启动或者提示已损坏。这在内部自用场景下的处理方式是做一次本地临时签名：
codesign --force --deep --sign - "/Applications/MongoDB Compass Isolated Edition.app"--sign -表示使用临时签名（ad-hoc），不依赖任何证书。这个操作只是让系统认可“这个包我改过，但我接受”，适用于自己机器上的内部测试环境。需要强调的是，这种做法只适合内部自用，任何形式的对外分发都要走正式的签名流程，这是合规底线。
Windows 上相对省事，但有两个注意点。一是某些安全软件可能会拦截对AppData目录下可执行程序资源的替换，如果替换后程序行为异常，先检查是不是被隔离了。二是替换时最好用管理员权限的资源管理器或者命令行，避免权限不足导致文件只写了一半。写到一半的 asar 是彻底损坏的，程序连启动画面都出不来。
6.3 首次启动的验证清单
替换完成后启动 Compass，按下面的顺序逐项确认，出问题时能快速定位到是哪一环坏了。
| 检查项 | 预期表现 | 异常含义 |
|---|---|---|
| 程序能否启动 | 正常出现主窗口 | 起不来 → asar 打包损坏或文件缺失 |
| 是否白屏 | 界面元素正常渲染 | 白屏 → 语言 JSON 语法错或带 BOM |
| 文案是否生效 | 出现中文文本 | 仍是英文 → 语言文件路径不对或未生效 |
| 界面是否有原始键名 | 无xxx.yyy形式文本 | 出现键名 → 翻译时误改了键名 |
| 按钮是否被截断 | 文字完整显示 | 被切 → 译文过长，需要精简 |
| 功能是否正常 | 能连库、能查文档 | 功能异常 → 误改了逻辑代码而非文案 |
我特别强调“界面是否有原始键名”这一项，因为它是翻译事故最典型的信号。一旦看到形如Connection.Button.Connect这种文本，说明你在某个环节改名了键，回头用备份的原始 JSON 做一次键名 diff，很快就能找到问题。
7. 踩坑记录与排查速查表
7.1 典型故障现象与根因对照
下面这份表是我自己在做汉化和后续维护中真实遇到过的，按出现频率排序。
| 现象 | 大概率根因 | 处理方式 |
|---|---|---|
| 启动后白屏 | JSON 带 BOM 或语法错误 | 用 node 校验，重新另存为 UTF-8 无 BOM |
| 程序直接闪退 | asar 打包时文件缺失或结构错乱 | 用备份回滚，重新解包核对文件数量 |
| 界面部分中文部分英文 | 文案在多个 bundle 里，只改了一处 | 全局 grep 未翻译的英文，逐个定位 |
| 提示找不到原生模块 | 误删了app.asar.unpacked目录 | 从备份恢复该目录，不要重新打包 |
| 升级后全部变回英文 | 安装器覆盖了resources | 按维护流程重新应用语言包 |
| macOS 提示应用已损坏 | 签名被破坏 | 执行本地临时签名后重启应用 |
| 某些 tooltip 仍是英文 | 文案硬编码在第三方依赖里 | 评估收益，通常不值得为此改依赖 |
| 服务端返回的报错是英文 | 错误信息由数据库服务端生成 | 无法汉化，属于正常现象 |
这里要专门说一下“服务端报错是英文”这条。很多人第一次做汉化，改完之后发现查询报错还是英文，以为没改成功，来回折腾。实际上这类信息是数据库服务端返回的，客户端只是原样展示，跟语言包没关系。想让它显示中文，得在服务端层面处理，那是另一个话题了。同理，图表库的 tooltip、部分第三方组件的内置文案、浏览器内核层面的右键菜单，都属于客户端改不到的地方，接受它就好。
7.2 升级后的失效处理与版本跟随机制
Compass 的升级机制会完整替换resources目录，这是汉化成果被冲掉的直接原因。所以维护流程的核心不是“防止升级”，而是“升级后快速恢复”。
我的做法是建一个内部小仓库，目录结构长这样：locales/下按版本号存en-US.1.40.0.json、en-US.1.41.2.json，根的README里写清楚当前生效版本和实施步骤。每次 Compass 升级后，先解包新版本，提取新的en-US.json，然后跑一次键对比：
# 对比新旧版本有多少新增键 node -e " const a = require('./locales/en-US.1.40.0.json'); const b = require('./locales/en-US.new.json'); const flat = (o, p='') => Object.entries(o).flatMap(([k,v]) => typeof v === 'object' ? flat(v, p+k+'.') : [p+k]); const sa = new Set(flat(a)), sb = new Set(flat(b)); console.log('新增:', [...sb].filter(k => !sa.has(k)).length); console.log('删除:', [...sa].filter(k => !sb.has(k)).length); "这条脚本输出两个数字，新增多少键、删除多少键。通常小版本升级只新增十几个键，几分钟就能补完；大版本可能有几十个，需要多花点时间。这种增量维护的方式，比每次从头翻译一遍要省力得多，也更不容易出错。
还有一个容易被忽略的点：保留一份原始英文包。不要只存中文版，英文原件要一直留着。原因很简单，翻译过程中难免有理解偏差，回头想确认原文到底怎么说的，没有原件就只能重新解包，而那时候你可能已经升级到新版本了，原文对不上。
提示：如果你的团队用配置管理工具统一部署数据环境，可以把“解包 → 替换语言文件 → 打包 → 签名”这一串操作写成一个脚本，跟版本号绑定。需要说明的是，这类脚本只在内部环境自用，不要对外传播。
8. 汉化之外，让团队真正用起来的两件小事
8.1 一份内部速查卡比完整汉化更有效
做完汉化之后我发现一个有意思的现象：就算界面全中文，新同事该不会用还是不会用。原因是语言只是表层，真正卡人的是对概念的理解。比如“模式分析”翻成中文了，但他不知道这个功能是在抽样统计字段类型分布，还是不知道抽样比例会影响结果准确性。
所以我在汉化之外加了一步：做一张 A4 大小的速查卡，把最常用的六七个操作路径画出来，配上中英文对照。比如“查看集合结构 → 点击集合名 → 选择 Schema 标签页 → 调整采样条数”，每一步都标注对应的英文原词。这张卡的效果比汉化本身好得多，因为它是面向任务的，而不是面向界面的。汉化解决“看得懂”，速查卡解决“会操作”，两件事不能互相替代。
8.2 把语言包当成一个需要维护的小项目
最后一个想说的是心态问题。很多人把汉化当成一次性任务，做完就扔，结果下次升级全部重来，然后又得重新翻一遍，翻出来的版本还和上次不一致，术语开始漂移。这种反复折腾的成本远高于一次性的规范化投入。
正确的做法其实很朴素：语言包进版本管理，术语表进版本管理，实施步骤写成文档，每次升级按流程走一遍。整个体系搭起来也就半天时间，后面每次维护可能只要十几分钟。我在实际使用中体会到的是，凡是需要跟着上游版本走的事情，一开始就把它工程化，比事后补救省力太多。真要偷懒，最后一定是加倍还回去。
如果还想再往前一步，可以把语言包做成一个轻量的补丁包：只包含发生变化的键，配一个应用脚本自动合并到新版本的原始语言文件里。这样每次升级的维护成本能压到最低，也避免了手工比对时的疏漏。这个思路不仅适用于 Compass，任何基于 Electron 的桌面工具汉化，基本都能照这套流程走一遍，换的只是路径和文件名而已。
