LiveStreet = поддержка многоязычного контента. Попытка 2.
2
Об этом уже писал Прочел livestreet.ru/blog/2109.html, livestreet.ru/blog/2347.html. Переключение интерфейса работает на славу. Но фильтр контента очень уж нужна. Поэтому начал сам потихоньку.
Для начало изменил несколько таблиц в базе, точнее prefix_topic_% (кроме prefix_topic_read). Внес полое `lang` (VARCHAR(128), NULL). После в файле Language.class.php нашел строчку (\classes\modules\language\):
@setcookie('LANG_CURRENT', $sLanguage, time()+60*60*24*intVal(LANG_SAVE_DAYS), SYS_SESSION_PATH, SYS_SESSION_HOST);
Как понял она устанавливает куки, что тоже работает. Если в index.php прописать
echo $_COOKIE['LANG_CURRENT']
выдается russian или english соответственно языку интерфейса. Но здесь один момент, через web-developer это куку увидеть так и не удалось увидеть. Не стал над этим задумывается, пошел дальше.
Начал разбирать файл \classes\modules\topic\mapper\Topic.mapper.class.php. Изменил запрос в функции AddTopic:
$sql = «INSERT INTO ».DB_TABLE_TOPIC."
(blog_id,
user_id,
topic_type,
topic_title,
topic_tags,
topic_date_add,
topic_user_ip,
topic_publish,
topic_publish_draft,
topic_publish_index,
topic_cut_text,
topic_forbid_comment,
topic_text_hash
)
VALUES(?d, ?d, ?,?, ?, ?, ?, ?d, ?d, ?d, ?, ?, ?)";
Изменил так:
$lang = $_COOKIE['LANG_CURRENT'];
$sql = «INSERT INTO ».DB_TABLE_TOPIC."
(blog_id,
user_id,
topic_type,
topic_title,
topic_tags,
topic_date_add,
topic_user_ip,
topic_publish,
topic_publish_draft,
topic_publish_index,
topic_cut_text,
topic_forbid_comment,
topic_text_hash,
lang
)
VALUES(?d, ?d, ?, ?, ?, ?, ?, ?d, ?d, ?d, ?, ?, ?,’”.$lang.”’)";
Тоже самое сделал и для функции AddTopicContent (правда я так и не понял, зачем нужна таблица prefix_topic_content). Запись топика в базу работает, нужное значение записывается как надо.
Пошел дальше. Перешел на функцию GetTopics, изменил запрос, добавил строчку
AND t.lang=’”.$_COOKIE['LANG_CURRENT'].”’.
На первй взгляд показалось что должно сработать. Но не тут то было. А точнее сказать работает, но не стабильно. Прехожу на русский язык там контент тока на русском языке, что и нужно было. Но если перейти на английский то картина не изменяется. Открываю в другом баузере, перехожу сразу на английский язык, контент на английском языке. Перехожу на русский язык контент не изменяется. Хотя в обеех случаях интерфей меняется как надо.
Делая вывод однозначно можно сказать, что я сделал что-то не так, и обусловить это можно тем, что я движок фактически незнаю. И вероятней всего сделал что-то не так или что-то не до делал.
Поэтому прошу помощи у Титанов, поскольку очень уж нужен этот функционал.
Для начало изменил несколько таблиц в базе, точнее prefix_topic_% (кроме prefix_topic_read). Внес полое `lang` (VARCHAR(128), NULL). После в файле Language.class.php нашел строчку (\classes\modules\language\):
@setcookie('LANG_CURRENT', $sLanguage, time()+60*60*24*intVal(LANG_SAVE_DAYS), SYS_SESSION_PATH, SYS_SESSION_HOST);
Как понял она устанавливает куки, что тоже работает. Если в index.php прописать
echo $_COOKIE['LANG_CURRENT']
выдается russian или english соответственно языку интерфейса. Но здесь один момент, через web-developer это куку увидеть так и не удалось увидеть. Не стал над этим задумывается, пошел дальше.
Начал разбирать файл \classes\modules\topic\mapper\Topic.mapper.class.php. Изменил запрос в функции AddTopic:
$sql = «INSERT INTO ».DB_TABLE_TOPIC."
(blog_id,
user_id,
topic_type,
topic_title,
topic_tags,
topic_date_add,
topic_user_ip,
topic_publish,
topic_publish_draft,
topic_publish_index,
topic_cut_text,
topic_forbid_comment,
topic_text_hash
)
VALUES(?d, ?d, ?,?, ?, ?, ?, ?d, ?d, ?d, ?, ?, ?)";
Изменил так:
$lang = $_COOKIE['LANG_CURRENT'];
$sql = «INSERT INTO ».DB_TABLE_TOPIC."
(blog_id,
user_id,
topic_type,
topic_title,
topic_tags,
topic_date_add,
topic_user_ip,
topic_publish,
topic_publish_draft,
topic_publish_index,
topic_cut_text,
topic_forbid_comment,
topic_text_hash,
lang
)
VALUES(?d, ?d, ?, ?, ?, ?, ?, ?d, ?d, ?d, ?, ?, ?,’”.$lang.”’)";
Тоже самое сделал и для функции AddTopicContent (правда я так и не понял, зачем нужна таблица prefix_topic_content). Запись топика в базу работает, нужное значение записывается как надо.
Пошел дальше. Перешел на функцию GetTopics, изменил запрос, добавил строчку
AND t.lang=’”.$_COOKIE['LANG_CURRENT'].”’.
На первй взгляд показалось что должно сработать. Но не тут то было. А точнее сказать работает, но не стабильно. Прехожу на русский язык там контент тока на русском языке, что и нужно было. Но если перейти на английский то картина не изменяется. Открываю в другом баузере, перехожу сразу на английский язык, контент на английском языке. Перехожу на русский язык контент не изменяется. Хотя в обеех случаях интерфей меняется как надо.
Делая вывод однозначно можно сказать, что я сделал что-то не так, и обусловить это можно тем, что я движок фактически незнаю. И вероятней всего сделал что-то не так или что-то не до делал.
Поэтому прошу помощи у Титанов, поскольку очень уж нужен этот функционал.
- 0
- 27 февраля 2010, 17:41
- netuser
Ошибку не исправит, но от проблем убережёт: формируя SQL запрос обрабатывайте данные на случай вредоносных вставок. То что у Вас сейчас — использовать нельзя, школяр-семиклассник Ваш сайт сломает.
Почитайте mysql_real_escape_string();
В ЛС это делается автоматически через библиотеку от Дмитрия Котерова DBSimple. Поизучайте, как правильно работать с этой библиотекой и сделайте без ошибок.
Почитайте mysql_real_escape_string();
В ЛС это делается автоматически через библиотеку от Дмитрия Котерова DBSimple. Поизучайте, как правильно работать с этой библиотекой и сделайте без ошибок.
ну смотрите
мы находимся на странице /page/russian/about/
(у меня все статические страницы созданы в такой иерархии)
сейчас при переключении на другой язык мы остаемся на этой же странице, что есть неправильно.
я предлагаю, чтобы скрипт, после того как переключит язык, сделает запись в кукисы — еще и принудительно обновлял текущую страницу на нужную нам, напр, /page/english/about/
разумеется только в случае, если мы находимся в /page/ и версия на другом языке существует
вроде как это не сложно сделать,
я после завтрака гляну
мы находимся на странице /page/russian/about/
(у меня все статические страницы созданы в такой иерархии)
сейчас при переключении на другой язык мы остаемся на этой же странице, что есть неправильно.
я предлагаю, чтобы скрипт, после того как переключит язык, сделает запись в кукисы — еще и принудительно обновлял текущую страницу на нужную нам, напр, /page/english/about/
разумеется только в случае, если мы находимся в /page/ и версия на другом языке существует
вроде как это не сложно сделать,
я после завтрака гляну
в общем, хоть я и дизайнер,
вроде получилось :)
в ActionLanguage.class.php
замените функцию EventIndex на новую:
если кто-то исправит говно-код — буду благодарен
вроде получилось :)
в ActionLanguage.class.php
замените функцию EventIndex на новую:
protected function EventIndex() {
if ($sLanguage=Router::GetActionEvent()) {
$this->Session_Set('language', $sLanguage);
if (defined('LANG_SAVE_DAYS') && LANG_SAVE_DAYS > 0) {
@setcookie('LANG_CURRENT', $sLanguage, time()+60*60*24*intVal(LANG_SAVE_DAYS), SYS_SESSION_PATH, SYS_SESSION_HOST);
}
if (isset($_SERVER['HTTP_REFERER'])) {
$pagename=explode('/',$_SERVER['HTTP_REFERER']);
if ($pagename[3]=='page') {
func_header_location(str_replace($pagename[4],$sLanguage,$_SERVER['HTTP_REFERER']));
} else {
func_header_location($_SERVER['HTTP_REFERER']);
}
}
}
func_header_location(DIR_WEB_ROOT);
если кто-то исправит говно-код — буду благодарен
не забудьте
это работает
если все статические страницы созданы в такой иерархии: /page/язык/имя_страницы/
это работает
если все статические страницы созданы в такой иерархии: /page/язык/имя_страницы/
статические страницы так и придется создавать (/page/язык/имя_страницы/). в ином случаи придется больше изменять код и базу.
а вот как быть с топиками? мне не дает покоя то, что я сделал сработало, но почему-то не стабильно.
а вот как быть с топиками? мне не дает покоя то, что я сделал сработало, но почему-то не стабильно.
у меня такое видение ситуации:
если у вас аудитория понимает оба языка (как у меня например — актуально для стран быв.ссср — русский и государственный), то фильтровать топики нет смысла, достаточно интерфейс менять и статические страницы
если же аудитория не пересекается и топики не дублируются на обоих языках — не вижу абсолютно никакого смысла в таком сочетании.
сделайте лучше два разных проекта. на разных доменах, с разными языками. ну максимум можно базу юзеров общую держать.
я не отговариваю вас,
если так хотите — проще всего посмотреть как сделан вывод топиков по тегу и доработать на основе этого вывод топиков в блогах.
тогда базу не придется трогать. просто будете к каждому топику цеплять языковой тег.
если у вас аудитория понимает оба языка (как у меня например — актуально для стран быв.ссср — русский и государственный), то фильтровать топики нет смысла, достаточно интерфейс менять и статические страницы
если же аудитория не пересекается и топики не дублируются на обоих языках — не вижу абсолютно никакого смысла в таком сочетании.
сделайте лучше два разных проекта. на разных доменах, с разными языками. ну максимум можно базу юзеров общую держать.
я не отговариваю вас,
если так хотите — проще всего посмотреть как сделан вывод топиков по тегу и доработать на основе этого вывод топиков в блогах.
тогда базу не придется трогать. просто будете к каждому топику цеплять языковой тег.
Комментарии (12)
RSS свернуть / развернуть