Traduire une application Django en italien

Ce que l’italien change dans les chaînes d’une application Django

L’italien s’écrit en alphabet latin, de gauche à droite, avec une longueur proche du français. Vos gabarits ne devraient donc pas déborder comme avec l’allemand, mais un bouton calibré pour l’anglais peut se révéler étroit : Settings devient Impostazioni, Sign up devient Registrati ou Registrazione.

Trois points demandent de l’attention :

• Le registre. Une interface professionnelle s’adresse à l’utilisateur au Lei : Inserisca la password, La preghiamo di riprovare. Les libellés de boutons très courts (Salva, Annulla, Elimina) sont des formes figées que l’on conserve même dans une interface au Lei. Mélanger Inserisci et Inserisca d’un écran à l’autre est l’incohérence la plus visible.
• Les accents. è, perché, più, città. La majuscule s’écrit È, pas E’ : une phrase comme « È necessario accedere » doit garder son accent. Le fichier doit être en UTF-8, ce que déclare l’en-tête Content-Type: text/plain; charset=UTF-8 généré par Django.
• Le genre et l’élision autour des variables. « Bienvenue, %(name)s » ne se traduit pas sans risque par Benvenuto, %(name)s, qui suppose un homme. Une tournure neutre comme Le diamo il benvenuto, %(name)s évite le problème. De même, un article devant une variable (dell’%(app)s ou della %(app)s ?) dépend du mot qui sera inséré : mieux vaut écrire nell’applicazione %(app)s.

Pluriels : msgid_plural, Plural-Forms et le cas de « many »

Les chaînes passées par ngettext ou la balise {% blocktranslate count %} apparaissent dans le .po avec un msgid_plural et plusieurs msgstr[n]. Le nombre de formes attendu est fixé par l’en-tête Plural-Forms du fichier.

Le référentiel CLDR distingue pour l’italien trois catégories : one, many et other. La catégorie many concerne les grands nombres ronds, qui prennent la préposition di : 1 messaggio, 5 messaggi, mais 1 milione di messaggi. Selon la version des outils gettext ou de Django, votre en-tête peut annoncer deux ou trois formes : ce qui compte, c’est que chaque entrée plurielle ait exactement autant de msgstr[n] que l’en-tête l’indique, sinon compilemessages signalera une erreur.

Deux pièges propres à l’italien :

• Zéro prend le pluriel : 0 messaggi, comme en anglais et contrairement au français.
• Certains noms sont invariables : 1 file, 3 file ; 1 città, 2 città. Les deux formes sont alors identiques, ce n’est pas une erreur.

Ce que Manuce rend, et ce qu’il ne fait pas

Vous récupérez le même fichier .po, prêt à remettre dans locale/it/LC_MESSAGES/ : indentation, ordre des entrées, guillemets, commentaires (y compris les lignes # Translators: et les références #: templates/…), fins de ligne, encodage et BOM sont conservés. Seules les valeurs changent. L’en-tête, dont Plural-Forms, reste celui de votre fichier.

• Les variables %(name)s, %(count)d et {name} sont vérifiées : chaque valeur traduite est comparée à la source, variables et balises comprises. Si un écart persiste, la valeur source est gardée et le rapport le signale.
• Ne sont pas traduits : les clés (msgid), les valeurs vides, les URL, les adresses email, les nombres, les couleurs, les formats de date, les identifiants et tout ce que vous avez marqué non traduisible.
• Le rapport liste les chaînes traduites et celles laissées telles quelles, avec la raison.

Manuce ne lance pas makemessages ni compilemessages à votre place et ne touche pas à votre code ni à settings.py. Il ne fournit pas non plus de traduction assermentée : si vos conditions générales en italien doivent être certifiées, il faut passer par un traducteur expert. Le prix porte sur les mots des valeurs, clés et balises exclues.

Dates, nombres et chaînes écrites en dur

L’italien écrit 1.234,56 et 3 marzo 2025, avec les mois en minuscules. Django applique ses propres formats italiens aux dates et aux nombres affichés par ses filtres comme {{ value|date }} ou par localize : ces valeurs ne passent pas par le .po et Manuce n’y touche pas.

Le piège vient des chaînes qui embarquent un format : _("Updated on %(date)s") est correct, alors que _("Updated on March 3") fige une date anglaise dans le catalogue. De même, une chaîne qui concatène deux morceaux traduits séparément (_("You have") + " " + str(n) + " " + _("items")) ne pourra jamais donner un italien correct, puisque l’accord et l’ordre des mots changent. Réécrivez-la en une seule chaîne avec variable et ngettext avant d’extraire.

Préparer le fichier et vérifier le résultat

Avant de déposer le fichier :

• Lancez python manage.py makemessages -l it, et -d djangojs si vos scripts utilisent gettext côté JavaScript : vous obtiendrez aussi un djangojs.po à traduire.
• Ajoutez du contexte aux mots ambigus avec pgettext : « Open » (état ou action ?) devient Aperto ou Apri. Le contexte apparaît en msgctxt dans le .po.
• Indiquez dans un commentaire # Translators: les chaînes qui ne doivent pas être traduites (nom de produit, code).

Après livraison :

• Lisez le rapport et traitez les chaînes restées en source.
• Les entrées marquées #, fuzzy par makemessages restent marquées, car les commentaires sont conservés ; compilemessages les ignore. Retirez le marqueur une fois la traduction vérifiée.
• Lancez compilemessages, activez l’italien et parcourez les écrans clés : vérifiez la cohérence du Lei, les accords autour des variables et la largeur des boutons.

En pratique

1. Générez le catalogue avec makemessages -l it (et -d djangojs si besoin).
2. Déposez locale/it/LC_MESSAGES/django.po : devis immédiat et extrait gratuit avant de payer.
3. Téléchargez le .po traduit et lisez le rapport des chaînes laissées en source.
4. Retirez les marqueurs fuzzy vérifiés, lancez compilemessages et testez l’interface en italien.