Skip to content

5. Internationalisation

Une application internationalisée affiche ses textes dans la langue de l'utilisateur. L'étude de cas est en français et en anglais. Le principe est simple : les gabarits contiennent des textes marqués comme « à traduire », et un dictionnaire par langue associe à chaque texte sa traduction. La langue choisie est mémorisée dans un cookie.

[Django] utilise pour cela [gettext], le système de traduction du projet GNU, que [Python] connaît aussi (module [gettext] de la bibliothèque standard), et que l'on retrouve dans de nombreux logiciels libres. Avec [gettext], la clé d'un texte est le texte lui-même, écrit dans la langue d'origine : un gabarit écrit [{% translate "Accueil" %}], et le dictionnaire anglais associe « Accueil » à « Home ». Une page reste ainsi lisible, et fonctionne, même sans dictionnaire : les textes s'affichent dans la langue d'origine. C'est une différence avec les versions [Symfony], [Laravel], [Flask], [Spring MVC], [ASP.NET Core MVC] et [NestJS] de l'étude de cas, qui utilisaient des clés abstraites ([MENU.ACCUEIL]). Les dictionnaires sont des fichiers texte, au format [.po] (Portable Object), que des outils savent extraire du code et que des logiciels de traduction savent éditer ; [Django] lit leur version compilée, les fichiers [.mo] (Machine Object). [gettext] sait aussi accorder un texte au pluriel, selon les règles de chaque langue. [Django] est d'ailleurs lui-même traduit ainsi : c'est grâce à ses dictionnaires que ses messages d'erreur sont en français depuis l'exemple 08. La mise en forme des dates et des montants reste celle de l'exemple 16.

5.1. Exemple 22 : une application en deux langues

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
22-i18n/
├── config/
│   ├── settings.py
│   ├── urls.py
│   └── ...
├── locale/
│   └── en/
│       └── LC_MESSAGES/
│           ├── django.mo
│           └── django.po
├── pages/
│   ├── templatetags/
│   │   ├── __init__.py
│   │   └── formats.py
│   ├── __init__.py
│   ├── modeles.py
│   └── views.py
├── static/
│   └── ...
├── templates/
│   ├── fragments/
│   │   └── navbar.html
│   ├── pages/
│   │   ├── accueil.html
│   │   └── produits.html
│   └── layout.html
└── manage.py

5.1.1. La configuration : config/settings.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# config/settings.py : la configuration de l'exemple 22

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent.parent
DEBUG = True
SECRET_KEY = "django-insecure-e%uqntr!nz5i2w(d^_-cwr6w=w^2z^mx6vpvpgsg91qvp)bnzl"
ALLOWED_HOSTS = []
TIME_ZONE = "Europe/Paris"
ROOT_URLCONF = "config.urls"
WSGI_APPLICATION = "config.wsgi.application"

# la langue par défaut, et les langues gérées par l'application
LANGUAGE_CODE = "fr"
LANGUAGES = [
    ("fr", "Français"),
    ("en", "English"),
]
# les dossiers des DICTIONNAIRES de l'application (fichiers .po, compilés en .mo)
LOCALE_PATHS = [BASE_DIR / "locale"]
# le cookie qui mémorise la langue choisie (c'est aussi le nom par défaut)
LANGUAGE_COOKIE_NAME = "django_language"

INSTALLED_APPS = [
    "django.contrib.staticfiles",
    "pages",
]

MIDDLEWARE = [
    # LocaleMiddleware : la langue de chaque requête, lue dans le cookie de la langue,
    # à défaut dans l'entête Accept-Language du navigateur, à défaut LANGUAGE_CODE
    "django.middleware.locale.LocaleMiddleware",
]

TEMPLATES = [
    {
        "BACKEND": "django.template.backends.django.DjangoTemplates",
        "DIRS": [BASE_DIR / "templates"],
        "OPTIONS": {
            "context_processors": [
                "django.template.context_processors.request",
                # la variable LANGUAGE_CODE : la langue de la requête
                "django.template.context_processors.i18n",
            ],
        },
    },
]

