sku*_*urt 18 naming-conventions internationalization
我们的网站应该翻译成不同的语言.一些措辞在消息属性文件中准备好进行翻译.我现在想要将其余文本添加到这些文件中.
命名文本块的好方法是什么?
<view>.<type>.<name>
Run Code Online (Sandbox Code Playgroud)
我们主要有网页,一些网站上有一些元素/模块在重复.
Paw*_*yda 11
据我所知,没有"标准"存在.因此很难说出什么是正确的以及什么是命名资源键的不正确方法.但是,根据我的经验,我可以这样推荐:
property file name: <module>.properties
resource keys: <view or dialog>[.<sub-context>].<control-type>.<name>
Run Code Online (Sandbox Code Playgroud)
我们可以讨论是否将一个模块中的每个字符串放入一个属性文件的正确方法 - 如果更新不经常发生并且没有那么多消息,那么可能是正确的.否则,您可能会考虑每个视图一个文件.
至于关键的命名策略:对于译者而言(听起来像是有尊贵的州长阿诺德S.的电影不是吗?)有一个上下文是很重要的.翻译实际上可能取决于它,即在波兰语中,如果是页面/对话框/任何标题,您将以不同的方式翻译消息,如果是按钮上的文本,则以完全不同的方式翻译消息.
此类资源键的一个示例可以是:
preferences.password_area.label.username=User name
Run Code Online (Sandbox Code Playgroud)
它为译者提供了足够的提示,说明它实际上是什么,这可能导致正确的翻译......
我们使用点符号和驼峰案例提出了以下关键命名约定(Java,btw):
标签键(表单标签,页面/表单/应用程序标题等...即,不是完整的句子;用于多个UI位置):
如果标签表示Java字段(即表单字段)并匹配表单标签:label.nameOfField
Else:label.sameAsValue
例子:
内容密钥:
projectName.uiPath.messageOrContentType.n.*
哪里:
例子:
优点/缺点:
+标签键可以轻松重复使用; 位置无关紧要.
+对于未重复使用的内容密钥,在UI上查找页面将是简单而合理的.
- 标签键位于UI上的翻译者可能不太清楚.对于不浏览页面的翻译人员来说,这可能不是问题,但对于开发人员来说可能仍然是一个问题.
- 如果必须在UI上的多个位置使用内容密钥(很可能),则在其他位置选择密钥名称是没有意义的.在我们的案例中,管理层并不关心内容区域的重复值,因此在这种情况下我们将使用不同的键(以在UI上显示位置).
对此公约的反馈 - 特别是将改进它的反馈 - 将非常受欢迎,因为我们正在修改我们的资源包!:)