宿主侧生成翻译文件的流水线

【踩坑实录】宿主侧生成翻译文件的流水线

▍现象
天文软件工程做全量汉化：上游的翻译源文件（po 格式，八个域）在手，目标格式是 Qt 的二进制翻译文件（qm）。第一版方案想当然：把转换工具链打进应用包，首次启动时在设备上转换——设备侧转换失败（工具链的依赖与目标环境不合），启动变慢，转换结果偶发不全。

▍定位过程
问题出在把构建期任务搬到了运行期：翻译源到目标格式的转换是纯静态计算（源文件不变结果不变），运行期做没有任何收益，还引入目标环境的工具链依赖。正确姿势是宿主侧（构建机）完成转换，产物随包分发。工程定稿的流水线：构建期用转换工具把八个域的 po 源转成一个中文 qm 文件，随包分发，应用启动时直接加载——状态栏、信息面板、设置对话框、天文计算器全部中文生效。

▍根因
混淆了构建期任务与运行期任务。判据很简单：输入不变输出不变的计算，都该在构建期做（翻译转换、资源压缩、索引构建）；依赖运行时状态的才留运行期（用户偏好、动态内容）。

▍对策
流水线固化进构建脚本：源翻译文件的获取（上游同步）、转换（宿主工具）、产物入包（资源目录）、加载验证（构建后冒烟检查中文界面）。上游更新时流水线重跑，新增字符串的翻译缺口在构建期暴露（对比源串数与译串数）。

▍延伸坑位
宿主工具与目标工具的分界（交叉构建篇讲过：宿主侧跑的工具用宿主版，别被交叉工具链误编）；翻译文件的多域合并（不同界面的翻译域合并时的优先级）；缓存失效（qm 的版本键与代码版本绑定，代码改了翻译没重转会加载旧文案）。

▍方法论沉淀
静态计算前移到构建期——这条纪律在翻译、字体、索引、压缩四类资源上全部适用，天文工程的翻译流水线是标准样板。

构建期翻译流水线的完整记录在天文工程实录，apps 板块 56 篇欢迎对照。