STATIC_URL = "static/"
STATICFILES_DIRS = [
    BASE_DIR / "static",
    BASE_DIR.parent / "commun" / "static",
]
  • ligne 14 : la langue par défaut de l'application, celle d'une requête qui n'en précise pas (exemple 08). C'est aussi la langue des textes des gabarits : le français n'a donc pas besoin de dictionnaire ;
  • lignes 15-18 : les langues que gère l'application ;
  • ligne 20 : [LOCALE_PATHS], les dossiers où [Django] cherche les dictionnaires de l'application, en plus des dossiers [locale] de chaque application (dont ceux de [Django] lui-même). Chaque dictionnaire est rangé dans un dossier [<langue>/LC_MESSAGES], sous le nom [django.po] (et [django.mo]) : c'est l'organisation que demande [gettext] ;
  • ligne 22 : le nom du cookie qui mémorise la langue choisie. [django_language] est la valeur par défaut ; nous l'écrivons pour qu'elle soit visible ;
  • lignes 29-33 : le middleware [LocaleMiddleware] de [Django] remplace notre middleware [FixerLangue] de l'exemple 16. Pour chaque requête, il choisit la langue, parmi celles du réglage [LANGUAGES] : celle du cookie de la langue s'il en existe un ; à défaut, celle que préfère le navigateur, d'après l'entête [Accept-Language] (exemple 12) ; à défaut, [LANGUAGE_CODE]. Il l'active ([translation.activate], exemple 16), et la range dans [request.LANGUAGE_CODE]. Il ajoute enfin à la réponse l'entête [Content-Language] (la langue de la page), et l'entête [Vary: Accept-Language], qui prévient les caches que la réponse dépend de cet entête ;
  • ligne 43 : le processeur de contexte [i18n] ajoute aux gabarits les variables [LANGUAGE_CODE] (la langue de la requête), [LANGUAGES] et [LANGUAGE_BIDI] (vrai pour une langue qui s'écrit de droite à gauche).

5.1.2. Le dictionnaire : locale/en/LC_MESSAGES/django.po

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
# locale/en/LC_MESSAGES/django.po : le dictionnaire anglais de l'exemple 22.
# msgid : le texte d'origine, tel qu'il est écrit dans les gabarits (en français) ;
# msgstr : sa traduction. Ce fichier est compilé en django.mo (le fichier que lit
# Django) par la commande : python manage.py compilemessages
msgid ""
msgstr ""
"Language: en\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

#: templates/fragments/navbar.html:6
msgid "Accueil"
msgstr "Home"

#: templates/fragments/navbar.html:7
msgid "Produits"
msgstr "Products"

#: templates/pages/accueil.html:4 templates/pages/accueil.html:7
msgid "Bienvenue"
msgstr "Welcome"

#: templates/pages/accueil.html:9
#, python-format
msgid "Bonjour %(nom)s !"
msgstr "Hello %(nom)s!"

#: templates/pages/accueil.html:11
#, python-format
msgid "Nous sommes le %(date)s."
msgstr "Today is %(date)s."

#: templates/pages/produits.html:4 templates/pages/produits.html:7
msgid "Nos produits"
msgstr "Our products"

#: templates/pages/produits.html:9
msgid "Produit"
msgstr "Product"

#: templates/pages/produits.html:9
msgid "Prix"
msgstr "Price"

#: templates/pages/produits.html:21
#, python-format
msgid "%(n)s produit au catalogue."
msgid_plural "%(n)s produits au catalogue."
msgstr[0] "%(n)s product in the catalogue."
msgstr[1] "%(n)s products in the catalogue."

Un fichier [.po] est une suite d'entrées, séparées par des lignes vides :

  • lignes 1-4 : un commentaire ;
  • lignes 5-11 : l'entrée d'en-tête : un texte vide ([msgid ""]), dont la « traduction » ([msgstr]) contient les informations du dictionnaire : la langue, le jeu de caractères, et la règle du pluriel de la langue ([Plural-Forms] : en anglais, deux formes, la seconde pour tout nombre différent de 1) ;
  • lignes 13-15 : une entrée ordinaire : [msgid] est le texte d'origine, tel qu'il est écrit dans le gabarit ; [msgstr] sa traduction. La ligne [#:] indique où le texte a été trouvé (un gabarit et une ligne) : c'est un commentaire, pour le traducteur ;
  • lignes 25-28 : un texte qui contient une variable. Dans le dictionnaire, une variable s'écrit [%(nom)s] (la syntaxe des chaînes de format de [Python], exemple 10) ; la ligne [#, python-format] le signale aux outils. La traduction peut déplacer la variable, ou changer la ponctuation qui l'entoure (le point d'exclamation n'est pas précédé d'une espace en anglais) ;
  • lignes 47-52 : un texte au pluriel : [msgid] est la forme au singulier, [msgid_plural] la forme au pluriel, et chaque forme de la traduction est numérotée ([msgstr[0]], [msgstr[1]]), dans l'ordre que fixe la règle [Plural-Forms]. En français, 0 et 1 sont au singulier, alors qu'en anglais 0 est au pluriel (« 0 products ») : [gettext] le sait, grâce à cette règle. C'est un progrès sur le « produit(s) » des versions précédentes de l'étude de cas.

On n'écrit pas ce fichier à la main. La commande :

1
python manage.py makemessages -l en

parcourt les gabarits et le code [Python] du projet, en extrait tous les textes marqués « à traduire », et crée ou met à jour le fichier [locale/en/LC_MESSAGES/django.po] : les nouveaux textes y sont ajoutés, avec une traduction vide, et les traductions déjà faites sont conservées. Il ne reste qu'à écrire les traductions, dans un éditeur de texte, ou dans un logiciel spécialisé ([Poedit], par exemple). La commande :

1
python manage.py compilemessages

compile ensuite chaque fichier [.po] en un fichier [.mo], binaire, rapide à lire, qui est celui que [Django] utilise. Il faut relancer le serveur après une compilation : les dictionnaires sont chargés une fois pour toutes. Ces deux commandes utilisent les programmes de [gettext] ([xgettext], [msgfmt]...), qu'il faut avoir installés (sous [Linux], le paquet [gettext] ; sous [Windows], par exemple les binaires distribués sur le site mlocati.github.io). Le fichier [django.mo] étant fourni avec l'exemple, il n'est pas nécessaire de les installer pour l'exécuter.

5.1.3. Le choix de la langue : les routes et les vues

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# config/urls.py : la table de routage principale

from django.urls import path, re_path

from pages import views

urlpatterns = [
    path("", views.accueil, name="accueil"),
    path("produits", views.produits, name="produits"),
    # re_path : une route décrite par une expression régulière ; une autre langue
    # que fr ou en ne correspond pas à la route (404)
    re_path(r"^langue/(?P<code>fr|en)$", views.changer_langue, name="langue"),
]
  • ligne 12 : [re_path] décrit une route par une expression régulière, plutôt que par la syntaxe de [path] (exemple 02). [^] et [$] marquent le début et la fin du chemin ; [(?P<code>fr|en)] est un groupe nommé : le texte qu'il reconnaît, [fr] ou [en] (la barre verticale signifie « ou »), est passé à la vue dans le paramètre [code]. Une autre langue ne correspond à aucune route : [/langue/de] donne une erreur 404.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
# pages/views.py : les vues ne savent rien de la langue : elles fournissent des
# données, les gabarits les traduisent et les mettent en forme

from datetime import date

from django.conf import settings
from django.shortcuts import redirect, render
from django.utils.http import url_has_allowed_host_and_scheme
from django.views.decorators.http import require_GET

from .modeles import Produit


@require_GET
def accueil(request):
    return render(request, "pages/accueil.html", {"nom": "Marie", "aujourdhui": date(2026, 9, 23)})


@require_GET
def produits(request):
    return render(request, "pages/produits.html", {"produits": [
        Produit("Clavier", 2500),
        Produit("Souris", 1250),
        Produit("Écran", 114900),
    ]})


# GET /langue/en : mémorise le choix dans le cookie de la langue, puis revient à la
# page précédente
@require_GET
def changer_langue(request, code):
    reponse = redirect(page_d_origine(request))
    # le cookie : un an de vie, illisible par le JavaScript de la page (httponly),
    # jamais envoyé avec une requête POST venue d'un autre site (samesite Lax)
    reponse.set_cookie(settings.LANGUAGE_COOKIE_NAME, code, max_age=365 * 24 * 3600,
                       httponly=True, samesite="Lax")
    return reponse


# la page d'où l'on vient (entête Referer), si elle appartient à CE site : rediriger
# vers une adresse quelconque venue de la requête permettrait d'envoyer
# l'utilisateur sur un autre site (faille "open redirect")
def page_d_origine(request):
    referer = request.headers.get("Referer", "")
    # url_has_allowed_host_and_scheme : vrai pour une adresse relative, ou une adresse
    # absolue dont la machine est celle de la requête
    if url_has_allowed_host_and_scheme(referer, allowed_hosts={request.get_host()}):
        return referer
    return "/"
  • lignes 14-25 : les vues de l'accueil et des produits ne savent rien de la langue : elles fournissent des données brutes (un nom, une date, des montants en centimes). La traduction et la mise en forme sont l'affaire des gabarits. La classe [Produit] a un nom et un prix en centimes ; la bibliothèque [formats] est celle de l'exemple 16 : son filtre [date_longue] écrit une date au format « complet » de la langue active (« mercredi 23 septembre 2026 », « Wednesday, September 23, 2026 »), et son filtre [monnaie] un montant ;
  • lignes 30-37 : la vue du changement de langue répond par une redirection vers la page d'où vient l'utilisateur : celui-ci retrouve sa page, dans la nouvelle langue ;
  • lignes 35-36 : la réponse porte un cookie, que le navigateur renverra à chaque requête. [set_cookie] reçoit son nom, sa valeur, et ses options : [max_age], sa durée de vie en secondes (un an) ; [httponly=True] le rend invisible au [JavaScript] de la page ; [samesite="Lax"] interdit au navigateur de l'envoyer avec une requête POST venue d'un autre site. Il est ajouté à la réponse sous la forme d'un entête [Set-Cookie] ;
  • lignes 43-49 : la page d'origine est donnée par l'entête [Referer] de la requête (l'orthographe fautive, avec un seul [r], est celle de la norme HTTP), que le navigateur remplit avec l'URL de la page qui contenait le lien. Mais cet entête vient du client, qui peut y mettre n'importe quoi. Rediriger aveuglément vers cette adresse ferait de notre application un redirecteur ouvert (open redirect) : un lien piégé, qui porte notre nom de domaine, pourrait envoyer l'utilisateur sur un site malveillant. La fonction [url_has_allowed_host_and_scheme] de [Django] ([django.utils.http]) vérifie qu'une adresse est relative, ou qu'elle désigne l'une des machines permises (ici, celle de la requête : [request.get_host()]) ; sinon, on revient à l'accueil.

[Django] fournit d'ailleurs une vue toute faite pour changer de langue, [django.views.i18n.set_language], qui fait le même travail à partir d'un formulaire POST ; nous avons écrit la nôtre pour la montrer, et pour changer de langue par un simple lien.

5.1.4. Traduire dans les gabarits

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
<!doctype html>
{% load static %}
{# LANGUAGE_CODE : la langue de la requête, "fr" ou "en" #}
<html lang="{{ LANGUAGE_CODE }}">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  {# le titre : le bloc [titre] de la page, déjà traduit #}
  <title>{% block titre %}{% endblock %}</title>
  <link rel="stylesheet" href="{% static 'bootstrap/css/bootstrap.min.css' %}">
  <link rel="stylesheet" href="{% static 'css/styles.css' %}">
</head>
<body>
  <div class="container py-3">
    {% include "fragments/navbar.html" %}
    <main>
      {% block contenu %}{% endblock %}
    </main>
  </div>
</body>
</html>
  • ligne 4 : l'attribut [lang] de la page indique sa langue aux navigateurs, aux moteurs de recherche et aux lecteurs d'écran ; [LANGUAGE_CODE] est la langue de la requête, fournie par le processeur de contexte [i18n] ;
  • ligne 9 : le titre de la page est fourni par la page elle-même, déjà traduit (bloc [titre]).
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
{# i18n : la bibliothèque des balises de traduction #}
{% load i18n %}
<nav class="navbar navbar-expand bg-light rounded mb-3 px-3">
  <div class="navbar-nav me-auto">
    {# translate : la traduction d'un texte, dans la langue de la requête #}
    <a class="nav-link" href="{% url 'accueil' %}">{% translate "Accueil" %}</a>
    <a class="nav-link" href="{% url 'produits' %}">{% translate "Produits" %}</a>
  </div>
  {# get_available_languages : les langues du réglage LANGUAGES, des couples (code, nom) #}
  {% get_available_languages as langues %}
  <div class="btn-group btn-group-sm">
    {% for code, nom in langues %}
      {# la langue courante est mise en évidence #}
      <a class="btn {% if code == LANGUAGE_CODE %}btn-primary{% else %}btn-outline-primary{% endif %}"
         href="{% url 'langue' code %}" title="{{ nom }}">{{ code|upper }}</a>
    {% endfor %}
  </div>
</nav>
  • ligne 2 : les balises de traduction sont dans la bibliothèque [i18n], que chaque gabarit doit charger (exemple 16) ;
  • lignes 6-7 : la balise [{% translate %}] rend la traduction d'un texte, dans la langue de la requête (ou le texte lui-même, s'il n'a pas de traduction) ;
  • lignes 10-17 : la balise [{% get_available_languages %}] range dans une variable les langues du réglage [LANGUAGES], des couples (code, nom), que la boucle décompose ([for code, nom in langues]). Un bouton par langue, qui mène à la vue [/langue/<code>]. La langue courante est mise en évidence ([btn-primary], bouton plein).
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
{% extends "layout.html" %}
{% load i18n formats %}

{% block titre %}{% translate "Bienvenue" %}{% endblock %}

{% block contenu %}
  <h1>{% translate "Bienvenue" %}</h1>
  {# blocktranslate : un texte qui contient des variables {{ nom }} #}
  <p>{% blocktranslate %}Bonjour {{ nom }} !{% endblocktranslate %}</p>
  {# with : la date, mise en forme d'abord (filtre date_longue, cf. exemple 16), puis insérée dans le texte #}
  <p>{% blocktranslate with date=aujourdhui|date_longue %}Nous sommes le {{ date }}.{% endblocktranslate %}</p>
{% endblock %}
  • ligne 4 : le bloc [titre], traduit, pour le gabarit parent ;
  • ligne 9 : la balise [{% blocktranslate %}] traduit un texte qui contient des variables : [{{ nom }}] y devient [%(nom)s] dans le dictionnaire. Seules des variables simples y sont permises (ni filtre, ni point) ;
  • ligne 11 : une variable calculée ne peut donc entrer dans le texte que par [with] : la date, mise en forme dans la langue de la requête par le filtre [date_longue], est rangée dans la variable [date] du texte.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
{% extends "layout.html" %}
{% load i18n formats %}

{% block titre %}{% translate "Nos produits" %}{% endblock %}

{% block contenu %}
  <h1>{% translate "Nos produits" %}</h1>
  <table class="table table-sm w-auto">
    <thead><tr><th>{% translate "Produit" %}</th><th class="text-end">{% translate "Prix" %}</th></tr></thead>
    <tbody>
      {% for produit in produits %}
        <tr>
          <td>{{ produit.nom }}</td>
          {# le filtre monnaie de l'exemple 16 : le format dépend de la langue #}
          <td class="text-end">{{ produit.prix_centimes|monnaie }}</td>
        </tr>
      {% endfor %}
    </tbody>
  </table>
  {# le pluriel : count choisit la forme d'après le nombre n ; plural sépare les formes #}
  <p>{% blocktranslate count n=produits|length %}{{ n }} produit au catalogue.{% plural %}{{ n }} produits au catalogue.{% endblocktranslate %}</p>
{% endblock %}
  • ligne 15 : le filtre [monnaie], dont le résultat dépend de la langue ;
  • ligne 21 : le pluriel. [count n=produits|length] donne le nombre qui choisit la forme ([length], exemple 14) ; la balise [{% plural %}] sépare la forme au singulier de la forme au pluriel, écrites dans la langue d'origine. Les noms des produits, eux, ne sont pas traduits : ce sont des données, qui, dans une vraie application, viendraient d'une base de données.

Hors des gabarits, on traduit par les fonctions du module [django.utils.translation] : [gettext("Accueil")] (souvent importée sous le nom court [_] : [_("Accueil")]), [ngettext] pour le pluriel, et [gettext_lazy], une traduction « paresseuse », faite seulement au moment où le texte est utilisé : c'est celle qu'il faut pour un texte défini au chargement d'un module (le libellé d'un champ de formulaire, par exemple), quand la langue de la requête n'est pas encore connue. L'étude de cas l'utilise.

5.1.5. Exécution

La page d'accueil, en français (la langue par défaut), puis en anglais après un clic sur le bouton « EN » :

Image

Image

La page des produits, dans les deux langues. Les montants suivent les conventions de chaque langue :

Image

Image

Le changement de langue, observé avec [curl]. L'option [-H] fournit l'entête [Referer] qu'enverrait le navigateur :

1
curl -i -H "Referer: http://localhost:8000/produits" http://localhost:8000/langue/en

1
2
3
4
5
6
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: http://localhost:8000/produits
Vary: Accept-Language
Content-Language: fr
Set-Cookie: django_language=en; expires=Mon, 27 Sep 2027 17:37:43 GMT; HttpOnly; Max-Age=31536000; Path=/; SameSite=Lax

La redirection ramène à la page d'origine, et le cookie est déposé pour un an. La réponse elle-même est encore en français ([Content-Language: fr]) : la langue n'a été choisie qu'à l'arrivée de la requête, avant que le cookie n'existe. Un [Referer] qui désigne un autre site ne permet pas d'y être redirigé :

1
curl -i -H "Referer: https://pirate.example/piege" http://localhost:8000/langue/en

1
2
3
4
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /
...

L'utilisateur revient à l'accueil, et reste chez nous. Enfin, la page d'accueil, demandée avec le cookie [django_language=en] (option [-b] de [curl]) :

1
curl -b "django_language=en" http://localhost:8000/

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
<!doctype html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Welcome</title>
...
    <a class="nav-link" href="/">Home</a>
    <a class="nav-link" href="/produits">Products</a>
...
  <h1>Welcome</h1>
  <p>Hello Marie!</p>
  <p>Today is Wednesday, September 23, 2026.</p>
...

Le cookie n'est pas signé : il circule en clair, et l'utilisateur peut le modifier. Ce n'est pas un problème : il ne contient rien de secret, et [LocaleMiddleware] n'accepte que les langues du réglage [LANGUAGES]. L'exemple suivant revient sur la confiance qu'on peut accorder à un cookie. Sans cookie, [LocaleMiddleware] lit l'entête [Accept-Language] du navigateur : [curl -H "Accept-Language: en-US,en;q=0.9" http://localhost:8000/] rend la page en anglais. Les deux mécanismes se combinent ainsi naturellement : la langue du navigateur à la première visite, puis celle que l'utilisateur a choisie. Une troisième façon, fréquente, place la langue dans l'URL ([/en/produits]) : la fonction [i18n_patterns] de [Django] préfixe alors les routes par la langue, et [LocaleMiddleware] la lit dans le chemin. L'étude de cas s'en tient au cookie.

https://stahe.github.io
Ce tutoriel, rédigé par l’IA d’Anthropic Claude à la demande de Serge Tahé, est mis à la disposition du public selon les termes de la licence Creative Commons Attribution – Pas d’utilisation commerciale – ShareAlike 3.0 Unported.