Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.134.81.206] |
|
Страницы: (2) 1 [2] все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Zipo, я твоего движка не видел, но мне кажется, что нечто подобное уже существует. Решил я с этой технологией поразбираться и вот, что я узнал(надеюсь кому-ниюудь эта информация будет полезна). Итак, GNU Gettext
Основы Основа библиотеки Gettext состоит в использовании метода gettext(). Идея gettext() заключается в том, что если есть строка, которую нужно перевести, то перевод строки ищется в базе данных(файл .po) Если gettext() находит перевод, то считывает его, иначе берет оригинальную строку. Строку для перевода надо передать методу как аргумент. print(gettext("Phrase for translation")) также можно использовать сокращенный вариант с подчеркиваним print(_("Phrase for translation")) xgettext Когда вы создали программу и пометили в ней строки с помощью функции gettext() или _(), необходимо эти строки извлечь программы для дальнейшего перевода. Делается это следующим образом: xgettext --keyword=_ -o trans_file.po my_script.php Важная особенность! xgettext извлекает только строки, заключенные в двойне кавычки. В итоге получается файл trans_file.po, который является обычным текстовым файлом, но построенным определенным образом. Этот файл отдается переводчикам на обработку(то есть на перевод). Переводчики возвращают готовый вариант и приходит пора msgfmt msgfmt Переведенный файл должен быть конвертирован в двоичный формат. sgfrm trans_file.po -o trans_file.mo Затем необходимо обспечить дерево каталогов для локалей. Надо создать каталог locale, а внутри этого каталога создать каталоги для каждого языка. Внутри каждого каталога создаем еще один каталог LC_MESSAGES, куда и помещаем trans_file.po и trans_file.mo Итого, структура каталогов будет примерно такой: locale/en/LC_MESSAGES/trans_file.po /trans_file.mo /ru/LC_MESSAGES/trans_file.po /trans_file.mo bindtextdomain() Чтобы сценарий мог читать строки из этих каталогов, надо настроить textdomain. bindtextdomain("trans_file","./locale"); Теперь gettext() знает, где, что искать. putenv() дело близится к концу. осталось установить переменную окружения LC_ALL, чтобы указать язык по умолчанию. putenv("LC_ALL=ru") Итого, окончательный вид программы: <?php putenv("LC_ALL=ru"); bindtextdomain("trans_file", "./locale"); print(_("phrase for translation")); ?> Готово! Сложно, но надежно. и удобно, так как переводом занимается переводчик и программист от него никак не зависит. Также предусмотрена функция msgmerge, для обновления перевода, то есть если в код добавлены новые строки. Для полноты изложенного следует отметить некоторые недостатки(они всегда есть). 1. в php нет поддержки Gettext по умолчанию 2. не очень хорошая переносимость с сервера на сервер - не всегда все хорошо вот вроде все для начала... надеюсь кому-нибудь эта технология поможет и облегчит жизнь при написании пользовался материалом книги "Professional PHP 4" издательства Wrox |
Сообщ.
#17
,
|
|
|
Да-м, вот почитал ответы... два файла на php это будет геморойно...
Тут оказалось, что нужен будет еще один язык, итого уже 3. Есть вариант сделать отдельную базу данных для всего этого переведенного и оригинального текста. Судя по ответам все равно нужно будет иметь три файла. Судя по ответу shipbrother, есть библиотека для таких целей. Я так понял это оптимальный вариант?!?! Объясню в общем свою цель. Сайт будет педставлять продукцию двух стран. Вся продукция будет находиться в базе данных.Каждый продукт нужно будет иметь на трех разных языках. Вот тут опять вопрос: делать одну базу, но с полями, например, name_ru, name_en ... для трех языков. Или делать три базы для каждого языка отдельно? Получатся идентичные базы, но с разными названиями баз. Тогда при выборе языка в переменную записал бы имя базы, а потом подставлял бы его в запросе. Это был бы один алгоритм, а если все в одной базе, это нужно будет писать три алгоритма для одного, второго и третьего языка, т.к. имена полей разные. Меня волнует удобство использования и дальнейшей модификации. |
Сообщ.
#18
,
|
|
|
2rebel
Мой совет, используй именно 3 поля. Это гораздо удобнее, ты можешь попутно генерировать строку select'а и просто в зависимостри от языка будешь делать следующее "select name_".$lang.", что на много удобнее. Я работаю в компании, где разрабатываются глобальные решения с многоязыковой поддержкой и используется именно этот метод. |
Сообщ.
#19
,
|
|
|
скачать GNU Gettext можно с - http://www.gnu.org/software/gettext
оригинальный мануал есть там же - http://www.gnu.org/software/gettext/manual/gettext.html The Purpose of GNU gettext - http://www.gnu.org/software/gettext/manual...ext_1.html#SEC2 на сколько я понимаю GNU Gettext больше рассчитан на сообщения, выводимые пользователю посредством php-скрипта(то есть перевод частей html, который php генерит на лету). но возможно, что он может работать и с информациией, хранимой в базах данных продуктов(например) - в подробности я не вдавался. p.s. по-моему с 3 разными базами удобнее. представь, что у тебя одна комбинированная база и надо на сайт добавить еще один язык - это тебе перелопапить всю структуру базы надо. А если у тебя на каждый язык по базе, да еще и с одинаковой структурой - то просто создал еще одну базу и все. единственный минус - не все хостинги дают создавать более одной базы |
Сообщ.
#20
,
|
|
|
А кто тогда мешает сделать так, создаем табличку товар + табличку описания + табличку языков. И все связка many-to-many.
В табличке товар у нас id товара, цена, что угодно. В табличке языков, id языка, назнание если надо, например: 1 Русский 2 English 3 Deutsch В табличке описания id товара, id языка, текст. И в итоге простая связка: SELECT a.id, a.цена, с.текст FROM товар a, язык b, описание с WHERE a.id=с.id_товара AND с.id_языка=b.id AND b.название='Русский' (ну или по ID) А ID определять в зависимости от того, на каком языке пользователь смотрит страничку. |
Сообщ.
#21
,
|
|
|
To SER-Gun
Серж, хватит раскрывать наши корпоративные секреты! А вообще-то я согласен, верно говорит. И уж с чем, а с языками геморроя не возникает! |
Сообщ.
#22
,
|
|
|
rebel,
shipbrother, есть таковая - тока она хороша пашет под Линуксом не под виндой ( вобщем я пока не видел нормально работающюю ) - тут хватает мороки с установкой а потом с настройкой |
Сообщ.
#23
,
|
|
|
Хорошо, делам по три поля для товаров и прочего, определились.
А многоязыность интерфейса сайта, тоже отдельную табличку с тремя полями под языки? |
Сообщ.
#24
,
|
|
|
А чем интерфейс отличается от всего остального? Ничем! Те же яйца, вид сбоку, так что и поступай аналогичным образом.
|
Сообщ.
#25
,
|
|
|
Что ты подразумеваешь под интерфесом? Если ты хочешь менюшки, то тут есть 2 варианта, создаешь либо столько файликов сколько тебе нужно языков, например text_ru, text_en, text_fr и забиваешь в них одни и теже переменные, только на разных языках, например:
text_ru $menu1="Тест1"; $menu2="Тест2"; $menu3="Тест3"; text_en $menu1="Test1"; $menu2="Test2"; $menu3="Test3"; А потом делаешь следующий include("text_".$lang), где $lang равно либо ru, либо en, либо fr в зависимости от того в какой версии сайта находится пользователь. |
Сообщ.
#26
,
|
|
|
Спасибо всем большое! Все понял, буду заниматься.
|
Сообщ.
#27
,
|
|
|
Потом ссылочку хоть кинь на творение
|
Сообщ.
#28
,
|
|
|
Цитата Потом ссылочку хоть кинь на творение Обязательно, но боюсь это будет не скоро , т.к. только начал изучать скрипты, базы и т.п. |
Сообщ.
#29
,
|
|
|
Никто никогда не смторел eGroupWare? Там есть такая фияа, как TranslationTools - Очень интересный подход к переводу. Вообще в eGroupWare есть много интересных вещей.
http://egroupware.org |