Начат перевод Drupal Administrator's guide

Многоязычность контента реализована модулем i18n - пока единственное решение. Ничего "из коробки" пока сам движок не предлагает, что к плюсам системы никак не отнесёшь. А i18n к сожалению отличается своеобразием в настройке и использовании (просто напросто глюковат - сколько версий его не пробовал). Не то чтобы через жопу, но на общем фоне простых в настройке друпаловских модулей выглядит близко к тому :)

PS. Если кто на drupal.ru нашёл решение с мультисайтингом - не читайте, это для фанатов ;) Не так уж сложно на самом деле, но имеет смысл только когда контент разных языков не требуется синхронизировать. Если требуется - модуль i18n это делает как может :\

> Вообще-то моя предыдущая реплика была шуткой. :) И слова "взглянуть повнимательнее и разобраться глубже" в равной мере относятся практически к любому программному продукту.

Так я тож смайлик в конце поставил. А что, на L.O.R. кто-то вообще говорит что-нибудь всерьёз? ;)

> annonymous # (*) (13.02.2005 8:11:10)

annonymous - annoying anonymous?

Регистрация тебе не помогла. Как был анонимусом - так и остался. Понты + незнание темы.

> А разве кто-то говорил что все решения должны быть только на Zope? Конечно же нет.

Это был риторический вопрос - понимаю что не должны и даже зоперы это понимают, полагаю. Вот только много ли сейчас таких решений? Как только вспоминают python в контексте веб - тут же возникает на бэкграунде тень великого и страшного Zopы :( Ещё раз прошу не принять за выпады в сторону этой платформы, но почему-то под чистый Apache+mod_python+реляционнаяСУБДкакая-нибудь (имхо эффективную по ресурсам и скорости связку) на питоне так мало решений? Кто-нибудь укажет на python CMS работающую в такой конфигурации? Разве что MoinMoin Wiki можно вспомнить ;) Вот тож кстати - у двух хостеров её пользовал, нигде mod_python или fast_cgi получить не удалось, хорошо хоть сайт там любительский и малопосещаемый - и на обычном cgi нормально живёт. Замкнутый круг - питон мало используют по причине отсутствия массовой поддержки, а хостеры не видят смысла поддерживать по причине отсутствия достаточного количества готовых решений.

Axel, спасибо за хороший и полный ответ.

Насчёт поиска - видимо это исправили, потому что раньше это посто было сделано через полную жопу. Но некоторые архитектурные решения мне тогда помню тоже не очень понравились (сейчас не скажу - просто не помню). Единственное что мне показалось интересным: идология, что всё есть node и taxonomy тут тоже весьма кстати. Структура базы данных тоже неплоха. Эти идеи я оттуда позаимствовал (и в PHP я разбирался тоже через этот движок).

Насчёт хранения перевода: мне кажется, что подключаемые файлы - гораздо более _эффективный_ вариант, потому что когда страница генерится туевой хучей запросов к базе это неправильно, а кеш, насколько я помню, там был только для анонимных пользователей (потому что иначе придётся кешировать результаты работы функций, что там, по-моему, не было предусмотрено, но что я у себя, в частности, предусмотрел).

Если в общем, то наверное действительно лучшего CMS нет и не будет, а Друпал - не плох, хотя и далеко не идеален (но активно развивается)... =)

> Регистрация тебе не помогла.

Это нарочно задумано. Чтобы ввести врага в заблуждение, а заодно
поломать мысленные штампы (у кого это ещё возможно). Некоторым всё-равно
не помогает ;)

> Как был анонимусом - так и остался. Понты + незнание темы.

Да куда нам до гигантов с целым годом опыта работы ;)

> Насчёт хранения перевода: мне кажется, что подключаемые файлы - гораздо более _эффективный_ вариант,

Согласен, по производительности пожалуй да, хотя не факт что по потреблению ресурсов. Ведь мы закатываем в память сразу целый перевод (скажем одного модуля), из которого модуль может быть дернет одну фразу. Поэтому я думаю хороший компромисс - это gettext, мы получаем индексированый поиск (mo-файлы) и возможность правки и обработки переводов внешними стандартными утилитами, в т.ч. любым текстовым редактором (po-файлы). В общем имхо тут можно слегка пожертвовать скоростью в пользу стандартности. А с инклюдами и хранением в текстовых файлах - каждый сам себе строитель велосипеда, посмотреть как в других вебскриптах это понаделано. До Друпала где-то около года возился с Postnuke (отрицательный опыт - тоже опыт) - вот насмотрелся на код, когда в модуле константа с невнятным названием, а где-то ещё хрен где в другом файле её определение. Когда переводишь - не всегда ясен смысл константы, да ещё в коде проще ошибиться и не то что-нибудь подставить. На наглядности кода это никак не в лучшую сторону сказывается. К сожалению в большинстве CMS именно такой способ применён, поэтому альтернатива предложенная в Drupal меня так порадовала, пусть даже девелоперы слишком уж соригинальничали запихнув переводы в базу :) Но кстати, хоть они даже в базе лежат - импорт/экспорт всё равно в po-формате gettext сделан.

В общем, imho, лучше так:
print _("Hello world") или
print t("Hello world") - это как в Drupal

чем так:
print _HELLO_WORLD;

Да, кэш для анонимных юзеров, но кеширование для отдельных функций там имеет место - для меню например. Что для анонимных, что для залогиненных. А может ещё где задействовано.

Axel, тогда больше аргументированно не возражу... =)