小语种站点翻译文件管理：PO/MO、JSON 与 XLIFF 怎么选

发布时间：2026-10-02 08:43 更新时间：2026-10-02 08:43 阅读量：0

准备做一个小语种官网时，多数企业主会把注意力放在翻译质量和页面上线时间上，很少有人提前问一句：这些翻译内容以后存在哪里、由谁来改。结果往往是上线三个月后要改一句俄语促销语，才发现翻译文本散落在插件后台、主题文件、甚至某个同事的表格里，改一处要翻三四个地方。翻译文件格式的选择，本质上是在决定「以后改文案的成本有多高」。这篇文章不讨论程序怎么写，只帮负责人搞清楚三种常见格式分别适合什么场景，以及立项时该向团队交代哪些事。

如果先把结论摆出来：WordPress 站点通常绕不开 PO/MO，静态站更常见 JSON，而需要和外部翻译公司来回交付时，XLIFF 是更省事的中间格式。三者不是互相替代的关系，很多项目会同时用到两种。下面分节说明各自的脾气，以及项目推进时该怎么准备。

三种格式各自解决什么问题

PO/MO 是 GNU gettext 体系的一对文件。PO 是可读的源文件，翻译人员能直接打开编辑；MO 是编译后的二进制文件，程序运行时读取它来显示译文。WordPress 主题和插件的界面文字、部分静态生成工具，都走这套机制。它的好处是生态成熟，几乎所有翻译工具都支持；麻烦之处在于改完 PO 必须重新编译成 MO，忘记编译就会出现「明明改了却不生效」的经典问题。对负责人的含义是：要确认服务商交付的是不是编译后的成品，而不是只丢一个 PO 过来。

JSON 是键值对文本，常见于静态站和前端框架。它结构简单，一个键对应一句译文，程序读取方便，部署时和页面一起打包即可，不涉及编译步骤。代价是它不携带上下文说明，译者只看到一串键名，容易把「提交」翻成名词而不是按钮动词。静态站做小语种时，JSON 往往按语言拆成独立文件，比如 zh-CN.json、pt-BR.json，改哪个语言就动哪个文件，边界清楚。

XLIFF 是面向翻译流程交换的 XML 格式。它可以在每一段文字旁附带备注、术语、状态标记，适合把内容发给外部翻译公司再收回来。多数翻译平台导入导出都支持它。缺点是文件体积偏大，人眼直接读比较累，一般作为「中间站」使用，最终仍要转成 PO/MO 或 JSON 落到站点里。

WordPress 与静态站分别怎么选

WordPress 做小语种，界面层文字（按钮、表单提示、错误信息）基本由主题和插件的 PO/MO 决定，内容层文字（文章、页面、产品描述）则由多语言插件管理，通常存在数据库里。这意味着一个现实问题：内容翻译和界面翻译是两套东西，不要混在一起验收。签约前可以要求服务商说明，哪部分改动需要重新编译 MO、哪部分在后台直接编辑即可。站内已有 建站方案 页面按语言和站点规模做了分类，可以先对照自己的情况看一遍再定格式。

静态站没有数据库，所有文本都在文件里，所以 JSON 是自然选择。好处是版本可控，配合代码仓库能清楚看到哪一句在什么时候被谁改过；坏处是每加一种语言就要多维护一整套文件，语言数量一多，人工同步容易出错。如果计划做五种以上语言，建议在项目早期就把文件名和目录结构定死，别等到中途再重构。

还有一种常见组合：内容用 XLIFF 交给翻译公司，收回后由技术方转成 PO/MO 或 JSON 入库。这种流程对负责人最友好，因为翻译进度和术语表都在专业工具里留痕，后期换服务商也能接得上。

立项前要准备的清单

下面这份清单可以直接发给内部同事或外包团队，逐条确认后再开工，能省掉后期大量返工。

• 先列出站点有几种语言、每种语言大概多少页面，估算翻译文件的数量级，避免「先做两种语言再说」导致的后期结构返工。
• 明确哪些文字属于界面、哪些属于内容。界面文字走 PO/MO，内容文字走多语言插件或独立数据文件，两边的修改流程分开写清楚。
• 确认交付物形态：PO 要附编译后的 MO；JSON 要说明按语言还是按模块拆分；XLIFF 要约定版本和字段命名，具体以所用翻译工具官方文档为准。
• 约定翻译文件的存放位置和命名规则，例如按语言代码分目录，语言代码参照 ISO 639-1 与地区组合，与站点 hreflang 保持一致，减少后续对不上号的情况。
• 要求提供术语表，至少覆盖品牌名、产品名、行业专有词，避免同一词在不同页面出现不同译法。
• 约定验收方式：随机抽三个页面，切换到目标语言，检查按钮、表单提示、错误信息是否都跟着变；再改一句译文，确认改动能按约定流程生效。
• 问清楚后续维护报价方式，是按文件数、按字数还是按小时，以及紧急改一句话的最短响应时间。
• 把源文件和译文都纳入版本管理，至少保留一份可回溯的历史，方便出问题时定位是哪次改动引入的。

如果团队里有技术人员，可以让其验证一次实际流程，例如在本地检查 PO 文件能否正常编译。下面这条命令只是格式校验示例，实际路径和文件名按项目替换，具体参数以 GNU gettext 官方文档为准。

# 校验 PO 文件语法，不生成 MO，仅检查格式问题
msgfmt --check --check-accelerators="_" -o /dev/null locales/pt_BR.po

正式编译为 MO，供程序运行时读取
msgfmt -o locales/pt_BR.mo locales/pt_BR.po

静态站的 JSON 文件可以用任何文本编辑器打开检查，但要注意两点：键名不要用中文或空格，避免程序读取异常；保存时统一用 UTF-8 编码，否则小语种变音字符容易变成乱码。相关排版细节可参考站内 模板与定制风格 栏目中关于字符编码的说明。

需要提醒的是，翻译文件格式不会直接影响页面被搜索引擎收录的效果，它影响的是你后续维护的效率和出错概率。语言越冷门、后期改动越频繁的项目，越应该在格式和流程上多花半天时间约定清楚，这半天通常比上线后每次改文案都找人救火划算得多。

回到最开始的问题：PO/MO 适合 WordPress 这类有成熟 gettext 生态的系统，JSON 适合结构简单的静态站，XLIFF 适合需要和外部翻译方反复交付的场景。选型时先看团队以后改文案的路径顺不顺，再决定用哪种。把上面那份清单走完一遍，项目推进时该问谁、该要什么交付物基本就清楚了。

准备做网站，先从哪一步开始？

如果你希望把上面的思路落到自己的行业与目标市场，可以先看 建站方案 了解一站式流程，再对照 客户案例 判断哪些做法适合自己的业务；也可以加微信 tsrz001 沟通需求，把页面结构、预算和排期先聊清楚再动手。

继续阅读