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