就两种国际化方法寻求建议。本土化。我有一个使用Spring MVC和Dojo的Web应用程序，我想支持多种语言。所以，我可以：
<spring:message>使用属性文件在服务器端生成相应的文本。dojo/i18n使用js文件在客户端选择适当的文本。 当然，两者的任何组合也是一种选择。
那么，每种方法的优缺点是什么？你什么时候使用一个与另一个？
答案 0 :(得分：1)
这两种方法的结合是唯一合理的答案。 基本上，你应该尝试坚持服务器端，并且只在真正需要的时候做客户端（没有其他方法，比如你有一些动态创建的控件）。
利弊？客户端字符串外部化的主要内容是，您将无法正确翻译所有内容。那是因为背景。根据具体情况，相同的英语术语可能会以不同的方式翻译
同时，您经常需要格式化消息（将参数添加到消息标记中），这可以通过调用MessageFormat.format()在常规Java中进行。从理论上讲，你可以在客户端做到这一点，但至少可以说这是冒险的。您将无法访问原始消息部分（如日期，某些数据源，等等），这可能会损害翻译的正确性
格式化日期，数字等在客户端更加痛苦。使用Dojo或jQuery Globalize是可能的，但结果可能不如它们应该的那么好。但是Spring无论如何都有格式化日期的问题（缺少默认本地日期/时间指定，你可能只选择短，中，长，全，这对我来说完全没用）。
另一个问题可能是处理复数形式（非英语）。信不信由你，但语言可能有多个复数形式（取决于数量），因为翻译可能会有所不同。我认为Dojo根本不会处理它（但是，我可能会弄错，自我评估以来已经过去了一段时间）。 Spring也不会处理它，但您可以基于ICU's PluralRules构建自定义解决方案（如果您足够难以学习格式并希望同时杀死翻译者，则可以构建PluralFormat）
简而言之，正确地做I18n远非易事，你将在服务器端获得更好的支持。
顺便说一句。我记得Dojo非常“沉重”，库本身超过1MB ......加载它可能需要一段时间，而且与其他应用程序相比，你的应用程序可能看起来很慢......这是其中一个原因，我建议{{3}而不是我们项目的Dojo。它可能没有那么多功能，但至少看起来很轻巧。