WordPress 6.5 中进行了各种国际化 (i18n) 改进，本开发人员说明将重点关注这些改进。
性能改进的本地化翻译系统
在过去的一年里，WordPress 贡献者仔细分析了WordPress 中现有i18n系统的性能，并最终创建了一个新的Performance Translations 功能插件，该插件提供了一个经过彻底检修的系统，性能显着提高。经过数千名Beta测试人员和去年年底的合并公告，这个新库现已包含在 WordPress 6.5 中！有关所有详细信息，请阅读#59656 。
Performant Translations 插件仍然有用，并将继续维护，以构建在具有独特附加功能的核心解决方案之上。与今天的情况一样，如果当前不存在 PHP 文件，该插件会自动将任何.mo文件转换为PHP文件。这对于翻译不是来自translate.wordpress.org或仅存在于该服务器本地的网站非常有用。
这个新库使加载二进制.mo文件的速度更快，并且使用的内存更少。它甚至支持同时加载多个语言环境，这使得网站语言切换更快。除此之外，它还支持 PHP 文件中包含的翻译，避免使用二进制文件格式并利用 OPCache 缓存（如果可用）。
事实上，新库速度如此之快，以至于它为首选语言功能插件从 WordPress 6.5 开始默认合并多个语言环境的翻译铺平了道路。
虽然这在很大程度上是一个无声且向后兼容的底层更改，但仍有一些事情需要注意：
新的.l10n.php 翻译文件格式
从WordPress.org下载语言包时，除了您已经熟悉的.mo和.po文件之外，还会有一个新文件.l10n.php。如果.mo 翻译文件有相应的.l10n.php文件，则将加载后者，从而使速度更快并使用更少的内存。
这是一个渐进增强，因此如果只有一个.mo文件但没有 PHP 文件，翻译仍将按预期加载。反之亦然！因此，理论上您可以在项目中仅使用.l10n.php翻译文件，并且即时翻译加载等功能将继续工作。目前，WordPress 仍然需要相应的.po文件.mo来进行更新检查等操作。不过，这个限制将来会得到解决，请参阅#60554了解更多信息。
注意：如果您没有在 wp-content/languages看到任何.l10n.php翻译文件，可能是语言包有一段时间没有更新，即没有新的翻译。
以下是 WordPress 6.5 支持的 PHP 翻译文件示例：
<?php
return [
'project-id-version' => 'WordPress - 6.5.x - Development',
'report-msgid-bugs-to' => '[email protected]',
'messages' =>
[
'original' => 'translation',
'contextEOToriginal with context' => 'translation with context',
'plural0' => 'translation0' . "\0" . 'translation1',
'contextEOTplural0 with context' => 'translation0 with context' . "\0" . 'translation1 with context',
'Product' => 'Produkt' . "\0" . 'Produkte',
],
];注意：这里的 EOT 代表“传输结束”字符（U+0004，或"\4"在 PHP 中）。它与 gettext 中用于将上下文与单数字符串粘合在一起的分隔符相同。
生成 PHP 翻译文件
如果您想自己生成这些 PHP 翻译文件，GlotPress 的 4.0 版（为 translate.WordPress.org 提供支持的插件）已经支持新.l10n.php格式。
除此之外，WP-CLI 2.10.0 ( i18n-command2.6.0) 提供了一个新wp i18n make-php命令来从给定的.po文件创建这些 PHP 文件。例子：
# Create PHP files for all PO files in the current directory.
$ wp i18n make-php .
# Create a PHP file from a single PO file in a specific directory.
$ wp i18n make-php example-plugin-de_DE.po languages如果您正在开发处理翻译的 WordPress 插件，您还可以使用新WP_Translation_File类将.mo文件转换为 PHP 文件。例子：
$contents = WP_Translation_File::transform( $mofile, 'php' );
if ( $contents ) {
file_put_contents( $path_to_php_file, $contents );
}用于自定义此行为的新过滤器
如果您出于某种原因想禁用对 PHP 文件的支持；例如，如果您的项目中还没有任何文件并且想要防止额外的文件查找操作，您可以使用新的translation_file_format 过滤器来更改首选格式（默认为php），如下所示：
add_filter(
'translation_file_format',
static function () {
return 'mo';
}
);现有load_textdomain_mofile过滤器仍可用于过滤.mo文件路径以加载特定文本域的翻译。但是，它仅适用于.mo文件。要过滤翻译文件的路径（无论是文件.l10n.php还是.mo文件），请使用新的load_translation_file过滤器。
使用$l10n全局变量
以前，当加载翻译时，WordPress 会将MO类的实例存储在$l10n全局变量中。在 WordPress 6.5 中，这将是一个新WP_Translations类的实例，充当具有类似功能的填充程序。如果您的项目以某种方式直接使用此全局变量或MO类，那么这是一个需要关注的区域。
缓存的语言文件路径列表
这是另一个轻微的性能改进，但与上面介绍的新本地化库无关。
在 get_available_languages()，WP_Textdomain_Registry 等地方，WordPress过去都是直接使用该glob()函数来检索特定目录下的所有.mo文件。这对于及时加载翻译以及了解安装了哪些翻译非常重要。但是，在具有大量语言文件的站点上，该glob()操作可能会变得非常耗时。
因此，#58919 / [57287]中引入了新的缓存机制。文件查找现在集中处理WP_Textdomain_Registry并存储在translations组中的对象缓存中，缓存键的格式为cached_mo_files_<hash>，其中<hash>是扫描目录的 MD5 哈希值，例如wp-content/languages。每当更新语言包时都会清除缓存。
此外，除了.l10n.php文件之外，查找现在还扫描文件.mo，以防站点上仅存在前者。
要了解更多信息，请查看官方日志。