В документе рассказано о создании многоязычных PHP приложений, используя пакет GetText (http://www.gnu.org/software/gettext/).URL: http://php.russofile.ru/ru/authors/multilangual/php_gettext_.../
Новость: http://www.opennet.me/opennews/art.shtml?num=5794
На мой взгляд GetText - архаизм полнейший, особенно для постоянно развивающихся веб-проектов.У меня есть оригинальная разработка - многоязычная CMS, возникшая полтора года назад в очень плотном контакте с переводчиками, и успешно зарекомендовавшая себя на многих проектах. Основной know-how - организация интерфейса редактора/переводчика, структура базы и простой эффективный api. Но есть и другие вкусности - макросы, "виртуальные хосты", WYSIWYG итд.. Пытался даже ведение версий по типу wiki сделать, но пока не закончил.
Хотелось бы сделать эту систему полезной сообществу, но совершенно нет опыта ведения opensource проекта, да и времени не особо много. Всегда работал один, даже CVS пока ни разу не пользовался. Кроме того, недостаточно владею английским (есть хороший немецкий :). Если интересно - может, кто-нибудь поможет?
>У меня есть оригинальная разработка - многоязычная CMS, возникшая полтора года назад
>в очень плотном контакте с переводчиками, и успешно зарекомендовавшая себя на
>многих проектах.Где ее можно посмотреть или прочитать документацию по-русски ?
Может и анорхизм, зато он используется в сотнях проектах...а вашу методику судя по всему кроме как в PHP нигде не применить...
Зато работает быстро. Все CMS, которые я щупал, абсолютно не выдерживают более-менее нормальной посещаемости(50.000-100.000 хитов в сутки)
>Зато работает быстро. Все CMS, которые я щупал, абсолютно не выдерживают более-менее
>нормальной посещаемости(50.000-100.000 хитов в сутки)Кстати, ни у кого нет желания поэксперементировать или просто изложить свой опыт, сравнив популярные открытые CMS (можно также форумы, wiki и т.д.) с точки зрения производительности и ресурсоемкости. В каких из них есть грамотное кеширование, а какие генерируют по сотне SQL запросов на кажлое обращение.
Меня часто спрашивают какую CMS/форум/wiki выбрать, приходится разводить руками.
Я в своё время искал базу для dating-портала, помимо прочих познакомился с Drupal. Очень хорошо оптимирован для большой нагрузки, да и вообще хорошо сработан, если применять по назначению - более-менее закрытые community информативного характера. Кроме того, авторы дают суппорт и оптимируют кэширование под условия заказчика. Но нам он не подошел, поэтому серьёзно погонять не довелось.
Кстати, gettext к Drupal прикручивается при необходимости. Хотя эта CMS использует собственную схему локализации, с хранением переводов в БД, но методы похожи на применяемые в gettext - каждое сообщение подлежащее переводу вызывается как аргумент специальной функции t(). Подменив эту функцию на вызовы gettext можно увеличить скорость работы для некоторых конфигураций.Оценка CMS по производительности на мой взгляд весьма не простая задача, нужно смоделировать условия, чтобы было одинаковое оформление страниц с одинаковой по весу графикой, учтя при этом разные возможности для дизайна в разных системах, и тестировать на похожих функциях - т.е. скажем сравнивать отдельно модули форумов, модули блогов и т.д. Я пока таких сравнений не встречал, ведь сложность тут в том, что каждую CMS для сравнения должны подготовить люди которые в ней хорошо разбираются и могут оптимально настроить.
Ещё возвращаясь к Drupal, забыл отметить, что для экспорта/импорта переводов там используется формат po-файлов gettext, это собственно и позволяет легко перейти к оригинальному gettext для поддержки локализации. А po-формат для хранения и обмена удобен тем, что получаем весь широкий набор инструментария для работы с переводами - от po-mode в emacs до специализированных утилит с глоссариями и проверкой синтаксиса. При этом после импорта po-файла в базу CMS предлагает в дополнение вебинтерфейс для правки переводов непосредственно на сайте.
>Ещё возвращаясь к Drupal, забыл отметить, что для экспорта/импорта переводов там используется
>формат po-файлов gettext, это собственно и позволяет легко перейти к оригинальному
>gettext для поддержки локализации. А po-формат для хранения и обмена удобен
>тем, что получаем весь широкий набор инструментария для работы с переводами
>- от po-mode в emacs до специализированных утилит с глоссариями и
>проверкой синтаксиса. При этом после импорта po-файла в базу CMS предлагает
>в дополнение вебинтерфейс для правки переводов непосредственно на сайте.Я этого там не помню, но тем кто к этому привык должно быть действительно удобно. Хотя, не необходимо, потому что на базе того-же самого .tsv можно было бы иметь весь инструментарий в виде банального офиса, что удобнее для преоблядающей группы тех редакторов, которые и про html не слышали.
А потом, необходимость экспорта/импорта обычно возникает, когда нет возможности эффективно работать в онлайне. А поскольку сама эта операция требует определённых манипуляций и в оффлайне невозможно отслеживать версии коллег, общая производительность чувствительно ниже. Сам одно время так работал, когда дома dsl небыло.
>самого .tsv можно было бы иметь весь инструментарий в виде банального
>офиса, что удобнее для преоблядающей группы тех редакторов, которые и про
>html не слышали.Удобство - дело привычки. Пока мне не встречалось клинических случаев, когда переводчик не признавал бы ничего кроме ворда, обычно достаточно указать, что есть два способа: перевод через вебинтерфейс (не особо удобно, зато сразу на сайте) и перевод текста в офлайне, причём в последнем случаем можно задействовать специальные программы либо обычный текстовый редактор. Обеспечить вебинтерфейсом удобства хотя бы равные интерфейсу обычных приложений - это понадобятся тонны JS (или подобных не особо стандартных методов) при сомнительной производительности. Поэтому, полагаю такую схему разумной - вебинтерфейс для мелких правок и специализированные приложения для массовых переводов в офлайне.
>А потом, необходимость экспорта/импорта обычно возникает, когда нет возможности эффективно работать в
>онлайне. А поскольку сама эта операция требует определённых манипуляций и
>оффлайне невозможно отслеживать версии коллег, общая производительность чувствительно ниже. Сам одноДа какие там манипуляции? Если человек вообще работает с вебинтерфейсом, то ткнуть кнопку экспорт и скачать к себе предлагаемый файл с переводом (друпал выдаёт всё в одном общем po-файле) - не сложная уж задача. Для ведения офлайновых переводов группой людей удобно задействовать системы контроля версий - как раз для них задача. Собственно в друпале именно такова официальная схема поддержки переводов - po-файлы разбитые по модулям движка лежат в cvs, скриптами они регулярно объединяются в общие файлы для каждого языка (просто для удобства импорта пользователем), можно скачать, импортировать и если что-то в официальном переводе не устраивает - поправить прямо у себя на сайте через вебинтерфейс.
PS. Разумеется всё вышесказанное имеет отношение только к переводам _интерфейса_, для переводов _контента_ Друпал не предлагает решений из коробки - есть доп. модуль поддержки многоязычности, работающий исключительно через вебинтерфейс.
Точное сравнение невозможно хотя бы по пой простой причине, что каждая cms разрабатывается под конкретное применение, где другая система становится практически малоэффективной. Даже "универсальнейший" typo3 имеет ограниченную целевую группу - шаг в сторону, и можно забыть про преимущества. Особенно, если наравне с остальными показателями учитывать трудозатраты на установку, обучение персонала и поддержку контента, поскольку от этого очень сильно зависит производительность системы в целом. А скорость отдачи контента - это только один фактор из многих.Будет проще, если сформулировать основные области применения, и попытаться оценить пригодность каждой системы. Например, "портал новостей", "корпоративный сайт", "развлекательный портал" итд.. Получится субъективная, но всётаки более полная картинка. А потом уже можно углубляться в детали.
> Может и анорхизм, зато он используется в сотнях
> проектах...а вашу методику судя по всему кроме
> как в PHP нигде не применить...Я бы не заикался о недостатках GetText , если бы речь шла об использовании в программах на C или подобном. Да и производительность при небольших объёмах контента наверняка отменная. Но это абсолютно статическая система, что для веба просто неприемлемо, а там где это бы и подошло, производительность обычно и близко не нужна. И переубедит меня только пример CMS с его использованием, которая была бы ещё и удобно или как минимум рационально организованна для переводчика, и при этом была достаточно гибкой для программиста.
> Где ее можно посмотреть или прочитать документацию по-русски ?
Не хотелось бы публиковать на форуме доступ к администрационной части, опасаюсь за безопасность. Пишите на мыло - пришлю.
С русской документацией очень плохо - всё что есть пока только на немецком:( Это ещё предстоит сделать, в первую очередь.
Конечно это тоже вариант решения проблемы мультиязычного программирования, но мы создаваля интернациональный сайт знакомств и использовали методику шаблонов. Написали либу которая берет из базы данных хтмл-код в котором места вставки пхп кода отмечены определенными маркерами и с помощью этой либы подставляли пхп. Это нам дало 1-е разделение пхп от хтмл, 2-е отделение текста (изначально русского) от "математики" и 3-е возможность вызова любого шаблона в зависимости от конкретной нужды, те понадобился русский запросил шаблон из 1-го сета, понадобился английский-из 2-го сета...кому будет интересно выкину либу...
Видимо, вам переводчики толковые попались :)Я о подобной системе тоже думал. Это кстати наиболее простое решение интернационализации для уже готовых одноязычных проектов, если там вообще темтлейты используются - создать для каждого языка свою директорию темплейтов, и выбирать нужную на этапе инициализации скрипта согласно куку или параметру.
Для меня вобщем-то стояла задача отделения контета от шаблонов, потому что переводчикам нужен чистый текст. Нас иногда до 6 человек (включая меня) из разных стран одновременно над текстом роботало, попробуй поставь в одной из версий какой-нибудь <div style=... - полчаса бесполезной дискуссии обеспеченно.
Есть более сложный вариант CMS на принципе темплейтов - contenido ( http://www.contenido.org ). Там одни и те же шаблоны ипользуются как для посетителя, так и для редактора. Строки текста заменяются полями ввода, редактор сразу как-бы живой сайт правит.
Кстати, локализация самой CMS сделана через gettext , но контент лежит в базе, а для каждого языка нужно вести отдельный проект, без возможности синхронизации. Вобщем, система внешне очень вылизанная, но достаточная разве что для ведения среднего корпоративного сайта силами малообразованной секретарши. Производительностью не отличается. Документации - "продажный" минимум; ровно столько, чтобы раскрутить покупателя на платные курсы.
Попытаюсь выразиться поточнее чем в первый раз, а то изза недопонимания один флейм пойдёт:1) Интернационализация обычно требуется как для интерфейса самой програмы, так и для контента, с которым эта программа работает.
2) В "настольных" программах в основном требуется именно интернационализация интерфейса, для доступности программы большему кругу пользователей. Сами пользователи обычно работают с более-менее одноязычным контентом, или во всяком случае ведут несколько языков не синхронно.
Тексты интерфейсов обычно транслируются на этапе разработки, программа попадает к пользователю в готовом виде и в процессе использования уже не дорабатывается.
Для такого применения gettext подходит прекрасно, и по праву популярен, хотя и не необходим. Видимо, большенству разработчиков хватает ума не изобретать заново такой простенький велосипедик...3) Веб-приложения динамичны по своей природе, и интернационализировать приходится именно динамический контент, объём которого значительно преобладает над объёмом текстов интерфейса. Особенно для cms систем, где сами пользовательские интерфейсы - чистейшая динамика, а "статична" только администрация. А работать с динамикой gettext не умеет, поэтому всегда приходится создавать отдельную систему интернационализации и интерфейсы к ней. И задействовать к ней параллельно ещё и gettext - исключительно дань привычке, других причин я не вижу. Это моё мнение; будут аргументы против - пожалуйста, пойдёт всем на пользу. Но производительность - не аргумент, поскольку на фоне нагрузки на отдачу динамики этот выигрыш никакой погоды не делает.
CobolХватит чушь нести уже. Ты видать совсем не понимаешь для чего есть GetText и для чего он нужен и применяется. Читаю твои сообщения и сразу вижу, что человек явно не о том говорит. GetText - это только одна из частей интернационализации конента, а именно, он нужен ДЛЯ СТАТИЧЕСКОЙ информации, коей в проектах дофига, например сообщения об ошибках скриптов и так далее. Не надо пусть! У тебя явная каша в голове - потомучто ты не разделяешь динамический контент и статический.
Настольная программа ничем от сайта не отличается - она действует точно также - в ней есть и динамические данные и статически, ты очень наверное удивишься, узнав, что на упонимаемом тобою, С++ GetText вовсе не занимается локализацией динамического контента.
В общем - учи мат часть, а то пудришь людям голову.
>Настольная программа ничем от сайта не отличается - она действует точно такжеА вот и нет. Отличается и сильно. Переводчик получает доступ к отдельной редакторской части сайта, которая от самого сайта отличается лишь тем, что можно кликнуть на любой блок текста и тут же перевести его не отрываясь от общего контекста страницы. При этом переводчик видит страницу в целом, на переводимом языке, где не переведенные блоки выделены, предположим, цветом.
Угу :-) Переводчики часто пожилые тетечки (бывшие учителя) или студенты. Очень у многих инета просто нет, ровно как инавыков общения с ними - как правило они дома на компе набивают текст в Worde :-) Для GetText есть очень удобный редактор под винду, который решает множество проблемсов.
Добавление для CoboltВидимо вы не работали с понастоящему большими проектами. Отсюда ваша нелюбовь к GetText'у. Когда у вас большой проект с 5 языками, включая китайский, и японский, китайских, кстати, два, то вы начинаете понимать что почем и в какое место.
GetText предоставляет реальные возможности по организации работы переводчиков хотябы для статического контента, потомучто освобождает программиста от головной боли менеджера контента. Мы пердаем переводчику удобный редактор PO файлов и спим спокойно. Передать ему PO файл или непонтяный текстовый файл ВАШЕГО формата - ну я посмотрю что вам скажет какой-нить Хон Гиль Дон на это - пошлет куда подальше, испаганит вам формат файла и приведет ваше приложение к неработоспособности.
Вы сильно ошибаетесь, думая, что все переводчики продвинутые пользователи. К томуже, в позвольте вас спросить - в чем именно будет редактировать переводчик ваш супер-файлик вашего формата? Могу подсказать - скорее всего в Word или еще какую гадость найдет - вот вы повеселитесь.
Я всеже остаюсь при мнении, что вы GetText скорее всего толком не использовали и с крупными проектами не работали - тогда бы вы не выдвигали таких возражений.
Извините за столь большое кол-во текста :-)Еще одна "интересная" идея cobolta - создать шаблоны для каждого языка. Опять же говорит о том, что человек не работал с большими проектами.
Давайте создадим 5 папок для 5 языков. Сайт обладает сложным дизайном и так далее. К чему мы в результате придем? Правильно - любое изменение дизайна повлечет за собой бегатню по десяткам папок и поиску файликов и их редактирования. В результате, поверьте на слово, вы получите бесконечные глюки и проблемы - там не доправили, тут нито стерли. С русским, ну английским еще просто - а что если вас попросят в шаблоне поправить китайское слово или исправить в нем иероглиф?
Надеюсь, что мои посты помогут пользователям отделить гениальные идеи от практически применимых. Я вовсе не ратую в данном посте за GetText, просто указываю на несостоятельность некоторых идей.
Приложение, а тем более многоязчное, это сложный организм, который требует тщательной проработки, а не выдвигания скорополительных идей.
Помните - что задача программера максимально отделить себя от контентменеджера - и все, что вы пишите в скриптах, шаблонах или других вспомогательных файлах обернется против вас, если вы не позаботитесь заранее об интерфейсах редактирования этой информации.
вот если где и реализована многоязычность, то это plone. правда к php это не имеет никакого отношения.