4

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

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

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

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

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

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

  1. 如果我们在 i18next 中使用源字符串作为键，那么从代码库中提取字符串的最佳工具是什么？xgettext 似乎不支持 Javascript。
  2. 如果我们在 i18next 中使用符号键，我们如何才能最好地生成原始 PO 文件？手动编写 POT 文件是一种好习惯吗？
  3. 同样，如果我们使用符号键，我们如何在更新原始语言字符串时轻松地使翻译无效？有这方面的工具吗？

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

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

4

2 回答 2

5

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

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

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

于 2013-10-16T13:52:55.427 回答
2

您可以尝试使用https://github.com/cheton/i18next-text。它允许您在没有 as 字符串的情况下使用 i18next 翻译key，并且您无需担心 i18n 键命名。此外，您还可以使用 Handlebars 注册 i18n 助手。

下面是一个简单的例子：

var i18n = 要求（'i18next'）；

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

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

查看JSFiddle 上的演示。

于 2015-03-17T13:23:05.897 回答