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

Question

这可能是一个愚蠢的问题,但这里有.

我见过几个项目使用一些翻译库(例如gettext)和普通英语占位符一起工作.例如:

_("Please enter your name");

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

_("error_please_enter_name");

我已经看到有关SO的各种建议与前一种方法一起工作,但我不明白为什么.我不知道如果你需要改变英语措辞,你会怎么做？因为如果将实际文本用作所有现有翻译的密钥,则还必须编辑所有翻译,并更改每个密钥.或者不是吗？

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

以这种方式做这绝对不是正确的规范化.我没有看到这种方法有很大的优势吗？

Answer 1

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

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

您准备了新版本,部分QA流程正在检查翻译.如果英语措辞发生了变化而且没有人检查翻译,它会像拇指一样伸出来并且会得到修复.

Answer 2

1. 主要语言已经存在:您不需要翻译它.
2. 与含糊不清的占位符相比,译者有更好的语境和真实的句子.
3. 占位符只是关键,仍然可以通过为其创建翻译来更改原始语言.因为当翻译不存在时,它使用占位符作为翻译文本.

Answer 3

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

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

Answer 4

我喜欢你的第二种方法.翻译文本时,你总是会遇到同音异义的问题.就像'open'可以表示窗口的状态,但也可以表示执行动作的动词.在其他语言中,这些同音异义词可能不存在.这就是为什么你应该能够为占位符添加意义的原因.最好的方法是将这个含义放在文本库中.如果在您使用的框架平台上无法做到这一点,那么定义"开发语言"可能是个好主意.这种语言将为文本条目添加含义,例如:'action_open'和'state_open'.你当然不得不付出额外的努力我将这种语言翻译成普通英语(或你为之开发的语言).我把这个哲学放在一些大型项目中 从长远来看,这节省了一些时间(和头痛).

在我看来,最好的方法是保持意义分离,所以如果你开发自己的翻译库或你使用的翻译库支持它,你可以做这样的事情:

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

哪里:

i18n(text, meaning)