ZK最佳国际化战略
您使用什么策略来国际化用 ZK 编写的 Web 应用程序？
我目前正在使用他们的“有趣”语法 ${c:l('LABEL_NAME')}，但它使用的机制有两个问题：
1）它不接受 \uchcode 语法，这是 java 中资源包的标准。无法从 NetBeans 编辑此类文件。
2）他们只为整个网络应用程序使用一个文件，该文件可能非常大，我担心可能的性能因素。
因此我有两个问题：
1）使用单个大属性文件是否会产生性能问题？
2）还有其他好的方法来国际化ZK应用程序（zscript我不认为是好的方法）？
What strategies do you use to internationalize web application written in ZK?
I'm currently using their 'funny' syntax ${c:l('LABEL_NAME')}, but it is using mechanism which has 2 problems:
1) It is not accepting \uchcode syntax, which is standard for resource bundles in java. There's no way to edit such files from NetBeans.
2) They are using only one file for whole webapp, which can be extremally large and I'm afraid of possible performance factor.
Therefore I have 2 questions:
1) Is the using of single large properties file a performance problem?
2) Are there any other good methods to internationalize ZK app (zscript I don't consider good method)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
1）这对我来说不是问题。语言文件比其他文件小得多（因此阅读它们的负载相当轻）
2）imo，我不会在我的在线项目中使用 zscript，您可以查看官方性能提示 - 不要使用 zscript 来获得更好的性能。
关于国际化 ZK 应用程序的更多信息，请参阅 ZK 开发者参考 - 标签
顺便说一句，我曾经创建一个 LabelManager 并管理不同语言/区域设置中的源。
1) it's not a issue for me. the language files are MUCH smaller than other files (so the loading of reading them are quite light)
2) imo, i won't use zscript in my online project, you can take a look the official performance tip - Not to Use zscript for Better Performance.
More info about internationalize ZK app, please refer to ZK Developer's Reference - Labels
btw, i used to create a LabelManager and manage the source in different langs/locales.
我认为加载 i18n 消息不存在性能问题，它使用快速哈希来定位消息，但存在内存问题（将消息文本加载到不同本地的内存中）。不过我不关心内存问题，因为它只是短信，而且服务器功能强大并且内存巨大。
对我来说，我总是使用 ascii 作为密钥，所以没有密钥编码问题。
有一点不方便的是我只能在一个 i3 文件中设置消息，如果我想设置多个（用于模块化消息）文件，我必须编写代码将 LabelLocator 注册到标签。
I think there doesn't have performance issue on load i18n message, it use fast hash to target a message, but a memory issue ( on load message text in to memory for different local). however i don't care memory issue since it is just text message and server is powerful and have huge memory.
and for me, I always use ascii as key, so no key-encoding issue.
one thing is not convenient is I can just set message in one i3 file, if I want to set multiple (for modularizing message) file I have to wright code registering a LabelLocator to Labels.
据我所知，c:l() 只是检索 I18N 标签的默认方法。如果您愿意，可以使用标准资源包。您所要做的就是实现一个静态方法，然后将其映射到 ZUL 页面。
As I know, c:l() is simply the default way to retrieve I18N labels. You could use the standard resource bundle if you like. All you have to do is to implement a static method and then use to map it to a ZUL page.