整了半天,没找到怎么简单粗暴的实现网站的中英文替换??
从前端的思路,看了i18n、微软字典等等,感觉这种还是属于键值对读参数的办法,效率偏低下。
从后端的思路,如果从接口翻译那基本凉凉,如果写翻译文件(用变量代替字符串),那效率也很低下,况且数据库还有那么多固定语言的信息,怎么翻译?
请问各位是解决这个问题的(做N个版本的别说了,不能通用多项目)
整了半天,没找到怎么简单粗暴的实现网站的中英文替换??
从前端的思路,看了i18n、微软字典等等,感觉这种还是属于键值对读参数的办法,效率偏低下。
从后端的思路,如果从接口翻译那基本凉凉,如果写翻译文件(用变量代替字符串),那效率也很低下,况且数据库还有那么多固定语言的信息,怎么翻译?
请问各位是解决这个问题的(做N个版本的别说了,不能通用多项目)
长期后端,提一些后端的解决方案。
从数据设计角度,一般都是主表+副表(翻译表),主表记录主键做与副表关联,主表存储一些不会变动的和不需要翻译的东西,比如业务键,放在主表,其他的需要翻译或者根据不同语言下需要变动的都放副表,查询的时候使用 join 进行查询。
副表的扩展还有一种可选。
因为在业务中,一般使用模型和数据库进行交互,在使用模型时,根据不同语言指定不同的表名肯定是没有问题的。其次这样多了一个好处,就是避免使用一张副表时数据过多,造成查询困难,当然,我们也可以通过添加索引来解决查询速度的问题。
数据库设计还有一种方案,即数据冗余方案,就只用一张表,添加一个 language 字段,用来标识语言,数据直接冗余,即拷贝已有语言的做修改,这样的问题就是还要额外维护一个业务键,其次就是数据冗余带来的问题,这样的好处就是查询变的简单了,不在需要 join。
个人比较倾向第一种数据库设计方案,即主表+副表,但是因为国际化项目不多,有幸在真实业务中用到过第二种,所以认为其为一种非常糟糕的解决方案,当然,实际情况还是取决于你的业务,根据业务来选择适合自己的方案。
数据库以外的后端部分内容,比如 tips ,这些都是翻译字符串。
翻译都是由专门的翻译人员进行翻译审核,避免机翻。
10 回答11.3k 阅读
5 回答4.9k 阅读✓ 已解决
4 回答3.2k 阅读✓ 已解决
2 回答2.8k 阅读✓ 已解决
3 回答5.2k 阅读✓ 已解决
1 回答3.3k 阅读✓ 已解决
3 回答1.5k 阅读✓ 已解决
就我厂来说: