在国际化进程中，发现了很多需要处理中英文不同语境的问题，仅仅汉译英是不够的。
1、日期格式修改
在处理JS日期插件的时候，发现了一个问题，国内的日期显示，与国外的显示，有大大的区别。
1、1星期的显示
国内的显示是周一、周二、周三，而国外的是Mon、Tue、Wed，是英文的缩写，并且是固定的用法，在修改日期插件源码的时候，从my97插件里面拷贝了英文周显示的数组，统一了展示。
1、年月日字符串的展示
很多显示年月日日期的地方，我们有两种展示方式，第一种如
-09-10
形式的，另一种是
年9月10日
的，本以为可以把后面的统一成前面的，就OK了，结果查阅了一下英文网站与咨询了一下在美国留学的同学，国外的日期展示方式，均应为
Sep10，
，那就修改格式化日期的工具类，还是参照了my97的代码，统一展示了年月日。
1、带时分秒日期的展示
国外的日期，不会像国内一样，展示4小时制的
19:0:00
，而是会展示
07:0:00PM
，会把AM（上午）、PM（下午）同时展示。格式化日期的工具类可以完成了，是单独处理英文的。
functionformatDateEn(d,type){/**支持格式：年月日格式：march8,*年月日时分格式：march8,PM0:48*年月日时分秒格式：march8,PM0:48:1*type:不传时，返回年月日*传m时，返回年月日，时分*传s时，返回年月日，时分秒*/vars=;varlang={aWeekStr:[wk,Sun,Mon,Tue,Wed,Thu,Fri,Sat],aMonStr:[Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec],};varnow=d?newDate(d):newDate();varyear=now.getFullYear();varmonth=now.getMonth();vardate=now.getDate();varhour=now.getHours();varminute=now.getMinutes();varsecond=now.getSeconds();date=datelt;10?0+date:date;hour=hourlt;10?0+hour:hour;minute=minutelt;10?0+minute:minute;second=secondlt;10?0+second:second;s=hourgt;1?PM:AM;if(!type){turnlang.aMonStr[month]++date+,+year;}elseif(type==m){turnlang.aMonStr[month]++date+,+year++hour+:+minute++s;}elseif(type==s){turnlang.aMonStr[month]++date+,+year+br+hour+:+minute+:+second++s;}}
1、4时区的展示
我们的某个产品线，与时间有紧密的关系，需要展示在顶部时区，这个通过JS的
newDate().getTimezoneOffset()
方法即可获取。时区的展示，找几个类似于苹果系统、Windows系统等有不同时区展示的字典表即可。
functiongetTimeZone(){vartimeZoneArr=[utc-1夸贾林岛,utc-11萨摩亚,utc-10夏威夷,utc-9阿拉斯加,utc-8太平洋时间(美国和加拿大),utc-7山地时间(美国和加拿大),utc-6中部时间(美国和加拿大),utc-5东部时间(美国和加拿大),utc-4：0加拉加斯,utc-4大西洋时间（加拿大）,utc-：0纽芬兰,utc-萨尔瓦多,utc-中大西洋,utc-1亚速尔群岛,utc英国,utc+1柏林、法国、丹麦,utc+罗马、巴勒斯坦、希腊,utc+科威特,utc+4毛里求斯,utc+5印度,utc+6缅甸、尼泊尔,utc+6：0仰光,utc+7曼谷,utc+8北京,utc+9首尔,utc+9：0达尔文,utc+10澳大利亚,utc+11所罗门群岛,utc+1新西兰,utc+1努库阿洛法,utc+14圣诞岛,];vartimeZoneArrEn=[utc-1夸贾林岛,utc-11萨摩亚,utc-10夏威夷,utc-9阿拉斯加,utc-8太平洋时间(美国和加拿大),utc-7山地时间(美国和加拿大),utc-6中部时间(美国和加拿大),utc-5东部时间(美国和加拿大),utc-4：0加拉加斯,utc-4大西洋时间（加拿大）,utc-：0纽芬兰,utc-萨尔瓦多,utc-中大西洋,utc-1亚速尔群岛,utc英国,utc+1柏林、法国、丹麦,utc+罗马、巴勒斯坦、希腊,utc+科威特,utc+4毛里求斯,utc+5印度,utc+6缅甸、尼泊尔,utc+6：0仰光,utc+7曼谷,utc+8Beijing,utc+9首尔,utc+9：0达尔文,utc+10澳大利亚,utc+11所罗门群岛,utc+1新西兰,utc+1努库阿洛法,utc+14圣诞岛,];varzeroZone=utc英国;varzeroZoneEn=utcbritain;if(lctu.getLanguage()==en){timeZoneArr=timeZoneArrEn;zeroZone=zeroZoneEn;}//获取当前时区vard=newDate();varstr=;varp=d.getTimezoneOffset();if(p==0){turnzeroZone;}vardd=p/60;dd=0-dd;dd=dd0?++dd:dd;vari=0,j=-1;for(leti=0;itimeZoneArr.length;i++){if(timeZoneArr.indexOf(dd+)-1){j=i;bak;}}turntimeZoneArr[j];}
、中英文字符的限制
我们saas建立app的输入框，限制字数为5，一般来说，一个app的名称，5个汉字足够了，多了也展示不开。但是也限制了5个英文，这就不够了，5个英文字符，连一个单词可能都拼不完。所以，包括这个输入框，我们很多的输入框，都修改了字数限制，比如限制10个字符，中文算个字符，英文算1个，可以解决这个产品问题。只是之前通过input自带的
maxlenth
来限制输入，现在就不够了，还得单独写JS进行验证。
、英语翻译的多样性与语法倒装
同样的中文单词，可以翻译成多个英文单词，这个需要具体产品线的产品经理对翻译之后的界面进行阅读校对，调整单词。中文单词，是不区分大小写的，英文的话，都是区分大小写，例如菜单，全部是大写字母开头，而在普通文案中，应当是全部小写，这又得额外处理。同样一句话，中文可能是正序，英文的话，可能就需要倒装才能表达完全的意思，这个也得注意。
4、英文的单复数处理
这个主要体现在页码上，我们之前的分页插件，是
共N条，每页显示M条
，翻译了之后，就是
TotalNitems,Mitemsperpage
，我看着是没啥问题，集团来自危地马拉的国际化负责人，告诉我们，不能这么展示，如果N是1的话，需要展示成
TotalNitem
，如果N大于1的话，需要展示成
TotalNitems
，这样才符合英文的语法与阅读习惯。尼玛，还得这样，我投机取巧了一下，改成了
TotalNitem(s)
，被告知，也是不行的，无奈之下，只能做JS判断了。
5、其余语境处理
我们在做英文版的时候，还考虑了香港与台湾版，我本以为香港与台湾的是一样的繁体版，实则不然，两者的繁体还不是一样，很多词语的使用也是不一样的。