就两种国际化方法寻求建议本土化.我有一个使用Spring MVC和Dojo的Web应用程序,我想支持多种语言.所以,我可以：
>使用< spring：message>使用属性文件在服务器端生成适当的文本.
>使用dojo / i18n使用js文件在客户端选择适当的文本.
当然,两者的任何组合也是一种选择.
解决方法:
这两种方法的结合是唯一合理的答案.
基本上,你应该尝试坚持服务器端,并且只在真正需要时才做客户端(没有其他方法,就像你有一些动态创建的控件).
优点和缺点？客户端字符串外部化的主要内容是,您将无法正确翻译所有内容.那是因为背景.根据具体情况,相同的英语术语可能会以不同的方式翻译.
同时,您经常需要格式化消息(将参数添加到消息标记中),这在常规Java中通过调用messageformat.format()来完成.从理论上讲,你可以在客户端做到这一点,但至少可以说这是冒险的.您将无法访问原始消息部分(如日期,某些数据源,等等),这可能会损害翻译的正确性.
格式化日期,数字等在客户端更加痛苦.使用Dojo或jQuery Globalize是可能的,但结果可能不如它们应该的那么好.但是Spring无论如何都有格式化日期的问题(缺少默认的本地日期/时间指定,你可能只选择短,中,长,全,这对我来说完全没用).
另一个问题可能是处理复数形式(非英语).信不信由你,但语言可能有多个复数形式(取决于数量),因为翻译可能会有所不同.我认为Dojo根本不会处理它(但是,我可能会弄错,自我评估以来已经过去了一段时间). Spring也不会处理它,但是您可以构建基于ICU’s PluralRules的自定义解决方案(如果您足够难以学习格式并希望同时杀死翻译者,则可以构建PluralFormat).
简而言之,正确地做I18n远非易事,你将在服务器端获得更好的支持.
BTW.我记得Dojo非常“重”,库本身超过1MB ……加载它可能需要一段时间,而你的应用程序可能看起来比其他人慢……这是其中一个原因,我推荐Globalize而不是Dojo对于我们的项目.它可能没有那么多功能,但至少看起来很轻巧.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
