Автор |
Сообщение |
KPOTOB |
Добавлено: 22 Дек 2007 16:01:40 Заголовок сообщения: |
|
no problemo  |
|
 |
Vlad |
Добавлено: 21 Дек 2007 00:30:26 Заголовок сообщения: |
|
А. Всё. Дошло
Тоже вариант. Обмозгую.
Просто у меня до сих пор попадались заказы на "синхронные" сайты, т.е. если страниц есть, то она есть на всех языках.
Отсюда и размышления мои в этом же направлении
Сенкс, за расширение восприятия  |
|
 |
KPOTOB |
Добавлено: 20 Дек 2007 14:33:42 Заголовок сообщения: |
|
Vlad
Я имею ввиду что у тебя каждая запись содержит код языка
id, language, title, text
По умолчанию у тебя код языка к примеру en
В моделе при запросе записи передается код языка из пользовательского агента и далее если нету для того языка, то делается попытка найти для дефолтного языка (или по цепочке до дефолтного деградирует)
Так у тебя таблица полями не распухнет и большее колво языков поддержать можно будет |
|
 |
Vlad |
Добавлено: 20 Дек 2007 10:14:39 Заголовок сообщения: |
|
КРОТОВ ты имеешь ввиду создание в рамках одной таблицы разноязычных полей?
articles:
id
ru_title
en_title
uk_title
ru_body
en_t..
? или я тебя не так понял? |
|
 |
KPOTOB |
Добавлено: 20 Дек 2007 00:02:57 Заголовок сообщения: |
|
Одно дело изменение параметров для селекта а другое дело фактически изменение const члена класса (изменение класса + describe таблици по новой)
А почему не сделать поля с языком?
language
title
text
И чтобу language деградировал в сторону дефолтного значения если нету запрашиваемого для текущей статьи? |
|
 |
Vlad |
Добавлено: 19 Дек 2007 13:55:19 Заголовок сообщения: |
|
2КРОТОВ
и 2timer0x01
практической реализации ещё нет. Я пока размышляю, как это сделать лучше.
В любом случае, как ни крути, а "переключение" таблиц в том, или ином виде будет.
разве что, ограничиться одной табличкой articles
но добавить поля ru_title, uk_title, en_title, ru_body, uk_body...
что, наверное, практически одно и то же?
Показывать мне пока нечего, пока сам думаю, как это реализовать лучше, проще и т.д. |
|
 |
timer0x01 |
Добавлено: 18 Дек 2007 20:27:21 Заголовок сообщения: |
|
У меня возник проблем и он тот же как на /forum/viewtopic.php?t=83 описано ...
Vlad пожалуйста привиди конкретный пример как ты реализуешь перевключение в beforfilter-ре между таблицами в теме выше ? Какой у тебя променливая для контроля конкретного языка (GET или Сесиии) ?
Покажи пожалуйста простой пример .. а то у меня тот же вопрос возник .. как сделать многоязычьность..
СПАСИБО |
|
 |
KPOTOB |
Добавлено: 18 Дек 2007 19:52:18 Заголовок сообщения: |
|
Какое чуство подсказывает (а код смотреть лень ) что падение перформанса будет - таблицу будет дескрайбить при каждой смене языка и хронически писать в tmp/cache/model |
|
 |
Vlad |
Добавлено: 18 Дек 2007 16:07:19 Заголовок сообщения: |
|
ну вот я про него родимого и говорю. Его ж вроед можно переопределить?
Правда, это при условии, что в основном-то сам хозяин базы, и какой хош префикс - такой и используешь.
Но если таблиц множество, то, вероятно, можно корректировать уже не префикс, а имя таблицы
т.е. если у нас префикс - myblog_users ...
то в апп_модел переделываем имя таблиц на
myblog_ru_articles
myblog_uk_articles
myblog_en_articles
соответственно. Или что-то не так? |
|
 |
KPOTOB |
Добавлено: 18 Дек 2007 14:57:14 Заголовок сообщения: |
|
А как быть с штатным префиксом от соединения? |
|
 |
Vlad |
Добавлено: 18 Дек 2007 13:54:09 Заголовок сообщения: Многоязычный сайт (таблицы) |
|
А как вы думаете такое решение для динамических данных.
Имеем таблицы в базе (например)
users
groups (условно - говоря) ну и дальше:
uk_articles
ru_articles
en_articles
...
Далее, переопределяем app_model, которая из Configure берёт текущую кодировку, и, в зависимости от имени таблицы, которая требуется в данный момент - либо устанавливает префикс в ru/uk/en
либо (если речь идёт об одноязычных таблицах) - делает префикс пустым.
Нормальное решение? Или есть проще пути? |
|
 |