动态数据本地化答案

【问题标题】：localization of dynamic data动态数据本地化
【发布时间】：2010-06-28 21:22:15
【问题描述】：

我正在寻找有关本地化存储在数据库中的数据的最佳做法的建议。我正在开发一个 Web 应用程序，其中所有静态文本都使用文件进行本地化。我们有几个选项可供管理员使用 UI 进行配置，这些选项存储在数据库中，需要本地化这些值。

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

每个领域的专业化本地化

这是为best practices for multilanguage database design 提出的解决方案。我们将为每个本地化字段创建一个单独的表。例如，假设我们的表 colors 包含 color_id、color_name 和 color_description 列，我们可能会将其分解为包含非本地化数据的 color 表和 color_translations 表 @987654328 @、locale、color_name 和 color_description 字段。

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

单表本地化

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

CREATE TABLE localized_text
(
    key          VARCHAR(256) NOT NULL,
    locale       CHAR(5) NOT NULL,
    value        VARCHAR(256),
    PRIMARY KEY (key, locale)
);

这会更容易导出以进行异地本地化，但会增加一定程度的间接性。

【问题讨论】：

这些“几个选项”不只是作为代码存储在数据库中并在应用程序演示级别进行翻译，是否有原因？无论如何，我认为选项一更干净，因为一张巨大的桌子有许多不同的翻译。模型可以很快变成地狱
我认为仅将代码存储在数据库中的主要反对意见是用户必须去两个不同的地方进行设置。这对于我们的大客户来说很好，他们将本地化文件发送出去进行翻译，但对于小客户来说并不理想。即使是较大的公司也必须将 UI 中的密钥复制到文件中进行翻译。一种可能的解决方案是更新 UI 以根据需要修改本地化文件。有人对此有什么想法吗？
执行选项 #1 并为您的客户实施一个简单的导入/导出工具，用于在应用程序之外翻译自定义内容。

标签： database-design localization

【解决方案1】：

我们将为每个本地化字段创建一个单独的表。例如，假设我们有color_id、color_name 和color_description 列的表格颜色......

假设您的colors 表只有静态文本，显而易见的选择是向其中添加一列，可能命名为locale，并为您关心的每个语言环境添加行。然后加入客户的语言环境以生成您想要的单一描述。

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

【讨论】：