Меню
Что нового?

Многоязычность.. Как лучше?

CORSAiR

Новичок
Многоязычность.. Как лучше?

Привет всем..

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

где то в темах сайта создаются скажем два файла: (можно и в базе, но файл легко редактировать откуда угодно плюс его можно отдать на перевод)

text.eng
text.rus

в каждом создаю массив:

файл: text.rus:
PHP: 
$txt[1] = "Меню";
$txt[2] = "Войти";
$txt[3] = "Выйти";

файл: text.eng:
PHP: 
$txt[1] = "Menu";
$txt[2] = "Login";
$txt[3] = "Logout";
ну и вместо текста выводить определенную строчку из массива..

Вопрос: на сколько правильно городить такую схему многоязычности? Есть ли что то более простое и эффективное ?
 

Tor

Новичок
почитай phpInside, там эта тема поднималась

но, в принципе, получится примерно то же самое

только массив сделай ассоциативным, так логичнее и удобнее в конце концов выйдет
 

Гриша К.

Новичок
Я тоже делаю сайт с разными языками.
Я брал за основу phpbb форум.

(1) Делайте к примеру папку /language/
(2) В ней к примеру папку /rus/ - для русского языка
(3) Делайте файл к примеру menu.php
(4) Как вам пояснил Tor, делайте к примеру так (в файле):
$lang['language'] = 'rus';
$lang['title'] = 'Заголовок';
$lang['name'] = 'Имя';
$lang['description'] = 'Описание сайта';
(5) Картинки размещаете к примеру /language/rus/img/

Для английского языка файл будет вглядить так (/language/eng/menu.php):
$lang['language'] = 'eng';
$lang['title'] = 'Title';
$lang['name'] = 'Name';
$lang['description'] = 'Site\'s description';
 
kvf77

kvf77

Red Devil
CORSAiR

в FAQ я создал спецуиально БОЛЬШОЙ раздел для таких как ты - зайди и почитай - там много способов с примерами. хотя FAQ помоему щас упало - ну погодь - попозжее сходи
 

CORSAiR

Новичок
Для таких как я? М-да.... но так как у супер гуру прекратил работать FAQ, я все таки решил задать вопрос в конференции. А для таких как ты есть раздел в правилах форума: "Как общаться в форуме" . Пункт первый.

P.S. как только фак заработает схожу обязательно
 

vadim

Guest
Мне нравится gettext
А для значений из базы просто рядом с полем NAME поля типа russian_NAME, german_NAME и тд. очень легко в зависимости от выбранного языка нужный столбец из базы выбирать
 

alexhemp

Новичок
vadim

Ужас какой. Т.е. для добавления нового языка нужно во все таблицы добавлять столбец?

Теорию построения БД не пробовали изучать?
 

texrdcom

Новичок
gettext - это единое и правильное решения нас не волнует сколько языков будет в приложении нам не надо создавать 152 языковых файлов - подумайте если вы пишите приложение модульное - сколько вам прийдеться создать языковых файлов - с gettext - создаеться один файл с языком по умолчанию и все!!!
gettext - применяеться не только в php приложениях...
Да есть маленькое замечания чтобы работали все языки надо проверить установлен ли модуль gettext - вот и все издержки ::)
 

Денч

Новичок
texrdcom
[offtop]
Прям рекламный буклет:)
[/offtop]
Ничего личного, я тоже дружу с gettext
 
Andreika

Andreika

"PHP for nubies" reader
нам не надо создавать 152 языковых файлов
а кто их за вас создавать будет то?

создаеться один файл с языком по умолчанию и все!!!
неужели там встроенный переводчик завелся, который по "языку по умолчанию" создает остальные 151 переводов

gettext - применяеться не только в php приложениях...
сильнейший аргумент

а если модульне установлен, то что тогда?
 

vadim

Guest
alexhemp
Да, это делается автоматом. В модуле администрирования есть скрипт, который всё это проделывается, потом щёлкаем по элементу, требующему перевод и появляются поля для заполнения на всех языках.
Если учесть, что переводить в базе данных очень мало чего нужно, то для вполне нормальное решение.
Конечно, правильней сделать отельную таблицу, где будут сопоставляться ID эелемента, язык и соответствующий языку перевод, но ради того, чтобы не переделывать все запросы, если мы откажемся от этой схемы, мы рещили сделать так.
В зависимости от выбраннаого языка константа DB_NAME_FIELD принимает вид язык_NAME, либо просто NAME, если язык стандартный.

И тем более все языки добавляются на стадии планирования и пробной разработки, так что потом проблем не будет, если мы даже сменим систему перевода
 

TheBattle

Новичок
Кстати, а ради примера, можно было посмотреть как мультиязычная поддержка делается в обычных программах. Так, например, я видел следующую организацию: есть ini-файл, где секции есть названия языков, а переменные в них - содержат перевод.
[english]
name=name
...
[russian]
name=имя
etc.
 

vadim

Guest
TheBattle
тоже интересно, тем более в ПХП есть удобная функция parse_ini_file
 

alexhemp

Новичок
vadim

Не надо называть костыли которые вы сделали

чтобы не переделывать все запросы
Нажмите для раскрытия...
нормальным решением.

Применение таких костылей показывает что система была спроектирована неверно.
Если сначала проектировать, а потом писать - то ты сам указал правильное решение.

И весьма странно что в базе "мало что переводить", а где же тогда храниться контент сайта? В файлах что-ли?
 

vadim

Guest
alexhemp
Я согласен с вами в том вопросе, что моё решение в теории неправильно, но теория на то и теория, чтобы давать обобщенные ответы, и в некоторых случаях приходится принимать решение, не соответствующее теории. Причин для этого может быть много (от вопросов производительности до желаний заказчика).

В данный момент занимаюсь проектом для продажи логотипов, музыки и тд для мобильников, поэтому всё, что переводить надо, так это названия категорий и групп, типа "Логотипы->Спорт" и тд. То есть основной контент это графика и музыка.
А текст внутри скриптов обрабатывает gettext
 
tf

tf

крылья рулят
gettext это хорошо. а с картинками которые могут быть на сайте как поступаете?
 

alexhemp

Новичок
vadim

Вопрос топика "Как лучше?". Ваш ответ к этой категории не относиться. Он относиться к категории - "как вставить костыль".

Я вот на своем опыте убедился - добавлять многоязычность лучше по науке, исправить запросы - дело нескольких минут, вместо вашего кривого Define добавляется поле, скажем LANG_ID и соотв. в запросы добавляется условие вида "AND LANG_ID=$lang_id".

Еще раз и медленно - вы использовали в своей программе "костыль" для сиюминутного решения неожиданно возникшей проблемы. Это не пример того - "как надо" делать с самого начала, о чем я и написал.
 

vadim

Guest
alexhemp
Ещё раз и медленно - прочитайте мой предыдущий пост и вы поймёте, что я с вами полностью согласен.
Проблема в том, что я работаю не в софтверной компании, и здесь софт создаётся по принципу "сегодня шефу пришла мысль в голову". Причём принцип "эта мысль может завтра у шефа испарится" тоже действует. Поэтому приходится вставлять костыли, так как они часто несут в себе меньшие издержки, чем рефакторинг половины всего кода. Причём, если костыль позволяет также вернутся к старому вариантов совершенно без потерь, то я только ЗА.

Пусть автор сам решает. что ему использовать
 
Войдите или зарегистрируйтесь для ответа.
Сверху