мультиязычный контент в базе

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

или чтоб наглядней - lang char(2) default 'en' и выборку типа если у статьи с этим id есть содержание на ru то фетчить ру, иначе en.

а допустим если у меня есть дерево каталогов, и я хочу тоже для них многоязыковой перевод. тогда получается, нужно как-то пппо-другому делать.. скажем, у каталога есть id, к которому прикреплены элементы (многоязыковые :) ). перевод каталога тогда нужно держать либо в той же таблице, либо не знаю. отдельная таблица переводов имён (и других текстовых полей) каталога?

бррр.. всё. догнал.. надо просто убрать флаг primary с id. тогда можно одинаковые id держать. долго же думал однако)

Правильно же оставить id первичным индексом и добавить поле cat_id, иначе как ты будешь UPDATE, DELETE делать.

если честно, то я думал, что выборка будет по 2-ум полям - id + lang_id (MUL). но правда не знаю, как это на скорости скажется. не добрался ещё до мануала.

cat_id - это идентификатор папки, в которой хранятся вск переводы какого-либо материала?

PostgreSql умеет работать с типом данных массив. Посмотри соответствующий раздел документации про работу с массивами.

Хорошая и важная тема. +1 Там, где я работал когда-то было так:

CREATE TABLE `galery_settings_t` (
  `id` int(11) NOT NULL auto_increment,
  `key_id` int(11) NOT NULL default '0',
  `main_text` text,
  `locale_id` varchar(2) default 'ru',
  `meta_title` varchar(250) default NULL,
  `keywords` text,
  `description` text,
  `no_pics_text` text,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=3 ;

Если бы я делал многоязычное приложение, то сделал бы именно так

в таком случае иметь еще одну табличку tree_translations int id, char(2) lang, text value

Обширная и нужная тема, ага.

У меня такая мысля была, хранить переводимый контент в формате gettext'а. Никто ничего подобного не реализовывал?

Где то я такое видял...
Не уверен, но кажется много кто с gettext делает.

Не реализовывал, только собирался.

думаю, хорошим примером здесь будет django с ее sites. в принципе от locale_id мало чем отличается, но я бы сделал как в django (мало ли, да и гибкости больше)

а можно про их структуру многоязычности где-то почитать в общих словах? я просто не знаком с django вообще, буду благодарен, если ссылок накидаешь

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