人们为什么使用翻译占位符而不是普通英语?

时间:2018-11-10 06:53:59

标签: gettext i18next react-intl react-i18next

是的,这是与以下情况相反的完全问题:Why do people use plain english as translation placeholders?

我一直使用标准的gettext方式进行翻译,但是现在我正在做前端,我意识到不仅大多数库都在使用键/占位符,而且有时建议(请参阅i18next)胜过使用纯文本。英语。

我与占位符的合作不多,但是我发现这很困难,因为:

  • 您必须始终发明唯一的占位符名称,需要使用约定
  • 也许您想重复使用相同的占位符名称,所以您必须找到一个与您要翻译的内容匹配的现有占位符
  • 按模块确定所有翻译范围或共享翻译会更好吗?我不确定

根据i18-next的文档,建议使用占位符,因为:

  

虽然可行,但可能会减少文件加载量,这使得   翻译的管理要困难得多,因为您需要更新   更改代码和json文件中的后备值。

  1. 我不会使用普通英语来减少要加载的文件数。这似乎显然是错误的。
  2. JSON? PO / POT有什么问题?已经有很多翻译工具。
  3. 如果需要更改措辞,则所有翻译都应进行审核,所以我认为这会破坏旧的翻译有点“好”,对吧?
  4. 在我看来,开发人员可以专注于正确设置英语文本,而翻译人员可以正确设置其他语言。
  5. 我真的不明白使用简单的英语要难得多。一个真实的例子将是很棒的。

我的猜测是两种方法都有优点和缺点,但是我看不到带有占位符的优点,所以我想了解一下。

1 个答案:

答案 0 :(得分:2)

我认为这只能归结为先前的假设,即固定的占位符ID意味着您以后可以修饰英语翻译字符串而不会破坏占位符与完成的外国翻译的联系。

但是,我对您有相同的看法-普通英语会更好,并且如果英语发生更改,那么当然也需要检查外国翻译是否也需要更新。

公约可能是错误的。