ем, тип: select article from articles where lang = 'et' and id = 34; это, вот, как я думал делать - добавить в таблицу столбик с языком и тянуть в зависимости от него, типа есть таблица articles с полями id, article, lang.
А потом добавь ... join `sections` AS `sect` on (`sect`.`lang` = `articles`.`lang` AND `sect`.`id` = `articles`.`id`) ...
sashkanar ок, видишь как тут просто. А теперь попробуй тоже самое для и увидишь, что text_rus, text_fr - говнище а не метод. Вот и вся разница)
О_о хм, как же много еще учить))) спасибо за ответы =) теперь разберусь. но вот возникла еще одна проблема - спрошу тут же ибо даже не знаю, как задать ей тему "кривые руки" или "я бландинка"))))))))) суть в том, что есть две таблицы - одна с марками машин, вторая с кратким описанием (статус (скорок приедет, продана итд), возраст машины (новая \ старая), и ид из таблицы с марками). делается обычный запрос, чтобы узнать количество машин определенной марки, например, БМВ(8), АУДИ(7). В СКЛ запрос адекватен и выводит все верно, но, собирая в ПХП - получается, что, если количество БМВ и АУДИ одинаково (БМВ(8) и АУДИ(8)), то возьмется лишь одна - либо БМВ, либо АУДИ, если же количество разное (БМВ(5) а АУДИ(7)), то выведет обе. В чем может быть проблема? код функции, что делает запрос: function getCarsAndCount(&$carcount) { dbConnect($connect); $query = 'select m.make, count(c.makeid) from t_make m, t_cars c '; $query .= 'where m.id = c.makeid group by(m.make);'; $result = mysql_query($query)or die(mysql_error()); if(mysql_num_rows($result) != 0) { while($info = mysql_fetch_array($result)) { $carcount[$info[1]] = html_entity_decode(stripslashes($info[0])); } } dbDisconnect($connect); return $carcount; } а в хтмл вывожу: if(getCarsAndCount($carcount)) { foreach($carcount as $key => $value) { echo('<li>'.strtoupper($value).' ('.$key.')</li>'); } } $value = марка машины, а $key = количество машин данной марки.
В начале своей карьеры использовал третий способ: использование отдельной таблицы с постфиксом. Замучился поддерживать согласованными справочные таблицы и от него отказался. Сейчас использую первый способ-столбик с постфиксом языка. Приведу пример, когда этот способ удобнее других. У меня есть справочник компаний. Нужно искать компанию по ее названию - причем пользователь может ввести часть названия компании на любом поддерживаемом языке. Запрос на поиск: select * from companies where company_ru like '%$name%' or company_en like '%$name%' Кроме этого в пользу этого способа можно привести разумное предположение, что организовать работу(редактирование, поиск) с одной таблицей проще чем с несколькими и в одной базе чем в нескольких базах. Код правда немного усложняется. Например я храню язык интерфейса приложения в сессионной переменной. Выборка статей (таблица articles) для выбранного пользователем языка ($lang) будет выглядеть так: select article from articles where article_{$lang} is not null; Здесь в полях article_xxx -текст статьи на языке xxx
1) самый полный мультиланг - много сайтов 2) view хендлеры + много баз 3) view хендлеры + идент таблица 4) view хендлеры + идент поле 5) просто много баз 6) идент таблица 7) идент поле далее всё не оч.
Приведу пример когда четвертый способ - разделение по отдельным базам данных вообще не годится. Есть таблица -справочник товаров с двумя полями: код товара +название товара и есть таблица заказов товара с полями: 1)код заказа 2) код товара 3) количество и т.д. Справочник товаров будет находиться в базах Database_ru,Database_en. Куда поместить таблицу заказов? В Database_ru? Тогда как выводить таблицу заказов в Database_en? Если поместить таблицу заказов в обе Database_ru и Database_en, то вывести сводную таблицу заказов не так просто. Можете привести примеры, что нельзя добиться с помощью первого способа?
Удобства, расширяемости, гибкости, полной многоязычности. Если существует не одно поле text_lang, а несколько, т.е title_rus, title_en, title_fr, text_en, text_rus_text_fr, note_ru, note_en ... дальше мне даже продолжать не хочется. А теперь поговорим об объединениях? =))
1)Делал сайты максимум двуязычные- русский и английский. Единственно где нет многоязычности-это в случае ввода данных посетителями сайта(форум, гостевая книга etc). Однако и в случае разных баз это тоже может быть( если конечно не поставить соответствующие фильтры на ввод). 2)Для удобства, расширяемости, гибкости вводится конфигурационная переменная -массив с кодами поддерживаемых языков. Там где нужны разные языковые поля просто используется цикл обработки по этому массиву. Поэтому при добавлении нового языка просто добавляется в этот массив новый язык- код приложения нигде править не нужно. 3) Насчет объединений не понял. Можете привести пример с таблицами и требуемое объединение? 4) В моем предыдущем посте приводил пример с таблицами товаров и заказов. Можете написать как вы реализуете подобную задачу?
runner сам то понял что сказал? я нет. локаль то всегда одна значит и БД по локали одна будет. локейтовые БД идентичные по архитектуре. сразу двух локалей быть не может.
Локаль определяет язык, используемый для вывода дней недели и месяцев и аббревиатур, а также влияет на вывод от функций DATE_FORMAT(), DAYNAME(), and MONTHNAME(). Однако это не означает, что я не могу вывести дату в требуемом формате и что вместо русских названий месяцев и дней недели смогу вывести только английские названия при русском языке интерфейса. Да, это делается программным путем и не используются встроенные функции MySql, но это вовсе не означает, что нельзя сделать многоязычный сайт при принятом мною способе. Какой пункт непонятен? Какие последствия на многоязычность из приведенного вами фактов?
я не системную локаль имел ввиду. а слово есть такое локаль. а данном случае, тк. у нас только один уровень языковой абстракции. можно употребить понятие "местные БД"
Все вышеприведенные параметры прописываются для каждого поддерживаемого языка в конфигурационном файле приложения и в зависимости от выбранного языка интерфейса используются данные этого языка. Вопросы к Mr.M.I.T. 1) Вы это значение слова локаль имели в виду? 2) Какие выводы следуют из этого и предыдущего ваших сообщений? Хотел бы высказать такое предположение по поводу использования разных баз для разных языков. Если сайт использует только справочные данные, то все прекрасно. Но как только нужно использовать таблицы данных, ссылающиеся на справочные таблицы, то этот способ вообще не годится.