WordPress 插件国际化：变量未翻译？

Question

我有一个 wordpress 插件，其中一些设置存储在一个数组中，每个设置都有一个 slug 和一个标签。

我的插件是基于class的，这是我的构造函数的代码

class My_Plugin {
  function __construct() {
    $this->_options = array(
        'optionA' => __( 'Text for first option', 'my-plugin' ),
        'optionB' => __( 'Text for second option', 'my-plugin' ),
        'optionC' => __( 'Text for third option', 'my-plugin' ),
    );
  }
}

我在几个地方使用了类似的结构，以存储与带有获取文本的标签关联的值列表。例如，稍后，此数组可用于创建具有用户设置的表单

foreach ($this->_options as $option_name => $option_label) {
    echo '<input type="text" name="' . $option_name .  '" value="' . $option_label . '"/>';
}

我在其他地方也使用类似的结构。现在，我注意到的奇怪（？）事情是，当我使用 PoEdit 翻译插件时，这些字符串没有被翻译。为什么会这样？除了更改结构并直接编写每个输入字段或重复结构之外，我还能做些什么吗？

Answer 1

您需要了解 gettext 库（包括 WordPress 中的库）的工作原理——一旦了解，此类问题的原因很容易推断：

__() 不是什么魔法标记，而是一个普通的旧函数。它以字符串作为输入，搜索当前加载的 MO 文件中的域，如果有任何，returns 翻译如果它找到一个。否则它 return 是未修改的输入（即回落到英语）。

因此，根据您未包含在此处的其余代码的知识，您需要问自己的问题是：是否已加载 my-plugin 域的翻译 在构造函数调用 __() 时?

一个合理的猜测是，不，不是。您首先构建了 My_Plugin 对象，因此在未加载翻译且 gettext 库尚未正确初始化时调用 __()。在这种情况下，该函数唯一能做的就是 return 原始英文字符串。在某个时候 later（按时间顺序，不一定按源代码顺序）您的 gettext 初始化挂钩被执行并调用 load_plugin_textdomain。从那时起，__() 将按预期运行。不过，这对您的构造函数来说为时已晚，因为您已经“翻译”了这些字符串。

像你这样存储翻译后的值是完全没问题的（尽管它也有点毫无意义，因为它不会给你带来任何有意义的性能优势）。但是您需要严格遵循一个简单的规则：首先加载翻译，然后使用它们。

WordPress 插件国际化：变量未翻译？

Wordpress plugin internationalization: variables not translated?

php

wordpress

gettext

internationalization