一般来说，翻译方法需要一个关键词＆gt;值映射并使用键将其转换为值。现在我认识到两种不同的方法来命名您的翻译密钥，在我的团队中，我们没有达成共识，这似乎是最好的方法。
方法1： 使用完整的英语单词或句子：
Name => Name
Please enter your email address => Please enter your email address
方法2： 使用描述情况的关键字：
NAME => Name
ENTER_EMAIL => Please enter your email address
我个人更喜欢方法＃1，因为它直接显示了消息的含义。如果翻译不存在，您可以回到密钥，这不会导致任何问题。但是，当翻译频繁更改时，该方法很麻烦，因为需要更新所有文件。此外，对于较长的文本，这些键变得非常大。这可以通过使用ENTER_EMAIL之类的键来解决，但是语法完全不在上下文中。抽象翻译密钥列表非常庞大，您需要所有密钥的元数据来解释其使用情况，并且可以更容易地发生冲突。
两种世界或第三种方法都是最好的吗？如何在应用程序中使用翻译键？在我们的例子中，它是一个基于php的Web应用程序，但我认为上面的问题通用性足以谈论i18n。
答案 0 :(得分：20)
这是iOS / OSX开发人员也面临的一个问题。对于他们来说，甚至有一个standard tool called genstrings假设方法1.但当然Apple开发人员不必使用这个工具 - 我没有。
虽然您使用方法1获得的安全网很好（即如果您以某种方式忘记了本地化字符串，您可以显示密钥），但它的缺点是它可能导致密钥冲突。有时，由于语法规则或上下文的差异，需要以两种不同的方式对一段相同的显示文本进行本地化。例如，“电子邮件”的法语翻译如果是对话标题则为“电子邮件”，如果是按钮则为“Envoyer un e-mail”（法语中“电子邮件”一词仅为名词，不能用作动词，不像英语，它既是名词又是动词）。使用方法2，您可以使用键EMAIL_TITLE和EMAIL_BUTTON来解决此问题，作为奖励，这将提示翻译人员帮助他们正确翻译。
方法2的另一个优点是您可以更改英文文本，而无需担心用英语和所有本地化更新密钥。
所以我推荐方法2！
答案 1 :(得分：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线程一样，而且例如当一组开发人员争夺编码风格时）。