Go语言视频零基础入门到精通

2878qw

今天看到国际化的一种实现，比较戳，不过也算一种方法，贴出来记录一下
Js代码
<%@ taglib prefix="s" uri="/struts-tags"%>   
  
XXXConstants = {version:"1.0"};   
  
XXXConstants.COMMON_SERVER_ERROR = '<s:text name="server.error" />';   
XXXConstants.COMMON_CONFIRM_TITLE = '<s:text name="common.confirm.title" />';  

<%@ taglib prefix="s" uri="/struts-tags"%>

XXXConstants = {version:"1.0"};

XXXConstants.COMMON_SERVER_ERROR = '<s:text name="server.error" />';
XXXConstants.COMMON_CONFIRM_TITLE = '<s:text name="common.confirm.title" />';


这个其实是一个js文件，但是它的后缀是.jsp（奇葩），目的是用struts2的tag渲染一下，获取资源文件里的文本常量。

然后在其他的js文件里，就可以直接引用了，比如
Js代码
alert(XXXConstants.COMMON_SERVER_ERROR);  

    alert(XXXConstants.COMMON_SERVER_ERROR);


然后维护这些资源文件。

确实有点戳，一般比较常规的做法是
Js代码
  
XXXConstants = {version:"1.0"};   
  
XXXConstants.COMMON_SERVER_ERROR = "服务错误";  

XXXConstants = {version:"1.0"};

XXXConstants.COMMON_SERVER_ERROR = "服务错误";


这个是XXXConstants_cn.js

Js代码
  
XXXConstants = {version:"1.0"};   
  
XXXConstants.COMMON_SERVER_ERROR = "server error";  

XXXConstants = {version:"1.0"};

XXXConstants.COMMON_SERVER_ERROR = "server error";


这个是XXXConstants_en.js

然后部署的时候，选择一个js文件部署就可以了。

2种方法比较，还是第2种比较自然一点。第一种方法，一样需要维护2个资源文件，在维护上没有什么优势。还要增加额外的流程，相当不自然。

不过，如果系统中本身就用到了struts2国际化的资源文件，那用第一种办法还是说得过去的，可以避免同时维护2套资源文件，戳就戳一点吧。