为什么人们使用简单的英语作为翻译占位符？答案

【问题标题】：Why do people use plain english as translation placeholders?为什么人们使用简单的英语作为翻译占位符？
【发布时间】：2011-05-13 02:05:10
【问题描述】：

这可能是一个愚蠢的问题，但这里是。

我见过几个项目使用一些翻译库（例如 gettext）与简单的英语占位符一起工作。比如：

_("Please enter your name");

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

_("error_please_enter_name");

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

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

这样做绝对不是正确的规范化。这种方法有我没有看到的巨大优势吗？

【问题讨论】：

Gettext: Is it a good idea for the message ID to be the english text?的可能重复

标签： internationalization gettext

【解决方案1】：

是的，您必须更改现有的翻译文件，这是一件好事。

如果您更改英文措辞，翻译可能也需要更改。即使他们不这样做，您也需要会说另一种语言的人来检查。

您准备了一个新版本，而 QA 流程的一部分是检查翻译。如果英文措辞改变而没有人检查翻译，它会像拇指酸痛一样伸出来，它会得到修复。

【讨论】：

+1 关于翻译在更改时需要中断的问题。
当然，有有种情况是不需要改变翻译的，即如果对英文措辞的改变并没有改变它的意思（琐碎的改写，拼写修复，空格变化）。在那种情况下，需要检查所有的翻译确实是个问题。
@sleske 可能这有点晚了，但是可以通过为基本语言创建一个翻译文件来解决改写/拼写问题，只需更改该字符串即可，这样您就不需要更改消息 ID。
在很多地方使用相同的 id 怎么样？想象一下使用了二十次甚至更多次的错误消息？使用简单的英语 msgid 会迫使您在代码中的每次使用中都更改它，而不仅仅是在 .PO 文件中更改一次。

【解决方案2】：

主要语言已经存在：您不需要翻译它。
与含糊的占位符相比，翻译者对真实句子的上下文更好。
占位符只是键，仍然可以通过为其创建翻译来更改原始语言。因为当翻译不存在时，它使用占位符作为翻译文本。

【讨论】：

请注意，2. 并不是真正的问题——如果您使用占位符，翻译人员只需要使用一个工具，在占位符旁边显示原始文本。不过，gettext 不需要这样的工具，使这更容易一些。

【解决方案3】：

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

所以我的理由是减少开发人员的工作量。

【讨论】：

是的，这就是根据 gettext 文档的原因：“GNU gettext 旨在最大限度地减少国际化对程序源的影响，使这种影响尽可能小且几乎不引人注意”（来自 gettext 手册, gnu.org/software/gettext/manual/gettext.html#Why)。

【解决方案4】：

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

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

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

地点：

i18n(text, meaning)

【讨论】：

现在我想起来了，这就是我倾向于这种方法的主要原因：您可以在单词中添加无限的上下文，以便在翻译时更容易理解。说得好，+1
实际上，gettext 有处理这种情况的机制，称为“上下文”。请参阅 gettext 手册“11.2.5 使用上下文解决歧义”。 gnu.org/software/gettext/manual/gettext.html#Contexts

【解决方案5】：

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

【讨论】：

是的，这可能是主要原因 - 对于单独的程序员和小团队来说有点可以理解，但是当你有 20 个由不同人维护的翻译文件时，它就会变得非常痛苦。这就是为什么我不明白为什么这似乎是某种行业标准

【解决方案6】：

嗯，它可能只是更容易阅读，也更容易翻译。我认为你的方式最适合可扩展性，但它确实需要额外的努力，一些开发人员可能认为不值得……而对于某些项目，可能不值得。

【讨论】：

【解决方案7】：

有一个后备层次结构，从最特定的语言环境到源代码中的非本地化版本。

所以法国的法语可能有以下后备路线：

fr_FR
法国
未本地化。源代码。

因此，在源代码中使用正确的英文句子可以确保如果在步骤 (1) 或 (2) 中没有提供特定的翻译，您至少会得到一个正确易懂的句子，而不是像“ error_file_not_found”。

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

【讨论】：

我个人更喜欢在这种情况下看到垃圾，所以我不会忽视问题，或者我什至告诉我的翻译引擎抛出错误。尽管如此，这是有效的信息，并且肯定是以这种方式工作的一个强有力的理由
格式化字符串错误——尤其是在使用 %s 时——不会导致垃圾，但会导致非常烦人的随机崩溃。

【解决方案8】：

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

您最终可能会得到比必要更多的占位符，从而导致翻译人员的工作量增加，并且可能出现不一致的翻译。但是，像 Poedit 或 Gtranslator 这样的优秀编辑器可能会对此有所帮助。

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

如果你使用

_("Please enter your name");

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

但是，如果你使用过

_("error_please_enter_name");

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

_("prompt_please_enter_name");

然后必须再次翻译。

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

有人同意/不同意吗？

【讨论】：