Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Организация мультиязычности в CMS

11K
21 сентября 2008 года
Affecting
10 / / 23.10.2005
Ребята. Нужен совет.
Необходимо организовать мультиязычность портала с минимальным нагрузом сервера.
Каким образом порекомендуете осуществить?

Портал пишется на постгресе.

Как я понимаю - 4 варианта организации мультиязычности.

С архивом записей в файлах php
Код:
/*
(int)$ID - идентификатор
(array)$arg - массив вставляемых значений типа "привет {$arg[0]}!"
*/
function getTranslate($ID, $arg)
switch($ID) {
 case "__1__";
   return "значени 1";
 break;
...
 case "__${n}__";
   return "значени ${n}";
 break;
}



С архивом записей в файлах txt
грубо говоря txt вида:

[1]:[Первый элемент];
[2]:[второй элемент {переменная1}];
...

и перебирать его с помощью пхп.


С архивом записей в файлах xml


С архивом записей в таблице базы (в данном случае постгрес)


Что посоветуете?
Необходим оптимальный вариант. Берем за пример что у нас по 1 запросу дёргается 100 записей по идентификаторам а в архивчике 10 000 записей.
353
21 сентября 2008 года
Nixus
840 / / 04.01.2007
Вот так:

lang/en/misc.php:
 
Код:
<?php
$lang['test'] = "Test";
// ...
?>


lang/ru/misc.php:
 
Код:
<?php
$lang['test'] = "Проверка";
// ...
?>


index.php:
 
Код:
<?php
$lang_id = 1 ? 'ru' : 'en';
$lang = array();
include('lang/'.$lang_id.'/misc.php');
echo $lang['test'];
?>
337
21 сентября 2008 года
shine
719 / / 09.06.2006
Считаем, что 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"

Вот как-то так.
11K
21 сентября 2008 года
Affecting
10 / / 23.10.2005
Nixus
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?

shine
Тема интересная. Так и буду организовывать, спасибо.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.
13
21 сентября 2008 года
RussianSpy
3.0K / / 04.07.2006
Думаю лучше использовать файлы, а не БД. Разбивать перевод на категории соответственно разделам и подгружать в зависимости от местоположения пользователя. Собственно свою систему мы так сейчас и пишем. БД надо использовать как можно реже на стороне посетителей. В админке в общем как хочешь ее можно использовать тк нагрузка все равно не будет большой (трудно представиь себе сайт где несколько тысяч администраторов сидит одновременно)
353
21 сентября 2008 года
Nixus
840 / / 04.01.2007
Цитата: Affecting
Nixus
Есть соображения до какого кол.-ва записей целесообразно хранение данных в массиве?


Все зависит от типа данных и метода доступа к ним. Только при чем тут многоязычность?

337
21 сентября 2008 года
shine
719 / / 09.06.2006
Цитата: Affecting
Тема интересная. Так и буду организовывать, спасибо.
Вопрос в ГДЕ ИМЕННО целесообразно хранить данные до определённого объема записей и когда их больше определённого объема.



Данные я бы хранил в БД (независимо от объема). Любые другие варианты по сути будут сводится к организации БД другими средствами т.к. опять таки прийдется создавать механизмы для чтения/вставки/изменения/удаления записей. Все это уже есть в постгресе + это сделано грамотно и хорошо оптимизировано по скорости + всякие полезные вещи типа индексов, тригеров и т.д.

За скорость не волнуйтесь: постгрес штука шустрая. В принципе 10000 записей это ерунда для любой БД.

В файлах я бы хранил только конфигурацию(default_language, ...) и, может быть, какие-то постоянные данные из-за которых нехотелось бы дергать БД (список областей Украины, список месяцев в году и т.д и т.п.).

276
24 сентября 2008 года
Rebbit
1.1K / / 01.08.2005
Цитата: shine
Данные я бы хранил в БД (независимо от объема).


