WordPress 6.5 改进 I18N 多语言翻译性能

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' => 'polyglots@example.com',
	'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,以防站点上仅存在前者。

要了解更多信息,请查看官方日志

给TA赏糖
共{{data.count}}人
人已赏糖
技术分享

Nginx反向代理永久性缓存

2024-2-28 21:54:55

技术分享

为 WooCommerce 创建一个支付网关插件

2024-2-29 1:44:34

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索