一份文件，五种格式：如何让你的 WordPress 翻译面向未来

你花了三周时间将你的 WordPress 主题翻译成西班牙语。该 .po 文件是完美的 —— 每个字符串都经过审查，每个变量都完好无损，每个复数形式都正确。然后你的客户决定从经典的 PHP 主题迁移到带有 React 前端的无头设置。

突然你的 .po 文件变得毫无用处。React 应用程序需要 .json。旧的 PHP 小部件仍然需要 .mo。处理移动应用程序的自由职业者想要 .xliff。而且没有人有时间将 4,000 个字符串重新翻译成三种不同的格式。

这不是一个极端情况。这是现代 WordPress 开发的现实，主题附带 PHP 和 JavaScript 组件，插件混合使用 Gettext 和 i18next，并且客户更改架构的频率比他们更改密码的频率更高。

为什么翻译文件格式比以往任何时候都重要

五年前，WordPress 翻译很简单。你有一个 .po 文件（人类可读的源文件）和一个 .mo 文件（编译的二进制文件）。就是这样。每个主题、每个插件、每个翻译工具都使用相同的语言。

如今，WordPress 生态系统在生产中使用至少五种翻译文件格式：

你需要了解的五种格式

.po (Portable Object) —— GNU Gettext 使用的人类可读的源格式。包含原始字符串 (msgid) 及其翻译 (msgstr)。这是翻译人员编辑的内容。

msgid "Add to Cart"
msgstr "Anadir al carrito"

msgid "Your order has been shipped to %s"
msgstr "Su pedido ha sido enviado a %s"

.mo (Machine Object) —— .po 文件的编译二进制版本。WordPress 在运行时使用 load_textdomain() 读取 .mo 文件。比在运行时解析 .po 更快，但不可人工编辑。

.json (JavaScript Object Notation) —— 由 wp_set_script_translations() 用于 Gutenberg 区块、React 组件和现代主题中基于 JavaScript 的翻译。WordPress 期望具有 locale_data 键的特定 JSON 结构。

{
  "locale_data": {
    "flavor-starter": {
      "Add to Cart": ["Anadir al carrito"],
      "Your order has been shipped to %s": ["Su pedido ha sido enviado a %s"]
    }
  }
}

.php (PHP Array) —— 一种越来越流行的格式，用于使用 Laravel 风格的翻译加载的主题和插件。一些现代 WordPress 主题完全绕过 Gettext，并从 PHP 数组加载翻译以提高性能。

<?php
return [
    'Add to Cart' => 'Anadir al carrito',
    'Your order has been shipped to %s' => 'Su pedido ha sido enviado a %s',
];

.xliff (XML Localization Interchange File Format) —— 用于不同工具和平台之间翻译交换的行业标准。被 memoQ、Trados 和 Memsource 等 CAT（计算机辅助翻译）工具使用。与专业的翻译人员合作时必不可少。

<trans-unit id="1">
  <source>Add to Cart</source>
  <target>Anadir al carrito</target>
</trans-unit>

问题：格式锁定

大多数翻译工具只产生一种输出格式。Poedit 为你提供 .po 和 .mo。WPML 将翻译存储在数据库中（根本不在文件中）。Weglot 将翻译保存在其服务器上，采用专有格式。即使像 Crowdin 和 Lokalise 这样的 TMS 平台也要求你为每个项目手动配置导出格式。

这会造成格式锁定 —— 你的翻译被困在你当前工具生成的任何格式中。当你的需求发生变化时，你面临两种选择：

1. 重新翻译所有内容为新格式（昂贵、耗时，并且你丢失了任何手动更正）
2. 编写自定义转换脚本（容易出错，特别是对于复杂的复数形式和变量）

这两种选择都不好。两者都浪费时间和金钱。两者都引入风险。

格式锁定造成的实际问题

场景 1：主题现代化。 你的客户的主题正在使用 Gutenberg 区块重建。旧的 PHP 模板使用 .mo 文件。新的区块需要 .json 用于 wp_set_script_translations()。你的 3,000 个已翻译字符串需要在过渡期间以两种格式存在。

场景 2：代理工作流程。 你管理着 20 个客户站点。有些使用经典主题 (.mo)。有些使用无头设置 (.json)。一个使用读取 PHP 数组的自定义框架。你需要为不同的客户提供不同格式的相同翻译。

场景 3：专业审校。 你的 AI 翻译准确率达到 95%，但你希望母语人士审阅剩余的 5%。专业的翻译人员使用 CAT 工具导入 .xliff。你需要将你的翻译导出为 .xliff，发送以供审校，然后合并更正。

场景 4：平台迁移。 你的客户正在从 WordPress 迁移到自定义 Node.js 应用程序。新的应用程序使用 i18next 并需要 .json 文件。你的 5,000 个 .po 格式的已翻译字符串需要转换 —— 不能丢失任何变量或复数形式。

