множественные варианты переводов

че то так в голову пришло, не то чтобы надо прям рещить, но все таки интересно кто что думает

может у кого какие наработки были

[b]

поставновка задачи[/b]

есть множечтвенные "переводы" одного и тогоже текста

переводы хранаться в БД по какому-то ключу, к примеру SITE_DESCRIPTION или GO_BUTTON…

ну и чем то между собой различаютсья, к примеру SITE_DESCRIPTION для главного домена - один, для поддомена или партнерского сайта другой.

Кнопочка так же отличаться может - для нормального языка, для сленга (что б по прикольней) ну и т.д. и т.п.

порядок поиска "перевода" скажем такой

  • поиск текста в "переводах" принадлежащих отдельному пользователю (предполагаем что пользователь может сам себе все напереводить)

  • поиск текста в данных поддомена/партнерского сайта

  • поиск текста в освной базе

  • если нигде нет вывести ключ

Как желательно реализовать?

вообще вся эта тема поднялась только из-за того что я увидел onMissingTranslation

в идеале было бы классно если бы первая поисковая функция/класс пытаясь найти текст, генерировала событие onMissingTranslation если он не был найден, вторая соотвественно подхватывала и тоже пыталась провести поиск так же, только в своем источнике ну и т.д

последняя событие не генерирует, а выводит ключ.

вообщем плохо получаеться

реализовал четыре стадии переводов

первая стадия вызываеться как положено, остальные рекурсивно в onMissingTranslation




public static function handleEvent(Event){

  ....

  $event->mesage = $this->translateMessage(...);

}



во-первых не понятно почему я получаю странную ошибку превышения количесва рекурентных вызовов, хотя код не отрабытывает дальше второго уровня (может еще проверить нужно)

во-вторых и это куда более важно чем все остальное при таком раскладе

  • реальные полученные данный скажем после последней стадии перевода (когда должен вернуться ключ) нигде не сохраняються, тоесть скажем попытка получиться перевод для языка ‘qq’ будет всегда! дергать источник (в случае с БД) это плохо

  • и (хотя это уже относиться к реализации, а не к событиям,) внутренний ключ при котором сохраняються данные см CMessageSource::translateMessage учитывает только язык и категорию, и не учитывает дополнительных параметров к примеру пользователя или партнера.

вообщем рекурсивный перевод по событиям фтопку

придеться переопределять loadMessages и translateMessage