为什么人们使用翻译占位符而不是简单的英语？

Question

是的，这是与Why do people use plain english as translation placeholders?

相反的确切问题

我一直使用标准的 gettext 方式进行翻译，但现在我正在做前端，我意识到不仅大多数库都使用键/占位符，而且有时建议（参见 i18next）而不是使用简单的英语。

我对占位符的工作不多，但我觉得这很困难，因为：

• 您必须始终发明独特的占位符名称，您需要约定
• 也许您想重复使用相同的占位符名称，因此您必须找到一个与您正在翻译的内容相匹配的现有名称
• 将所有翻译的范围划分为每个模块还是共享翻译更好？我不确定

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

虽然这可行并且可能会减少要加载的文件，但它会使 翻译管理更加困难，因为您需要更新 更改代码和 json 文件中的备用值。

1. 我不会使用简单的英语来减少要加载的文件数量。这显然是错误的。
2. JSON？ PO/POT 有什么问题？已经有很多工具可供翻译人员使用。
3. 如果需要更改措辞，则应审查所有翻译，所以我想它会破坏旧的翻译有点“好”，对吧？
4. 在我看来，开发人员可以专注于正确处理英文文本，而翻译人员可以正确处理其他语言，这似乎更容易。
5. 我真的不明白使用简单的英语有多难。一个现实生活中的例子会很棒。

我的猜测是这两种方法各有利弊，但我看不到占位符的优点，所以我想了解一下。

Answer 1

我认为这只能归结为之前的假设，即固定的占位符 id 意味着您以后可以在不破坏占位符与已完成外文翻译的连接的情况下对英文翻译字符串进行微调。

不过，我对你的看法是一样的——通俗的英文更好，如果英文变了，当然也需要检查外文翻译是否也需要更新。

约定可能是错误的。