Более грамотная реализация мультиязычности, XML

[Nelius]

Автор оригинала: texrdcom
Nelius
Сразу решайте следующие:
1) Есть языковые данные, нужно переводить их как то, будете хранить в бд, будете писать интерфейс для переводчиков.
2) использовать для этого сложный формат. хмл, также проблематично, пока будете переводить сами все окей, но отдадите перевод сделать переводчику, могут быть трудности.
3) Поиск по переводам интерфейса не логично выполнять, значит база данных не нужна.
4)есть пару стандартов на счет трансляции, один сраспространённых gettext, плюс к нему есть шаровый редактор для переводов PDOedit.

Спасибо что откликнулись!
Смотрите какое тут дело... Сайт интернациональный, каждый пользователь может сделать запись, допустим в блоге или в коменте, на своем родном языке, каждая страница сайта переведена на большинство языков мира каждая надпись на кнопочке, панельке, во всплывающей подсказке, контекстной справочной информации переведена.
Один раз все это будет переведено и все, дальше тока редактирование и то крайне редко, то есть даю переводчику статью, он ее переводит на японский, присылает мне в любом формате, будь то PDF или RTF или TXT а я его просто добавляю на сайт)
В моей админке я захожу в раздел где могу добавить "статические" html странички на сайт тупо жму добавить новую страницу, выбираю из списка японский язык, copy|paste переведенный текст и все, проблем нет. Если будет необходимо дам переводчику права в админке только на добавление текстов. Сам текст страничек храниться в БД (UTF-8) без всякого XML ибо по страницам есть поиск. А в XML я храню тока надписи кнопочек, сообщения об ошибках итд, они разнятся от модуля к модулю... мне удобно хранить общие данные для всего сайта в одной XMLке и для каждого модуля свои данные в собственной XMLке. Поиск по по переводам интерфейса, вы правы, выполняться не будет, НО при большой нагрузке читать эти XML из файлов мне кажется будет тормознее чем из БД. К тому же я могу их один раз извлечь и закешировать в памяти.
Вот на чем я основываюсь делая выбор в каком формате и где хранить эти данные. Если вы, считаете что при нагрузке 3000-5000 человек находящихся на сайте в данный момент и активно его использующих быстрее будет брать данные из файлов, я с удовольствием использую ваш опыт в своем проекте, просто хочется реальных примеров... мож кто работал или имеет свой популярный проект типа блогов или сайтов знакомств, поделитесь опытом пожалуйста.

 

[Alexandre]

А в XML я храню тока надписи кнопочек, сообщения об ошибках итд, они разнятся от модуля к модулю... мне удобно хранить общие данные для всего сайта в одной XMLке и для каждого модуля свои данные в собственной XMLке. Поиск по по переводам интерфейса, вы правы, выполняться не будет, НО при большой нагрузке читать эти XML из файлов мне кажется будет тормознее чем из БД. К тому же я могу их один раз извлечь и закешировать в памяти.

я приблизительно так и делал - только мои настройки не применялись для многоязычности: технология следующая

все данные, которые должны быть использованы - формируются в XML
далее есть некоторый XSLT - который формирует преобразование, например из XML

<word id=hello>
    <lang=ru>привет</lang>
    <lang=en>hello</lang>
</word>
<word id=save>
    <lang=ru>созранить</lang>
    <lang=en>save</lang>
</word>

преобразуем в РНР текст lang.inc.php :

$en = array(  'hello' => 'hello' , 'save'=>'save'  ... );
$ru = array(  'hello' => 'привет' ,  'save'=>'сохранить' ... );

делается это один раз первоначально , и далее при добавлении делаем новые преобразования... Далее мы только инклудим наш массив - быстро и красиво!!!

 

[Nelius]

Спасибо Alexandre. Детально изучаю XML+XSLT. Думаю без полного освоения этих технологий врядли что у меня получится, вот и занялся ими вплотную.
О результатах тестов и экспериментов отпишусь.
Жду еще постов от программеров кто реализовывал высоконагруженные системы.

 

[dark-demon]

Alexandre, то, что ты привёл xml-лом не является и врятли какой xsl-трансформатор такое скушает...

 

[Nelius]

Автор оригинала: dark-demon
Alexandre, то, что ты привёл xml-лом не является и врятли какой xsl-трансформатор такое скушает...

