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

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

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

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

一个语言一个字段

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

喃~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

article表（无需翻译的字段留在该表）：

article_trans表（需要翻译的字段都放该表）：

JSON怎么样

{
    "title": {
        "zh": "标题",
        "en": "title"
    }
}

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

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

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

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