Environnement de traduction pour VSCode avec devcontainer

[ezlo-picori]

Suite à ma première participation à la documentation (#1809), j'ai configuré un devcontainer qui me permet d'automatiser toute la mise en place de l'environnement de traduction, directement dans un conteneur docker auquel se branche VS Code.

Je ne sais pas du tout si ça peut intéresser la communauté en général donc ce pull-request est surtout une base de discussion pour le moment. Je pourrai faire une démonstration de cet environnement lors de la prochaine soirée de traduction si vous le souhaitez.

Si vous voulez tester ça, il vous suffit d'installer docker desktop et VS Code, puis d'effectuer l'action Clone repository in container volume... en spécifiant comme dépôt https://github.com/ezlo-picori/python-docs-fr/tree/meta-devcontainer.

Je compte ajouter deux fonctionnalités à ce qui est déjà en place:

• pre-commit: appel automatisé et systématique à make verifs, make wrap lors de chaque commit (et refus du commit tant que l'un de ces deux commande échoue/modifie les sources.
• "formatOnSave": j'aimerais ajouter powrap comme outil de formatage à VSCode ce qui forcerait l'appel à "powrap" dès que l'on sauvegarde un fichier .po

Si vous avez des retours, remarques, suggestions, questions, n'hésitez pas!

[JulienPalard]

Je ne suis pas de la génération vscode, mais j'apprécirai une démo lors du prochain atelier :)

[vpoulailleau]

Je ne suis pas de la génération vscode, mais j'apprécirai une démo lors du prochain atelier :)

Mais tu peux configurer emacs ou vi pour faire appel au conteneur (je ne suis pas contre spacemacs que j'ai beaucoup utilisé avant de passer à VS Code) 😉

En tout cas, je trouve que c'est une bonne idée d'avoir tout les outils installés facilement.

[ezlo-picori]

J'ai mis en place pre-commit pour automatiser l'exécution de powrap et pospell à chaque tentative de commit.
Cependant pospell se plaint de nombreux mots inconnus tels que hachable ou muable. Donc j'ai commencé à remplir un dictionnaire personnalisé qui, pour le moment, lève les erreurs issues de whatsnew/ et des premiers fichiers dans library/.

Est-ce que vous êtes d'accord sur la pertinence d'inclure un tel dictionnaire personnalisé dans la base? Avant que je ne passe du temps à le remplir pour l'essentiel de la doc actuelle...

Merci pour vos retours!

[jeanas]

N'es-tu pas en train de réécrire le fichier dict qui est à la racine ? Note bien que pospell s'exécute dans la CI, il ne peut jamais y avoir de mot manquant, sans quoi une PR ne peut pas être fusionnée.

[ezlo-picori]

En effet! Ce qui confirme deux choses:

• On est bien d'accord sur la pertinence de ce dictionnaire
• J'aurais mieux fait d'aller me coucher tant que j'avais encore les yeux en face des trous hier soir 😅

Je ne comprend pas comment je suis passé à côté... Mais c'est parfait!

Petite question en rapport du coup: est-ce qu'il y a une raison pour laquelle dict ne détaille pas l'affixation des mots? Ça éviterait d'avoir à renseigner manuellement les formes dérivées comme pour

déserialise
déserialiser
déserialiseur
déserialiseurs
désérialisation
désérialiseur
désérialiseurs
déserialisées
déserialisés
désérialisés
désérialise
désérialiser
désérialisé
désérialisées

qui peut être simplement remplacé par

désérialisation/sérialisation
désérialiseur/sérialiseur
désérialiser/sérialiser

Est-ce que peut-être que le fichier dict est utilisé par un autre outil que pospell qui attendrait une liste de mots fixe et ne supporterait pas le format de dictionnaires personnels d'Hunspell? Éventuellement padpo?

edit: J'ai ma réponse. En l'état padpo filtre les résultats retournés par grammalecte-cli.py en éliminant les résultats dont le mot est directement dans le fichier dict donc il faut garder une liste à plat. En fouillant un peu, j'ai l'impression que grammalecte s'appuie sur les dictionnaire Hunspell et donc devrait être capable de gérer le format de fichier personnel. Mais l'option --personnal-dict de grammalecte-cli.py attend un fichier JSON (load personnal dictionary (JSON file)) dont je n'arrive pas à trouver le schéma attendu. Si quelqu'un a une piste, j'aimerais creuser pour peut-être à terme pouvoir utiliser un dictionnaire amélioré aussi bien dans pospell que dans padpo (l'intérêt étant surtout d'indiquer, non pas juste une liste blanche de mot, mais de préciser leur nature syntaxique: féminin/masculin, invariant, adjectif, ...). Mais je m'égare par rapport à la thématique d'origine de ce PR, j'ouvrirai plus tard un discussion sur le discuss de l'AFPy plutôt.

Pour le moment, je retiens juste que je configure pre-commit pour utiliser le fichier dict avec pospell.

[jeanas]

Comme discuté hier à l'atelier, l'idée serait de fusionner cette PR s'il y a quelques autres personnes qui font part de leur intérêt pour ce genre d'environnement, donc manifestez-vous si vous pensez utiliser ce conteneur.

[vpoulailleau]

@ezlo-picori padpo utilise grammalecte et son format de dictionnaire… (https://grammalecte.net/home.php?prj=fr)

Un jour, je me dit que padpo devrait aussi prendre en compte le dictionnaire de pospell ou carrément ne pas vérifier l'orthographe (vu qu'on passe pospell aussi), mais plutôt se concentrer sur les erreurs de grammaire (entre autres).

[JulienPalard]

manifestez-vous si vous pensez utiliser ce conteneur

Il semble que personne ne se soit manifesté en huit mois, je ferme cette PR.

J'aurai au moins appris l'existance d'une feature de vscode, merci @ezlo-picori !

D'ailleurs les utilisateurs de vscode qui me lisent devraient utiliser vscodium, une version sans la télésurveillance Microsoft.