Наверное просто поленился привести код полностью) Но смысл то передал, что собственно и требовалось

 

[grigori]

dark-demon, ты сетуешь на невозможность воспользоваться методом copy-paste или просто придираешься?
Alexandre, идея отличная, мне очень понравилась.
Не только для мультиязычности - для конфигов и любых относительно небольших наборов данных, которые читаются скриптом намного чаще, чем меняются, но иногда надо посмотреть человеку и подправить руками или просто не требуют условий выборки - такое можно делать!

Сейчас напишу класс, который при 1м обращении читает xml и генерит php.
Потом читает php-файл с массивом/классом данных (включая время изменения) и проверяет, не менялся ли xml-файл.
При использовании байткод-кеша гибкость/скорость/переносимость такой техники мне кажется намного лучше, чем использование базы данных.

 

[Nelius]

байткод-кеша

grigori расскажите пожалуйста об этом поподробнее? Я много наслышан о всяких APC, XCache, PHP Accelerator, но сам не пользовал, задач таких ресурсоемких не было. Я не ошибся в перечеслении?
Насколько я понимаю при помощи этого можно хранить данные в shared memory, насколько это ускорит все я тоже могу себе представить. Но вот какие именно данные и как мне неизвестно. И еще, ведь ничто тогда не мешает также взять данные единажды из БД а не из файла. Поправьте, дополните меня пожалуйста, если я что-то недопонимаю.

 

[dark-demon]

Nelius, нет, основное их предназначение - кэшировать байткод, чтобы при каждой загрузке скрипта не происходила трансляция кода с языка php в zend-байткод.

вообще говоря, если использовать такой подход, то использование xml становится лишним...

 

[Nelius]

Автор оригинала: dark-demon
Nelius, нет, основное их предназначение - кэшировать байткод, чтобы при каждой загрузке скрипта не происходила трансляция кода с языка php в zend-байткод.

вообще говоря, если использовать такой подход, то использование xml становится лишним...

О! Теперь понятнее) Согласен что XML в этом случаем можно исключить...
То есть могу просто инклюдить ru.lng:

$lang['thing'] = 'Что-то';
$lang['something'] = 'Еще Что-то';

Закешировать его и дело с концом?)

 

[dark-demon]

угу

 

[Nelius]

Спасибо! Это многое решает на самом деле, ведь по мере роста проекта я думаю рано или поздно наступает время когда байткод-кеш становится просто необходим. А при его использовании что может быть быстрее чем обычный массив пхп, поэтому я все же откажусь от своей старой схемы хранения XML в БД и попробую сделать так. Результатами эксперимента поделюсь в этой теме.

 

[grigori]

Автор оригинала: Nelius
grigori расскажите пожалуйста об этом поподробнее? Я много наслышан о всяких APC, XCache, PHP Accelerator, но сам не пользовал, задач таких ресурсоемких не было. Я не ошибся в перечеслении?

# Zend Platform
# APC (APC GUI)
# XCache
# eAccelerator
# ionCube Encoder
# PHP Accelerator (PHP 4)

Насколько я понимаю при помощи этого можно хранить данные в shared memory, насколько это ускорит все я тоже могу себе представить. Но вот какие именно данные и как мне неизвестно.

Какие данные положишь - те и возьмешь.
Правильный вопрос - какие что туда писать. Например, можно результат выборки из базы по ID.

И еще, ведь ничто тогда не мешает также взять данные единажды из БД а не из файла. Поправьте, дополните меня пожалуйста, если я что-то недопонимаю.

Обычно цель кеширования данных в разделяемой памяти - снижение нагрузки на БД.

-~{}~ 11.11.07 16:57:

Автор оригинала: dark-demon
Nelius, нет, основное их предназначение - кэшировать байткод, чтобы при каждой загрузке скрипта не происходила трансляция кода с языка php в zend-байткод.

Не стоит обобщать.

если использовать такой подход, то использование xml становится лишним...

В задаче автора - возможно, но я говорю не про этот конкретный случай.
Хранение данных в формате XML в файлах имеет для меня заметные и ощутимые преимущества по сравнению с синтаксисом массивов на php.
Мне не хочется устраивать holy war на тему "Array vs XML" - у вас другие задачи и вам это скорее всего просто не надо.

 

[dark-demon]

нет ^_^ у меня другие задачи и поэтому мне это надо, а вот топикастеру - наврятли.