上一篇介绍文案替换,文案替换完成了,但是具体要展示中文 or 英文,对前端来说,需要处理两种情景。
我们有的产品线,做了前后端分离,html 由前端部署,这样的话,在上午已经介绍,我们使用代码,生成了英文版的 html,跟后台协调了一下,根据产品线的不同,分为两种方式部署。
英文版、中文版,都需要嵌入我们相同的JS,所以,要获取当前的语言环境,我写了一个 LCTU 的工具类,暴露了一个 getLanguage 的全局方法,用于获取语言版本。
因为产品线众多,而且一开始没拍板如何部署英文的系统,我做了四种方式的兼容
具体代码如下:
function getLanguage() {
// return "en";
var langArr = ['zh_cn', 'en', 'zh_tw'];
// 获取当前的语言环境
// 0.取域名首位数,北美的为us
// 1.根据url关键字获取,关键字:language
// 2.根据cookie获取,关键字:language
// 3.根据url路径获取 //4.保留功能,通过浏览器语言版本选择
var language = 'zh_cn',
temp = '';
if (window.location.hostname.indexOf('us') === 0) {
language = 'en';
} else if ((temp = getQueryString('language'))) {
if (langArr.indexOf(temp) > -1) {
language = temp;
}
} else if ((temp = getCookieByKey('language'))) {
if (langArr.indexOf(temp) > -1) {
language = temp;
}
} else {
language = getLanguageByPath();
}
return language;
}
考虑到 cookie、path、参数的操作风险性与商业价值,后来大部分的业务线,使用了北美单独的域名,以 us 开头的,OK,那就是使用第一种方法就 OK 了,不过,我还保留了通过url关键字获取的方式,用于测试环境上调试中英文版本。
上面的代码,本来以为可以处理全部的情况,后来发现还少了一种情景,我们有一个 saas 的业务线,客户可以使用我们的 saas 系统,配置自己的网站,也可以解析到自己的域名上,这样的话,以上四种方式,一下子都不适合了。
没办法,我跟后台协商了一下,使用 saas 英文业务线生成的网站,会在每个界面上,存一个 local_area 的全局变量,简单粗暴的解决了问题。
if(typeof local_area == "string" && local_area == "us"){ ……}
后来使用着国外的vpn逛天猫的时候,发现天猫直接跳转到了国际版,这个根据 dns 判断一下,倒是很简单。

