Dans l’administration Django, les modèles sont regroupés par application. Par défaut, Django construit le nom affiché à partir du nom interne de l’application. Cela convient rarement tel quel dès que l’on veut une interface d’administration propre, et encore moins lorsqu’elle doit être traduite.
La bonne méthode consiste à définir le nom lisible de l’application dans sa classe AppConfig, avec l’attribut verbose_name. Si ce nom doit suivre la langue active, on l’entoure simplement avec gettext_lazy().
Définir un nom lisible avec AppConfig
Imaginons une application Django nommée users. Son fichier apps.py peut contenir :
from django.apps import AppConfig
from django.utils.translation import gettext_lazy as _
class UsersConfig(AppConfig):
name = "users"
verbose_name = _("Users")
name reste le chemin Python de l’application. verbose_name, lui, correspond au nom destiné à être affiché à un humain. C’est donc cet attribut qu’il faut modifier pour renommer l’application dans l’administration.
Il ne faut pas utiliser label pour cela. Cet attribut sert d’identifiant interne à l’application et intervient notamment dans les migrations. Le modifier sur un projet existant peut casser les références à l’application.
Pourquoi utiliser gettext_lazy ?
Le fichier apps.py est chargé au démarrage de Django, avant qu’une langue précise soit forcément active. C’est pour cette raison que l’on utilise gettext_lazy(), généralement importé sous le nom _ :
from django.utils.translation import gettext_lazy as _
La traduction n’est alors réellement résolue qu’au moment où Django doit afficher le texte.
Si votre administration n’est pas multilingue, vous pouvez évidemment utiliser directement une chaîne de caractères :
class UsersConfig(AppConfig):
name = "users"
verbose_name = "Utilisateurs"
Créer la traduction
Dans un projet déjà configuré pour l’internationalisation, générez ou mettez à jour le catalogue français :
python manage.py makemessages -l fr
Django ajoute alors la chaîne Users au fichier locale/fr/LC_MESSAGES/django.po. Il suffit de la traduire :
msgid "Users"
msgstr "Utilisateurs"
Compilez ensuite les catalogues :
python manage.py compilemessages
Lorsque le français est la langue active, l’administration affichera désormais Utilisateurs. Avec une autre langue, Django utilisera la traduction correspondante si elle existe.
Faut-il modifier INSTALLED_APPS ?
Avec les versions actuelles de Django, une classe AppConfig unique placée dans le fichier apps.py est normalement détectée automatiquement lorsque INSTALLED_APPS contient simplement le nom de l’application :
INSTALLED_APPS = [
# ...
"users",
]
Vous pouvez aussi référencer explicitement la classe de configuration :
INSTALLED_APPS = [
# ...
"users.apps.UsersConfig",
]
Les anciens projets Django utilisaient parfois default_app_config dans le fichier __init__.py. Cette configuration n’est plus nécessaire sur les versions modernes de Django.
À retenir
AppConfig.verbose_namedéfinit le nom lisible de l’application.gettext_lazy()permet de traduire ce nom selon la langue active.labeln’est pas destiné à renommer une application dans l’interface.- Une classe
AppConfigunique dansapps.pyest automatiquement détectée par Django dans le cas habituel.
Cette petite configuration suffit pour éviter les noms techniques ou anglais dans l’administration et garder une interface cohérente avec le reste du projet.
Documentation : configuration des applications Django et traduction avec Django.


Laisser un commentaire