Языки для портала

Статус
В этой теме нельзя размещать новые ответы.

solarb

Постоялец
Регистрация
11 Июл 2009
Сообщения
64
Реакции
15
Здраствуйте!
Я хотел спросить как самое оптимальное решение перевести сайта. Мне нравится метод с array-ом в езиковом файле. Но в моем портале есть формы с селектом которые тоже надо перевести.

Примеры: Страны, Титла(mr,mrs,doctor) и далее.

Я думал над mysql решением но языки тоже будут добавляться и добавление column языка во все таблицы звучит неоптимизировано.

Помогите пожалуйста форумчане :)
 
Я думал над mysql решением но языки тоже будут добавляться и добавление column языка во все таблицы звучит неоптимизировано.
Это не то, что не оптимизировано. Это вообще тихий ужас. В большинстве движков сайтов для хранения фраз разных языков обычно используются таблици следующей структуры:
phrase_id (varchar) - идентификатор фразы;
language_id (unsigned integer) - идентификатор языка;
phrase (varchar/mediumtext/etc) - текст фразы.

Теперь, по принципу работы.
Допустим, у Вас есть некая фраза "Hello, World!". Соответственно, первая запись для этой фразы в БД будет иметь вид, например:
phrase_id: hello_world - (идентификатор фразы);
language_id: 0 - (ноль - обычно номер дефолтного языка, например английского);
phrase: Hello, World! (собственно, текст фразы).

И вот, Вы созрели наконец добавить в свой сайт русский язык. Для этого необходимо в туже самую таблицу добавить еще одну запись для всех фраз аналогично этой:
phrase_id: hello_world - (идентификатор фразы не меняется);
language_id: 1 - (в нашем примере 1 соответствует русской языковой локализации);
phrase: Привет, мир! (текст фразы уже на русском языке).

Большинство CMS работают так, что если они не находят, например, фразу в русском варианте, то в таком случае будет применена из этой же таблицы фраза, которой соответствует номер языка "0"(ноль, дефолт). Это удобно, когда количество фраз переваливает за 3-4 тысячи и становится трудно все контролировать.

Еще есть один способ, который использовался в вордспрессе. А именно, замена фраз специальной функцией PHP:
PHP:
string function _(string $phrase) {}
Этот способ хранит все фразы в специальных файлах с расширением *.mo или *.po. Он дает довольно высокую производительность, но крайне неудобен для редактирования и сохранения фраз.
 
Спасибо за быстрый ответ!
Етот метод вправде хорош. А есть ли метод похожий на етого , но менее зависимый mysql?(мой mysql постоянно зависает)
Чтобы бы я мог редактировать этот language файл (array-ский) из админки(который я сам пишу но нет идеи как сделать ето)?

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

Извините за плохой руский.
 
Как вариант - использовать опять же таки хранение фраз в файле, в виде сериализированных массивов. Для сериализации массивов(представления массива в виде текстовой строки) можно использовать функции PHP serialize/unserialize или кодировать их в json формате функциями json_encode/json_decode. Написать класс, который бы подгружал фразы из файла и выдавал, по указанным идентификатору фразы и языка нужный текст - не составляет проблемы. Но, должен заметить, что такой способ не является самым оптимальным в плане производительности. Особенно, когда фраз много(больше тысячи). Каждый раз компилятор PHP будет выгружать эти фразы в память(а она не резиновая), что создает дополнительные нагрузки. С другой стороны, этот вопрос можно легко решить, если есть возможность выделить под процессы PHP больше оперативной памяти. Скажем, 2-4Мб только под работу с фразами - хватит с головой. В любом случае, как не крути, лучше использовать MySQL. Все таки, работа с БД дает более широкие возможности в плане сортировки и обработки данных.
 
Никаких сериализаций что бы дополнительно не тратить время.
Все бы хорошо, но Вы упускаете из вида один существенный момент. Автор ведет речь не только о чтении фраз из файлов, но и о возможности править эти файлы из админки. Соответственно, сохранять фразы в структурированных классах - возможности нет(в принципе, есть, но это сложно и не уместно).


И файлы как всегда работают быстрее чем БД.
Начиная с 4-ой версии MySQL, в большинстве случаев, работа с БД дает большую производительность, чем работа с файлами. Проверено самолично.
 
Скорость спорный момент, но скорее всего за файлами. Тем более в сравнении, идет выборка 20 строк (а не всех, которые допустим, нужны для данной локализации) из БД поэтому файл получается медленнее.
Нет, и тут преимущество за БД. Особенно, при больших объемах информации. Все дело в том, что MySQL не нуждается в компилировании большинства запросов. А данные читаются напрямую из файлов. В то время, как PHP сначала компилирует текст кода, включая вышеупомянутые фразы из файлов, и только после этого приступает к обработке. Кроме того, стоит учесть и тот факт, что в PHP нет жесткой привязки к типам данных. Очень много(относительно) времени теряется при переносе текстовых данных, формировании текстовых буферов и т.д..
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху