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

Nelius

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

Так как faq на профилактике, а в поиске толком ничего не нашел по конкретно моему случаю...
Обращаюсь к гуру со следующим вопросом:

У меня в CMS следующая реализация мультиязычности:

Пример:

<?xml version="1.0"?>
<data>
<ru>
<login_button>Войти</login_button>
<err_login>Неверный логин</err_login>
<err_pass>Неверный пароль</err_pass>
</ru>
<en>
<login_button>Login</login_button>
<err_login>Incorrect login</err_login>
<err_pass>Incorrect password</err_pass>
</en>
</data>

Пример сильно упрощенный, но смысл я думаю передает.

Далее в скрипте я использую:
PHP:
$lang = new SimpleXMLElement($xml_iz_primera);
Далее могу пихать в шаблон:
PHP:
$lang->$cfg['site_lang']->login_button
В этом случае данные храняться в БД.

Возможно такая реализация будет работать быстрее:

Файл: ru.lng
PHP:
$lang['login_button'] = 'Войти';
$lang['err_login'] = 'Неверный логин';
$lang['err_pass'] = 'Неверный пароль';
Файл: en.lng
PHP:
$lang['login_button'] = 'Login';
$lang['err_login'] = 'Incorrect login';
$lang['err_pass'] = 'Incorrect password';
Далее в скрипте:
PHP:
include($cfg['site_lang'].'.lng');
И просто юзаем:
PHP:
$lang['login_button']
...
Или третий вариант храним контент как он реализован во 2 варианте в БД а после доставания его оттуда юзаем eval ...

Как будет правильней и какой вариант будет быстрее при большой нагрузке :confused:

P.S. В первом варианте, в примере, реализация не лучшая ибо в память грузятся данные всех языков... если кто знает как сделать лучше подскажите, так как с XML я только начал работать.

Заранее спасибо.
 

Nelius

кипарис во дворе
Про get_text я знаю... правда пока его не изучал особо...
Но как я понял он тоже работает с файлами... разве это будет быстрее чем mysql при большой нагрузке?

-~{}~ 06.11.07 19:43:

Поясню немного...
Представьте что на сайте 1000 человек, и все с огромной страстью к кликанью.... и вот они кликают все непрерывно... дико нагружая мой сервак)))

Так вот при большой нагрузке каждый include на счету ибо мучает мои харды... запросы к БД тоже на счету, но в моей нынешней реальзации на извлечение из БД языковых данных я не трачу ни одного запроса, все данные встраиваются в структуру CMS и извлекаются одновременно с критичными данными(конфиг, тексты страничек, права доступа к разделу)

Вот я и пытаюсь найти оптимальную реализацию...
Смотрю в сторону файлов (оно же мой пример и вроде как gettext) или в сторону eval чтоб не нагружать интерпретатор парсингом тяжелых XML
 

SiMM

Новичок
> или в сторону eval чтоб не нагружать интерпретатор парсингом тяжелых XML
Тогда смотреть разумнее в сторону [m]parse_ini_file[/m], а не eval
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Автор оригинала: Nelius
при большой нагрузке каждый include на счету ибо мучает мои харды...
Решение: Bytecode cache (APC, XCache)
запросы к БД тоже на счету
Оптимизация запросов и индексов, сегментация, репликация
языковые данные извлекаются одновременно с критичными данными (конфиг, тексты страничек, права доступа к разделу)
Вам хороший хирург тоже поможет

чтоб не нагружать интерпретатор парсингом тяжелых XML
А че б не кешировать в памяти результат парсинга, проверяя только время изменения файла?
 

crocodile2u

http://vbolshov.org.ru
gettext - очень быстрое решение. возможно, наиболее быстрое из существующих для php.
 

alexcrown

Новичок
У gettext только один минус - использование его под Windows (через IIS или Apache) может приводить к проблемам на мультиязычных сайтах, т.к. setlocale устанавливает локаль для процесса, а в Windows веб-сервер вроде как выполняется мультипоточно в одном процессе. Соответственно, локаль, а следовательно и данные для перевода, может измениться в процессе работы параллельного скрипта (Я правда не проверял).

Если вы используете XSLT, то некоторые мысли по поводу реализации мультиязычности есть тут http://www.artlebedev.ru/tools/technogrette/xslt/multilang/ .

А еще можно использовать gettext при xsl-преобразованиях с помощью возможности XSLTProcessor::registerPHPFunctions()
 

Духовность™

Продвинутый новичок
Тогда смотреть разумнее в сторону parse_ini_file, а не eval
Не разумно. Во-первых, parse_ini_file спотыкается на какие-то там символы, содержащиеся в строке - проверено. Во-вторых,языковой массив $_LANG['ru'][...] будет ничуть не хуже.
 

