27

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

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

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

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

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

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

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

4

2 回答 2

22

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

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

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

所以我推荐方法2！

于 2012-05-18T14:44:42.927 回答
1

为什么不使用两个世界？我对短字符串使用方法#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 与方法 #2 线程中，而且例如当开发人员团队为编码风格而争吵时）。

于 2015-08-31T15:09:26.610 回答