Distribution EOLE » Modules » Scribe » eole-sympa

Le contexte semble assez différent de ce qui est observable sur les VM de test. Voici les différences :
- la variable "date" n’est pas renseignée via la création de liste dans l’EAD2 ou l’interface de sympa ;
- le script traite le fichier modifié manuellement avec la variable "date" sans erreur.

Si la variable "date" contient 06 "f<E9>vr. 2020 at 09:38:21" et non "06 févr. 2020 at 09:38:21", il semble y avoir un problème d’encodage dans l’outil d’édition du fichier ou dans l’outil d’affichage. Si il y a un problème avec l’outil d’édition du fichier, il faudrait s’assurer que ce n’est pas un outil "externe" (hors EAD2 et interface sympa). Les outils "internes" ne devraient pas avoir de problème d’édition de l’UTF-8.

À ce stade, la seule suggestion qui vient à l’esprit est de renseigner explicitement l’encodage pour l’ouverture des fichiers "config" : ligne 93, la fonction open() peut prendre en argument encoding="utf-8".
Cela donne la ligne suivante :

            with open(configuration, 'r', encoding="utf-8") as conf_fh: 

Bonjour Benjamin,

Je ne pense pas que les fichiers aient été édités en externe vu que l'erreur est présente sur plusieurs établissements.
Peu probable aussi que ce soit avec l'interface web de Sympa.

Ces données date de 2020, à l'époque Scribe 2.6 probablement. Ensuite, migrations, réinstallations, restaurations...

Ce qui est curieux, c'est que le problème se produise maintenant.

Je peux tester cette modification si tu veux.

Bonjour Laurent,

Peux-tu nous transmettre le résultat de la commande "locale" sur un des serveur qui a le problème stp ?

Vu que la lecture des fichiers avec des accents ne pose pas de problème, l’ajout de l’encodage est probablement un coup dans l’eau mais ce serait dommage de ne pas tester.

Vu que le champ "date" n’apparaît pas dans les fichiers sur les VM de test, on peut réfléchir à les supprimer lors du traitement. Il devrait être possible de les réécrire également puisque c’est la même information que le champ "date_epoch".

Il faudrait tout de même trouver la procédure qui créé ce champ "date" et intervenir au bon endroit dans le code si possible. Si c’est une procédure qui n’est plus utilisée (datant des 2.6), le nettoyage semble une bonne option à ce stade de compréhension du problème.

locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="fr_FR.UTF-8" 
LC_NUMERIC="fr_FR.UTF-8" 
LC_TIME="fr_FR.UTF-8" 
LC_COLLATE="fr_FR.UTF-8" 
LC_MONETARY="fr_FR.UTF-8" 
LC_MESSAGES="fr_FR.UTF-8" 
LC_PAPER="fr_FR.UTF-8" 
LC_NAME="fr_FR.UTF-8" 
LC_ADDRESS="fr_FR.UTF-8" 
LC_TELEPHONE="fr_FR.UTF-8" 
LC_MEASUREMENT="fr_FR.UTF-8" 
LC_IDENTIFICATION="fr_FR.UTF-8" 
LC_ALL=fr_FR.UTF-8

Problème d'encodage, certains fichiers sont en ISO-8855-15.
Comme le problème n'est apparu qu'à la Réunion, solution recommandée : convertir les fichiers en utf-8.