i18n服务器端与客户端 [英] i18n server-side vs. client-side

问题描述

就两种国际化方法寻求建议.本土化.我有一个使用Spring MVC和Dojo的Web应用程序，并且我想支持多种语言.因此，我可以:

Seeking some advice on two approaches to internationalization & localization. I have a web app using Spring MVC and Dojo, and I would like to support multiple languages. So, I could:

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

1. Use <spring:message> to generate the appropriate text on the server side using a properties file.
2. Use dojo/i18n to select the appropriate text on the client side using a js file.

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

And of course any combination of the two is also an option.

那么，每种方法的优缺点是什么?您何时会使用一个与另一个?

So, what are the pros and cons of each approach? When would you use one vs. the other?

推荐答案

这两种方法的组合是唯一合理的答案. 基本上，您应该尝试坚持服务器端，并且仅在确实需要时才进行客户端(没有其他方法，就像您有一些动态创建的控件一样).

The combination of these two approaches is the only reasonable answer. Basically, you should try to stick to server-side, and only do client-side when it is really necessary (there is no other way, like you have some dynamically created controls).

利弊?客户端字符串外部化的主要缺点是，您将无法正确翻译所有内容.那是因为上下文.取决于上下文，相同的英语术语可能会以不同的方式翻译.
同时，您通常需要格式化消息(在消息标签中添加参数)，这在常规Java中可以通过调用MessageFormat.format()来完成.从理论上讲，您可以在客户端执行此操作，但这至少可以说是有风险的.您将无法访问原始消息部分(例如日期，某些数据源，等等)，这可能会损害翻译的正确性.
在客户端格式化日期，数字等会更加麻烦.使用Dojo或jQuery Globalize可以实现，但结果可能不尽如人意.但是无论如何，Spring仍然存在格式化日期的问题(缺少默认本地日期/时间指定，您只能选择短，中，长，完整，对我来说这完全没用).
另一个问题可能是处理复数形式(非英语).相信与否，但语言可能具有不止一种复数形式(取决于数量)，因此翻译可能会有所不同.我认为Dojo根本不会处理它(但是，我可能会误认为，自评估以来已经过去了一段时间). Spring不会很好地处理它，但是您可以基于 ICU的 PluralRules (或PluralFormat，如果您很难学习格式化的话并希望同时杀死翻译者.

Pros and cons? The main con of client-side string externalization is, you won't be able to translate everything correctly. That's because of context. The same English terms might be translated in a different way, depending on the context.
At the same time, you will often need to format message (add parameters to your message tag), which in regular Java you would do by calling MessageFormat.format(). Theoretically, you could do that on the client-side, but this is risky to say the least. You won't have access to original message parts (like dates, some data sources, whatever) and it might hurt translation correctness.
Formatting dates, numbers, etc. is more painful on the client-side. It is possible with Dojo or jQuery Globalize, but the results might not as good as they should be. But Spring has problem with formatting dates, anyway (lack of default local date/time designation, you may only choose from short, medium, long, full, which to me is completely useless).
Another issue might be handling plural forms (non-English). Believe, or not but languages may have more than one plural form (depending on the quantity) and because of that translations might differ. I don't think Dojo is handling it at all (however, I might be mistaken, some time has past since I evaluated it). Spring won't handle it as well, but you may build custom solution based on ICU's PluralRules (or PluralFormat if you're hard enough to learn formatting and want to kill the translators at the same time).

简而言之，正确地执行I18n绝非易事，您将在服务器端获得更好的支持.

To cut a long story short, doing I18n correctly is far from being easy and you'll get better support on the server side.

顺便说一句.我记得Dojo相当繁重"，库本身超过1MB ...可能需要一段时间才能加载它，并且与其他应用程序相比，您的应用程序似乎很慢...这是原因之一，我建议全球化，而不是我们项目的Dojo.它可能没有那么多功能，但至少看起来很轻巧.

BTW. I remember Dojo as quite "heavy", library itself was over 1MB... It might take a while to load it and your application might seem slow comparing to others... That was one of the reasons, I recommended Globalize rather than Dojo for our projects. It might not have so many features, but at least it seems lightweight.

这篇关于i18n服务器端与客户端的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！