Django propose un excellent système d'internationalisation (i18n) pour traduire les éléments statiques d'une application, comme les menus, les boutons ou les messages. En revanche, la traduction des contenus stockés en base de données (articles, produits, catégories, etc.) nécessite une approche différente. C'est là qu'intervient django-parler, une bibliothèque qui simplifie la gestion du contenu multilingue tout en s'intégrant parfaitement à Django. Dans cet article, nous verrons comment l'utiliser pour traduire efficacement le contenu dynamique de vos applications.
Comprendre la différence entre traduction statique et traduction dynamique
Avant d'installer une bibliothèque supplémentaire, il est important de comprendre qu'il existe deux types de traduction dans Django.
Traduction statique
Elle concerne tous les textes écrits directement dans le code.
Par exemple :
Ici, le mot Title est traduit grâce au système d'internationalisation intégré à Django.
Cette approche fonctionne parfaitement pour :
- les boutons
- les menus
- les messages d'erreur
- les labels des formulaires
- les notifications
Ces textes sont connus dès le développement.
Traduction dynamique
Le problème apparaît lorsque le contenu provient de la base de données.
Prenons un modèle simple.
Si un utilisateur crée un article intitulé :
Découvrir Django
Comment afficher automatiquement :
- Discover Django
- Descubrir Django
- Django entdecken
selon la langue de l'utilisateur ?
Les champs classiques de Django ne savent stocker qu'une seule valeur.
On pourrait créer :
Mais cette solution devient rapidement difficile à maintenir :
- duplication des champs ;
- migrations complexes ;
- ajout d'une nouvelle langue coûteux ;
- code peu évolutif.
C'est exactement le problème que résout django-parler.
Qu'est-ce que django-parler ?
django-parler est une bibliothèque open source conçue pour ajouter la gestion du contenu multilingue aux modèles Django.
Son principe est simple :
Au lieu d'ajouter plusieurs colonnes dans une même table, django-parler crée automatiquement une table dédiée aux traductions.
Par exemple :
Maintenant, Chaque traduction devient ainsi un enregistrement distinct.
Un même article peut donc posséder :
| Langue | Titre |
|---|---|
| Français | Découvrir Django |
| Anglais | Discover Django |
| Espagnol | Descubrir Django |
Cette approche présente plusieurs avantages :
- architecture propre ;
- évolutivité ;
- nombre illimité de langues ;
- performances optimisées ;
- intégration native avec l'ORM Django.
Installation de django-parler
La première étape consiste à installer la bibliothèque.
pip install django-parler
Ajoutez ensuite l'application dans le fichier settings.py.
Configurez ensuite les langues disponibles.
Puis ajoutez la configuration de django-parler.
Cette configuration indique à Django quelle langue utiliser par défaut ainsi que la langue de secours lorsqu'une traduction n'existe pas.
Création d'un modèle traduisible
Au lieu d'hériter de models.Model, un modèle multilingue hérite de TranslatableModel.
Le champ date_creation reste hors de TranslatedFields, car une date n'a aucune raison de varier selon la langue. Elle demeure un champ classique de la table principale.
La méthode __str__ utilise safe_translation_getter plutôt qu'un accès direct self.title. C'est une précaution importante : __str__ est fréquemment appelé dans des contextes où aucune langue active n'est garantie (shell Django, logs, interface d'administration), et où la traduction demandée pourrait ne pas exister pour cet objet précis. safe_translation_getter('title', any_language=True) retourne, en dernier recours, n'importe quelle traduction disponible plutôt que de lever une exception DoesNotExist.
L'interface d'administration
TranslatableAdmin surcharge plusieurs méthodes du ModelAdmin standard pour générer une interface à onglets, un onglet par langue déclarée dans PARLER_LANGUAGES. Cette classe intervient à plusieurs niveaux :
get_form()injecte dynamiquement les champs traduits dans le formulaire, en lisant la configuration_parler_metagénérée parTranslatedFields.- Le template d'administration est remplacé par une version fournie par parler, incluant le JavaScript de gestion des onglets.
save_model()est surchargée pour itérer sur chaque langue soumise dans le formulaire et créer ou mettre à jour la ligne de traduction correspondante.
Ajouter une nouvelle langue à l'application ne nécessite donc aucune modification de admin.py : il suffit d'ajouter l'entrée correspondante dans PARLER_LANGUAGES, et un nouvel onglet apparaît automatiquement.
Les URLs multilingues
i18n_patterns() préfixe automatiquement chaque route qu'elle englobe avec un code de langue issu de LANGUAGES. Concrètement, path('', include('blog.urls')) génère dynamiquement, au démarrage du serveur, une route pour chaque langue configurée :
/fr/
/en/
L'inclusion de path('i18n/', include('django.conf.urls.i18n')) fournit une vue prête à l'emploi, nommée set_language, utilisée pour construire un sélecteur de langue côté frontend.
La vue (view)
Un point notable : la vue ne contient aucune logique liée à la traduction. C'est précisément l'un des principaux bénéfices de parler : la couche de présentation (vues) reste agnostique de la langue, celle-ci étant résolue plus bas, au niveau des descripteurs du modèle.
Que ce passe t'il au niveau des templates pour l'affiche?
Dans le fichier.html, {{ article.title }} et {{ article.content }}, eux, passent par les descripteurs de parler. Le template ne fait qu'accéder à l'attribut normalement, sans aucune syntaxe particulière. C'est la langue active de la requête, déterminée en amont par LocaleMiddleware (A definir dans le settings.py), qui détermine silencieusement quelle traduction est renvoyée depuis ArticleTranslation.
Le formulaire de changement de langue ({% url 'set_language' %}) n'affiche rien de dynamique : il envoie juste la langue choisie et l'URL courante (request.path) à la vue fournie par Django, qui met à jour le cookie django_language et redirige sur la même page.
NB : Nous n'avons aucun {% if LANGUAGE_CODE == 'fr' %} nulle part. Le template reste unique, identique quelle que soit la langue servie : toute la résolution se fait en amont, au niveau du modèle et du middleware, pas dans le template.
Pourquoi utiliser django-parler ?
Par rapport à une gestion manuelle des traductions, django-parler offre de nombreux avantages :
- code plus propre ;
- meilleure organisation de la base de données ;
- ajout de nouvelles langues sans modifier les modèles ;
- intégration complète avec l'ORM Django ;
- compatibilité avec Django Admin ;
- gestion automatique des langues de secours (fallback).
Ces caractéristiques en font une solution particulièrement adaptée aux blogs, plateformes e-commerce, systèmes de gestion de contenu (CMS) et applications SaaS destinées à un public international.
La traduction du contenu dynamique représente un défi courant dans les applications web modernes. Bien que Django fournisse un excellent système d'internationalisation pour les textes statiques, il ne permet pas, à lui seul, de gérer efficacement les données multilingues stockées en base de données. En apportant une couche de traduction directement au niveau des modèles, django-parler simplifie considérablement cette problématique. Son intégration avec l'ORM Django, son architecture basée sur des tables de traduction dédiées et sa simplicité d'utilisation en font une solution robuste et évolutive pour développer des applications véritablement internationales.
Dans un prochain article, nous irons plus loin en découvrant comment intégrer django-parler avec l'interface d'administration de Django, afin de permettre aux administrateurs de créer et gérer facilement des contenus multilingues sans écrire une seule ligne de code.