问题描述

我有 a plugin 将帖子状态放置到帖子类型的管理菜单中。我正在国际化的中间，我想知道如何处理这种情况。

该插件使用一些唯一的字符串，将获得如下这样的文本域：

__( 'Select the post statuses to <strong>exclude</strong> from post type admin menus', 'csmpmsi' )

但是也有一些情况我使用的是 core-related 的 core-related，意思就是这样：__( 'Pages' )。在这种情况下，对于我排除文本域并利用已经本地化在核心的术语，似乎是完全有道理的。然而，该法典似乎非常明确：

If you’re trying to translate a plugin, the same advice as above applies, except that

  • you must use a domain, which is loaded in a hook of your plugin

  • every translation call must become __(‘text’, ‘domain-name’)

那么这个 WP-kosher？

最佳解决方案

不要依赖核心字符串进行翻译，他们可能随时更改或获取 context 参数。一旦发生这种情况，您的用户将获得部分翻译的界面，您的翻译无法解决这个问题。

还要记住，同一个字符串不一定用同一个字来翻译。即使没有上下文参数，在某些语言中为插件使用不同的翻译也许是有用的。但是，如果您不在插件中包含字符串，这将是不可能的。

看到这个 chat discussion 我们有几天前关于这个话题。

次佳解决方案

是的，但请不要。这就像编码标准，更好地跟随它，即使你可以通过绕过它获得小的优势。

更好的理由：

  1. 在版本 3.5 中，WordPress 没有一个整体翻译文件，由于性能原因，它被分为 3 部分。如果这种趋势继续下去，当您尝试在__('Pages')中使用默认域时，您是否可以确保加载默认域？

  2. 您不会将工作保存到本地化程序 – 像 poedit 这样的翻译工具不知道如何处理一个文件中的两个翻译域，在本例中，他们将生成一个.po 文件，其中包含单词’Pages’，即使您使用它的默认域。本地化人不会检查他翻译的字符串的实际使用情况，除非他需要了解上下文，以便他不会注意到不同的域并将其翻译出来。另外，如果本地化程序知道他的工具，他将有一个基于 WordPress 核心翻译文件的翻译 DB，使得 poedit 可以自动翻译像’Pages’ 这样的单词。

参考文献

注：本文内容整合自 Google/Baidu/Bing 辅助翻译的英文资料结果。如果您对结果不满意，可以加入我们改善翻译效果：薇晓朵技术论坛。