search

siecledeslumieres / wordpress-sans-epicene

Wordpress débarrassé du langage épicène dit "inclusif"
5 stars 2 forks source link

présentation sous forme d'extension #2

Open epiclair opened 3 years ago

epiclair commented 3 years ago

Bonjour

Ces fichiers de traductions seraient peut-être plus pratiques à utiliser sous forme d'une extension. Voulez-vous que je vous prépare cela ?

siecledeslumieres commented 3 years ago

Bonjour epiclair,

Merci beaucoup ! Je trouve que c'est une excellente idée ! Je suis totalement ouvert à ce qu'on soit dans une démarche collective, libre et open source, et si vous pouvez créer une extension pour automatiser la traduction, c'est génial !!

Wordpress fait tourner en 2020 38% de tous les sites web sur Internet, l'enjeu est suffisamment important pour justifier de s'organiser et de résister. Je n'aurais pas les compétences techniques pour vous aider spécifiquement sur la création de l'extension, mais en s'y mettant à plusieurs, entre l'extension et la mise à jour des fichiers de traductions. Ça devrait bien fonctionner ! Je vous ai envoyé une invitation pour collaborer au répertoire.

epiclair commented 3 years ago

J'ai écrit l'extension, elle est disponible là : https://github.com/epiclair/wordpress-sans-epicene/tree/test-extension

Il me reste un souci avec github parce que le nom du répertoire dans l'archive est "wordpress-sans-epicene-test-extension" alors que wordpress a besoin de "wordpress-sans-epicene". Je vais voir comment modifier cela.

epiclair commented 3 years ago

J'ai trouvé comment ajouter un fichier. Cela se fait au moment de créer une nouvelle version donc le fichier utilisable dans l'espace d'administration est là : https://github.com/epiclair/wordpress-sans-epicene/releases/download/test1/wordpress-sans-epicene.zip

maniackcrudelis commented 3 years ago

@epiclair

Penses-tu que nous pourrions utiliser une extension pour nettoyer le fichier de langue original plutôt que le remplacer ? J'ai écris ce script, en bash toutefois, qui donne de très bon résultats.

Il me semble qu'il pourrait être plus intéressant de procéder de la sorte pour ne pas interferer avec les mises à jour des traductions.

Mais cela est-il faisable en php ?

epiclair commented 3 years ago

Les extensions ne modifient pas les fichiers sinon les modifications seront écrasées au moment des mises à jour. Dans l'extension, les traductions corrigées sont chargées en premier avant les traductions officielles. Donc, si un nouveau texte apparait dans WordPress, il sera bien traduit en français.

J'ai vu votre script, il peut être intéressant pour préparer les fichiers de traduction de l'extension mais il vaut mieux ne pas l'utiliser directement et vérifier les modifications avant de les mettre en ligne parce que la langue française est parfois surprenante. Je me demande si ce genre d'outils doit faire partie du même projet github ou si c'est plus efficace de faire un projet "outils de l'extension" ?

maniackcrudelis commented 3 years ago

Ok, je comprend approximativement ce que tu expliques.

Dans ce cas, je vais probablement travailler à l'automatisation du process à partir d'un wordpress avec mise à jour automatique. Je devrais pouvoir arriver à un résultat intéressant avec des commits directement ici.

Car je pense vraiment que si nous devons prendre chaque traduction une à une et les vérifier manuellement, nous abondonnerons vite...

maniackcrudelis commented 3 years ago

@epiclair

Je repensais à ta réponse, devrais-je comprendre que les chaines qui ne sont pas dans la traduction fourni par l'extension sont prisent dans la traduction officielle ? Le cas échéant, pourrions nous considérer que l'extension pourrait ne contenir que les chaines à modifier ? Cela permettrait de ne pas avoir à faire une mise à jour pour la moindre virgule déplacée ou espace remplacé par un espace insécable, etc et se concentrer uniquement sur les chaines qui contiennent du langage "inclusif".

Je pense bien évidemment à des lignes entières, pas des mots seulement. Ça nécessiterait un travail de parsing bien superflu.

epiclair commented 3 years ago

Oui je n'avais pas pensé à ça. Cela sera plus simple à maintenir si les fichiers de traductions de l'extension ne contiennent que les textes à corriger.

maniackcrudelis commented 3 years ago

@epiclair si on arrive à un fichier .po de la sorte:

msgid "Author website"
msgstr "Site de l’auteur"

msgid "No version or author information is available."
msgstr "Aucune information de version ou d’auteur n’est disponible."

...

Avec une conversion en .mo avec fmtmsg, est-ce que c'est fonctionnel pour toi ? Là j'ai un script qui me fait le boulot et me sort un .po et le .mo qui lui correspond. Et qui ne contient donc que les chaines modifiées, comme l'exemple précédent.

J'ai déjà push sur la branche inclusive_cleaner si tu veux faire un test. Je ne sais pas en revanche si l'entête du fichier .po est nécessaire. Là elle n'y est pas.

epiclair commented 3 years ago

Je viens de tester l'encodage et les pluriels, il n'y a pas de problèmes si les entêtes sont absents. Quand wordpress charge plusieurs fichiers pour le même domaine de langue, il prend les entêtes du dernier fichier chargé. Là, le dernier fichier est celui des traductions officielles donc c'est bon.

J'ai fait une nouvelle version de test avec les nouveaux fichiers de langue : https://github.com/epiclair/wordpress-sans-epicene/releases/download/test2/wordpress-sans-epicene.zip

maniackcrudelis commented 3 years ago

Je viens de faire un essai de ton extension, ça fonctionne parfaitement et ça ne perturbe pas les autres parties de la traduction.

Je vais continuer à travailler sur le script, pour automatiser le tout, il ne restera plus ainsi qu'à vérifier les commits pour être sûr qu'il n'y ai pas de régression.

Est-ce que ton extension pourrait récupérer ses fichiers directement depuis le dépôt github ? Pour être plus efficace sur le suivi.