这可能是一个愚蠢的问题，但现在就去了。
我见过几个使用普通英语占位符的翻译库（例如gettext）的项目。例如：
_("Please enter your name");
而不是抽象占位符（这一直是我本能的偏好）
_("error_please_enter_name");
我已经看到有关SO的各种建议与前一种方法一起工作，但我不明白为什么。我没有得到的是如果你需要改变英文措辞你会怎么做？因为如果将实际文本用作所有现有翻译的密钥，则必须编辑所有翻译，并更改每个密钥。或者不是吗？
这不是很麻烦吗？为什么这是行业标准？
以这种方式执行它绝对不是正确的规范化。我没有看到这种方法有很大的优势吗？
答案 0 :(得分：31)
是的，您必须更改现有的翻译文件，这是好事。
如果您更改英语措辞，翻译可能也需要更改。即使他们不这样做，也需要某人说另一种语言来检查。
您准备了新版本，部分质量检查流程正在检查翻译。如果英语措辞发生了变化而且没有人检查翻译，它会像拇指一样伸出来并且会得到修复。
答案 1 :(得分：18)
答案 2 :(得分：7)
我们一直在使用抽象占位符，在创建新函数时必须将所有内容写入两次非常烦人。当英语是占位符时，你只需用英语编写代码，从一开始你就有了有意义的输出，而不必考虑命名占位符。
所以我的理由是开发人员的工作量减少了。
答案 3 :(得分：6)
我喜欢你的第二种方法。翻译文本时，您总是遇到同音异义词的问题。就像'open'可以表示窗口的状态，但也可以表示执行动作的动词。在其他语言中，这些同音异义词可能不存在。这就是为什么您应该能够在占位符中添加含义。最好的方法是将这个含义放在文本库中。如果在您使用的框架平台上无法做到这一点，那么定义“开发语言”可能是个好主意。这种语言将为文本条目添加含义，例如：'action_open'和'state_open'。你当然不得不付出额外的努力我将这种语言翻译成普通英语（或你为之开发的语言）。我把这个哲学放在一些大型项目中，从长远来看，这节省了一些时间（并且令人头痛）。
在我看来，最好的方法就是保持意义分离，所以如果你开发自己的翻译库或你使用的翻译库支持它，你可以这样做：
_(i18n("Please enter your name", "error_please_enter_name"));
其中：
i18n(text, meaning)
答案 4 :(得分：4)
有趣的问题。我假设主要原因是您在开发过程中不必关心翻译或本地化文件，因为主要语言在代码本身中。
答案 5 :(得分：3)
嗯，这可能只是它更容易阅读，更容易翻译。我认为你的方式最适合可扩展性，但它只需要额外的努力，一些开发人员可能认为不值得......而对于某些项目，它可能不是。
答案 6 :(得分：3)
有一个回退层次结构，从大多数特定区域设置到源代码中的非本地化版本。
法国的法国人可能会有以下后备路线：
因此，在源代码中使用正确的英语句子可以确保如果在步骤（1）或（2）中没有提供特定的翻译，那么至少会得到一个比随机程序员垃圾更合适的可理解句子，如“ ERROR_FILE_NOT_FOUND”。
另外，如果是格式字符串，你会怎么做：“抱歉，％s不存在”？更糟糕的是：“将％s条目写入％s，总大小：％d”？
答案 7 :(得分：3)
相当古老的问题，但我还没有在答案中看到另外一个原因：
最终可能会有更多的占位符，因此翻译人员的工作量会增加，翻译可能会出现不一致的情况。但是，像Poedit或Gtranslator这样的优秀编辑可能会对此有所帮助。
坚持你的榜样： 文本“请输入您的姓名”可能出现在不同模板中的不同上下文中（开发人员很可能不知道也不应该这样）。例如。它不能用作错误，而是用作输入字段占位符的提示。
如果您使用
_("Please enter your name");
它是可重用的，开发人员可能不知道已存在的错误消息密钥，并且只是直观地使用相同的文本。
但是，如果您使用
_("error_please_enter_name");
在之前的模板中，开发人员不一定会意识到这一点，并且会构成第二个密钥（最有可能根据预定义的措辞方案而不是完全混乱），例如。
_("prompt_please_enter_name");
然后必须再次翻译。
所以我认为这不能很好地扩展。预先商定的后缀/前缀的措辞方案，例如：对于上下文，我认为永远不会像文本本身一样精确（要么过于冗长，要么过于笼统，事先你不知道，之后就很难改变），对开发人员而言，更多的工作是不值得恕我直言。
有人同意/不同意吗？