Internationalization 为什么人们使用普通英语作为翻译占位符？

这可能是一个愚蠢的问题，但问题来了

我见过几个项目使用一些翻译库（例如gettext）处理纯英语占位符。例如：

_("Please enter your name");

而不是抽象的占位符（这一直是我本能的偏好）

我已经看到了关于使用前一种方法的各种建议，但我不明白为什么。我不明白的是，如果你需要更改英文措辞，你会怎么做？因为如果将实际文本用作所有现有翻译的键，则也必须编辑所有翻译，并更改每个键。还是你没有

那不是很麻烦吗？为什么这是行业标准

---

这样做绝对不合适。这种方法有我没有看到的巨大优势吗？

有趣的问题。我认为主要原因是，在开发过程中，您不必关心翻译或本地化文件，因为主要语言就在代码中

主语言已经存在：您不需要翻译它

与模糊占位符相比，译者对真实句子有更好的语境

占位符只是键，仍然可以通过创建翻译来更改原始语言。因为当翻译不存在时，它使用占位符作为翻译文本

---

是的，你必须改变现有的翻译文件，这是一件好事

如果你改变了英文的措辞，翻译可能也需要改变。即使他们没有，你也需要会说另一种语言的人来检查

---

你准备了一个新版本，QA过程的一部分是检查翻译。如果英语的措辞发生了变化，没有人检查翻译，它会像拇指疼痛一样突出，并且会得到修复。

可能只是因为它更容易阅读，也更容易翻译。我认为，您的方式是最好的可扩展性，但它只是需要额外的一点努力，一些开发商可能不认为值得…对于某些项目，可能不是这样。

我喜欢你的第二种方法。翻译文本时，你总是遇到同音异义词的问题。比如“open”可以表示窗口的状态，也可以表示执行操作的动词。在其他语言中，这些同音词可能不存在。这就是为什么您应该能够在占位符中添加含义的原因。最好的方法是把这个意思放到你的文本库中。如果在您使用的框架平台上不可能这样做，那么最好定义一种“开发语言”。此语言将为文本条目添加含义，如：“action_open”和“state_open”。你将不得不付出额外的努力将这种语言翻译成通俗易懂的英语（或你为之发展的语言）。我在一些大型项目中运用了这一理念，从长远来看，这节省了一些时间（和头痛）

在我看来，最好的方法是将意思分开，因此，如果您开发自己的翻译库或您使用的翻译库支持它，您可以这样做：

_(i18n("Please enter your name", "error_please_enter_name"));

其中：

i18n(text, meaning)

---

有一个回退层次结构，从最特定的语言环境到源代码中的未本地化版本

因此，在法国的法国人可能有以下退路：

fr_fr

fr

未定位。源代码

因此，在源代码中使用正确的英语句子可以确保，如果在步骤（1）或（2）中没有提供特定的翻译，您至少可以得到一个正确的可理解句子，而不是像“error\u file\u not\u found”这样的随机程序员垃圾句

---

另外，如果是格式字符串，您会怎么做：“对不起，但是%s不存在”？更糟糕的是：“已将%s个条目写入%s，总大小：%d”

我们使用抽象占位符已有一段时间了，创建新函数时必须将所有内容写入两次，这非常烦人。当英语是占位符时，您只需用英语编写代码，从一开始就有了有意义的输出，而不必考虑命名占位符

---

因此，我的理由是开发人员的工作量会减少。

这是一个很老的问题，但我还没有在答案中看到另一个原因：

您可能会得到比需要更多的占位符，从而为翻译人员带来更多的工作，并可能出现不一致的翻译。然而，像Poedit或Gtranslator这样的优秀编辑可能会对此有所帮助

要坚持你的例子： 文本“请输入您的姓名”可能出现在不同模板的不同上下文中（开发人员很可能不知道，也不需要知道）。例如，它不能用作错误，而是用作提示，就像输入字段的占位符一样

如果你使用

_("Please enter your name");

它是可重用的，开发人员可以不知道错误消息已经存在的密钥，而只是直观地使用相同的文本

但是，如果您使用

_("error_please_enter_name");

在以前的模板中，开发人员不一定意识到这一点，而是组成第二个密钥（根据预定义的措辞方案，最有可能不会导致完全混乱），例如

然后必须再次翻译

所以我认为这不能很好地扩展。我认为，预先商定的后缀/前缀的措辞方案（例如，用于上下文）永远不会像文本本身那样精确（要么太冗长，要么太笼统，事先你不知道，事后很难更改），而且对于开发人员来说，更多的工作是不值得的

---

有人同意/不同意吗？

是的，这可能是主要原因——对于孤独的程序员和小团队来说，这是可以理解的，但是当你有20个翻译文件由不同的人维护时，这就变成了巨大的痛苦。这就是为什么我不明白为什么这似乎是某种行业标准+1卓越

_("error_please_enter_name");

_("prompt_please_enter_name");