Добрый день. Есть движок на котором весит около 10 сайтов. Т.е. на одних и тех же скриптах все держится. Когда пользователь заходит на сайт, то по урлу определяется какую базу использовать и какие шаблоны. Написано все это дело под Zend Framework. Надо все сайты сделать мультиязычными. Все бы ничего, можно было бы юзать тот же самый Zend Translate из фраемворка, но хочется сделать так: чтобы был один класс который отвечал бы за переводы не только фраз используемых в дизайне, но и всего контента сайта (менюшки, статьи). Плюс желательно, чтобы все переводы делились по мелким файлам в JSON виде. Так будет удобнее вытягивать перевод для ява скрипта (там просто много всяких выскакивающий менюшек яваскриптовых). Была у меня такая идея: все переводы разбить по следующей иерархии: МОДУЛЬ -> КОНТРОЛЛЕР -> ДЕЙСТВИЕ-> ОБЪЕКТ(прим: контент-менеджер)->АЛИАС_КОНТЕНТА->ID_ЯЗЫКА = ПЕРВОД ТЕКСТА. Разбивать по иерархии я думаю необходимо, чтобы файлики JSON в конечном итоге весили как можно меньше (дабы не грузить много трафика пользователю). НО, в такой иерархии есть минус........ некоторые фразы/переводы могут относится к разным модулям одновременно - т.е. являться общими (пример: надпись WELCOME присутствует во всех модулях и контроллерах, а вот в модуле заказа продукции не присутствует). Вот немогу сообразить как сделать правильнее в этом случае? И вообще в чем изначально лучше хранить все эти переводы (до экспорта в JSON)? Можно сделать формочку куда переводчик будет записывать все данные переводов, а эта формочка будет писаться в БД, а после как перевод будет закончен сделать экспорт по файлам JSON? Вообщем подскажите верный путь ........... может кто сталкивался уже с такой проблемой?
Люди бились над данной проблемой примерно 40 лет. В итоге пришли к тому, что на свет появился gettext: не идеальный, но, имхо, лучший из существующих. У меня лично к нему только одна претензия: он не поддерживает формы окончаний в зависимости от числа.
с базой в вашем случае думаю будет правильный ход по поводу иериархии думаю не стоит разбивать по модулям, контоллером, etc, а разбить именно по логике текста давненько ваял "мультиязычный" сайт, делал грубо: 1. список фраз c ключами на английском (если фраза большая - сокращал) 2. функция l($key) которая если ключ в списке перевода не существует возращала ключ было удобно, особых проблем не выявлено. функция примерна такая: PHP: <? function l($key) { return Text::GetInstance()->get($key); } думаю, если Вам нужны будут все фразы для модуля можно нарисовать что то вроде Text::GetInstance()->getListForModule($moduleName);
Ti, вообщем то понятно. Так наверное и сделаю, не буду заморачиваться. Только помимо фраз класс должен еще и переводить все полностью, что только можно переводить (статьи, меню, т.д.). А чтобы в ява скрипт не грузить много инфы, то просто разделю используемые переводы на три типа Smarty (перевод для фраз на шаблоне), JS (для яваскрипта), Translate (весь остальной контент). AlexGousev, по поводу gettext сказать честно, не особо с ним знаком. Ознакомлюсь... может что и выйдет толкового. Еще подумал, что если тупо для яваскрипта готовить JSON файлы....... то не прокатит. Выбирая из базы можно сделать так, что если нет перевода на текущем языке, выбрать его на любом другом (чтобы не выдавалось пустое окно). А в случае если загнать все в JSON то потом надо уже с файлами париться - сравнивать английские русские и другие переводы. А что вообще думаете по поводу идеи, что 10 ресурсов лежат на одних и тех же файлах? Лично для меня минус только в том, что все ресурсы используют одни и те же модели, а их со временем приходится переписывать (в соответствии с новыми требованиями), и потом начинается геморой несовместимости.