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

【问题标题】：gettext-style keys with i18next, and general workflow带有 i18next 的 gettext 样式键和一般工作流程
【发布时间】：2013-10-24 14:08:42
【问题描述】：

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

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

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

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

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

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

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

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

【问题讨论】：

你可以试试l10ns，那么你就不需要处理PO文件了。
感谢您的建议。请注意，l10ns 仅使用 ICU MessageFormat。虽然与 gettext 可移植对象相比，它当然有其优势，但这个问题的隐含目标是非常支持它们，部分原因是外部原因（非程序员的现有工具、熟悉度等）。毫无疑问，有 MessageFormat 替代品，但有时切换技术的成本不值得他们的优势。

【解决方案1】：

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

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

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

【讨论】：

对于其他我没有答案的东西...我只知道人们以您想要的方式使用它...但我个人更喜欢符号键
感谢您的回答，如果我们需要使用 gettext 样式的键，这将很有帮助。现在我们也想坚持使用符号键。我看到您也是转换器的作者，请问您是否在使用符号键时亲自使用它？如果没有，您能否对其用户群的规模做出非常粗略的估计？我们只是想在编写我们自己的工具之前尝试看看其他人的表现如何，或者，如果我们负担不起，就寻找替代方案。
抱歉，回答迟了。不，我自己没有使用转换器。我们在一些项目中使用 webtranslate UI。我不能说有多少人使用了转换器——我只知道有一些人在使用它。抱歉，我帮不上忙。
没问题，你一直很有帮助。再次感谢。

【解决方案2】：

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

下面是一个简单的例子：

var i18n = 要求（'i18next'）； // 扩展 i18n 对象以提供新的 _() 方法 i18n._ = 要求（'i18next-text'）._; i18n._('节省您的时间，提高工作效率。');

Check out the demo 在 JSFiddle 上。

【讨论】：