docs: add more translations for reference/import.po #298
No reviewers
Labels
No labels
bug
duplicate
enhancement
help wanted
invalid
meta
question
wontfix
No milestone
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
AFPy/python-docs-fr!298
Loading…
Reference in a new issue
No description provided.
Delete branch "Lenormju/fork-python-docs-fr:reference-import-3.13-more"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
e8a43008b70f133d31a30f133d31a300725796d0Merci pour cette contribution.
Pour ce qui n'a pas à être traduit, je pense qu'il faut recopier la version originale. À confirmer par @mdk.
@ -1440,7 +1453,6 @@ msgstr """d'importation."#: reference/import.rst:706#, fuzzyfuzzy non traité.
En effet, j'avais pas saisi les subtilités de syntaxe Sphinx, bien vu, merci.
@ -1137,3 +1147,3 @@"donnée plus bas) sont consultés pendant le parcours du ``__path__`` du paquet."#: reference/import.rst:564#, fuzzymême remarque que ci-dessus.
même réponse que ci-dessus
@ -1107,9 +1117,12 @@ msgid """submodules will be found. By definition, if a module has a :attr:`!__path__` ""attribute, it is a :term:`package`."msgstr """L'attribut :attr:`~module.__path__` devrait être une :term:`sequence` ("Nous traduisons should par doit, voir l'utilisation du condionnel.
je n'avais pas connaissance de cette doc. Je suis d'accord avec :
J'ai appliqué la correction.
@ -1109,1 +1119,4 @@msgstr """L'attribut :attr:`~module.__path__` devrait être une :term:`sequence` (""possiblement vide) de chaînes de caractères listant tous les emplacements où ""les sous-modules du paquets seront trouvés. Par définition, si un module a "Et le présent plutôt que le futur, voir utilisation du futur.
j'écrirais ainsi où se trouvent les sous-modules du paquet (sans s à paquet).
pris en compte, merci
@ -1118,3 +1131,3 @@"than :data:`!sys.path`."msgstr """L'attribut ``__path__`` d'un paquet est utilisé pendant l'importation des ""L'attribut ``__path__`` d'un paquet est utilisé pendant l'importation de ses "L'étiquette fuzzy vient de ce que l'original a modifié
en
je l'avais loupé, bien vu, merci
@ -1134,3 +1145,1 @@"être vide. Les mêmes règles que pour :data:`sys.path` s'appliquent au ""``__path__`` d'un paquet et :data:`sys.path_hooks` (dont la description est ""donnée plus bas) est consulté pendant le parcours de ``__path__`` du paquet.""Les mêmes règles que pour :data:`sys.path` s'appliquent au ``__path__`` d'un "Sous Unix, tu peux utiliser fuzzy_diff pour aider à trouver ce qui a généré les fuzzys.
Merci pour le conseil, mais malheureusement j'ai contribué sans avoir le luxe de disposer d'un environnement Unix.
@ -1227,6 +1237,9 @@ msgid """removed in Python 3.12 and is no longer called during the resolution of a ""module's repr."msgstr """La méthode :meth:`!module_repr` est dépréciée depuis Python 3.4, et a été "Voir le glossaire pour deprecated.
je n'avais pas connaissance de cette ressource, mais en effet le terme est bien adapté, et j'ai donc appliqué la suggestion
@ -1973,3 +1983,2 @@"package>` pour Python 3.3. La :pep:`420` a aussi introduit le protocole :""meth:`recherche du chargeur <find_loader>` comme une alternative à :meth:""`find_module`.""meth:`recherche du chargeur !find_loader` comme une alternative à :meth:"Le nom de méthode n'a pas à être traduit, donc garder la version originale.
ok
@ -2036,3 +2046,3 @@#: reference/import.rst:8msgid "import machinery"msgstr ""msgstr "mécanisme d'import"importation (voir le glossaire)
je suis d'accord pour la partie "importation", mais il y a plusieurs dizaines d'occurrences à travers la page de l'utilisation de "mécanisme" pour traduire "machinery". J'ai néanmoins appliqué ta suggestion telle quelle, sans le "mécanisme" donc
Je me suis mal exprimé. Je voulais écrire mécanisme d'importation (juste remplacer import par importation).
@ChristopheNan merci pour cette relecture, tu as trouvé plusieurs inattentions, et plusieurs manques de contexte de ma part
Pour le sujet des traductions à ne pas faire, j'en ai justement discuté avec @mdk hier et il disait que ça semblait être un bug upstream, que ça n'aurait pas du se retrouver là, donc j'ai préféré ajouter un commentaire pour dire que ces bouts de code étaient intentionnellement non traduits. D'autant plus que @mdk disait qu'on n'arriverait pas à leur faire passer les checks de la CI ensuite.
Merci @Lenormju
Je suis un peu paumé dans les conflits indiqués par git.
Les commentaires de traduction devraient être avant l'entrée correspondante (voir la spécification des fichiers .po)
-> Peux-tu remettre en forme le fichier conformément aux spécifications (poedit dispose d'une boite pour entrer les commentaires) ?
Mais ce n'est pas ça qui génère le conflit git.
51b6e9807a4da756ace2@ChristopheNan il y a eu côté upstream la correction du problème mentionné ici, j'ai donc enlevé toutes les occurences de commentaires (
#) que j'avais introduites, n'étant plus nécessaires.Je n'avais pas saisi que mes commentaires étaient mal positionnés, merci pour la remarque.
Je me note néanmoins pour l'année prochaine que disposer d'un linter local (et donc d'un environnement de dev) est important pour être efficace en terme de contribution, et ne pas générer trop de charge de votre côté (relecture).
Merci @Lenormju !