Les caratères spéciaux ne passent pas quand on importe un fichier dans admin django

[nfavrod]

Dans l'administration django , lorsque qu'on importe un fichier de données comme : electronics_categories_FR.json

Il y a des soucis d'encodage

[Skrattoune]

coucou,

comme je te disais, j'ai commencé à analyser ce problème ce matin

Ils ont choisi d'utiliser l'appli https://github.com/django-import-export/django-import-export/
pour l'exportation des tables à travers l'admin.
doc: https://django-import-export.readthedocs.io/en/latest/

en parcourant les issues, je n'ai pas trouvé de réponse directe, mais juste une piste lié à un paramètre d'environement qui pourrait manquer dans notre config, mais dont je n'ai pas trouvé mention ni dans les réglages de openrepairplatform, ni de django-import-export:

https://user-images.githubusercontent.com/20482413/104337386-bb3d2780-54f5-11eb-97ca-4493b56ea53b.png
django-import-export/django-import-export#1141

Il serait intéressant de voir si sur leur machine de prod, ils ont aussi le problème lors de l'importation de fichiers exportés,
sachant que le fichier exporté chez nous semble a priori ok:

UTF-8, avec les accents

[Skrattoune]

Un idée si on n'arrive pas à avoir Lucien ou Clément à exporter/importer chez eux pour voir si ils ont ou pas le pb
serait d'ouvrir une issue directement chez https://github.com/django-import-export/django-import-export/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc

[nfavrod]

Alors - en encodant le fichier en ISO_LATIN_1 le fichier s'importe correctement.

Voici 2 csv, celui en UTF-8 ne fonctionne pas l'autre oui.

electronics_categories_FR_ISO_latin_1.csv
electronics_categories_FR.csv

@Skrattoune : on peut mettre des tag sur cette issue en : "Stand-By", ou "Ask Clément" - "Have a workaround" ?

[nfavrod]

Voici la preuve que ça fonctionne :-)

[Skrattoune]

@nfavrod
Bon, je pense que j'ai trouvé la source de nos problèmes (lié à #20):

quand on initialise les machines virtuelles, il y a cette série de messages qui montre qu'il y a un problème avec nos variables serveur:

Step 10/27 : RUN sed -i -e 's/# fr_FR.UTF-8 UTF-8/fr_FR.UTF-8 UTF-8/' /etc/locale.gen &&     locale-gen
 ---> Using cache
 ---> 46e2f87224ab
Step 11/27 : ENV LC_ALL fr_FR
 ---> Using cache
 ---> e0c033766241
Step 12/27 : ENV LANG fr_FR
 ---> Using cache
 ---> 5f274c87ba29
Step 13/27 : ENV LANGUAGE fr_FR

on ne devrait jamais avoir référence à fr_FR, mais toujour fr_CH
donc il y a une variable globale qui est mal configurée.

Tu peux jetter un coup d'oeil stp ?

pour référence: https://www.localeplanet.com/icu/fr-CH/index.html

[Skrattoune]

bon ... j'ai trouvé et je patche deployment\django\Dockerfile dans lequel il y a apparement les déclarations de variables d'environnement:

# SwissFrench ENV for date
RUN sed -i -e 's/# fr_CH.UTF-8 UTF-8/fr_CH.UTF-8 UTF-8/' /etc/locale.gen && \
    locale-gen
ENV LC_ALL fr_CH
ENV LANG fr_CH
ENV LANGUAGE fr_CH

Par contre, on ne devrait déclarer fr_CH qu'une seule fois ... pas 5 fois !

• Nico: paramétrer le fichier deployment\django\Dockerfile

ARG !!!!!!!!!!!!!

par contre je viens de découvrir en explorant un peu les fichiers que le fichier deployment\django\openrepairplatform.cron n'est quasiment pas paramétré non plus !

* * * * * openrepairplatform cd /srv/app && LANG=fr_CH.UTF-8 EMAIL_PASSWORD={{EMAIL_PASSWORD}} SECRET_KEY={{SECRET_KEY}} DJANGO_SETTINGS_MODULE=openrepairplatform.settings.prod /usr/local/bin/python3 manage.py publish_events > /tmp/log_publish_events 2>&1
0 16 * * * openrepairplatform cd /srv/app && LANG=fr_CH.UTF-8 EMAIL_PASSWORD={{EMAIL_PASSWORD}} SECRET_KEY={{SECRET_KEY}} DJANGO_SETTINGS_MODULE=openrepairplatform.settings.prod /usr/local/bin/python3 manage.py notify_next_day_events https://reparons.org > /tmp/log_nextday_events 2>&1
# 0 22 * * * openrepairplatform cd /srv/app && LANG=fr_CH.UTF-8 EMAIL_PASSWORD={{EMAIL_PASSWORD}} SECRET_KEY={{SECRET_KEY}} DJANGO_SETTINGS_MODULE=openrepairplatform.settings.prod /usr/local/bin/python3  manage.py clean_inactive_users > /tmp/clean_users 2>&1
# empty line

le fr_CH est à nouveau hardcodé, ainsi que le nom du domaine !
il faudrait aussi le définir une seule fois dans les paramètres d'environnement, puis juste y faire reférence

C'est super error-prone !

• Nico: définir nom domaine dans paramètres d'environnement

• Nico: paramétrer deployment\django\openrepairplatform.cron

par contre, dans le fichier deployment\nginx\templates\nginx.conf.template, DOMAIN est parametrisé !

et de plus le setting de prod de django fait aussi appel à ce paramètre :
ALLOWED_HOSTS = [ os.getenv("DOMAINS"), ]

[Skrattoune]

J'ai fait le tour des fichiers, ce sont les seules mentions de reparons
Par contre, plein de mention de atelier-soude et ateliersoude

Je traite dans l'issue #1

[nfavrod]

J'ai fait le tour des fichiers, ce sont les seules mentions de reparons
Par contre, plein de mention de atelier-soude et ateliersoude

Je traite dans l'issue #1

@Skrattoune : fais une nouvelle issue non ?

[Skrattoune]

Bon, j'ai trouvé une nouvelle piste qui a l'air plus directement en lien avec notre problème:
le module utilisé pour l'import/export déclare dans ses classes des variables de classe:
to_encoding = "utf-8"
et
from_encoding= "utf-8"

• changer valeurs to_encoding et from_encoding dans les modules admin concernés
• verifier ce que le sed de deployment\django\Dockerfile fait et corriger en fonction

[Skrattoune]

essai avec:

to_encoding = 'ISO_LATIN_1'
from_encoding='ISO_LATIN_1'

"iso-8859-1" est sans doute le code pour 'ISO_LATIN_1'

[Skrattoune]

Aucun changement losrque Nico a essayé avec :

to_encoding = 'ISO_LATIN_1'
from_encoding='ISO_LATIN_1'

nouveau commit avec "iso-8859-1"

• a tester sur machine

• regarder messages lors du relaunch

[Skrattoune]

OK, j'ai trouvé une piste sérieuse: https://forum.ubuntu-fr.org/viewtopic.php?id=1479671

• essayer de voir dans le système si la langue suisse est installée (voir lien ci-dessus) et si besoin instALLER LE PACK DE LANGUE
• [ ]