解决方案：翻译一次，获取所有格式

SimplePoTranslate 采用不同的方法。当你上传 .po、.pot、.json 或 .xliff 文件并运行翻译时，你将获得一个包含所有五种格式的 ZIP 文件：

translations-es_ES.zip
├── flavor-starter-es_ES.po
├── flavor-starter-es_ES.mo
├── flavor-starter-es_ES.json
├── flavor-starter-es_ES.php
└── flavor-starter-es_ES.xliff

这不是锁定在企业级后面的“高级功能”。每个付费计划 —— Pro（19 美元/月）和 Lifetime（399 美元一次性） —— 都包含每个翻译作业中的所有五种输出格式。

为什么这对面向未来很重要

当你从一开始就拥有所有五种格式时，你永远不需要重新翻译。你的翻译是一种可以适应任何技术要求的资产：

• 客户从经典主题迁移到 Gutenberg？部署 .json 文件。
• 新开发人员更喜欢 PHP 数组？将 .php 文件交给他们。
• 专业翻译人员想要审阅？发送 .xliff 文件。
• 迁移到不同的 CMS？.json 和 .xliff 文件与平台无关。

你翻译一次。这些格式在你需要时随时可用。

每种格式在 WordPress 中的工作方式

了解哪个文件放在哪里对于干净的部署至关重要。

部署 .mo 文件（经典 PHP 主题和插件）

wp-content/languages/plugins/woocommerce-es_ES.mo
wp-content/languages/themes/flavor-starter-es_ES.mo

当站点语言匹配时，WordPress 会自动加载它们。无需插件。零数据库开销。这是提供最佳性能的方法。

部署 .json 文件（Gutenberg 区块和 JS 组件）

wp-content/languages/plugins/woocommerce-es_ES-{handle}-{md5}.json

文件名包含脚本句柄和一个 MD5 哈希值。当你在插件或主题中调用 wp_set_script_translations() 时，WordPress 会匹配这些值。如果你正在构建 Gutenberg 区块，这是使你的翻译后的区块标签和描述正确显示的文件。

使用 .xliff 文件（专业审校工作流程）

.xliff 文件不会部署到 WordPress。当你需要将翻译发送给专业的审阅者或将其导入 CAT 工具时，它们用作交换格式。工作流程如下所示：

1. 上传 .po 到 SimplePoTranslate 并获取 ZIP 文件中的 .xliff
2. 将 .xliff 发送给你的翻译人员或审阅者
3. 接收返回的更正后的 .xliff
4. 将更正后的 .xliff 上传到 SimplePoTranslate 并获取更新后的 .mo 和 .json

此往返工作流程保留每个变量和复数形式，因为 SimplePoTranslate 的语法锁定在每个阶段都保护它们。

供应商锁定测试

这是一个简单的测试，可以确定你当前的翻译工作流程是否存在锁定问题：

1. 你现在可以导出你的翻译为标准的 .po 文件吗？
2. 如果你今天取消你的翻译工具订阅，你会保留每个已翻译的字符串吗？
3. 你可以将你的翻译导入到完全不同的工具或平台而无需重新翻译吗？

如果对这些问题的任何一个回答为“否”，那么你就被锁定了。像 Weglot 和 GTranslate 这样的服务无法通过所有三个问题 —— 取消订阅，你的翻译就会消失。WPML 将翻译存储在数据库中，这使得导出成为可能，但很痛苦。即使像 Poedit 这样的桌面工具在纸面上通过了测试，但也仅限于 .po 和 .mo。

使用 SimplePoTranslate，所有三个问题的答案都是“是”。你下载五种格式的标准文件。它们是你的。明天删除你的帐户，你所做的每一个翻译仍然有效。

构建与格式无关的翻译库

对于管理多个项目的代理机构和开发人员来说，最明智的方法是构建一个翻译库 —— 一个 Git 存储库或共享文件夹，你在其中存储每个客户项目的翻译文件。

translations/
├── client-acme/
│   ├── es_ES/
│   │   ├── flavor-starter-es_ES.po
│   │   ├── flavor-starter-es_ES.mo
│   │   ├── flavor-starter-es_ES.json
│   │   ├── flavor-starter-es_ES.php
│   │   └── flavor-starter-es_ES.xliff
│   └── de_DE/
│       └── ...
├── client-globex/
│   └── ...

当客户需要一种新格式时，你已经拥有了它。当客户更改平台时，你的翻译可以零成本迁移。当新的开发人员加入团队时，他们可以准确地看到已翻译的内容以及采用的格式。

这就是“面向未来”的真正含义 —— 不是预测你的客户明年将使用哪种技术，而是确保你的翻译可以与他们选择的任何技术一起使用。

准备好停止担心文件格式了吗？免费试用 SimplePoTranslate —— 上传一个文件，返回五种格式。无需转换脚本，无需重新翻译，没有锁定。