/*
(int)$ID - идентификатор
(array)$arg - массив вставляемых значений типа "привет {$arg[0]}!"
*/
function getTranslate($ID, $arg)
switch($ID) {
case "__1__";
return "значени 1";
break;
...
case "__${n}__";
return "значени ${n}";
break;
}
Организация мультиязычности в CMS
Ребята. Нужен совет.
Необходимо организовать мультиязычность портала с минимальным нагрузом сервера.
Каким образом порекомендуете осуществить?
Портал пишется на постгресе.
Как я понимаю - 4 варианта организации мультиязычности.
С архивом записей в файлах php
С архивом записей в файлах txt
грубо говоря txt вида:
[1]:[Первый элемент];
[2]:[второй элемент {переменная1}];
...
и перебирать его с помощью пхп.
С архивом записей в файлах xml
С архивом записей в таблице базы (в данном случае постгрес)
Что посоветуете?
Необходим оптимальный вариант. Берем за пример что у нас по 1 запросу дёргается 100 записей по идентификаторам а в архивчике 10 000 записей.
Необходимо организовать мультиязычность портала с минимальным нагрузом сервера.
Каким образом порекомендуете осуществить?
Портал пишется на постгресе.
Как я понимаю - 4 варианта организации мультиязычности.
С архивом записей в файлах php
Код:
С архивом записей в файлах txt
грубо говоря txt вида:
[1]:[Первый элемент];
[2]:[второй элемент {переменная1}];
...
и перебирать его с помощью пхп.
С архивом записей в файлах xml
С архивом записей в таблице базы (в данном случае постгрес)
Что посоветуете?
Необходим оптимальный вариант. Берем за пример что у нас по 1 запросу дёргается 100 записей по идентификаторам а в архивчике 10 000 записей.
Вот так:
lang/en/misc.php:
lang/ru/misc.php:
index.php:
lang/en/misc.php:
Код:
<?php
$lang['test'] = "Test";
// ...
?>
$lang['test'] = "Test";
// ...
?>
lang/ru/misc.php:
Код:
<?php
$lang['test'] = "Проверка";
// ...
?>
$lang['test'] = "Проверка";
// ...
?>
index.php:
Код:
<?php
$lang_id = 1 ? 'ru' : 'en';
$lang = array();
include('lang/'.$lang_id.'/misc.php');
echo $lang['test'];
?>
$lang_id = 1 ? 'ru' : 'en';
$lang = array();
include('lang/'.$lang_id.'/misc.php');
echo $lang['test'];
?>
Считаем, что CMS спроектирована согласно MVC модели, раз не говорится обратное.
В БД (модель) хранятся сухие числа. Например, у поста в блог есть три комментария.
В контроллере при выборе пользователя языка сохраняем в сессию значение выбранного языка: session[:language] = 'ru'
За представление страницы пользователю отвечает View.
В общем случае верстка страницы может отличаться в зависимости от языка. Например, в одном языке слово может быть длиннее чем в другом и не помещаться в блоке малой ширины. Создаем несколько View: одну под каждый язык. Файлы с view называем единообразно: article_ru.html.erb, article_en.html.erb, ...
С такой структурой мы можем в контроллере подсовывать клиенту представление соответствующее выбранному языку или значению по умолчанию, если пользователь ничего не выбрал:
render :action => "article_#{session[:language] || property(:default_language)}.html.erb"
Вот как-то так.
В БД (модель) хранятся сухие числа. Например, у поста в блог есть три комментария.
В контроллере при выборе пользователя языка сохраняем в сессию значение выбранного языка: session[:language] = 'ru'
За представление страницы пользователю отвечает View.
В общем случае верстка страницы может отличаться в зависимости от языка. Например, в одном языке слово может быть длиннее чем в другом и не помещаться в блоке малой ширины. Создаем несколько View: одну под каждый язык. Файлы с view называем единообразно: article_ru.html.erb, article_en.html.erb, ...
С такой структурой мы можем в контроллере подсовывать клиенту представление соответствующее выбранному языку или значению по умолчанию, если пользователь ничего не выбрал:
render :action => "article_#{session[:language] || property(:default_language)}.html.erb"
Вот как-то так.
Nixus
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?
shine
Тема интересная. Так и буду организовывать, спасибо.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?
shine
Тема интересная. Так и буду организовывать, спасибо.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.
Думаю лучше использовать файлы, а не БД. Разбивать перевод на категории соответственно разделам и подгружать в зависимости от местоположения пользователя. Собственно свою систему мы так сейчас и пишем. БД надо использовать как можно реже на стороне посетителей. В админке в общем как хочешь ее можно использовать тк нагрузка все равно не будет большой (трудно представиь себе сайт где несколько тысяч администраторов сидит одновременно)
Цитата: Affecting
Nixus
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?
Все зависит от типа данных и метода доступа к ним. Только при чем тут многоязычность?
Цитата: Affecting
Тема интересная. Так и буду организовывать, спасибо.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.
Данные я бы хранил в БД (независимо от объема). Любые другие варианты по сути будут сводится к организации БД другими средствами т.к. опять таки прийдется создавать механизмы для чтения/вставки/изменения/удаления записей. Все это уже есть в постгресе + это сделано грамотно и хорошо оптимизировано по скорости + всякие полезные вещи типа индексов, тригеров и т.д.
За скорость не волнуйтесь: постгрес штука шустрая. В принципе 10000 записей это ерунда для любой БД.
В файлах я бы хранил только конфигурацию(default_language, ...) и, может быть, какие-то постоянные данные из-за которых нехотелось бы дергать БД (список областей Украины, список месяцев в году и т.д и т.п.).
Цитата: shine
Данные я бы хранил в БД (независимо от объема).
Поддержываю. Также хочу заметить что не всегда можно совать фразы на разных языках в файл. К примеру наши клиенты размещали информацию об обектах представленых на портале на нескольких языках. Тут файлам никак не место. Хотя ми использовали гибридное решение. Тоесть фрази которые присудствовали в шаблонах страниц держали таки в файлах. Но ето было обосновано реализацией MultiLanguageSmarty и моим нежеланием его менять :)
Также советую создать хорошо продуманий базовый класс для сущностей предметной области, которые могут быть представлены на разных языках. К примеру. У меня била возможность обращаться к многоязычним полям следующим образом
Код:
$obj->field // для пользовательских страниц
$obj->field__ru // для админки
$obj->field__en
$obj->field__ru // для админки
$obj->field__en
На чем основано ваше утверждение, что нельзя помещать слова на разных языках в один файл, но при этом можно в одну БД? Точно также хорошо будет работать и в файле, если использоваться единственно верную кодировку unicode (UTF-8 или как вариант, если нужно что-то сильно навороченное UTF-24)
К тому же в CMS (если она вменяемая) есть такое понятие как модули. И вам придется решать еще проблему как сделать так чтобы идентификаторы фраз и слов самой системы не пересекались с идентификаторами модулей (которые к слову часто разрабатываются сторонними программистами).
К тому же в CMS (если она вменяемая) есть такое понятие как модули. И вам придется решать еще проблему как сделать так чтобы идентификаторы фраз и слов самой системы не пересекались с идентификаторами модулей (которые к слову часто разрабатываются сторонними программистами).
Цитата: RussianSpy
На чем основано ваше утверждение, что нельзя помещать слова на разных языках в один файл.
Видимо имелось ввиду ето
[quote=Rebbit]Также хочу заметить что не всегда можно совать фразы на разных языках в файл. К примеру наши клиенты размещали информацию об обектах представленых на портале на нескольких языках.[/quote]
Проблема не в кодировке. Обясняю подробнее. Мы создали сайт на котором продается нечто. Припустим НЛО. У НЛО есть описание, есть замечания пользователя относительно условий продажи НЛО и еще много текстовой инфы. Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках. Ну не файлы же мне редактировать когда он захочет еще одно НЛО продать.
я бы вообще в INI-файлах хранил не только языковые локализации, но и адреса картинок и пр. Один язык - один INI-файл. И быстрее, и БД не напрягается на выборки. Да и редактировать их, как бы это высказаться помягчее... наглядней, что-ли, прямо в notepad'е можно...
Цитата: Rebbit
Видимо имелось ввиду ето
Проблема не в кодировке. Обясняю подробнее. Мы создали сайт на котором продается нечто. Припустим НЛО. У НЛО есть описание, есть замечания пользователя относительно условий продажи НЛО и еще много текстовой инфы. Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках. Ну не файлы же мне редактировать когда он захочет еще одно НЛО продать.
Проблема не в кодировке. Обясняю подробнее. Мы создали сайт на котором продается нечто. Припустим НЛО. У НЛО есть описание, есть замечания пользователя относительно условий продажи НЛО и еще много текстовой инфы. Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках. Ну не файлы же мне редактировать когда он захочет еще одно НЛО продать.
Не путайте теплое с мягким. Это уже не элементы интерфейса CMS, извините меня. Это деление проекта на языковые разделы. Если уж вы хотите иметь описание одного и того же товара на разных языках то тут надо иметь как минимум две таблицы в одной из которых будут собственно товары (id, артикул, цена, количество и т.д.), а в другой соответственно описания товаров на разных языках (id товара, язык, параметры описания). И в данном случае действительно удобнее использовать таблицы.
Если же говорить именно об интерфейсах системы, то намного удобнее как верно заметил mfender использовать файлы: их подгружать не так накладно, и редактировать удобно и при переноске не нужно возиться с экспортом/импортом в БД.
Цитата: Rebbit
Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках.
3 варианта данных которые ввел пользователь - модели(или часть одной большой). Оформление в котором пользователь (не обязательно тот же самый пользователь) будет все это видеть - представления.
Мультиязычность CMS скорее подразумевает возможность ткнуть в EN, RU или UA и увидеть UI на своем языке, чем возможность вводить данные на разных языках.
RussianSpy описал чуть выше как можно организовать такую многоязычную модель.