Question

我们希望与翻译人员交换PO文件，并将这些文件转换为i18next的原生JSON格式。使用i18next-conv utility时，这听起来非常简单。

然而，i18next期望更多或更少的特殊键;例如，关于i18next命名空间，dot具有特殊含义。相比之下，gettext PO文件旨在为其消息ID 提供源字符串（使用原始语言）。

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

主要原因是我们想要使用的所有翻译工具，以及我们所有翻译人员都希望使用的翻译工具。使用符号键会翻译真正的痛苦。无论如何，我们从围绕此的辩论中发现，这主要是一个意见问题;我们有点做了我们的，我们想把这个限制作为这个问题的要求。

从技术角度使用源字符串作为i18next键真的是个坏主意吗？逃脱他们有多难？除了我们应该关注的点和命名空间之外还有什么吗？

如果我们确定要继续使用符号键，是否有替代i18next-conv可以使用源字符串作为消息ID从PO文件生成i18next JSON转换文件？我们理解，我们很可能需要在符号名称和原始语言字符串之间保持单独的映射，我们已准备好这样做。

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

如果我们在i18next中使用源字符串作为键，那么从代码库中提取字符串的最佳工具是什么？ xgettext似乎不支持Javascript。

如果我们在i18next中使用符号键，我们如何才能最好地生成原始PO文件？手工编写POT文件是一种很好的做法吗？

同样，如果我们使用符号键，那么每当我们更新原始语言字符串时，我们怎么能轻易地使翻译无效？那有工具吗？

我们理解这些问题非常基础，但我们对于有关i18next-gettext集成的信息很少感到有些惊讶。 i18next-conv工具存在且与广告一样完美，但它实际上有用吗？人们真的使用它吗？如果是，我们的问题是否相关？

最后，我们对系统成熟度的期望有点过高吗？

Answer 1

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

即可

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

所以.和:可以毫无顾虑地在密钥内使用。

Answer 2

您可以尝试使用https://github.com/cheton/i18next-text。它允许您使用i18next翻译而不需要key作为字符串，并且您不必担心i18n键命名。此外，您还可以使用把手注册i18n助手。

以下是一个简单的例子：

var i18n = require('i18next');

// extends i18n object to provide a new _() method
i18n._ = require('i18next-text')._;

i18n._('Save your time and work more efficiently.');

JSFiddle上的

Check out the demo。

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

2 个答案: