有人对资源文件中的键命名有什么建议吗？例如，您的键名是基于需要本地化的文本还是基于使用该文本的控件？
假设您在多个屏幕中有一个编辑按钮（一个用于编辑用户，一个用于编辑组）。您可以使用以下键：
或
或
您更喜欢哪种方案，为什么？
【问题讨论】：
标签： localization internationalization
我在字面量前加上用例或动作类名。例如：
PlaceOrder.invalidId=订单 {0} 的 ID 无效
PlaceOrder.success=您的订单 {0} 成功
PlaceOrder.fail.visa=您的签证是...
PlaceOrder.fail.communications=我们不能...
PlaceOrder.submit=立即购买
登录=登录
Login.fail=您的凭据没有...
Login.alread=您已经登录
这样可以避免碰撞：
EditStudent=编辑 EditClass=编辑 EditCourse=编辑课程
...还可以更轻松地找到您需要的东西。
我分组的另一种方式是按实体：
Person.id=# Person.name=名字 Person.surname=姓氏
这些可以显示为包含实体的表上的标题。它可以在以下情况下为您节省：
Person.id=# 类.id=# Course.id=课程编号
最后，通过在属性键中提供上下文，您可以避免错误翻译。比如我曾经有过：
否=否
它被用作左上角单元格的 id (#) 表头，但我们的法语翻译为法语做了这个：
否=非
...他认为是“不”这个词（是的否定）。 :)
当您想要重构/重命名类并快速更新这些属性键而无需查看模板时，最后（但并非最不重要）前缀将有助于您。
【讨论】：
我们以该术语的英文版本为基础。例如：编辑用户 那就是我们的开发人员可以轻松阅读它，并且可以在整个应用程序中需要该术语的多个位置重复使用。
【讨论】：
它以英文文本为基础，但以窗口/对话/你有什么作为前缀，其中出现了单词或短语。至少当布局空间有限时，您可能希望避免陷入到处都有完全相同的字符串的陷阱：这会阻止您使用缩写来获得体面的布局，尤其是在芬兰语等多音节语言中。
当然，您仍然应该努力在命名方面保持一致。如果您在商业上这样做，增加字符串的数量也会增加翻译成本。
不要忽视同音异义词的危险。提供上下文有助于防止这种情况。不要害怕使资源名称比实际的英文术语长，这可以大大帮助翻译人员。
【讨论】：
@cherouvim 的回答 +1，但它总是归结为文档。
记录每个值（使用资源源文件格式支持的任何注释机制），包括每个参数的数据类型（如果字符串是可格式化的）。例如，.resx 格式的 VS 编辑器公开了一个注释字段，这使得它非常容易。
这样的消息：
无法在 {1} 之前安排 {0} 作业。
将被记录为：
记录的错误消息，{0}：作业名称，{1} ISO 8601 格式的日期/时间。
【讨论】：
我认为首先应该使用某种 XML 文件来存储这种数据。
类似：
编辑>
按钮>
**
然后使用“翻译”类来获取（并设置/保存）文本。
类似：
myTranslateClass.load('translate.xml');
myTranslateClass.get( 'button' , 'edit' , 'user' );
这是一个简单的例子。
【讨论】：