i18n/l10n

La localisation (l10n) et l’internationalization (i18n) sont deux concepts proches, mais différents :

Internationalisation: Preparing the software for localization. Usually done by developers. Il s’agit de la préparation d’une application à gérer plusieurs langues.
Localisation: Writing the translations and local formats. Usually done by translators., qui consiste à utiliser l’internationalisation pour supporter une ou plusieurs langues spécifiques.

L’internationalisation est donc le processus permettant à une application d’accepter une forme de localisation. La seconde ne va donc pas sans la première, tandis que la première ne fait qu’autoriser la seconde.

https://medium.com/@sakhawy/multilingual-support-in-django-5706e1e144a8

`i18n_patterns()`

La clé des traductions se trouve au niveau des fichiers urls() que nous avons déjà analysés précédemment : cette clé est injectée grâce à la fonction i18n_patterns(), que nous trouvons dans le module django.conf.urls.i18n. Cette fonction suffixe l’URL de votre application par le code de la langue (en, fr, ar, …) :

from django.conf.urls.i18n import i18n_patterns
from django.urls import include, path


urlpatterns = i18n_patterns( <1>
    path('', include('gwift.urls')),
)

<1> Plutôt que d’utiliser la fonction path(), nous utilisons ici la fonction i18n_patterns()

Par défaut, le langage qui sera appliqué comme traduction sera celui défini au niveau de la configuration générale de l’application (settings.py), dans la variable LANGUAGE_CODE.

Un middleware (((Middleware))) s’occupe, sur base de l’entête HTTP Accept-Language, de définir le langage par défaut à servir à l’utilisateur. Il y a donc assez peu de choses à faire pour qu’une application soit proprement configurée :

Utiliser la fonction de traduction au niveau des URLs,
Traduire l’application footnote:[Et j’admets que cette deuxième étape peut être plus ardue que prévu.].