Мультиязычность сайта

[Dez]

vasinsky, в твоем варианте, как я понял, есть понятие основной статьи, которая обязательно должна существовать и только после ее переводы сохраняются.
Я бы хотел от этой архитектуры уйти. Чтобы можно было создать статью чисто на каком то дополнительном языке, которая будет отображаться на своей версии сайта и не будет иметь никакой "русской основной" версии..

 

[С.]

vasinsky, а чего так мало таблиц, можно же ещё поля к статье через eav организовать, чтобы совсем энтерпрайзненько было.

Ничего особенного. Обычный паттернез головного мозга.

 

[vasinsky]

в твоем варианте, как я понял, есть понятие основной статьи

)) нет. не обязательно

в таблицу table articles - добавляешь поле lid - которое указывает на язык статьи - т.е. просто указываешь - в на каком языке статья.

С., а как выглядит не петтернез ?

 

[hell0w0rd]

Таблица languages на мой взгляд лишняя. Либо enum, либо varchar(2) (или 5, если ru_RU), ну и индекс естественно.

 

[С.]

С., а как выглядит не петтернез ?

Если брать твою же схему, то:

table articles
aid | preview | text | language | parent_aid

 

[vasinsky]

Если брать твою же схему, то:

table articles
aid | preview | text | language | parent_aid

я же писал почему вывел в отдельную языки: появиться необходимость или желание сменить название языка - и по твоей схеме придётся делать Update всех строк с этим языком

parent_id - да, согласен, просто щас уже не помню мотивацию.

 

[Dez]

)) нет. не обязательно

в таблицу table articles - добавляешь поле lid - которое указывает на язык статьи - т.е. просто указываешь - в на каком языке статья.

С., а как выглядит не петтернез ?

Ну это ты уже подделываешь.
Вообще есть же главная тут задача - находясь на какой то версии статьи, сформировать ссылки на ее другие версии.
Для твоей системы недостаточно как ты показал, надо еще дубляж направлений перевода вести:
1 | 2 | 2
2 | 1 | 1
1 | 3 | 3
3 | 1 | 1
и т.д.

 

[С.]

Приведи пример, когда нужно сменить название языка.

 

[vasinsky]

Ну это ты уже подделываешь.

ну это исходя из не полноты ТЗ + решение вполне логичное - указать язык статьи - не так ли

дубляж направлений перевода вести:

нет там ни какого дубляжа) parent_aid - встретиться столько - сколько версий (языков) статьи

сформировать ссылки на ее другие версии.
Для твоей системы недостаточно как ты показал,

)) у меня же получается - я даже пример запроса показал - указываешь в условии aid статьи + язык

 

[vasinsky]

Приведи пример, когда нужно сменить название языка.

ну вот например - ты указывал в своей таблицы английский как ENG
а потом решил - что наглядней в url - ENGLISH (для примера)

в урле стал писать /article/english/10 вместо /article/eng/10

если ранее ты искал в БД where lang = 'eng' - и искал 'eng' - то теперь перед этим придеться псевдоменять наименование языка

switch($lang){
    case 'eng' : $lang = 'english'; ....
}

и т.д.

вообщем это один из примеров.

я посчитал - таблицу с языками - как отдельный, самостоятельный, не зависимый справочник - и могу глумиться над ним скока угодна и на первое апреля народ веселить и в новый год радовать и просто когда нажрусь глумиться. ну это так...

 

[С.]

Это у тебя последствия паттернеза. Отдыхай больше.

 

[vasinsky]

ну вообщем раз аргументов нет - то как обычно.
вообщем - если охота с логикой сайто-визиточника сидеть - то можно всегда и везде с одной таблицей не плохо управляться

 

[Dez]

)) у меня же получается - я даже пример запроса показал - указываешь в условии aid статьи + язык

твой запрос достанет с русского на английский.
А с английского на русский он уже не будет работать

 

[Dez]

вообщем - если охота с логикой сайто-визиточника сидеть - то можно всегда и везде с одной таблицей не плохо управляться

а-ха-ха, глубокое замечание

 

[vasinsky]

Dez, не не, у меня бывает, делай в одной таблице.

 

[AmdY]

при чём здесь тз, у тебя в справочник
English en
Russian ru
Заказчик видит только текст, а как оно в бд, это твоё дело.
Да и в любом случае один тяжёлый апдейт раз в год, лучше чем каждый раз делать запрос с 2 джойнами. Хотя да, у тебя схема нормализирована. НО это не удобно, особенно связи на оригинал.

 

[WMix]

vasinsky, прикольно конечно, только язык я держал бы непосредственно в статье.

CREATE TABLE IF NOT EXISTS `article` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;

CREATE TABLE IF NOT EXISTS `content` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `article_id` int(10) unsigned NOT NULL,
  `language` enum('en','de','ru') NOT NULL,
  `body` text NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `article_id` (`article_id`,`language`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 ;

ALTER TABLE `content`
  ADD CONSTRAINT `content_ibfk_1` FOREIGN KEY (`article_id`) REFERENCES `article` (`id`);

 

[Dez]

WMix, так неплохо, но мне не нравится момент тут, что я же через ActiveRecord буде работать и неохота так искусственно разбивать и в результате объект будет использоваться типа:
$article->content->body
вместо понятного
$article->body

 

[WMix]

$article->content->body
$article->content->title
$article->public_date

по мне очень понятно

 

[AmdY]

$article->public_date - это не верно, материалы живут своей жизнью, как только разошлись.