There are three kinds of classical ideas for solving i18n problems

There are three classic ideas for solving i18n problems, the first is to provide each page with relevant pages for each language. The second is to separate the content from the representation and do the content files in different languages. The third is the dynamic translation of page content. The third is very rare, and machine translation technology is difficult to meet people's expectations. The 2nd kind is our commonly used properties.

The premise of these three implementations is to be able to get the language and coding that the client wants to display. When using properties files, we don't need to manually understand Accept-language from customer requests, because Java encapsulates these tasks, so long as you provide a properties file, The desired display is available on the page with the corresponding message labels (JSTL and the broad framework support).

In struts and other frameworks, we are more accustomed to using properties files to solve i18n problems. In my current project, I use a different JS file to solve this problem, I found it is not bad. I wrote a series of JS files: **_zh_cn.js, **.js server-side output code, such as User_not_found. According to the version of IE or customer settings to choose a different JS file. There is a problem is that you can not put all the confidence in a JS file inside, this will cause the JS file is too large.

The idea of the landlord can be said to be a combination of one and two, the content of separation, but not in the properties, is placed in the JS file, equivalent to each page to provide each language-related JS files.

I have always felt that the entire site to put all the content of a properties is not a good habit, will appear very bloated, complex, so the landlord's method is more agree. And the decision to display the language of the work from the server to the client, reduce the consumption of server-side resources, and changed the JS file page display can immediately be reflected, no need to consider the issue of resource reload. The only drawback is that there is no good tool support at the moment.