提问人：Pekka 提问时间：11/20/2010 最后编辑：Arnaud MeuretPekka 更新时间：8/9/2013 访问量：2006
为什么人们使用简单的英语作为翻译占位符？
Why do people use plain english as translation placeholders?
问：
这可能是一个愚蠢的问题，但这里是。
我见过几个项目使用一些翻译库（例如 gettext）使用简单的英语占位符。例如：
_("Please enter your name");
而不是抽象的占位符（这一直是我的本能偏好）
_("error_please_enter_name");
我已经看到关于 SO 使用前一种方法的各种建议，但我不明白为什么。我不明白的是，如果你需要改变英文措辞，你会怎么做？因为如果将实际文本用作所有现有翻译的键，您也必须编辑所有翻译，并更改每个键。或者不是吗？
这不是很麻烦吗？为什么这是行业标准？
这样做绝对不是正确的规范化。这种方法有我没有看到的巨大优势吗？
答：
4赞
ThiefMaster
11/20/2010
#1
有趣的问题。我认为主要原因是您在开发过程中不必关心翻译或本地化文件，因为主要语言在代码本身中。
评论
1赞
Pekka
11/20/2010
是的，这可能是主要原因 - 对于单独的程序员和小团队来说，这在某种程度上是可以理解的，但是当您拥有由不同人维护的 20 个翻译文件时，这就会变得非常痛苦。这就是为什么我不明白为什么这似乎是某种行业标准
20赞
Savageman
11/20/2010
#2
- 主要语言已经存在：您不需要翻译它。
- 与模糊的占位符相比，译者对真实句子的上下文更好。
- 占位符只是键，仍然可以通过为其创建翻译来更改原始语言。因为当翻译不存在时，它使用占位符作为翻译文本。
评论
3赞
sleske
11/28/2011
请注意，2.这并不是真正的问题 - 如果您使用占位符，翻译人员只需要使用一个工具，在占位符旁边显示原始文本。尽管如此，gettext 还是通过不需要这样的工具使这变得更容易一些。
32赞
Nicholas Knight
11/20/2010
#3
是的，您必须更改现有的翻译文件，这是一件好事。
如果更改英文措辞，翻译可能也需要更改。即使他们不这样做，您也需要会说另一种语言的人来检查。
您准备一个新版本，QA 流程的一部分是检查翻译。如果英文措辞发生了变化，没有人检查翻译，它就会像拇指酸痛一样突出，并且会得到修复。
评论
0赞
Orbling
11/20/2010
+1 关于翻译在更改时需要中断的极好观点。
5赞
sleske
11/28/2011
当然，在某些情况下，翻译不需要更改，即如果对英语措辞的更改不会改变其含义（琐碎的改写、拼写修复、空格更改）。在这种情况下，检查所有翻译确实是一个问题。
1赞
lordscales91
3/13/2016
@sleske 这可能来得有点晚，但可以通过为基本语言创建一个翻译文件来解决，只需更改该字符串，这样您就不需要更改消息 ID。
1赞
Ben Lime
6/13/2018
在很多地方使用相同的 ID 怎么样？想象一下，一条错误消息被使用了二十次甚至更多次？使用简单的英语会迫使您在代码中的每次用法中更改它，而不仅仅是在文件中更改一次。msgid.PO
3赞
Nathan MacInnes
11/20/2010
#4
嗯，这可能只是它更容易阅读，更容易翻译。我认为你的方式最适合可扩展性，但它确实需要额外的努力，一些开发人员可能认为不值得......对于某些项目来说，情况可能并非如此。
5赞
Jan
11/20/2010
#5
我喜欢你的第二种方法。在翻译文本时，您总是会遇到同音异义词的问题。就像“打开”一样，可以表示窗口的状态，也可以表示执行动作的动词。在其他语言中，这些同音异义词可能不存在。这就是为什么您应该能够为占位符添加含义的原因。最好的方法是将此含义放在文本库中。如果这在您使用的框架平台上是不可能的，那么定义“开发语言”可能是个好主意。这种语言将为文本条目添加含义，例如：“action_open”和“state_open”。当然，您将不得不付出额外的努力，我将这种语言翻译成简单的英语（或您开发的语言）。我已经将这一理念融入了一些大型项目中，从长远来看，这节省了一些时间（和麻烦）。
在我看来，最好的方法是将含义分开，因此，如果您开发自己的翻译库或您使用的翻译库支持它，则可以执行以下操作：
_(i18n("Please enter your name", "error_please_enter_name"));
哪里：
i18n(text, meaning)
评论
1赞
Pekka
11/20/2010
现在我想起来了，这就是我倾向于使用这种方法的主要原因：您可以在单词中添加无限的上下文，从而在翻译时更容易正确。说得好，+1
8赞
sleske
11/28/2011
实际上，有处理这个问题的机制，称为“上下文”。请参阅 gettext 手册“11.2.5 使用上下文解决歧义”。gnu.org/software/gettext/manual/gettext.html#Contextsgettext
3赞
user268396
11/20/2010
#6
有一个回退层次结构，从最具体的区域设置到源代码中的未本地化版本。
因此，法国的法语可能有以下回退路线：
- fr_FR
- 法国
- 未本地化。源代码。
因此，在源代码中拥有适当的英语句子可以确保如果步骤 （1） 或 （2） 中没有提供特定的翻译，您至少会得到一个正确可理解的句子，而不是像“error_file_not_found”这样的随机程序员垃圾。
另外，如果它是一个格式字符串：“对不起，但%s不存在”，你会怎么做？更糟糕的是：“将 %s 个条目写入 %s，总大小：%d”？
评论
0赞
Pekka
11/20/2010
在这种情况下，我个人更喜欢看到垃圾，这样我就不会忽视问题，或者我什至告诉我的翻译引擎抛出错误。尽管如此，这是有效的信息，肯定是以这种方式工作的有力理由之一
0赞
ThiefMaster
11/20/2010
格式字符串错误 - 尤其是在使用 %s 时 - 不会导致垃圾，但会导致随机崩溃，这非常烦人。
8赞
che
11/20/2010
#7
我们使用抽象占位符已经有一段时间了，在创建新函数时必须将所有内容写入两次非常烦人。当英语是占位符时，你只需用英语编写代码，你从一开始就有有意义的输出，而不必考虑命名占位符。
因此，我的理由是减少开发人员的工作量。
评论
0赞
sleske
11/28/2011
是的，这就是 gettext 文档的原因：“GNU gettext 旨在将国际化对程序源代码的影响降到最低，使这种影响尽可能小且几乎不明显”（摘自 gettext 手册，gnu.org/software/gettext/manual/gettext.html#Why ）。
3赞
benebun
7/26/2012
#8
这是一个很古老的问题，但我还没有在答案中看到另一个原因：
您最终可能会得到不必要的占位符，从而为翻译人员带来更多的工作量，并可能造成不一致的翻译。但是，像 Poedit 或 Gtranslator 这样的优秀编辑器可能会对此有所帮助。
坚持你的榜样： 文本“请输入您的姓名”可能会出现在不同模板的不同上下文中（开发人员很可能不知道，也不需要）。例如，它不能用作错误，而是用作提示，例如输入字段的占位符。
如果您使用
_("Please enter your name");
它是可重用的，开发人员可能不知道错误消息的现有密钥，而只是直观地使用相同的文本。
但是，如果您使用
_("error_please_enter_name");
在以前的模板中，开发人员不一定会意识到这一点，并且会组成第二个密钥（很可能是根据预定义的措辞方案，以免最终陷入完全混乱），例如
_("prompt_please_enter_name");
然后必须再次翻译。
所以我认为这不能很好地扩展。预先商定的后缀/前缀措辞方案，例如上下文，我认为永远不可能像文本本身那样精确（要么太冗长，要么太笼统，事先你不知道，之后很难改变）并且对于开发人员来说是更多的工作，恕我直言，这不值得。
有人同意/不同意吗？
评论