Как поменять имя приложения в админке Django
Здравствуйте, уважаемые коллеги.
Когда-то давно передо мной встала проблема определения имени приложения в админке Django. Как вы знаете, django.contrib.admin выводит в своём интерфейсе англоязычные имена для applications в виде заголовков блоков, в которых, собственно, расположены страницы самих моделей.
Собственно, увидев такой вариант оформления панели, один из заказчиков попросил хотя бы для основных управляемых элементов (а их было не так уж мало) перевести заголовки на русский язык.
Так начались поиски ответа на вопрос: «Как поменять название приложения в админке Django». Как оказалось, вопрос был не совсем точным, поскольку во фреймворке уже имелось встроенное решение. Документация Django подсказала, что в модели можно переопределить свойство app_label в классе Meta.
У этого метода есть серьёзный недостаток: app_label используется Django ещё и для именования таблиц в базе данных. Так что тут особо не разгуляешься: текст не переведёшь, а ошибка в имени может вызвать долгие романтические отношения с БД.
Решение, которое мне удалось найти — не новое. Оно расположено на code.djangoproject.com. И тут уж я не помню: сам я его допиливал, либо обратился к кому-то за помощью, но в общем, мне удалось получить вот такой сниппет, который я до сих пор вставляю в свои модели:
Работает это дело просто: при создании структуры таблиц используется переменная value, а для получения выводимой метки — title. В процессе работы возникли проблемы с именами таблиц, так что добавилась функция get_raw_name, а также, две переменные, которые позволили не писать имена БД и приложения в каждой модели.
После внедрения такого сниппета, код моделей должен будет выглядеть так:
Итого, мы имеем переопределённое имя приложения и возможность переопределять имя таблицы в базе данных. Второе, кстати, чревато последствиями, поскольку при возникновении связей между таблицами система может рухнуть. Так что, наиболее правильно не прописывать db_table или определять это свойство так, как оно должно выглядеть по-умолчанию.
Полная русификация админки
Здравствуйте. На днях возникла задача русифицировать админку django включая названия моделей, полей и приложений. Основной целью было избежать модифицирования кода django. Продолжительное гугление не дало целостной картины этого процесса. Поэтому я решил собрать все в одном месте.
Сразу скажу, что еще в самом начале проекта поставил django-admin-tools и тем самым сохранил себе некоторое количество нервных клеток. А все манипуляции проводились над django 1.3.
Подготовка
Для начала пропишем в конфигурационном файле
Затем создадим свои классы для приборной панели и меню django-admin-tools. Для этого выполним последовательно команды
python manage.py custommenu
python manage.py customdashboard
В результате выполнения этих комманд у вас в корневой директории проекта появятся два файла dashboard.py и menu.py. Далее в конфигурационном файле проекта нужно указать где находятся нужные классы. Для этого допишем в него следующие строчки
Путь может быть любой. Главное чтоб по нему находились нужные классы
При выполнении этой команды будут просканированы все файлы на предмет обращения к словарю и составлен файл django.po, который появится в папке locale/ru/LC_MESSAGES. Можно выполнять эту команду регулярно после добавлений новых обращений к словарю в коде или же править файл django.po руками.
Чтоб изменения в словаре вступили в силу нужно выполнить команду
python manage.py compilemessages
после завершения которой рядом с файлом django.po появится django.mo.
Перевод имени приложения
Первым делом нужно заставить админку отображать русское название для имени приложения. На одном из форумов советовали просто прописать в поле app_label подкласса Meta в модели нужное значение, но от этого я отказался сразу. Так как меняется url приложения и с syncdb начались проблемы. Перекрытие метода title у str тоже не помогло так как слетал фильтр и admin-tools начинал лепить все модели в один бокс.
Я обычно запускаю команду makemessages в процессе работы над проектом, а значит нам нужно место, где будет обозначено обращение к словарю. Проще говоря я вписываю в файл __init__.py своего приложения следующий код
Здесь мы импортируем модуль ugettext_lazy и делаем обращение к словарю за переводом. Если после этого запустить команду makemessages еще раз, то в файл django.po будут добавлены следующие строки
#: feedback/__init__.py:2
msgid «Feedback»
msgstr «»
и мы сможем подставить в msgstr свой перевод. В данном случае «Обратная связь». Теперь нам нужно сделать так чтоб при отображении шаблона названия приложения бралось из нашего словаря. Для этого сначала переопределим шаблон app_list.html. Этот шаблон используется при выводе модуля AppList.
В нашей директории templates создадим определенную структуру директорий и положим туда файл app_list.html так чтоб у нас получился путь
templates/admin_tools/dashboard/modules/add_list.html
Этот файл должен иметь то же содержание что и оригинальный app_list.html. Теперь изменим код в строке 5 на следующий
Таким образом при отображении названия приложения в общем списке будет браться наше значение из словаря.
В общем списке название отображается нормально, но когда мы заходим в само приложение, то заголовок модуля все еще не переведен. Для того чтоб исправить это заглянем в наш файл dashboard.py, который мы создавали в начале, и найдем там класс CustomAppIndexDashboard. Он отвечает за формирования страницы приложения в админке. В его методе __init__ исправим код чтоб получить следующее
Здесь мы завернули self.app_title в функцию ugettext_lazy и теперь на странице приложения название будет так же переведено.
Остались только хлебные крошки. Там по-прежнему отображается оригинальное название.
Модуль breadcrumbs используется в большом количестве шаблонов, поэтому за мыслями я полез потрошить файлы django.contrib.admin. Результатом чего стал вот такой класс. Его надо прописать в файле admin.py вашего приложения до регистрации модулей админки. Забегая вперед скажу, что здесь мы так же переводим и заголовки страниц просмотра, редактирования и добавления модели c помощью библиотеки, о которой расскажу чуть ниже.
При помощи него мы заменяем контекст для рендеринга шаблона на вызов функции ugettext_lazy. Таким образом мы перевели название приложения в хлебных крошках и заголовке страницы. Но это еще не все. Для полноты картины нам надо перегрузить еще один шаблон admin/app_index.html И строку 11 заменим на
Осталось только перевести имя приложения в выпадающем меню. Для этого достаточно перегрузить шаблон admin_tools/menu/item.html и поправить пару строк. В блок load второй строки добавляем i18n, а в конец 5й строки вместо << item.title >> пишем <% trans item.title %>.
Теперь все названия нашего приложения будут отображаться из словаря django.mo. Можем идти дальше
Перевод названия модели и полей
Если название приложения нам нужно просто выводить в переведенном виде, то название модели хорошо бы выводить с учетом падежа, рода и числа. В поисках красивого решения я наткнулся на великолепный модуль pymorphy от kmike, за который ему огромное спасибо. Он очень удобен в использовании и прекрасно делает свою работу! К тому же для админки нам большая скорость не нужна. Все что нам остается — это установить модуль pymorphy и интегрировать его в django руководствуясь шагами из документации.
Теперь нам нужно переопределить несколько шаблонов в админке и расставить там фильтры pymorphy при этом все переводы строк должны оставаться в одном месте. А именно в файле django.po.
Дальше будем для примера русифицировать модель Picture чтоб она отображалась как «Картинка». Первым делом в этой модели пропишем
И добавим в файл django.po
msgid «picture»
msgstr «картинка»
msgid «pictures»
msgstr «картинки»
msgid «title»
msgstr «заголовок»
Теперь осталось сделать чтоб переведенные слова отображались с учетом падежа и числа
Начнем с шаблона admin/change_list.html. Он отвечает за вывод списка элементов модели. Для начала добавим в блок load модуль pymorphy_tags. Например в строку 2. Чтоб получилось
Далее находим там строку 64, которая отвечает за вывод кнопки добавления
Здесь мы добавили изменение названия модели в винительный падеж. И получили правильную надпись «Добавить картинку». Подробнее о формах изменения можно почитать здесь.
Заголовки страниц уже переведены в нужной форме с помощью класса I18nLabel так что можно двигаться дальше.
Теперь перегрузим шаблон admin/change_form.html. Сначала нужно добавить модуль pymorphy_tags в блок load, а затем исправить там хлебные крошки заменив в строке 22
Далее во списку идет шаблон admin/delete_selected_confirmation.html. В нем все правки делаем тем же способом, что и в предыдущих случаях. Здесь нужно сначала исправить хлебные крошки вот так
К сожалению функция delete_selected, которая отвечает за вывод этой страницы не поддерживает extra_context, что меня очень печалит. Поэтому я сделал свой фильтр, который изменяет форму числа в зависимости от величины объекта.
Теперь во всех местах надо расширить блок blocktrans примерно так
<% blocktrans %>Are you sure you want to delete the selected << objects_name >>? All of the following objects and their related items will be deleted: <% endblocktrans %>
исправить на
<% blocktrans with objects_name|inflect:"вн"|plural_from_object:deletable_objects as objects_name %>Are you sure you want to delete the selected << objects_name >>? All of the following objects and their related items will be deleted:
После всего этого остается лишь перегрузить шаблон admin/pagination.html, подключить в нем модуль pymorphy_tags и заменить в нем строку 9 на
фильтр lower я добавил потому что возникала ошибка при преобразовании прокси объекта gettext в фильтре plural. Но, возможно, это у меня в окружении такой глюк и у вас не будет необходимости его добавлять.
Следующий по плану шаблон admin/filter.html Тут просто первые две строки заменить на
Остались только пользовательские сообщения, которые все еще выводятся без учета числа. Для того чтоб исправить эту досадную несправедливость нужно переопределить метод message_user у класса ModelAdmin. Можно вставить это в admin.py. У меня получилось делать следующим образом
Здесь мы разбираем сообщение по словам и склоняем их в нужную форму. Отдельно отличаются сообщения для групп объектов и для единиц.
Вот теперь мы можем наблюдать примерно такую картинку
Заключение
Отсутствие предусмотренных решений в архитектуре django, безусловно, расстраивает, но все в наших руках. Возможно некоторые решения могут показаться вам кривыми, но я пока не нашел способа сделать это изящнее.
При написании статьи я старался изложить кратко и по пунктам, и не смотря на количество текста получается не так много движений для достижения результата. Это при условии использования приведенного выше кода.
Основная цель этой работы была перевести административный интерфейс и сохранить все переведенные строки в одном месте, а именно в языковом файле. Что мы и получили.
Буду благодарен за любые замечания и предложения. Спасибо за внимание.
P.S. Уже готовые шаблоны вы можете забрать здесь. Вам нужно будет распаковать содержимое архива в вашу директорию templates.
[UPD]: Михаил (kmike) завел проект на bitbucket под названием django-russian-admin для автоматизации всех приведенных выше действий.
Начинаем работу с админ-панелью
На этом занятии мы затронем еще один ключевой момент фреймворка Django – работа со встроенной админ-панелью. Она поставляется сразу «в коробке» и доступна для нашего сайта по адресу:
Причем, по умолчанию, фреймворк использует английский язык. Чтобы переключиться на русскую локализацию, нужно в пакете конфигурации в файле settings.py изменить константу LANGUAGE_CODE, установив ее в значение:
И при обновлении страницы увидим русскоязычный вариант админ-панели.
С помощью встроенной админки можно решать практически все типовые задачи, которые нам могут потребоваться. Это и создание пользователей с разными полномочиями (ролями), отображение всех наших приложений, добавление, удаление и изменение записей и так далее. Она подойдет для большинства сайтов так, что создавать свою админ-панель в Django попросту нет необходимости.
Итак, для входа нам нужно ввести имя пользователя и пароль. Но у нас пока их нет и вообще нет ни одного зарегистрированного пользователя в админ-панели. Поэтому, сначала необходимо создать суперпользователя – администратора сайта. Для этого я перейду в терминал и в новой вкладке консоли выполню команду (из каталога проекта coolsite):
python manage.py createsuperuser
Здесь нам будет предложено указать логин (имя пользователя). В учебных целях я укажу root. Далее, нужно ввести адрес электронной почты, пусть это будет root@coolsite.ru. (Почта может быть не существующей в учебном проекте, а вообще, нужно указывать адрес реальной почты, на которую будут приходить служебные сообщения). И, наконец, вводим пароль (1234) и повторяем его. Конечно, такой простой пароль и имя пользователя я использую сугубо в рамках этих занятий. В реальности старайтесь указывать необычные, уникальные имена и большой, сложный пароль, иначе, получив доступ к админ-панели, злоумышленник легко нарушит работу вашего сайта.
Все, суперпользователь создан и мы теперь можем войти в админку, указав root и пароль 1234. На главной странице мы видим два зарегистрированных приложения: «Группы» и «Пользователи». То есть, мы можем создавать новых пользователей уже непосредственно здесь, а также назначать им определенные группы.
Однако, здесь нет нашего приложения women. Почему? Дело в том, что его нужно зарегистрировать, то есть, указать, что мы хотим его видеть в админ-панели. Для этого откроем файл women/admin.py, который отвечает за взаимосвязь приложения с админкой, где мы будем регистрировать наши модели. Вначале импортируем их:
и зарегистрируем модель Women:
Возвращаемся в админку и при обновлении главной страницы видим наше приложение и зарегистрированную модель Women. Если щелкнуть по ней, то видим список наших записей и здесь же можем их редактировать, удалять и добавлять новые. Это очень удобно.
И, смотрите, при выборе определенной записи, мы видим кнопку «Смотреть на сайте». Эта кнопка появляется только тогда, когда в модели определена функция get_absolute_url(). Если мы ее закомментируем и обновим админку, то эта кнопка пропадет. Так, что эта функция достаточно часто используется в различных модулях фреймворка Django.
Давайте немного настроим админ-панель, чтобы она выглядела приятнее и дружелюбнее. Первое, что мы сделаем – это заменим название Women на «Известные женщины». Для этого перейдем в файл с моделями (women/models.py) и в классе Women пропишем специальный вложенный класс Meta, который используется админкой для более тонкой настройки модели:
Здесь verbose_name – это специальный атрибут, отвечающий за название модели. Однако, мы видим, что админ-панель по прежнему добавляет латинскую s в конец нашего имени, то есть, пытается сделать его множественное число. Чтобы явно указать, как будет звучать название во множественном числе, определим еще один атрибут:
Так стало гораздо лучше. Добавим сортировку записей по дате их создания и по заголовку с помощью еще одного атрибута ordering:
Как происходит упорядочение по нескольким полям? Сначала идет сортировка по первому полю (в данном случае дате создания), но если даты оказываются равными, то учитывается следующее поле (заголовок) и так далее. Перейдем в админ-панель и видим, что особо ничего не поменялось, записи и так шали в порядке возрастания времени создания. Изменим сортировку по первому полю на противоположную (ставим знак минус):
и порядок отображения постов также поменялся. Причем, обратите внимание, указанная сортировка будет также влиять на порядок отображения статей и на сайте. Если перейти на главную страницу, то увидим посты в той же последовательности, что и в админке.
Далее, мы поменяем отображение заголовка women приложения на другой – «Женщины мира». Для этого перейдем в файл women/apps.py и в классе конфигурации приложения пропишем атрибут:
Здесь тоже обратите внимание, что все это работает благодаря подключению приложения в пакете конфигурации (файл settings.py) через этот класс:
Если бы мы написали просто ‘women’, то заголовок «Женщины мира» в админ-панели не появился бы.
Следующим шагом добавим в списке записей дополнительные поля: id, title, время создания, изображение, флаг публикации. Для этого нужно открыть файл women/admin.py и объявить класс, унаследованный от ModelAdmin:
Здесь в атрибуте list_display указываем список отображаемых полей, в атрибуте list_display_links – список полей в виде ссылки для перехода к конкретной записи, а атрибут search_fields определяет поля, по которым можно будет производить поиск записей. (В этом классе есть и другие атрибуты, вы можете изучить их самостоятельно).
Зарегистрируем этот класс в функции register:
причем, WomenAdmin должен обязательно идти после класса модели Women. Возвращаемся в админку и видим все эти поля. Но они имеют английское написание, а нам бы хотелось иметь русские названия. Поправим. Перейдем в класс определения модели Women (women/models.py) и у каждого поля в конструкторе соответствующих классов добавим именованный параметр verbose_name:
Теперь имена полей отображаются с нашими значениями.
По аналогии зарегистрируем вторую модель Category. В файле women/admin.py пропишем:
И вызовем функцию register:
Переходим в админку и видим, что появилось второе приложение с набором указанных полей. Также скорректируем все названия. Перейдем в файл women/views.py и в класс Category добавим вложенный класс Meta:
Кроме того, у поля name добавим параметр verbose_name:
Все, теперь мы можем полноценно работать и с рубриками в нашей админ-панели.
Однако, измененное метаописание полей модели (параметр verbose_name) желательно внести и в таблицы БД. Создадим еще один файл миграции командой:
python manage.py makemigrations
и, затем, применим все миграции:
python manage.py migrate
Все, в целом админка у нас настроена и давайте теперь добавим с ее помощью новую запись. Введем в поле title «Ариана Гранде», заполним другие поля, кроме картинки и нажмем добавить. Админка сообщит об ошибке, т.к. поле photo у нас идет как обязательное. Поэтому выберем картинку и сохраним. Запись была добавлена успешно, в поле photo мы видим путь к изображению, а в проекте появилась папка media с загруженной фотографией.
Видите как это удобно: нам не нужно вручную прописывать механизм загрузки изображений, фреймворк Django все берет на себя и делает это автоматически. Это очень круто! Правда, здесь может возникнуть одна проблема, когда загружаются изображения с одинаковыми именами и помещаются в одну папку. Как это обойти мы позже разберем. А сейчас добавим отображение картинок в списке статей на главной странице. Делается это очень просто, в шаблон index.html добавим строчки:
Мы здесь вначале проверяем: имеется ли вообще какой-либо путь к изображению (так как не у всех наших записей он присутствует), а затем, используем встроенный атрибут url, который возвращает корректный URL-адрес к текущему изображению. Я загружу все изображения для каждой статьи и получим уже более полноценное отображение постов.
Давайте еще немного улучшим нашу админку и сделаем так, чтобы поле is_published можно было редактировать прямо в списке статей. Выполняется это очень просто. В классе WomenAdmin (файл women/admin.py) добавим еще один атрибут:
И теперь в списке статей в панели появились чекбоксы, где мы можем убирать или ставить галочки, то есть, поле стало редактируемым.
Далее, добавим поля, по которым сможем фильтровать наш список статей. Опять же в классе WomenAdmin прописываем атрибут:
где указываем список полей для фильтрации. Переходим в админку и видим, что справа появилась панель с возможностью выбирать записи по публикации и времени создания.
Вот так в базовом варианте можно выполнять настройку админ-панели и работать через нее с записями таблиц БД.
Видео по теме
#2. Модель MTV. Маршрутизация. Функции представления
#3. Маршрутизация, обработка исключений запросов, перенаправления
#4. Определение моделей. Миграции: создание и выполнение
#6. Шаблоны (templates). Начало
#7. Подключение статических файлов. Фильтры шаблонов
#8. Формирование URL-адресов в шаблонах
#9. Создание связей между моделями через класс ForeignKey
#10. Начинаем работу с админ-панелью
#11. Пользовательские теги шаблонов
#12. Добавляем слаги (slug) к URL-адресам
#13. Использование форм, не связанных с моделями
#14. Формы, связанные с моделями. Пользовательские валидаторы
#15. Классы представлений: ListView, DetailView, CreateView
#16. Основы ORM Django за час
#18. Постраничная навигация (пагинация)
#19. Регистрация пользователей на сайте
#20. Делаем авторизацию пользователей на сайте
#21. Оптимизация сайта с Django Debug Toolbar
#22. Включаем кэширование данных
#23. Использование капчи captcha
#24. Тонкая настройка админ панели
#25. Начинаем развертывание Django-сайта на хостинге
#26. Завершаем развертывание Django-сайта на хостинге
© 2021 Частичное или полное копирование информации с данного сайта для распространения на других ресурсах, в том числе и бумажных, строго запрещено. Все тексты и изображения являются собственностью сайта
Руководство Django часть 4: административная панель Django
Теперь, когда модели для сайта местной библиотеки созданы, добавим некоторые «настоящие» данные о книгах, используя административную панель Django Admin. Для начала мы покажем, как зарегистрировать в ней модели, потом как войти и создать какие-нибудь данные. В конце статьи мы покажем некоторые способы дальнейшего улучшения вида админ-панели.
| Предусловия: | Сначала завершите: Руководство часть 3: использование моделей. |
|---|---|
| Цель: |
