更新：几年后我遇到了这个问题：现在我知道这是一种非常糟糕的方法.请不要使用它.您可以始终为i18n使用其他表(例如product和products_lang),并为每个区域设置单独的条目：更好地用于索引,更好地用于搜索等.

我正在尝试在MySQL / PHP站点中实现i18n.

我读过一些答案,指出“ i18n通常不是数据库的一部分”,我认为这是一种狭narrow的方法.
关于产品名称,或者像我的实例一样,数据库中存储的菜单结构和内容呢？

考虑到语言应该是可扩展的,我想知道您如何看待我的方法,因此,我尝试避免使用“每种语言解决方案的一栏”.

一种解决方案是对字符串进行翻译时使用引用(id),并且对于每个可翻译列,都有一个包含主键,字符串ID,语言ID和翻译的表.

我认为的另一个解决方案是使用JSON.因此,我的数据库中的菜单项如下所示：

idmenu label
------ -------------------------------------------
5      {"en":"Homepage", "it":"pagina principale"}

您如何看待这种方法？

解决方法:

“一种解决方案是对字符串进行翻译时使用引用(id),对于每个可翻译列,都有一个包含主键,字符串ID,语言ID和翻译的表.”

我实现了一次,我所做的就是我采用了现有的数据库模式,查找了所有具有可翻译文本列的表,并为每个这样的表创建了一个单独的表,其中仅包含那些文本列,并附加了其他语言ID和ID并将其保存到原始表中的“数据”行.因此,如果我有：

create table product (
  id          int          not null primary key
, sku         varchar(12)  not null
, price       decimal(8,2) not null
, name        varchar(64)  not null
, description text          
)

我将创建：

create table product_text (
  product_id  int          not null
, language_id int          not null
, name        varchar(64)  not null
, description text
, primary key (product_id, language_id)
, foreign key (product_id) references product(id)
, foreign key (language_id) references language(id)
)

我会这样查询：

SELECT    product.id
,         COALESCE(product_text.name, product.name) name
,         COALESCE(product_text.description, product.description) description
FROM      product
LEFT JOIN product_text
ON        product.id = product_text.product_id 
AND       10         = product_text.language_id

(10恰好是您现在感兴趣的语言ID.)

如您所见,原始表保留了text列-如果当前语言没有可用的翻译,这些列将作为默认列.

因此,无需为每个文本列创建一个单独的表,而为所有文本列仅创建一个表(每个原始表)

就像其他人指出的那样,JSON想法存在一个问题,那就是几乎不可能对其进行查询,这又意味着无法仅在特定时间提取所需的翻译.