Gestion des entrées de l'index en français #255

New Issue

ChristopheNan · 2023-12-01T13:22:58Z

ChristopheNan commented

2023-12-01 13:22:58 +00:00

La génération des fichiers .po inclut désormais les entrées d'index des fichiers .rst sources. Comme je l'indique ici, la syntaxe rst semble prise en compte. Je pense qu'il convient de définir un référentiel de ces entrées pour éviter d'avoir un index non cohérent avec l'original anglais et surtout non exploitable en raison de coquilles ou interprétations différentes entre fichiers.
Créons-nous un fichier dédié pour lister les entrées d'index en français ?
Avez-vous d'autres propositions ?

La génération des fichiers *.po* inclut désormais les entrées d'index des fichiers *.rst* sources. Comme je l'indique ici, la syntaxe *rst* semble prise en compte. Je pense qu'il convient de définir un référentiel de ces entrées pour éviter d'avoir un index non cohérent avec l'original anglais et surtout non exploitable en raison de coquilles ou interprétations différentes entre fichiers. Créons-nous un fichier dédié pour lister les entrées d'index en français ? Avez-vous d'autres propositions ?

ChristopheNan commented

2023-12-01 13:24:01 +00:00

@mdk : possible de créer une étiquette "méta" pour les tickets ?

mdk added the

meta

label 2023-12-03 09:58:08 +00:00

mdk commented

2023-12-03 10:07:58 +00:00

La génération des fichiers .po inclut désormais les entrées d'index des fichiers .rst sources

Parles-tu des lignes comme #: library/stdtypes.rst:15 ?

cohérent avec l'original anglais

Ces références sont cohérentes avec le commit stocké dans le Makefile:

$ make print-CPYTHON_CURRENT_COMMIT
afa24d52b821c2020e0966f96a6205bca7db85e9

c'est celui mis à jour à chaque merge d'usptream.

Il existe une "pression" autour de ce "merge upstream":

Si on merge souvent, on crée des conflits¹ dans les PR ouvertes.
Si on merge peu souvent, les références divergent, et on risque de traduire des choses qui ont déjà été modifiées.

Donc j'essaye de merger lorsque le nombre de PR est bas, ce qui n'arrive en effet plus depuis quelques mois.

[1] : Merger peut causer des conflits en masse : si quelques mots sont introduits en haut d'un fichier rst, avec la limite à 80 colonnes ça peut suffire à introduire une nouvelle ligne proche de ces mots, et cette nouvelle ligne "décale" d'une ligne tous les paragraphes suivants, ce qui cause des milliers de "modifications" peu pertinentes, proche du flag fuzzy, donc souvent difficiles à merger :

-#: library/collections.rst:477
+#: library/collections.rst:478
 msgid "Deque objects support the following methods:"
 msgstr "Les objets *deques* gèrent les méthodes suivantes :"
 
-#: library/collections.rst:481
+#: library/collections.rst:482
 msgid "Add *x* to the right side of the deque."
 msgstr "Ajoute *x* à l'extrémité droite de la *deque*."
 
-#: library/collections.rst:486
+#: library/collections.rst:487
 msgid "Add *x* to the left side of the deque."
 msgstr "Ajoute *x* à l'extrémité gauche de la *deque*."
 
-#: library/collections.rst:491
+#: library/collections.rst:492
 msgid "Remove all elements from the deque leaving it with length 0."
 msgstr ""
 "Supprime tous les éléments de la *deque* et la laisse avec une longueur de 0."

> La génération des fichiers .po inclut désormais les entrées d'index des fichiers .rst sources Parles-tu des lignes comme `#: library/stdtypes.rst:15` ? > cohérent avec l'original anglais Ces références sont cohérentes avec le commit stocké dans le `Makefile`: ```bash $ make print-CPYTHON_CURRENT_COMMIT afa24d52b821c2020e0966f96a6205bca7db85e9 ``` c'est celui mis à jour à chaque `merge` d'usptream. Il existe une "pression" autour de ce "merge upstream": - Si on merge souvent, on crée des conflits¹ dans les PR ouvertes. - Si on merge peu souvent, les références divergent, et on risque de traduire des choses qui ont déjà été modifiées. Donc j'essaye de merger lorsque le nombre de PR est bas, ce qui n'arrive en effet plus depuis quelques mois. [1] : Merger peut causer des conflits en masse : si quelques mots sont introduits en haut d'un fichier rst, avec la limite à 80 colonnes ça peut suffire à introduire une nouvelle ligne proche de ces mots, et cette nouvelle ligne "décale" d'une ligne **tous** les paragraphes suivants, ce qui cause des milliers de "modifications" peu pertinentes, proche du flag fuzzy, donc souvent difficiles à merger : ```diff -#: library/collections.rst:477 +#: library/collections.rst:478 msgid "Deque objects support the following methods:" msgstr "Les objets *deques* gèrent les méthodes suivantes :" -#: library/collections.rst:481 +#: library/collections.rst:482 msgid "Add *x* to the right side of the deque." msgstr "Ajoute *x* à l'extrémité droite de la *deque*." -#: library/collections.rst:486 +#: library/collections.rst:487 msgid "Add *x* to the left side of the deque." msgstr "Ajoute *x* à l'extrémité gauche de la *deque*." -#: library/collections.rst:491 +#: library/collections.rst:492 msgid "Remove all elements from the deque leaving it with length 0." msgstr "" "Supprime tous les éléments de la *deque* et la laisse avec une longueur de 0." ```

ChristopheNan commented

2023-12-06 21:39:10 +00:00

Je me suis mal exprimé.
je lève cette question pour déterminer comment prendre en compte les nouvelles lignes qui ont été introduites comme les lignes 304 et suivantes de cette révision : https://git.afpy.org/AFPy/python-docs-fr/blame/branch/3.11/reference/introduction.po

Maintenant, les fichiers .po contiennent explicitement les entrées de l'index, en fin de fichier. Afin d'avoir un index cohérent en français (je dois avouer que je n'ai pas vérifié comment est construit l'index en français), il faut que les traductions soient cohérentes entre tous les fichiers .po.

Je me suis mal exprimé. je lève cette question pour déterminer comment prendre en compte les nouvelles lignes qui ont été introduites comme les lignes 304 et suivantes de cette révision : https://git.afpy.org/AFPy/python-docs-fr/blame/branch/3.11/reference/introduction.po Maintenant, les fichiers *.po* contiennent explicitement les entrées de l'index, en fin de fichier. Afin d'avoir un index cohérent en français (je dois avouer que je n'ai pas vérifié comment est construit l'index en français), il faut que les traductions soient cohérentes entre tous les fichiers *.po*.

ChristopheNan commented

2023-12-07 20:34:41 +00:00

Et ces nouvelles entrées font que la vérification par pospell échoue systématiquement : les entrées d'index pour les mots-clés (en anglais) ne sont pas traduites.

Et ces nouvelles entrées font que la vérification par *pospell* échoue systématiquement : les entrées d'index pour les mots-clés (en anglais) ne sont pas traduites.

ChristopheNan referenced this issue from AFPy/pospell

2023-12-07 20:37:12 +00:00

.po files include index entries #14

ChristopheNan commented

2023-12-09 14:15:24 +00:00

Une illustration de ce que je veux dire :
for mot in list mapping string integer bytes ; do pogrep --recursive --line-number --exclude-dir=venv --exclude-dir=locales "^${mot}$" ; done

Une illustration de ce que je veux dire : ``for mot in list mapping string integer bytes ; do pogrep --recursive --line-number --exclude-dir=venv --exclude-dir=locales "^${mot}$" ; done``

Sign in to join this conversation.

No Label