比特币核心界面里的中文提示不是程序员顺手打上去的，它要走完一条从源码到翻译平台再回编译的流水线。看懂这条流水线，能回答一类很具体的问题：为什么某句新加的报错在中文界面里仍是英文、为什么翻译偶尔整批回退、为什么测试网里看到半中半英的混搭。本文机制描述以比特币核心 v31.0 源码树与仓库文档为准。
字符串是怎么被标记的
按仓库文档 translation_strings_policy 的约定，图形界面源码（src/qt 目录下）里要翻译的文字用 tr 函数包裹；非界面的核心代码（src 下）用下划线加括号的宏包裹。这些包裹不改变字符串内容，只是给抽取工具做记号。核心代码里还有一类 TRANSLATE_NOOP 写法：字符串出现在源码里但从不调用翻译函数，纯粹等着被抽取工具收进目录——启动日志、初始化提示这类文本常走这条路，翻译好了供界面或日志展示。
从源码到 en.ts 再到各语言
抽取的工具链在文档里写得很清楚：脚本从 Qt 与非 Qt 源码里收集字符串，用到 gettext 与 Qt SDK 自带的 lupdate，产出 src/qt/locale 下的 bitcoin_xx_YY 格式翻译文件。其中 bitcoin_en.ts 有特殊地位：它是所有其他语言的母本，源码文案一有变动，它必须先更新。构建系统里有一个 translate 目标，跑一条 cmake 命令把这些生成步骤串起来。也就是说，英文母本是机器生成的，人工翻译追在其后。
Transifex 上的志愿者流水线
翻译管理平台用的是 Transifex，仓库文档明确写着平台监控 GitHub 仓库、发现新的待翻译字符串后自动同步，拉取合并之后可能要几个小时才出现在网页界面里。翻译志愿者在平台上逐条填译文，攒够进度的语言包再被拉回代码仓库，编译进发行版。这个节奏决定了两个常见现象：新文案上线初期，所有语言都暂时显示英文原文，这是正常时滞而不是 bug；某个语言的翻译质量波动，取决于当期志愿者投入，与项目本身没有关系。
界面之外的文字不在流水线里
值得划清边界：只有面向用户、且按上文规则标记过的文字进入这条流水线。开发者脚本、RPC 返回里的技术性错误串、以及政策文档里明确豁免的极端罕见技术错误，不做国际化处理。RPC 的报错文本从设计上就是英文常量，任何语言的客户端看到的都一样，这也是为什么各家钱包的链上错误通常保持英文原样——翻译会破坏程序对错误文本的匹配。
一个自检小实验
想亲眼看看这条流水线的接缝，可以翻开发行版的安装目录：语言文件编译成二进制的 qm 资源；在源码树里搜某个界面上见过的中文句子，它不会在源码里，只能在 locale 目录的对应语言 ts 文件里。反过来，在某语言 ts 文件里搜一句新版报错，多半找不到，或者标着 unfinished——这就是你界面里看到英文的那句话的全部身世。
译者常见的三个误区
第一，把 RPC 错误串也翻译了：程序靠文本匹配分支，译后字符串会让逻辑失灵，政策文档对技术错误也作了豁免。第二，改了 en.ts 而不改源码：母本由抽取脚本维护，手工改动会在下一次生成时被覆盖。第三，术语不统一导致同一概念在菜单里三个译法：平台上有术语表机制，动手前先查再译，这比个人语感重要。
为什么有些文字永远保持英文
流水线的入口条件决定了覆盖面：没有被翻译宏包裹的字符串，抽取工具根本看不见它们；面向开发者的目录、文档和脚本，政策上明确不做国际化。这带来一个实用推论——自动化程序可以安全匹配 RPC 与日志里的英文常量，不会因为用户切换界面语言而失配；真正会随语言变化的是图形界面文案与启动过程提示，人读的部分可以本地化，机读的部分保持原样。
风险提示：本文描述开源项目的工程流程，不构成任何投资建议；流水线细节随版本调整，以仓库当时的文档与源码为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。