i18n 服务器端与客户端

Question

就国际化和本地化的两种方法寻求一些建议。我有一个使用 Spring MVC 和 Dojo 的 Web 应用程序，我想支持多种语言。所以，我可以：

1. 用于<spring:message>使用属性文件在服务器端生成适当的文本。
2. 用于dojo/i18n使用 js 文件在客户端选择适当的文本。

当然，两者的任何组合也是一种选择。

那么，每种方法的优缺点是什么？你什么时候会使用一个和另一个？

Answer 1

这两种方法的结合是唯一合理的答案。基本上，您应该尝试坚持使用服务器端，并且仅在确实必要时才使用客户端（没有其他方法，就像您有一些动态创建的控件一样）。

优点和缺点？客户端字符串外部化的主要缺点是，您将无法正确翻译所有内容。这是因为上下文。根据上下文，相同的英语术语可能会以不同的方式翻译。
同时，您经常需要格式化消息（向消息标记添加参数），在常规 Java 中，您可以通过调用MessageFormat.format(). 理论上，您可以在客户端执行此操作，但至少可以说这是有风险的。您将无法访问原始消息部分（例如日期、某些数据源等），并且可能会损害翻译的正确性。
在客户端格式化日期、数字等更加痛苦。使用 Dojo 或 jQuery Globalize 是可能的，但结果可能不如应有的那么好。但无论如何，Spring 在格式化日期方面存在问题（缺乏默认的本地日期/时间指定，您只能从短、中、长、完整中进行选择，这对我来说完全没有用）。
另一个问题可能是处理复数形式（非英语）。不管你相信与否，语言可能有不止一种复数形式（取决于数量），因此翻译可能会有所不同。我认为 Dojo 根本没有处理它（但是，我可能是错的，自从我评估它以来已经过去了一段时间）。Spring 也不会处理它，但您可以基于ICU 的 PluralRules构建自定义解决方案（如果您很难学习格式化并且想同时杀死翻译器，则可以使用 PluralFormat）。

长话短说，正确执行 I18n 绝非易事，您将在服务器端获得更好的支持。

顺便提一句。我记得 Dojo 相当“重”，库本身超过 1MB...加载它可能需要一段时间，并且与其他应用程序相比，您的应用程序可能看起来很慢...这就是原因之一，我推荐Globalize而不是 Dojo对于我们的项目。它可能没有那么多功能，但至少看起来很轻量。