前端国际化系列之中英文语境处理

Question

在国际化进程中，发现了很多需要处理中英文不同语境的问题，仅仅汉译英是不够的。

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、其余语境处理

我们在做英文版的时候，还考虑了香港与台湾版，我本以为香港与台湾的是一样的繁体版，实则不然，两者的繁体还不是一样，很多词语的使用也是不一样的。