翻译和开发人员之间的内部化、工作流

Question

抱歉，我的英语不好

在我们的项目中，我们将实现内部化，在本例中，我使用的是i18，特别是“react i18Next”。翻译基于公用文件夹中的locales文件夹。

我的问题是，工作流在developer和translator之间应该是什么样的呢？通常，翻译人员会直接更改json (使他们学习如何阅读json)，或者他们只是在纸上翻译网站的文本，这取决于了解json结构的开发人员手动添加/更改已翻译的文本。

这是locales文件夹结构的一个例子，有两个语言文件夹，一个是"en“，另一个是"zh"，都包含具有相同名称但翻译不同的json文件。

地区文件夹结构

json文件

这是按钮上实现的一个例子。

地区实施

提前谢谢。

Answer 1

看看i18nexus.com。这是一个专为使用ReactiveI18Next而构建的平台。只需导入您的翻译文件，并将i18next直接连接到i18nexus。然后，您可以邀请翻译人员在那里编辑和确认翻译。设置起来真的很容易。

下面是一个5分钟的反应教程：https://medium.com/javascript-in-plain-english/react-localization-the-winner-is-i18next-i18nexus-b7cd9f14094e

Answer 2

最有可能的是，您应该为此使用一个翻译平台：

• 你把文件上传到翻译平台，
• 翻译人员使用为他们量身定制的UI翻译，
• 你会收到翻译后的文件。

有许多平台可供选择：

• 洛嘉丽 (商业) --免责声明:我在这里工作
• 莫吉托 (开放源码)
• 克劳丁 (商业)
• LingoHub (商业)
• 罗西泽 (商业)
• 短语 (商业)
• 过渡费克斯 (商业)
• 韦布莱特 (开放源码)
• 萨纳塔 (开放源码)

Answer 3

许多翻译器熟悉许多文件格式，并拥有直接处理这些格式所需的工具。其他人则不太精通技术，他们依赖于客户端(他们通常有必要的脚本技巧)或中介将字符串转换成更易于管理的格式，如Excel或CSV。

因此，这取决于你和你的翻译(或者你的语言服务提供商，如果你用一个语言服务提供商在一个地方管理所有的语言)来协商一个工作流程，充分利用你各自的才能，以合理的努力和成本获得好的结果。

最重要的事情，你会想要担心(而且没有任何工具会解除你)是为译者提供上下文。如果他们不知道他们正在翻译的字符串到底在哪里被使用，你就会得到很差的结果。