1

我们正在开发一个旅行门户，对于一个旅行门户，它的内容和细节是核心。我们计划在多个语言环境中使用它，因此这意味着我们需要处理每个语言环境的动态数据。

目前我们有以下表格

Destination
Transport
Places of Interests
user comments etc.

每个表都包含很多字段，例如

Name
ShortDescription
LongDescription

以及许多其他可能包含大量数据的字段，我们需要以特定于语言环境的方式处理数据。

我不确定我们如何最好地设计一个应用程序来处理这种情况，我想到的一件事就是在每个表中为每个语言环境添加额外的列，但这意味着对于新的语言环境，需要从数据库更改为代码级别这一点都不好。

由于每个表都包含很多列，这些列可以包含符合国际化条件的数据，所以我的问题是处理这种情况的最佳方法是什么

编辑1 在做了一些分析和一些观察之后，我想到的一种方法如下..

我打算为每个表创建一个翻译表，比如目的地我有以下设计

    table languages
    -- uuid (varchar)
    -- language_id(varchar)
    -- name (varchar)  

    table Destination
    --uuid (varchar)
     other fields which are not part of internationalization.

table Destination_translation
-- id (int)
-- destination_id (int)
-- language_id (int)
-- name (text)
-- description(text)

欢迎对上述方法提出任何有价值的建议......

4

2 回答 2

1

以前国际化应用程序时，我们有一个基于区域设置的值表。所以，我们做了这样的事情：

创建一个名为 local_strings 的表，由 string_code、locale_code、值组成。这包含各种值的翻译。因此，如果您已翻译成三种语言，则每个 string_code 将有三个具有不同 locale_code 的条目。

然后，每个主表（在您的情况下为目的地、运输等）都引用了 local_strings 表中的 string_code。

最后，在从数据库中查询值时，只需确保始终加入 local_strings 表并始终使用用户的当前语言环境。或者，您可以将这些值缓存在内存中，这样您就不必总是加入该表。然而，根据我的经验，这张桌子永远不会变得那么大，所以加入它并没有太多的开销。

于 2011-04-03T06:47:33.003 回答
0

有几个选项可以解决这个问题：

  1. 通过区域设置列扩展您的表，并在每个查询中包含区域设置。您甚至可以修改索引以包含语言环境列。
  2. 为本地化字符串创建单独的表

我肯定会支持选项 1，因为它使表格看起来仍然像真实的东西，并且仍然可以通过直接查看数据来读取它们。它还可以防止您进行子选择或连接，这有助于提高性能。选项 2 的优点只是对管理界面的程序员来说更容易（如果你有的话）。

于 2011-04-03T06:47:59.763 回答