讨论：解决i18n的另外一种方式

在Struts等框架中中大家比较习惯使用properties文件来解决i18n问题。在我现在的一个项目中，我使用不同的js文件来解决这个问题，发现还不错。
我写了一系列的js文件：**_zh_CN.js ,**.js
服务器端输出代码，比如user_not_found.
根据IE的版本或者客户的设定选用不同的js文件。
有一个问题就是，不能把所有的信心放在一个js文件里面，这样会导致js文件太大。

做是能这样做

但是我觉得维护成本高，properties多简单啊

我觉得满好，只不过，I18N不只是这样而已.

维护js比properties成本高吗？不觉得。
其实对应的一个properties文件对应一个js文件。我不知道成本高在那里

解决i18n的问题有三种经典思路，第一个是为每个页面提供每种语言的相关页面。第二种是把内容从表现形式中分离出来，做不同语言的内容文件。第三种是动态翻译页面内容。第三种很少见，而且机器翻译技术还很难达到人们的预期。第2种就是我们常用的properties。
这三种实现的前提都是要能够得到客户端希望显示的语种和编码。使用properties文件的时候我们不需要手动的从客户请求中去了解accept-language，因为java把这些工作都封装了，只要你提供了properties文件，并在页面中用相应的消息标签（jstl和各大framework都有支持），就能得到期望的显示内容。
楼主的思路可以说是结合了一和二，把内容分离出来，但不是放在properties中，是放在js文件中，相当于为每个页面提供了每种语言相关的js文件。
我原来一直觉得把整个网站的所有内容信息都放到一个properties中不是一个好习惯，会显得很臃肿、复杂，所以对于楼主的方法比较赞同。而且把决定显示那个语种的工作从服务器端挪到了客户端，减少了服务器端资源的消耗，而且改变了js文件页面显示能马上得到体现，无需考虑资源重新载入的问题。唯一的缺憾是目前没有好的工具支持。

不知猜测的对不对，还望楼主详细阐述设计思路以及实现手段。

如果你的JS的提示方式比较单一，应该差不多
不过如果你觉得比properties这种key=value的模式还简单的话，我没话说了 hehe

mvnforum的做法是用properties，不过它在发布时，根据不同的properties生成各种语言的JSP。用户可以随时选择不同的语言界面。

js中也是
key=value一样的。