动态数据的本地化

Ros*_*oss 5 database-design localization

我正在寻找有关本地化存储在数据库中的数据的最佳实践的建议.我正在开发一个Web应用程序,其中所有静态文本都使用文件进行本地化.管理员可以使用UI配置多个选项,这些选项存储在数据库中并需要对这些值进行本地化.

我们提出了几个可能的想法.您对这些解决方案有何看法?是否有更好的选择,甚至是标准的最佳实践?

每场专业本地化

这是针对多语言数据库设计的最佳实践提出的解决方案.我们将为每个本地化字段创建一个单独的表.例如,假设我们有台colorscolor_id,color_namecolor_description列,我们可以打破它为color与非本地化的数据和表格color_translationscolor_id,locale,color_namecolor_description领域.

但是,我们的客户经常将本地化文件发送给第三方进行翻译,这变得很棘手.

单表本地化

另一种选择是创建一个表来表示所有数据库本地化:

CREATE TABLE localized_text
(
    key          VARCHAR(256) NOT NULL,
    locale       CHAR(5) NOT NULL,
    value        VARCHAR(256),
    PRIMARY KEY (key, locale)
);
Run Code Online (Sandbox Code Playgroud)

这对于异地本地化而言更容易导出,但增加了一定程度的间接性.

Jam*_*den 1

我们将为每个本地化字段创建一个单独的表。例如,假设我们的表格颜色带有color_id,color_namecolor_description列......

假设您的colors只是静态文本,显而易见的选择是向其中添加一列,也许locale为您关心的每个区域设置命名并添加行。然后加入客户的区域设置以生成您想要的单一描述。

为此,您必须将静态描述与与区域设置无关的数据分开,因为本地化描述引入了多对一关系。作为权宜之计,您可以将英文描述保留在主表中,并在所有对它们的引用消失后将其删除。