带有 i18next 的 gettext 样式键和一般工作流程

Question

我们想与翻译人员交换 PO 文件，并将这些文件转换为 i18next 的原生 JSON 格式。使用i18next-conv 实用程序听起来很简单。

但是，i18next 需要或多或少的特殊键；例如，点对于 i18next 命名空间具有特殊含义。相比之下，gettext PO 文件旨在为其消息 ID携带源字符串（原始语言）。

我们知道消息 ID 可以是任意的，因此可以直接映射到 i18next 键，但是出于各种原因，我们希望使用源字符串并使用 PO 文件。

主要原因是我们想使用的所有翻译工具，可能还有我们所有翻译人员的工具，都期待这一点。使用符号键会使翻译变得非常痛苦。无论如何，我们从围绕这个问题的辩论中得出的结论是，这主要是一个意见问题；我们有点做我们的，我们想把这个限制作为这个问题的要求。

从技术角度来看，将源字符串用作 i18next 键真的是个坏主意吗？逃离他们有多难？除了点和命名空间之外，还有什么我们应该关心的吗？
如果我们确定要继续使用符号键，是否有替代 i18next-conv 的方法可以使用源字符串作为消息 ID 从 PO 文件生成 i18next JSON 翻译文件？我们知道我们很可能需要维护符号名称和原始语言字符串之间的单独映射，我们已经准备好这样做。

此外，我们想知道一般的工作流程。原始的 PO 文件是如何生成的？翻译文件是如何维护的？

我们知道这些问题是非常基本的，但我们发现有关 i18next-gettext 集成的信息如此之少，这让我们感到有些惊讶。i18next-conv 工具存在并且像宣传的那样完美运行，但它真的有用吗？人们真的使用它吗？如果是这样，我们的问题是否相关？

最后，我们对系统成熟度的期望是不是有点太高了？

Answer 1

如果您喜欢使用源字符串作为键，只需更改

nsseparator = ':::'
keyseparator = '::'

所以.并:可以在钥匙内部使用，而不用担心。

Answer 2

您可以尝试使用https://github.com/cheton/i18next-text。它允许您使用 i18next 翻译而无需使用 askey字符串，并且您无需担心 i18n 键命名。此外，您还可以向 Handlebars 注册 i18n 帮助程序。

下面是一个简单的例子：

var i18n = require('i18next');

// 扩展 i18n 对象以提供新的 _() 方法
i18n._ = require('i18next-text')._;

i18n._('节省您的时间并提高工作效率。');

查看JSFiddle 上的演示。