Nelius

кипарис во дворе
Автор оригинала: crocodile2u
gettext - очень быстрое решение. возможно, наиболее быстрое из существующих для php.
Я поизучал gettext, почитал... спорить с тем что это очень быстрое решение не буду, но что-то мне подсказывает что это решение будет не очень удобным для моей CMS. И как видно из коментариев и отзывов которые я прочел, многие испытывают проблемы при использовании данных функций.
Спасибо за совет, но я думаю я буду искать альтернативу.

-~{}~ 07.11.07 12:14:

Всем спасибо за советы.
Хотелось бы выяснить вот что, допустим я использую кэширование и основные данные, после парсинга, у меня будут храниться в памяти, согласен это сильно ускорит работу скриптов в целом.
Хотелось бы теперь узнать кто как у себя реализовал хранение данных... в файлах или в БД или... Как я уже говорил ранее в данный момент у меня данные храняться в БД, пробовал использовать файлы с языковыми массивами, но под нагрузкой и то и то не проверялось, если у кого есть опыт практического применения какой-либо реализации, поделитесь пожалуйста как оно у вас работает и с какими проблемами вам приходилось сталкиваться.
 

crocodile2u

http://vbolshov.org.ru
Nelius
Мне почему-то кажется, что вряд ли система локализации/интернационализации будет узким местом твоей системы.
 

Nelius

кипарис во дворе
Автор оригинала: crocodile2u
Nelius
Мне почему-то кажется, что вряд ли система локализации/интернационализации будет узким местом твоей системы.
Возможно вы и правы, мне может элементарно не хватить опыта или навыков чтобы оптимально преодолеть другие "узкие места", просто сейчас перерабатываю систему полностью, хочется сделать все качественно, это меня и сподвигло попросить людей поделиться опытом. Так что буду ждать ответов :)
 

SiMM

Новичок
Автор оригинала: triumvirat
Не разумно. Во-первых, parse_ini_file спотыкается на какие-то там символы, содержащиеся в строке - проверено.
А eval не спотыкается? :) Плохому танцору...
 

Alexandre

PHPПенсионер
Тогда смотреть разумнее в сторону parse_ini_file, а не eval
смотри в сторону shered memory

-~{}~ 07.11.07 21:10:

А еще можно использовать gettext при xsl-преобразованиях с помощью возможности XSLTProcessor::registerPHPFunctions()
я бы этого не советовал - callBack - это всегда медленно. У меня давно есть мысль написать плагин gettext для libxslt. Делов часа на четыре и будет счастье!
 

WP

^_^
А у меня для каждого языка компилится свой шаблон, поэтому 0 потерь в скорости.
 

Nelius

кипарис во дворе
Автор оригинала: Alexandre
смотри в сторону shered memory
Я уже тоже пришел к этому выводу, спасибо!
Можно еще узнать ваше мнение, как бы вы хранили данные?
В языковых массивах в файлах или может быть XML в MySQL?

-~{}~ 08.11.07 01:20:

Автор оригинала: WP
А у меня для каждого языка компилится свой шаблон, поэтому 0 потерь в скорости.
Впринципе это тоже выход, но это не всегда бывает удобно, у меня так раньше тоже было ;)
 

dark-demon

d(^-^)b
насчёт xslt - я недавно выкладывал решение допускающее частичную локализацию и позволяющее писать в исходниках нормальный текст, а не причудливый xpath путь.

если в кратце...
пишем текст по английски, помечая локализуемые части:

english text <translate>english text</translate> english text

а в xsl файле локализации просто пишем:

<template match="//translate[text()='english text']">русский текст</template>

либо не пишем и там остаётся английский текст.
 

Alexandre

PHPПенсионер
Можно еще узнать ваше мнение, как бы вы хранили данные?
В языковых массивах в файлах или может быть XML в MySQL?
все индивидуально... в одном проекте я использовал хранение XML в текстовом поле БД (но это были не языковые данные). Это дает некоторый плюс, но если по ним не вести поиск. Встроенный поиск по xpath в MySQL немного тормозное, но в некоторых случаях его использовать можно. Как уже подсказали решение - используется несколько разных XSLТ преобразований. В последнем проекте я использовал для хранения специальную таблицу MySQL: lang_id, key, text.
 

Nelius

кипарис во дворе
Спасибо dark-demon и Alexandre!
Буду пробовать разные подходы, сравнивать под нагрузкой.
А пока наверное остановлюсь на хранении в MySQL так как поиск по этим данным никогда не производился и не будет.
Есть поиск по страницам локализованным, но оно реализованно примерно как у вас Alexandre.
Еще раз всем спасибо!
 

texrdcom

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