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

Question

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

方法1：使用完整的英文单词或句子:

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

方法二：使用描述情况的关键词：

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

我个人更喜欢第一种方法，因为它直接显示了消息的含义。如果翻译不存在，你可以回退到关键字上，并且这不会造成任何问题。然而，如果翻译经常更改，这种方法会很麻烦，因为所有文件都需要更新。对于较长的文本，这些关键字变得非常大。可以通过使用像ENTER_EMAIL这样的键来解决这个问题，但是措辞完全脱离上下文。抽象翻译键列表将会很庞大，你需要元数据来解释所有键的使用情况，碰撞可能更容易发生。

有没有两全其美或第三种方法？你如何在你的应用程序中使用翻译键？在我们的情况下，这是一个基于 PHP 的 Web 应用程序，但我认为上述问题足够通用，可以谈论 i18n 的问题。

- Jurian Sluiman

---

有趣的问题。 我也倾向于方案1，但在情况需要时会采用混合方案。 - Ja͢ck

我更喜欢第二种方案，当然，前提是每个条目都必须有英文（或原始语言）输入。每个记录还应包括最后更新的日期/时间，以指出已更改的消息和需要更新翻译的需求。另外，应存储一条记录，告知原始语言是什么。 - Jonathan M

Answer 1

这同样也是iOS/OSX开发人员面临的问题。对于他们，有一个称为“genstrings”的标准工具假定使用方法1。当然，苹果开发人员不必使用此工具-我没有用。

使用第一种方法可以获得安全保障（例如，如果您忘记本地化字符串，则可以显示密钥），但缺点是可能会导致密钥冲突。有时，由于语法规则或上下文的差异，相同的文本需要以两种不同的方式进行本地化。例如，“电子邮件”的法语翻译在对话框标题中将是“E-mail”，而在按钮中将是“Envoyer un e-mail”（在法语中，“电子邮件”仅是名词，不能用作动词，不像英语中同时是名词和动词）。使用第二种方法，您可以使用EMAIL_TITLE和EMAIL_BUTTON键解决此问题，并且作为奖励，这将向翻译人员提供提示，以帮助他们正确翻译。

第2种方法的另一个优点是，您可以更改英文文本，而无需担心更新英文和所有本地化中的密钥。

因此，我建议使用方法2！

- Clafou

---

你提供的 EMAIL_TITLE 和 EMAIL_BUTTON 的例子非常好，但我认为这不是一个现实的例子。作为英语开发人员，你不知道这个法语情况。所以你首先写下 E-mail (#1) 或者 EMAIL (#2)。然后你的法语翻译回来告诉你他需要两个键，于是你把按钮改成了 E-mail (button) (#1) 或者 EMAIL_BUTTON (#2)。两种方法的过程都是一样的，最终你会遇到冲突，需要解决它。你对此有什么想法？ - Jurian Sluiman

开发人员需要了解一些国际化规则。他们不必知道特定的语言，只需知道，在这种情况下，一段文本不能被期望在不同的上下文中重复使用（即使在英语中没有问题）。因此，在开发应用程序时，当您为“电子邮件”按钮引入新字符串时，即使您已经看到了不同上下文中的“电子邮件”，您也需要向字符串表中添加一个条目。 - Clafou

请注意，对于许多平台来说，这个不可重用的规则得到了帮助，因为 UI 视图是在捆绑包中本地化的，您不需要编写代码从字符串表中加载每个文本片段（因此您经常会获得要翻译的相同英文文本的多个实例，但这没关系，因为它们的上下文可能不同）。 - Clafou

最终我们将采用方法#1，但我会接受你的答案（因为一切都解释得很好）。使用gettext，我们现在扫描整个代码库。如果一个英语句子被更改了，它会自动更新到gettext文件中。我们还可以比预期更容易地使用POedit将键复制到值上。我们还没有遇到您提到的限制，但这可能是因为我们只有英语、荷兰语、德语和俄语版本，还没有法语版本。我们会看看如果问问我们的翻译员会发生什么 :) - Jurian Sluiman

参见https://dev59.com/SXVC5IYBdhLWcg3wrDNd#13978656。例如，它可能是一个指向社交网络的链接，在美国它可能是Facebook，但在中国它可能是微博。因此，MsgIds可能是类似于socialSiteUrl和socialSiteLabel的东西。 - Ryan

Answer 2

为什么不两者兼顾呢？我使用方法1来处理短字符串，使用方法2来处理长句子。我不介意在同一个文件中混合使用两种方法。

例如，在以下字符串中，如果在新的应用程序版本中修改了用户体验，则文本可能会更改：

"screen description" = "Tap the plus button to add a new item. Tap an item for more options or to edit its details.";

因此，在这种情况下，应该采用方法 #2。但是对于像下面示例中的简单字符串，方法 #1 更加有用:

"Preferences" = "Preferences";

一般来说，当人们试图标准化事物时，我常常觉得这是一种限制。个人而言，我更喜欢一种更“无政府主义”的方法，即多种方法都是有效的（不仅仅是在这个方法#1 vs 方法#2的线程中，还包括例如开发团队在编码风格上的争论）。

- bio