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

"код языка" | "лексема" | "локализованная строка"

Таблица в данный момент имеет размер около 30Мб и продолжает расти, т.к. приложение в процессе создания.

Стоит задача - обеспечить поддержку разных языков.

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

Кто знает, как грамотно организовать такую подсистему в приложении?

_____________
Сложное - просто. Простое сложно.

moskitos80
Для статических данных самым быстрым в плане ненерации страницы будет такой подход:
1. Сделать отдельный каталог с исходниками шаблонов, например source_templates;
2. Сделать отдельный каталог, где будем хранить шаблоны для каждого поддерживаемого языка, например: lng_templates;
3. В шаблонах вставлять вместо статического текста какой-то код, ну например: <!--{#код_статического_блока#}--!>;
4. В базе для каждого теста хранить: привязку к языку, код статического блока, сам текс;
5. Написать скрипт, который будет брать шаблоны из каталога source_templates заменять в них коды статических блоков на соответствующий текс из базы и складывать в каталог lng_templates/<код_языка>;
6. В движке подпилить что бы брались шаблоны из нужного языкозависимого каталога.

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

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

vagrand Спасибо за идеи - в копилку как варианты Вот только в данном случае, вся фигня в том, что разрабатываемая система - это web API. Оно не имеет видов, шаблонов и прочих прелестей. Ему заразе надо сказать дай то и то и желательно на "том" зыке - оно и должно дать на "том" языке или матюкнуться и послать... тоже на "том" языке.

_____________
Сложное - просто. Простое сложно.

moskitos80
А чем API отличается от обычного сайта и почему там не могут использоваться шаблоны?

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

Я из API клиенту передаю только данные, а клиент у себя уже строит страницы и презентует их юзеру.

_____________
Сложное - просто. Простое сложно.

moskitos80
Что значит только данные? HTML страницы, изображения, медиа контет, да все что возвращает сервер это данные, просто в разных форматах. Так вот вопрос - в каком формате ваш сервер возвращает данные вашему клиенту? Ну например XML или JSON?

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.

JSON

_____________
Сложное - просто. Простое сложно.

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

как я понял у тебя таблица, которую приложение "копирует к себе по ближе". и тебе нужно постоянно эту копию обновлять чтоб не отстать от таблицы так? . так вот эта таблица она как заполняется? постепенно добавляются новые ряды итд или же полностью обновляется

moskitos80
И все-таки не совсем понятно тут значение выражения "статические данные", но если вам не подходит первый метод, то советую тогда закешировать данные через Redis. Для тех данных которые редко изменяются это очень хороший способ, т.к. Redis (если сбоев не было) хранит данные постоянно, только вытесняет те что редко запрашиваются на диск, в отличие от например memcached, который невлезающие данные просто удаляет.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.