Реализация системы настроек для многоязычного сайта?

Question

[excalibur]

Названия опций лежат в xml-файлах, но значения этих опций должны лежать в БД. Сейчас система настроект прекрасно работает на сайте, но для него введена многоязычность, соответственно нужно учитывать многоязычность и для системы настроет. Есть много ньюансов. Например, есть опция «option_api», которая хранит ключ к api внешнего сервиса, т.е. этот ключ будет один т тот же для каждого языка сайта. Есть опции, которые можно выставлять в «да», «нет», «не указано», т.е. это либо радио-баттон или селект — т.е. значение могу использовать для всех языков сайта. Но есть опции, которые хранят в себе название, например, названия раздела сайта, т.е. они являются текстовым полем, и для каждого языка будут иметь свои значения.


Сейчас опции и их значения я храню в 2-х таблицах: в первой опции, во второй все варианты значений к этим опциям. Т.е. сейчас можно вернуть старое значение опции, а можно добавить новое и т.д. например опция может быть изображением, например, логотип — зимний вариант лого, летний, чтобы можно было переключаться в зависимости от времени года.


Структуру таблиц не привожу, чтобы не навязывать свое мнение. Использую Zend Framework, если это чем-то поможет.

В общем, поделитесь, пожалуйста, своим опытом реализации подобного на сайте.

Answer 1

[doranych]

Названия опций лежат в xml-файлах, но значения этих опций должны лежать в БД.

Само по себе это уже не очень понятно. Зачем хранить их так хранить, хотя дело ваше.
Итак.
Теперь на тему вопроса.
Можно добавить к свойствам в названии язык. Например так, ru_confname, en_confname, jp_confname и так далее.
Ну и в процессе запроса нужного параметра добавлять сокращение языка.
Есть другой вариант, можно во второй таблице добавить код языка и запрашивать с его учетом. Но это вариация первого варианта.

Comments

[excalibur]

Пока я смотрю в сторону второго варианта, но в этом случае не знаю как быть с теми опциями, которые будут одинаковыми для всех языков, поскольку дублировать их для каждого языка не очень хочется. И если так, то что делать со значениями опций, их «переводить» или для каждого языка будет свой набор значений опций?
В xml-файлах удобно хранить, так как легко добавляется новая опция и легко настраивается. Мне как-то проще создавать опции и их свойства в файлах, чем в базе данных.

[doranych]

Ну дело ваше, как хранить, мне просто странным показалось.
По поводу одинаковых свойств.
Можно либо дублировать свойства, либо оставлять язык пустым и тогда подгружать значение, т.е. запрашивать значения с языком и пустым языковым кодом, на тот случай если в конкретный момент не известно переводится ли это свойство.
Пока писал возникла еще одна идея.
Перестроить вторую таблицу сделав ее матрицей языков, т.е. примерно так

option_id| ru 	| en 	| ge | uni
1 	 | знач | val 	|    |   
2	 | имя	| name 	|    |   
3	 |    	|     	|    |значение для всех языков

ну и так далее, суть, надеюсь, понятна.
И указывать

[doranych]

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

SELECT * FROM `opt_table` WHERE option_id = 1

затем просто нужный язык выдергивать из ассоциативного массива.

//узнаем язык
$lang = $_REQUEST['lang'];
...
$opt_value = (isset($res_arr[$lang])) ?  $res_arr[$lang] :  $res_arr["uni"];

[excalibur]

На счет матрицы — да, понятно. Только этот вариант не подойдет по той причине, что придется менять структуру таблицы при добавлении нового языка. Перевод сайта можно расширить к более 60-ти языков, на которые гугл предлагает перевод. Для первода контента сайта я использую 2 таблицы: в одной храню информацию которую не перевожу, а во второй перевод, где есть уникальный ключ по двум полям: «id_origin» и «lang», например, значения полей будет таким: id_origin = 100, lang = «en». Таким способом можно добавлять сколько угодно новых языков. А в случае с опциями по настройке есть много ньюансов, о которых я уже писал…

[excalibur]

И к стати, Вам мысленно плюс в карму и за ответ. Спасибо за помощь! А что Вы думаете на счет использования поля «lang» и чтобы в нем хранить язык значения опции? Но тогда пока не понятно как хранить значения, которые не требуют перевода.

[doranych]

Не за что.
Ну, с плюсом потом как-нибудь разберемся)
Lang использовать в вашем случае, пожалуй актуально.
Не переводимые опции можно задавать с языком NULL и соответственно выбирать примерно так

SELECT * FROM `opt_table` WHERE `option_id` = 100 and (`lang` = "ru" or `lang`= NULL)

Соответственно выбираем руками язык, либо null. Это на тот случай, если все-таки не понятно, что там у вас с переводимостью опции.

[excalibur]

Пока мне кажется, что это

or `lang`= NULL

отличная идея для значений опций, которые не зависят от языка!

[doranych]

Удачи в дальнейшей разработке)

[excalibur]

Спасибо! Ваш ответ отмечу как лучший.