Поддержываю. Также хочу заметить что не всегда можно совать фразы на разных языках в файл. К примеру наши клиенты размещали информацию об обектах представленых на портале на нескольких языках. Тут файлам никак не место. Хотя ми использовали гибридное решение. Тоесть фрази которые присудствовали в шаблонах страниц держали таки в файлах. Но ето было обосновано реализацией MultiLanguageSmarty и моим нежеланием его менять :)

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

 
Код:
$obj->field        // для пользовательских страниц
$obj->field__ru    // для админки
$obj->field__en
Не держыте языкозависемые поля в одной таблице с самими сущностями (так было у меня и такой подход вызывает большые трудности при добавлении нового языка). ИМХО лутше добавить join и пожертвовать перформенсом чем розкладывать грабли себе под ноги. Дешевле купить хороший сервак чем угробить кучу времени на рефакторинг и т.п.
13
24 сентября 2008 года
RussianSpy
3.0K / / 04.07.2006
На чем основано ваше утверждение, что нельзя помещать слова на разных языках в один файл, но при этом можно в одну БД? Точно также хорошо будет работать и в файле, если использоваться единственно верную кодировку unicode (UTF-8 или как вариант, если нужно что-то сильно навороченное UTF-24)

К тому же в CMS (если она вменяемая) есть такое понятие как модули. И вам придется решать еще проблему как сделать так чтобы идентификаторы фраз и слов самой системы не пересекались с идентификаторами модулей (которые к слову часто разрабатываются сторонними программистами).
276
24 сентября 2008 года
Rebbit
1.1K / / 01.08.2005
Цитата: RussianSpy
На чем основано ваше утверждение, что нельзя помещать слова на разных языках в один файл.


Видимо имелось ввиду ето
[quote=Rebbit]Также хочу заметить что не всегда можно совать фразы на разных языках в файл. К примеру наши клиенты размещали информацию об обектах представленых на портале на нескольких языках.[/quote]
Проблема не в кодировке. Обясняю подробнее. Мы создали сайт на котором продается нечто. Припустим НЛО. У НЛО есть описание, есть замечания пользователя относительно условий продажи НЛО и еще много текстовой инфы. Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках. Ну не файлы же мне редактировать когда он захочет еще одно НЛО продать.

8
24 сентября 2008 года
mfender
3.5K / / 15.06.2005
я бы вообще в INI-файлах хранил не только языковые локализации, но и адреса картинок и пр. Один язык - один INI-файл. И быстрее, и БД не напрягается на выборки. Да и редактировать их, как бы это высказаться помягчее... наглядней, что-ли, прямо в notepad'е можно...
13
24 сентября 2008 года
RussianSpy
3.0K / / 04.07.2006
Цитата: Rebbit
Видимо имелось ввиду ето

Проблема не в кодировке. Обясняю подробнее. Мы создали сайт на котором продается нечто. Припустим НЛО. У НЛО есть описание, есть замечания пользователя относительно условий продажи НЛО и еще много текстовой инфы. Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках. Ну не файлы же мне редактировать когда он захочет еще одно НЛО продать.



Не путайте теплое с мягким. Это уже не элементы интерфейса CMS, извините меня. Это деление проекта на языковые разделы. Если уж вы хотите иметь описание одного и того же товара на разных языках то тут надо иметь как минимум две таблицы в одной из которых будут собственно товары (id, артикул, цена, количество и т.д.), а в другой соответственно описания товаров на разных языках (id товара, язык, параметры описания). И в данном случае действительно удобнее использовать таблицы.

Если же говорить именно об интерфейсах системы, то намного удобнее как верно заметил mfender использовать файлы: их подгружать не так накладно, и редактировать удобно и при переноске не нужно возиться с экспортом/импортом в БД.

337
25 сентября 2008 года
shine
719 / / 09.06.2006
Цитата: Rebbit
Наш пользователь полиглот и для того чтоб повысить имоверность продажи своего НЛО розмещает всю текстовую информацию на 3 языках.



3 варианта данных которые ввел пользователь - модели(или часть одной большой). Оформление в котором пользователь (не обязательно тот же самый пользователь) будет все это видеть - представления.

Мультиязычность CMS скорее подразумевает возможность ткнуть в EN, RU или UA и увидеть UI на своем языке, чем возможность вводить данные на разных языках.

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

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог