如何为简单的多语言网站(PHP MySQL)构建数据库?

发布于 2024-10-29 12:28:35 字数 464 浏览 1 评论 0原文

一年多前我开发了一个网站。内容是/是两种语言,现在我需要构建一个数据库驱动的更新/数据插入系统,以便他们插入一些新闻、事件等。 创建这样的表的最佳方法是:

news_id         int(10) unsigned PK
lang_id         int(2)
status          tinyint(1)
title           varchar(255)
title_en        varchar(255)
title_es        varchar(255)
content         text
content_en      text
content_es      text
date_inserted   datetime
date_modified   datetime
type            varchar(45)
atach           text

然后为语言创建一个表

I've developed a website more than a year ago. The content were/is in two languages and now I need to build a database driven update/data insertion system for them to inserte some news, events etc.
Is the best approach to create tables like this:

news_id         int(10) unsigned PK
lang_id         int(2)
status          tinyint(1)
title           varchar(255)
title_en        varchar(255)
title_es        varchar(255)
content         text
content_en      text
content_es      text
date_inserted   datetime
date_modified   datetime
type            varchar(45)
atach           text

then create a table for the languages

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

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

发布评论

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

评论(2

原谅我要高飞 2024-11-05 12:28:35

对于任何一种特定请求,您应该只关心一种语言。虽然您只能选择页面请求所需的语言,但以这种方式组织内容仍然不是最佳实践。

您应该做的是使用区域设置并提供内容的默认值。因为虽然您可能认为您总是会创建一段内容的两个版本,但在一个不太完美的世界中,这并不总是会发生。

因此,您首先要创建模型来反映这种关系。为了简单起见,我将其称为内容。但你的内容当然可以是任何内容。

`content` (The Table)
id
status
title
content
dataCreated
dateModified
owner

`contentTranslations` (The Table)
id
contentId (FK)
locale
title
content
dateCreated
dateModified

现在,您只需要一种方法来了解用户希望使用哪个区域设置。我更喜欢使用 Zend_Locale 来管理我的所有语言环境,并使用 Zend_Translate 来进行 key=>value 翻译。 (但这不适合长内容翻译)。

当您知道要使用哪个区域设置时,您所需要做的就是执行查询以通过联接进行选择。

优点

然而,所有这一切的优点在于,如果您还没有为特定语言版本创建内容,那么您仍然可以默认并滚动到原始文章/内容的基本语言被写在.

SELECT c.id, c.status, c.title, c.content
FROM content as c
LEFT JOIN contentTranslations as t
ON c.id = t.contentId
WHERE c.id = 21231 AND t.locale = X

You should only care about one language for any one particular request. While you could only select the language that the page request requires, it still isn't best practice to organise your content in such a way.

What you should do is use locales and provide defaults for a content. Because while you might think you will always create two versions of a piece of content, in a less than perfect world this doesn't always happen.

So, you would first create your model to reflect this relationship. For simplicity I will just refer to this as content. But you could of course have your content to be anything.

`content` (The Table)
id
status
title
content
dataCreated
dateModified
owner

`contentTranslations` (The Table)
id
contentId (FK)
locale
title
content
dateCreated
dateModified

Now, you just need a way to know which locale the user wishes to use. I prefer using Zend_Locale for managing all of my locales, and Zend_Translate for short key=>value translations. (This isn't suitable for long content translations though).

When you know which locale you want to use, all you need to do is perform your query to select with a join.

The Beauty

The beauty of all of this however, is that if you haven't created your content for a particular language version, then you can still default and roll onto your base language which the original article/content was written in.

SELECT c.id, c.status, c.title, c.content
FROM content as c
LEFT JOIN contentTranslations as t
ON c.id = t.contentId
WHERE c.id = 21231 AND t.locale = X
要走干脆点 2024-11-05 12:28:35

如果您只需要两种语言并且语言特定字段的数量不高,则将所有内容保存在一个数据库中是一种可行的方法。

但从长远来看,最好将其分成两个数据库,其中一个保存不依赖于语言的数据,另一个保存翻译。这将使您可以轻松地在未来的

“新闻”数据库中添加更多语言:

news_id         int(10) 
status          tinyint(1)
date_inserted   datetime
date_modified   datetime
type            varchar(45)
atach           text

“翻译”数据库:

translation_id  int(10) 
news_id         int(10) 
lang_id         int(2)
title           varchar(255)
content         text

但是,在某些情况下这也可能很慢。不确定该网站获得了多少流量。

顺便说一句:因为我可以看到类型是 varchar(45) 我认为这也可能与语言相关?

Keeping everything in one database is the way to go if you're only going to have two languages and if the amount of language specific fields is not high.

But for the long run it might be better to split it into two databases, one of them holding the data that doesnt depend on the language, the other one for the translations. This will allow you to easily add more languages in the future

"NEWS" database:

news_id         int(10) 
status          tinyint(1)
date_inserted   datetime
date_modified   datetime
type            varchar(45)
atach           text

"TRANSLATIONS" database:

translation_id  int(10) 
news_id         int(10) 
lang_id         int(2)
title           varchar(255)
content         text

BUT, this might also be slow in certain circumstances. Not sure how much traffic does that site get.

Btw: since I can see the type is a varchar(45) I asume thats might also be language related?

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