接口 怎么实现多语言的喃?

比如数据库有几个字段

{
"id": 907,
"title": "测试测试",
"name": "测试测试",
"type": "1",
"logo": "https://xxx.com/907.png",
"content": "测试测试",
}

我想实现8个语言版本,应该怎么规划喃?
应该不能实时调用第三方翻译接口吧 数据又不一样 难道要一个语言保存一个字段吗?

《L05 电商实战》
从零开发一个电商项目,功能包括电商后台、商品 & SKU 管理、购物车、订单管理、支付宝支付、微信支付、订单退款流程、优惠券等
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 31

我们目前有实际的海外多语言商业项目在运行中,参考了多个开源项目,也参考了海外一些大公司的做法,之前也踩过不少坑,有些经验可以分享一下。

多个语言字段是个不错的解决方案,如果只有两三种语言,那显然也是合适的。但是有个显而易见的问题,如果需要扩展,是个灾难问题,搜索查询也是不容易,小项目可以使用。

json存储多语言,看着也不错,可以自由扩展,接口只要直接输出,前端自由选择调用。但问题是,如果客户不需要多语言呢,那你的主表中存一个json数据吗?或者冗余一个字段,来存储多语言json,这样会污染表结构。

我们后来在国际saas软件公司那边方案的基础上优化了一版,具体做法是: 设计一张多语言表,字段可以简化为key、value,key由需要翻译的数据表名、数据表ID、数据表字段名、语言组成,比如商品ID为12的标题需要英文语言,那key可以为:product:12:title:en,值为该翻译文字。

这样的好处在于,多语言可以和主系统解耦,你可以额外再提供一个翻译系统。翻译数据可以放到缓存中,读取方便。不管多少语言多少系统随意扩展。 坏处也有,搜索做起来相对麻烦,如果使用es,那就不是问题。

2周前 评论
人艰不拆 2周前
tiantian10000 (楼主) 2周前
tiantian10000 (楼主) 2周前
黑将军 1周前

一般都是维护多套语言本版,也可以在数据库里标注语言本版,相当于一个分类

2周前 评论

看看 本地化 或许对你有帮助

2周前 评论
tiantian10000 (楼主) 2周前

就按你说的,用8个字段来搞,没错的。

2周前 评论
tiantian10000 (楼主) 2周前
wlm212 2周前
Lucifer103

一个语言一个字段

2周前 评论

我们之前有一个做法是你数据库保存文章的时候可以考虑写个占位符 然后针对占位符做不同语言的翻译 这样即使有100个你去扩展都没有问题,查询得时候只需要针对词条跟当前语言就可以关联对应得本土化语言

2周前 评论
playmaker

喃~

2周前 评论

github.com/spatie/laravel-translat... 用这个包实现,这个多语言存的是json。

2周前 评论
tiantian10000 (楼主) 2周前
MArtian (作者) 2周前

花个时间做个词典库?

2周前 评论

多个字段,没毛病 或者用JSON

2周前 评论
{
"id": 907,
"title": "测试测试",
"name": "测试测试",
"type": "1",
"logo": "https://xxx.com/907.png",
"content": "测试测试",
}

如果logo也要国际话的, 你这个表需要 4*7=28 新增28个字段

2周前 评论

不建议用多个字段来存不同语言,现在是 8 个语言 8 个字段,如果未来要增加 10 个语言,还要改表结构,最好用一个 JSON 字段来存所有语言版本,扩展起来方便很多

2周前 评论

我们目前有实际的海外多语言商业项目在运行中,参考了多个开源项目,也参考了海外一些大公司的做法,之前也踩过不少坑,有些经验可以分享一下。

多个语言字段是个不错的解决方案,如果只有两三种语言,那显然也是合适的。但是有个显而易见的问题,如果需要扩展,是个灾难问题,搜索查询也是不容易,小项目可以使用。

json存储多语言,看着也不错,可以自由扩展,接口只要直接输出,前端自由选择调用。但问题是,如果客户不需要多语言呢,那你的主表中存一个json数据吗?或者冗余一个字段,来存储多语言json,这样会污染表结构。

我们后来在国际saas软件公司那边方案的基础上优化了一版,具体做法是: 设计一张多语言表,字段可以简化为key、value,key由需要翻译的数据表名、数据表ID、数据表字段名、语言组成,比如商品ID为12的标题需要英文语言,那key可以为:product:12:title:en,值为该翻译文字。

这样的好处在于,多语言可以和主系统解耦,你可以额外再提供一个翻译系统。翻译数据可以放到缓存中,读取方便。不管多少语言多少系统随意扩展。 坏处也有,搜索做起来相对麻烦,如果使用es,那就不是问题。

2周前 评论
人艰不拆 2周前
tiantian10000 (楼主) 2周前
tiantian10000 (楼主) 2周前
黑将军 1周前

建议保存为多个语言版本的记录,记录一个语言字段,主语言手写,其他语言手写或机翻

2周前 评论
id l_type title content name
id 语言类型 标题 内容 姓名
id l_type title content name
1 chinese 标题 内容 姓名
2 chinese title desc name

把多语言的部分单独领出来,价格语言类型就好。没必要加字段。

2周前 评论
ncccc1 2周前

这个具体看你项目的实际情况来决定,如果你能确定你项目,只会有两三个语种,如:中、英,那么你直接在本表添加多列的不同语言字段是成本最低的。
然后上面说的json存储多语言,你一定要多考虑项目实际使用情况,慎用,因为json对索引、搜索场景,你会遇到大麻烦,仔细想想自己项目有没有这类场景。

我推荐你一种我目前在使用的,方便扩展多语言的建表方式:

article表(无需翻译的字段留在该表):

id type created_at
1 0 1659322154
2 1 1659322154

article_trans表(需要翻译的字段都放该表):

id title name article_id lang
1 中文标题1 名称1 1 zh
2 en title 1 name 1 1 en
3 中文标题2 名称2 2 zh
4 en title 2 name 2 2 en
1周前 评论

JSON怎么样

{
    "title": {
        "zh": "标题",
        "en": "title"
    }
}
1周前 评论
liziyu 1周前
小李世界 1周前

可以实现一个独立的多语言系统。基本模块如下:

  • 翻译服务(买翻译接口)
  • gitlab 服务(一个站点一个仓库,master分支对应正式域,preN分支对应测试域)
  • 自动发布服务(仓库被 push 后,将多语言文件自动发布到对应的站点)
  • 语料库

数据表基本字段:语种、文件、key、value

所有文件都是 json 文件。 前端工程只需要读取指定目录下的多语言文件即可。

1周前 评论
liziyu 1周前
declandragon (作者) 1周前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!