如何使用 Zend、l18n mysql 建立多语言数据库模型?

发布于 2024-11-19 04:22:00 字数 532 浏览 3 评论 0原文

我知道这个话题已经讨论过几次了,但对我来说,没有一个是最终的解决方案。

情况 我正在设计一个关系型 mysql 数据库,该数据库稍后应保存多语言内容。您可以从 Wikipedia 或 Microsoft 技术支持页面了解这一点。每种语言的内容应该相同。例如,如果翻译丢失,网站会为您提供自动翻译的相同内容或以信息可用的语言提供的相同内容。如果未设置某些值,则应回退到第二或默认浏览器语言或通过谷歌等进行翻译。开发环境是Zend。

到目前为止,我的想法是解决问题:

两个主键:(ID,语言) 优点:通过数据库抽象层轻松访问数据库。 问题:外键、关系船、后备

列,带有语言后缀: 优点:数据库性能好,没有关系问题。 问题:数据库抽象层无法处理这个问题?

是否有任何概念已被证明是正确的或者比其他概念更可取?有没有人已经创建了这样的东西并可以与我分享他的经验?是否存在针对这种情况的修改后的 Zend DB 控制器?如何将此信息链接到表单?

感谢您的帮助、提示和建议!

亲切的问候,

曼努埃尔

I know this topic was discusses a couple of times, but none of them represents the ultimate solution for me.

Situation
I'm designing a relational mysql database which later should hold multilingual content. You know this from the Wikipedia or Microsoft Tech Support Pages. The contents should be the same for every language. e.g If translations are missing the site offers you the same content automatically translated or in the languages which the information is available in. If some values are not set, it should fallback to the second or default browser language or translate it e.g. through google. Development environment is Zend.

My ideas so far are for Solving the Problem:

Two Primary Keys: (ID, Language)
Advantage: Easy Database Access through database abstraction layers.
Problem: Foreign Keys, Relations ships, Fallbacks

Columns with language suffix:
Advantage: DB Performance, No relational Problems.
Problem: Database abstraction layers cannot handle this?

Has any concept proven itself or is preferable over the other? Has anyone already created something like this and can share his experience with me? Does a modified Zend DB Controller exist for this situation? How do you link this information to a form?

Thank you for your help, hints and suggestions!

Kind regards,

Manuel

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

秋心╮凉 2024-11-26 04:22:00

第二个选项将无法维护(这应该添加到缺点方面)。要实际添加另一种语言,您需要修改表抽象层。听起来像一场噩梦。

第一种选择似乎更有希望,但不幸的是要使其发挥作用还有很多工作要做。然而,根据我的经验,这是相当典型的解决方案,所以我不会重新发明轮子。
我要补充的是,语言回退应该在 Zend 端完成,数据库会丢失一些信息。您可能会想到某种索引表来保存内容的唯一 ID 和可用语言等信息。如果您需要提供某些服务,您将读取该记录,将其与接受语言进行比较,并再次向数据库询问有效内容(使用最合适的语言)。唯一的问题是,您需要以某种方式创建这样的索引表(我看到的最好的方法是在将内容插入内容表时触发)。

工作量很大,但问题并不容易。

The second option would be not maintainable (this should be added on the minuses side). To actually add another language you'll need to modify table and abstraction layers. Sounds like a nightmare.

The first option seems much more promising but unfortunately there is a lot to do to make it work. However, from my experience this is rather typical solution, so I would not reinvent the wheel.
What I have to add is, language fallback should be done on the Zend side, database would miss some information. You may think of some kind of index table to hold information such as unique id of the contents and available languages. If you need to serve something, you would read such record, compare it against of Accept Languages and ask database again for valid contents (using the most suitable language). The only problem is, you would need to create such an index table somehow (the best way I see would be trigger on inserting contents to your content table).

A lot of work but the problem is not too easy.

梦里泪两行 2024-11-26 04:22:00

我现在正在研究完全相同的问题。

不知何故,将所有内容添加到同一个数据库中对我来说没有意义。假设我想做到极致并支持大约 50 种语言,但这只会使我的数据库膨胀。因此,我倾向于将主要数据库保留在我的主要语言中,然后引入一些 Zend_Translate 概念。 Zend_Translate 应该为您提供您正在寻找的后备解决方案。虽然主要导航和核心设计对我的网站来说并不是什么大问题,但我现在最关心的是如何存储所有主要内容以及如何翻译,因为这些元素除其他外还包含 HTML。对于主要内容,我可能会使用一些替代方法,并使用带有每种语言的表的单独数据库。

I am working on the exact same problem right now.

Somehow it does not make sense to me to add everything into the same database. Lets say I want to go to the extreme and support some 50 languages this would just bloat my DB. So, I tend to keep my main DB in my main language and then introduce some Zend_Translate concept into it. Zend_Translate should give you the fallback solution you are looking for. While the main navigation and core design is not much of a problem for my web site my biggest concern right now is how to store all the main content and how to translate because these elements contain HTML among other things. For the main content I will probably use some alternate approach and use a separate DB with tables for each language.

‘画卷フ 2024-11-26 04:22:00

我的平台将是一个社区驱动的数据库。所以我实际上会依靠人类翻译它。无论如何,你都必须存储信息,所以我首先关心的不是数据库大小或性能,而是易用性。到目前为止,我的想法是实现如上所述的某种结构,但不确定我是否会在理论上做到这一点。

语言决定:
开始,应用程序获取用户预设的语言、第二语言、文章的英语母语。从数据库中获取文章时,我将检查每一列的以下内容: 1. 主要语言是否可用? 2. 有第二语言吗? 3. 如果两者都不是,则以母语或英语显示文章,并为用户提供来自谷歌翻译 API 的建议进行翻译。我想这将需要大量的涂层和操纵控制器或建立一个商业模型来做到这一点。

@tawfekov 是这样的东西或类似的东西很容易用学说实现吗?

My plattform will be a community driven database. So I actually gonna rely on humans translating it. You have to store the information anyways, so my first concern is not the database size or performance, but easy usability. So far my idea is to implement some structure as described above, not yet sure if i'll do it in doctrine or not.

Language decision:
Start, application gets users preset language, secondary language, english mother-tong of the article. Fetching the article from the database I will check the following for every column: 1. is the primary language available? 2. Is the secondary language available? 3. If neither of them, display article in mother-tong or english and offer the user to translate it with suggestions from the google translate api. I guess it's gonna be quite a bit of coating and manipulating controllers or building a business model doing this.

@tawfekov is something like this or similar easily realizable with doctrine?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文