1

对于在多语言网站和电子商店工作过很多经验的人来说，这更像是一个问题。这不是数据库结构问题或类似的问题。这是关于如何存储多语言网站的问题：而不是如何存储翻译。多语种网站不仅可以翻译成多种语言，还可以有特定语言的内容。例如，网站的英文版本可以具有与俄语或任何其他语言的同一网站完全不同的结构。对于这种情况，我想出了 2 种存储模式：

// NUMBER ONE

table contents // to store some HYPOTHETICAL content
    id         // content id

table contents_loc // to translate the content
    content, // ID of content to translate 
    lang,    // language to translate to
    value,   // translated content
    online   // availability flag, VERY IMPORTANT

ADVANTAGES:
- Content can be stored in multiple languages. This schema is pretty common, except maybe for the "online" flag in the "_loc" tables. About that below.
- Every content can not only be translated into multiple languages, but also you could mark online=false for a single language and disable the content from appearing in that language. Alternatively, that record could be removed from "_loc" table to achieve the same functionality as online=false, but this time it would be permanent and couldn't be easily undone. For instance we could create some sort of a menu, but we don't want one or more items to appear in english - so we use online=false on those "translations".

DISADVANTAGES:
- Quickly gets pretty ugly with more complex table relations.
- More difficult queries.



// NUMBER 2

table contents // to store some HYPOTHETICAL content
    id,        // content id
    online     // content availability (not the same as in first example)
    lang,      // language of the content
    value,     // translated content

ADVANTAGES:
1. Less painful to implement
2. Shorter queries

DISADVANTAGES:
2. Every multilingual record would now have 3 different IDs. It would be bad for eg. products in an e-shop, since the first version would allow us to store different languages under the same ID and this one would require 3 separate records to represent the same product.

第一个存储选项似乎是一个很好的解决方案，因为您也可以轻松地使用它而不是第二个，但反过来您就不能轻松地做到这一点。唯一的问题是……第一个结构似乎有点矫枉过正（除了产品存储等情况）

所以我对你的问题是：

实施第一个存储选项是否合乎逻辑？根据您的经验，有人会需要这样的解决方案吗？

4

2 回答 2

1

我们问自己的问题总是：

多种语言的内容是否相同，它们是否需要关系？

可翻译模型

如果答案是肯定的，您需要一个可翻译的模型。因此，模型具有同一记录的多个版本。因此，您需要为每条记录设置一个语言标志。

优点：它为您提供了一个结构，您可以在其中查看例如哪些内容尚未翻译。

每种语言的单独记录 但很多时候，我们认为另一种解决方案是更好的解决方案：完全分离两种语言。我们主要在 CMS 解决方案中看到这一点。这个故事不仅被翻译了，而且也有所不同。例如，在国家 1，他们有不同的菜单结构、其他新闻项目、其他产品和其他页面。

优点：完全的灵活性，没有来自其他语言的意外记录。

示例 我们认为它就像写一本杂志：您可以写一本，然后翻译成另一种语言。是的，这是可能的，但在现实世界中，我们越来越多地看到内容在结构上有所不同。人们不喜欢感到惊讶，因此您需要许多步骤来确保内容不会以错误的语言显示，页面不会被重复创建等。

共享逻辑 所以我们做的大部分时间是：共享视图，使按钮、输入等可翻译，但保持内容分离。这样每个管理员都可以在他的区域内工作。如果我们需要确认某些记录在所有语言中都可用，我们总是可以通过在它们之间创建链接（很好的关系）来欺骗它，但这不是我们大部分时间使用的标准。

像产品这样的真正可翻译的记录 因为我们在创建模型等方面很灵活，所以我们可以根据需求决定如何使用它们。我不会试图寻找一个适用于所有人的通用解决方案，因为没有。您需要基于您的数据的解决方案。

于 2012-10-15T08:52:07.727 回答
0

假设您需要一个可翻译的模型，正如 Luc 所描述的那样，我建议为内容表的 value 列提供某种特殊字符分隔的键值对格式。例子：

@en=英语术语@de=德语术语

您可以使用 UDF（T-SQL 中的用户定义函数）来设置/获取基于指定语言的适当术语。

用于选择：

从内容中选择 id, dbo.GetContentInLang(value, @lang)

对于更新：

更新内容集 value = dbo.SetContentInLang(value, @lang, new_content) where id = @id

UDF：

一种。确实会影响性能，但这也是您必须在 content 和 content_loc 表之间进行的连接的情况

和

湾。有点难以实现，但实际上可以在整个数据库中重用。

您也可以在应用程序/UI 层执行上述操作。

于 2013-03-02T22:10:08.877 回答