请问大家是如何解决多语言网站的问题的?无论是通过前端解决还是后端解决?

SenYi
  • 13

整了半天,没找到怎么简单粗暴的实现网站的中英文替换??

从前端的思路,看了i18n、微软字典等等,感觉这种还是属于键值对读参数的办法,效率偏低下。

从后端的思路,如果从接口翻译那基本凉凉,如果写翻译文件(用变量代替字符串),那效率也很低下,况且数据库还有那么多固定语言的信息,怎么翻译?

请问各位是解决这个问题的(做N个版本的别说了,不能通用多项目)

回复
阅读 1.4k
2 个回答
  1. 基本上还是基于字符串替换
  2. 无论是静态页面、动态页面、API、错误信息,都是如此
  3. 就我厂来说:

    1. 基础语言是英语
    2. 用各种工具提取要翻译的文案,整理成 po 文件
    3. 翻译出各语言版本,然后使用各种 i18n 模块替换显示

长期后端,提一些后端的解决方案。

数据库

主表+副表

从数据设计角度,一般都是主表+副表(翻译表),主表记录主键做与副表关联,主表存储一些不会变动的和不需要翻译的东西,比如业务键,放在主表,其他的需要翻译或者根据不同语言下需要变动的都放副表,查询的时候使用 join 进行查询。

副表的扩展还有一种可选。

  • 一、就是上面说的直接一张主表对应一张副表,副表中使用 language 字段来标识不同语言。
  • 二、使用一张主表对应多张副表,即使用表后缀来区分不同语言。

因为在业务中,一般使用模型和数据库进行交互,在使用模型时,根据不同语言指定不同的表名肯定是没有问题的。其次这样多了一个好处,就是避免使用一张副表时数据过多,造成查询困难,当然,我们也可以通过添加索引来解决查询速度的问题。

主表冗余

数据库设计还有一种方案,即数据冗余方案,就只用一张表,添加一个 language 字段,用来标识语言,数据直接冗余,即拷贝已有语言的做修改,这样的问题就是还要额外维护一个业务键,其次就是数据冗余带来的问题,这样的好处就是查询变的简单了,不在需要 join。

个人比较倾向第一种数据库设计方案,即主表+副表,但是因为国际化项目不多,有幸在真实业务中用到过第二种,所以认为其为一种非常糟糕的解决方案,当然,实际情况还是取决于你的业务,根据业务来选择适合自己的方案。

业务字符串

数据库以外的后端部分内容,比如 tips ,这些都是翻译字符串。

补充

翻译都是由专门的翻译人员进行翻译审核,避免机翻。

你知道吗?

宣传栏