一篇文章带您了解如何实现WordPress主题/插件本地化翻译

要实现WordPress主题和插件的本地化翻译就需要了解什么是国际化和本地化以及WordPress是如何实现国际化和本地化的。

本文涵盖以下内容：

什么是国际化？
如何国际化你的插件
什么是本地化？
本地化文件
如何实现本地化
解读po翻译文件
如何在 WordPress中翻译JavaScript 中的内容
安装WP-CLI
在Windows上安装wp-cli
更新WP-CLI
WP-CLI生成JSON翻译文件
WP-CLI生成POT翻译模板

什么是国际化？

国际化是为软件（在本例中为 WordPress）提供多语言支持的过程。国际化通常缩写为 i18n，其中 18 代表第一个 i 和最后一个 n 之间的字母数。

为您的插件和主题提供 i18n 支持可以使其覆盖尽可能多的受众，即使不需要您提供额外的语言翻译。当您将软件上传到 WordPress.org 时，所有 JS 和 PHP 文件都将自动解析。任何检测到的翻译字符串都会添加到 translate.wordpress.org 中，以允许社区进行翻译，确保 WordPress 插件和主题以尽可能多的语言提供。

对于 PHP，WordPress 有一个由来已久的流程，请参阅如何国际化您的插件。WordPress 5.0 的发布带来了类似的 JavaScript 代码翻译过程。

如何国际化你的插件

为了使字符串在应用程序中可翻译，必须将原始字符串包装在对一组特殊函数之一的调用中。这些函数统称为“gettext”。

什么是本地化？

本地化描述了翻译国际化插件的后续过程。本地化通常缩写为（因为 l 和 n 之间有 10 个字母。l10n

本地化文件

POT（可移植对象模板）文件

此文件包含插件中的原始字符串（英文）。

PO （Portable Object）文件

每个翻译人员都会获取文件并将各个部分翻译成他们自己的语言。结果是一个与 格式相同的文件，但带有翻译和一些特定的标头。每种语言都有一个文件。POTmsgstrPOPOTPO

MO （Machine Object）文件

从每个翻译的文件中构建一个文件。这些是 gettext 函数实际使用的机器可读的二进制文件（它们不关心 OR 文件），并且是文件的“编译”版本。转换是使用命令行工具完成的。通常，应用程序可能会相应地使用多个大型逻辑可翻译模块和不同的文件。

以上内容来源于WordPress开发人员资源库，有需要的朋友可以去进行深入的解析和理解。对于新入门的朋友来说可能有些不太好理解，总的来说所谓的国际化就是通过（一系列）函数将文字（字符串、变量、单复数等）标记为可以被翻译的形式，那么相应的本地化就是将已经标记的文字翻译成某种语言。国际化是主题或插件的开发者需要考虑的问题，想要把主题和软件翻译成大美的中文就只需要了解如何本地化即可。

对于如何实现WordPress国际化以及Gettext函数的使用方法可以参考《如何国际化你的插件》

如何实现本地化

本文将着重解释如何实现本地化。

举个例子，当你打开了一个已经完成国际化的主题或者插件的源代码是你应该会看到很多类似

__( ‘Blog Options’, ‘my-plugin’ ); 这样的代码。函数的格式：__(‘文本域’,”路径域”);其中文本域表示可以被翻译的文本也就是前端将会显示的内容，域路径定义插件翻译的位置。

结合之前所说的.pot为模板.po为可以编辑的翻译文件.mo为编译后的翻译文件，简单理解为，当WordPress看到了__( ‘Blog Options’, ‘my-plugin’ );这样一条语句时会在众多的.mo文件中通过my-plugin来进行匹配，当匹配到的mo文件中如果包含了Blog Options的翻译条目时就会把Blog Options替换成翻译后的文本并输出到页面上。

这样是不是就很好理解了呢?那么接下来就看看怎么创建和编辑翻译文件。

当你下载了一个以及国际化的主题或插件，你应该可以找到languages或lang目录，而里面大概率会躺着一个.pot文件或很多.po文件；其他都不重要我们只需要.pot的模板文件，有了翻译模板文件就可以使用Poedit等软件创建对应语言的po文件进行编辑并生成mo文件供WordPress使用了。

解读po翻译文件

如果没有pot文件可以参考本文接下来讲到的如何创建pot模板文件。

接下来展示一个po文件的示例：

# Copyright (C) 2023 
# This file is distributed under the GPLv2.
msgid ""
msgstr ""
"Project-Id-Version: Smush Pro 3.14.0n"
"Report-Msgid-Bugs-To: https://wpmudev.comn"
"POT-Creation-Date: 2023-07-21 12:47+0800n"
"PO-Revision-Date: 2023-08-15 15:14+0800n"
"Last-Translator: cnuu <admin@cnuu.net>n"
"Language-Team: n"
"Language: zh_CNn"
"MIME-Version: 1.0n"
"Content-Type: text/plain; charset=UTF-8n"
"Content-Transfer-Encoding: 8bitn"
"Plural-Forms: nplurals=1; plural=0;n"
"X-Generator: Poedit 3.3.2n"
"X-Domain: wp-smushitn"

#. Plugin Name of the plugin
#: app/class-admin.php:285 app/class-admin.php:324
#: app/pages/class-dashboard.php:110 app/pages/class-dashboard.php:353
#: app/views/directory/meta-box.php:43 core/modules/bulk/class-mail.php:65
msgid "Smush Pro"
msgstr "Smush 专业版"

这段代码是一个.pot文件的内容，用于国际化。下面是每一行的解释：

1. "Project-Id-Version: Smush Pro 3.14.0n": 定义项目的版本号。
2. "Report-Msgid-Bugs-To: https://wpmudev.comn": 提供报告消息ID和bug的URL。
3. "POT-Creation-Date: 2023-07-21 12:47+0800n": 创建此模板的日期和时间。
4. "PO-Revision-Date: 2023-08-15 15:14+0800n": 上次修订此模板的日期和时间。
5. "Last-Translator: cnuu <admin@cnuu.net>n": 最后翻译此模板的人的名字和电子邮件地址。
6. "Language-Team: n": 语言团队的名称或标识，通常用于指定负责特定语言的翻译团队。
7. "Language: zh_CNn": 指定此模板的语言版本，这里是简体中文。
8. "MIME-Version: 1.0n": MIME版本号。
9. "Content-Type: text/plain; charset=UTF-8n": 内容类型和字符集，这里是纯文本和UTF-8字符集。
10. "Content-Transfer-Encoding: 8bitn": 内容传输编码方式，这里是8位编码。
11. "Plural-Forms: nplurals=1; plural=0;n": 定义复数形式的规则。这里表示该语言只有一种复数形式。
12. "X-Generator: Poedit 3.3.2n": 用于生成此模板的工具的名称和版本号。
13. "X-Domain: wp-smushitn": 指定与这个模板相关的域名或项目名称，这里是wp-smushit插件。

然后是双引号包围的字符串，这些是消息ID和对应的原始字符串（msgid）以及翻译后的字符串（msgstr）。例如：

• msgid "Smush Pro" 表示原始字符串是 “Smush Pro”。
• msgstr "Smush 专业版" 表示翻译后的字符串是 “Smush 专业版”。

其中，#: app/class-admin.php:285 app/class-admin.php:324 等行表示这些字符串在哪些源代码文件中出现，以及它们在文件中的具体位置。这对于翻译者来说非常有用，因为他们可以知道这些字符串在哪里使用，以便更好地进行翻译。

如果你理解了上面的内容那么不需要借助其他软件也可以手动创建.po文件了。

文件的命名规则：

例如wp-plugin-name-zh_CN.po

不用说，文件名必须是中文，单词间用-分隔连接，最后zh_CN代表使用ISO 639-1标准规定的语言代码，例如：

• en_US（英语）
• zh_CN（简体中文）
• fr_FR（法语）
• de_DE（德语）
• es_ES（西班牙语）

编辑完成后创建的对应.mo文件应放置在主题或插件目录下的languages文件夹内或者wp-content/languages/对应目录下，不同作者写的方法肯定也不一样，区别对待。

有了以上的知识储备本地化翻译已经不再深奥，相信阅读到这里你已经迫不及待跃跃欲试了，别急，下面的内容可能是你在其他地方找寻不到的实用经验总结。

有可能你会遇到这样的问题，一段文字已经在翻译文件中添加了并且翻译都已生效就是某一部分仍旧无法翻译。

这时候你需要找出这段文字在源代码中出现的位置，确定这段文字（文本）是否已经进行了国际化定义，也就是之前提到的函数__(‘文本域’,”路径域”);，并且路径域是否和你的翻译文件匹配。

如果没有定义函数那么你可以手动修改源代码添加定义函数，你需要了解函数的实用方法以及__()_e()_x()_ex()_n()_nx()等不同函数的区别和用法。如果路径域和你的翻译文件不匹配你也可以修改路径域或者创建一个对应路径域的翻译文件。

还有一种可能就是这段文字最终确定是由JS文件输出的。

2024年2月20日更新
如何添加自定义JavaScript i18n

/**
 * 添加自定义翻译
 * Adding Custom Translations
 */
function admin_enqueue_scripts() {
/*注册js*/
    wp_register_script( 'wpmc_script', plugins_url( 'assets/filename.js', __FILE__ ),
	array('wp-element', 'wp-i18n')
    );
//加载翻译，接受可选的第三个路径参数
      wp_set_script_translations( 'wpmc_script', 'text-domain', plugin_dir_path( __FILE__ ) . 'languages' );
    wp_enqueue_script('wpmc_script' );
  }
  add_action( 'init', 'admin_enqueue_scripts' );

/**
 * END
 */

/*JavaScript中添加定义*/
__ = wp.i18n.__;//add i18n

/*处理文本示例：*/
__('text','text-domain')

本文是作者@avenjan对WordPress本地化翻译的一些心得和总结，分享给想要了解此部分知识和技能的朋友，部分内容可能不是十分准确和专业，但也希望能给有需要的朋友带来一些执导和帮助。如有疑问和意见欢迎评论区讨论，感谢关注！