internationalization - 翻译文件中键值的最佳实践

Question

通常，转换方法采用键 > 值映射，并使用键将其转换为值。现在我认识到两种不同的方法来命名您的翻译键，在我的团队中，我们没有就似乎最好的方法达成共识。

方法一:
使用完整的英语单词或句子:

Name => Name
Please enter your email address => Please enter your email address

方法二:
使用关键字描述情况:

NAME => Name
ENTER_EMAIL => Please enter your email address

我个人更喜欢方法#1，因为它直接显示了消息的含义。如果翻译不存在，您可以回退到 key ，这不会导致任何问题。但是，当翻译频繁更改时，该方法很麻烦，因为所有文件都需要更新。同样对于较长的文本，这些键变得非常大。这是通过使用像 ENTER_EMAIL 这样的键来解决的。 ，但措辞完全脱离了上下文。抽象翻译键的列表将是巨大的，您需要所有键的元数据来解释它们的用法和冲突可以更容易地发生。

是否有两全其美的方法或第三种方法？您如何在应用程序中使用翻译键？在我们的例子中，它是一个基于 php 的 web 应用程序，但我认为上面的问题是通用的，足以谈论 i18n。

Answer 1

这也是 iOS/OSX 开发者面临的问题。对他们来说，甚至还有一个 standard tool called genstrings 假设方法 1。但当然 Apple 开发人员不必使用此工具——我不需要。

虽然您使用方法 1 获得的安全网很好(即，如果您以某种方式忘记本地化字符串，您可以显示 key )，但它的缺点是可能导致 key 冲突。有时，由于语法规则或上下文差异，需要以两种不同的方式本地化一段相同的显示文本。例如，“电子邮件”的法语翻译如果是对话框标题，则为“电子邮件”，如果是按钮，则翻译为“Envoyer un e-mail”(在法语中，“电子邮件”一词只是一个名词和不能用作动词，不像在英语中它既是名词又是动词)。使用方法 2，您可以使用 EMAIL_TITLE 和 EMAIL_BUTTON 键来解决此问题，作为奖励，这将为翻译人员提供提示，帮助他们正确翻译。

方法 2 的另一个优点是您可以更改英文文本，而不必担心更新英文和所有本地化版本的 key 。

所以我推荐方法2!