Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 2e613a6

Browse files
awecxJulienPalard
authored andcommitted
Améliorations du README. (#1331)
* Améliorations du README. * Suggestions de ChristopheNan. (cherry picked from commit cfa4c41)
1 parent 84b19b4 commit 2e613a6

File tree

2 files changed

+152
-167
lines changed

2 files changed

+152
-167
lines changed

CONTRIBUTING.rst

Lines changed: 129 additions & 133 deletions
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,7 @@ version locale.
6868
git fetch upstream
6969
7070
71-
On créé ensuite une branche. Il est pratique de nommer la branche en fonction du
71+
On crée ensuite une branche. Il est pratique de nommer la branche en fonction du
7272
fichier sur lequel on travaille. Par exemple, si vous travaillez sur
7373
« library/sys.po », vous pouvez nommer votre branche « library-sys ».
7474
Cette nouvelle branche nommée « library-sys » est basée sur « upstream/3.9 ».
@@ -93,22 +93,27 @@ Ici, remplacez « library/sys.po » par le fichier que vous avez choisi préc
9393
9494
Ou lancez simplement Poedit puis « Fichier » → « Ouvrir ».
9595

96-
Si vous n'utilisez pas Poedit, vous pouvez utiliser `powrap <https://github.com/JulienPalard/powrap>`_
97-
(voir la section *outils*) qui reformate correctement le fichier que vous avez modifié.
98-
Exécutez `powrap -m` (reformater tous les fichiers modifiés)
99-
ou `powrap library/sys.po` (un fichier en particulier) :
96+
97+
Traduction
98+
~~~~~~~~~~
99+
100+
Vous pouvez dès à présent commencer à traduire le fichier en respectant les `conventions`_ du projet.
101+
Pour vous aider à ne pas faire de fautes d'orthographe, vous pouvez vérifier que tous les mots utilisés sont
102+
bien dans le dictionnaire (ça ne vérifie pas la grammaire, pour cela utilisez `padpo (beta)`_). En cas
103+
de doute, un `glossaire`_ répertorie déjà les traductions retenues pour certains termes techniques ou faux amis
104+
en anglais.
100105

101106
.. code-block:: bash
102107
103-
powrap -m
108+
make spell
104109
110+
Vous pouvez aussi réindenter les fichiers avec :
105111

106-
Traduction
107-
~~~~~~~~~~
112+
.. code-block:: bash
108113
109-
Vous pouvez dès à présent commencer à traduire le fichier en respectant les `Conventions`_ du projet.
114+
make wrap
110115
111-
La commande suivante lance les vérifications nécessaires :
116+
Et pour faire les deux à la fois, lancez :
112117

113118
.. code-block:: bash
114119
@@ -133,29 +138,35 @@ La documentation est publiée l'adresse `<http://localhost:8000/library/sys.html
133138
(ou tout autre port indiqué par la sortie de la commande précédente). Vous pouvez
134139
recommencer les étapes de cette section autant de fois que nécessaire.
135140

141+
Poedit donne beaucoup d'avertissements, par exemple pour vous informer que
142+
« la traduction devrait commencer par une majuscule » car c'est le cas pour
143+
la source. Ces avertissements ne sont pas tous fondés. En cas de doute,
144+
*affichez et relisez la page HTML produite* avec ``make serve``.
145+
136146
*pull request*
137147
~~~~~~~~~~~~~~
138148

139-
C'est le moment de `git add` et `git commit`.
140-
`git add` place nos modifications dans l'index de Git en
149+
Une fois que le *make verifs* ne lève pas d'erreur et que vous êtes certains de bien respecter les
150+
`Conventions`_ de traduction, vient le moment d'envoyer votre travail sur le dépôt local.
151+
152+
``git add`` place nos modifications dans l'index de Git en
141153
attendant d'être propagées dans le dépôt local.
142154

143155
.. code-block:: bash
144156
145157
git add library/sys.po
146158
147159
148-
Puis on propage les modifications dans le dépôt local avec un commit.
160+
``git commit`` permet de les propager :
149161

150162
.. code-block:: bash
151163
152164
git commit -m "Traduction de library/sys.po" # Ou un autre message plus inspiré :)
153165
154-
155-
Poussez ensuite vos modifications sur votre fork Github.
156-
Le -u n'est utile qu'une fois pour que votre client git se souvienne que cette
157-
branche est liée à votre fork Github (et donc que vos futurs `git pull` et
158-
`git push` sachent quoi tirer).
166+
Poussez ensuite vos modifications sur votre *fork* Github avec ``git push``.
167+
Le ``-u`` n'est utile qu'une fois pour que votre client git se souvienne que cette
168+
branche est liée à votre *fork* Github (et donc que vos futurs ``git pull`` et
169+
``git push`` sachent quoi tirer).
159170

160171
.. code-block:: bash
161172
@@ -166,13 +177,14 @@ Github. Si vous l'avez manqué, allez simplement sur https://github.com/python/p
166177
et un joli bouton « Compare & pull request » devrait apparaître au bout de
167178
quelques secondes vous indiquant que vous pouvez demander une pull request.
168179

169-
Mettez dans le commentaire de la pull request le texte suivant :
180+
Mettez dans le commentaire de la *pull request* le texte suivant :
170181
« Closes #XXXX » où XXXX est le numéro du ticket GitHub créé pour réserver le fichier traduit.
182+
Cela permet à Github de lier la *pull request* au ticket de réservation.
171183

172184
À partir de là, quelqu'un passera en revue vos modifications, et vous fera des
173185
suggestions et corrections. Pour les prendre en compte, retournez sur votre branche
174-
contenant du fichier concerné (au cas où vous auriez commencé quelque chose d'autre
175-
sur une autre branche) :
186+
contenant le fichier concerné (au cas où vous auriez commencé quelque chose d'autre
187+
sur une autre branche) :
176188

177189
.. code-block:: bash
178190
@@ -196,7 +208,7 @@ de votre *origin* au *upstream* public, pour « boucler la boucle ». C'est le
196208
rôle des personnes qui *fusionnent* les *pull requests* après les avoir relues.
197209

198210
Vous avez peut-être aussi remarqué que vous n'avez jamais commité sur une
199-
branche de version (``3.8``, ``3.9``, etc.), seulement récupéré les
211+
branche de version (3.8, 3.9, etc.), seulement récupéré les
200212
modifications à partir d'elles.
201213

202214
Toutes les traductions sont faites sur la dernière version.
@@ -210,20 +222,20 @@ les plus anciennes par l'`équipe de documentation
210222
Que traduire ?
211223
--------------
212224

213-
Vous pouvez utiliser `potodo`_, un outil fait pour trouver des fichiers ``po``
225+
Vous pouvez utiliser `potodo`_, un outil fait pour trouver des fichiers *po*
214226
à traduire. Une fois installé, utilisez la commande ``make todo`` dans votre clone
215227
local.
216228

217229
Vous pouvez choisir n'importe quel fichier non réservé dans la liste
218230
renvoyée par la commande **à l'exception** des fichiers de :
219231

220-
- ``c-api/`` car c'est une partie très technique ;
221-
- ``whatsnew/`` car les anciennes versions de Python sont pour la plupart obsolètes et leurs journaux de modifications ne sont pas les pages les plus consultées ;
222-
- ``distutils/`` et ``install/`` car ces pages seront bientôt obsolètes.
232+
- *c-api/* car c'est une partie très technique ;
233+
- *whatsnew/* car les anciennes versions de Python sont pour la plupart obsolètes et leurs journaux de modifications ne sont pas les pages les plus consultées ;
234+
- *distutils/* et *install/* car ces pages seront bientôt obsolètes.
223235

224236
Vous pouvez commencer par des tâches faciles comme réviser les entrées
225237
*fuzzy* pour aider à garder la documentation à jour (trouvez-les à l'aide
226-
de `make fuzzy`). Une entrée *fuzzy* correspond à une entrée déjà traduite
238+
de ``make fuzzy``). Une entrée *fuzzy* correspond à une entrée déjà traduite
227239
mais dont la source en anglais a été remodifiée depuis (correction orthographique,
228240
changement d'un terme, ajout ou suppression d'une phrase…). Elles sont
229241
généralement plus « faciles » à traduire.
@@ -235,8 +247,61 @@ idée, et passer ensuite à la traduction de celles qui ne le sont pas encore.
235247
Conventions
236248
-----------
237249

250+
Certaines conventions ont été édictées pour homogénéiser la traduction.
251+
Il faut suivre les règles de `style`_ imposées, les `règles rst`_ et
252+
les traductions déjà définies dans le `glossaire`_.
253+
254+
255+
Style
256+
~~~~~
257+
258+
Une bonne traduction est une traduction qui transcrit fidèlement l'idée originelle
259+
en français, sans rien ajouter ni enlever au fond, tout en restant claire, concise et
260+
agréable à lire. Les traductions mot-à-mot sont à proscrire et il est permis — même
261+
conseillé — d'intervertir des propositions ou de réarranger des phrases de la
262+
documentation anglaise, si le rythme l'exige. Il faut aussi chercher des
263+
équivalents français aux termes techniques et aux idiotismes rencontrés, et prendre
264+
garde aux anglicismes.
265+
266+
Utilisation du futur
267+
++++++++++++++++++++
268+
269+
Dans la description du comportement de Python (au sens large, c'est-à-dire
270+
l'interpréteur lui-même mais aussi toutes les bibliothèques), la version
271+
originale utilise souvent le futur : « if you do this, it will produce
272+
that… ». En français, l'utilisation du présent convient tout à fait et le
273+
présent est souvent plus facile à lire : « si vous faites ceci, il se
274+
produit cela… ». On ne conserve le futur que si la seconde proposition
275+
se situe réellement dans le futur (par exemple, on peut penser qu'un
276+
processus de compilation n'est pas immédiat) ou pour des raisons de
277+
concordance des temps.
278+
279+
Utilisation du conditionnel
280+
+++++++++++++++++++++++++++
281+
282+
La version originale est très polie envers le lecteur ; elle lui intime
283+
rarement des obligations, préférant employer « you should ». Cependant, en
284+
français, il est d'usage d'être plus direct pour être correctement compris :
285+
« vous devez ». *Vous devriez* est en effet généralement compris comme quelque
286+
chose dont l'on peut de temps en temps se passer, alors que c'est très
287+
rarement le cas pour les « you should » de cette documentation.
288+
De la même manière, « can » est souvent mieux traduit sans introduire de notion
289+
de possibilité, en particulier quand la phrase est à la voix passive ; la
290+
phrase « these objects can be accessed by… » se traduit mieux par « on accède à
291+
ces objets en… ».
292+
293+
Utilisation du masculin
294+
+++++++++++++++++++++++
295+
296+
Dans un souci de lisibilité et en accord avec la préconisation de
297+
l'Académie française, nous utilisons le masculin pour indiquer un
298+
genre neutre. Par exemple : l'utilisateur ou le lecteur.
299+
300+
Règles rst
301+
~~~~~~~~~~
302+
238303
Prototypes et exemples
239-
~~~~~~~~~~~~~~~~~~~~~~
304+
++++++++++++++++++++++
240305

241306
Il ne faut pas traduire le nom des éléments de la bibliothèque standard (noms
242307
de fonctions, paramètres de ces fonctions, constantes etc.) mais les laisser
@@ -267,7 +332,7 @@ mais pas en
267332
...
268333
269334
Liens hypertextes
270-
~~~~~~~~~~~~~~~~~
335+
+++++++++++++++++
271336

272337
Il faut transformer les liens hypertextes qui redirigent vers une page dont il
273338
existe une version française (c'est notamment très souvent le cas pour les
@@ -278,61 +343,17 @@ doit devenir ```Jeu de la vie <https://fr.wikipedia.org/wiki/Jeu_de_la_vie>`_``.
278343

279344

280345
Balises
281-
~~~~~~~
346+
+++++++
282347

283348
Ne traduisez pas le contenu des balises comme ``:ref:...`` ou ``:class:...``.
284349
Vous devez cependant traduire les balises ``:term:...``, qui font référence à
285-
un concept ou une primitive Python défini dans le `glossaire <https://docs.python.org/fr/3/glossary.html>`_.
350+
un concept ou une primitive défini dans le `glossaire Python <https://docs.python.org/fr/3/glossary.html>`_.
286351
La syntaxe est ``:term:nom_français<nom_anglais>``. Par exemple, traduisez
287352
``:term:`dictionary``` en ``:term:`dictionaire <dictionary>```.
288353

289354
Comme le glossaire est déjà traduit, il y a forcément une correspondance à chaque
290355
terme que vous pouvez rencontrer.
291356

292-
Style
293-
~~~~~
294-
295-
Une bonne traduction est une traduction qui transcrit fidèlement l'idée originelle
296-
en français, sans rien ajouter ni enlever au fond, tout en restant claire, concise et
297-
agréable à lire. Les traductions mot-à-mot sont à proscrire et il est permis — même
298-
conseillé — d'intervertir des propositions ou de réarranger des phrases de la
299-
documentation anglaise, si le rythme l'exige. Il faut aussi chercher des
300-
équivalents français aux termes techniques et aux idiotismes rencontrés, et prendre
301-
garde aux anglicismes.
302-
303-
Utilisation du futur
304-
~~~~~~~~~~~~~~~~~~~~
305-
306-
Dans la description du comportement de Python (au sens large, c'est-à-dire
307-
l'interpréteur lui-même mais aussi toutes les bibliothèques), la version
308-
originale utilise souvent le futur : « if you do this, it will produce
309-
that… ». En français, l'utilisation du présent convient tout à fait et le
310-
présent est souvent plus facile à lire : « si vous faites ceci, il se
311-
produit cela… ». On ne conserve le futur que si la seconde proposition
312-
se situe réellement dans le futur (par exemple, on peut penser qu'un
313-
processus de compilation n'est pas immédiat) ou pour des raisons de
314-
concordance des temps.
315-
316-
Utilisation du conditionnel
317-
~~~~~~~~~~~~~~~~~~~~~~~~~~~
318-
319-
La version originale est très polie envers le lecteur ; elle lui intime
320-
rarement des obligations, préférant employer « you should ». Cependant, en
321-
français, il est d'usage d'être plus direct pour être correctement compris :
322-
« vous devez ». *Vous devriez* est en effet généralement compris comme quelque
323-
chose dont l'on peut de temps en temps se passer, alors que c'est très
324-
rarement le cas pour les « you should » de cette documentation.
325-
De la même manière, « can » est souvent mieux traduit sans introduire de notion
326-
de possibilité, en particulier quand la phrase est à la voix passive ; la
327-
phrase « these objects can be accessed by… » se traduit mieux par « on accède à
328-
ces objets en… ».
329-
330-
Utilisation du masculin
331-
~~~~~~~~~~~~~~~~~~~~~~~
332-
333-
Dans un souci de lisibilité et en accord avec la préconisation de
334-
l'Académie française, nous utilisons le masculin pour indiquer un
335-
genre neutre. Par exemple : l'utilisateur ou le lecteur.
336357

337358
Glossaire
338359
~~~~~~~~~
@@ -423,6 +444,36 @@ underscore tiret bas, *underscore*
423444
whitespace caractère d'espacement
424445
========================== ===============================================
425446

447+
Ressources de traduction
448+
------------------------
449+
450+
- les canaux IRC sur freenode :
451+
452+
- `#python-docs-fr <http://irc.lc/freenode/python-docs-fr>`_ — communauté python autour de la documentation française,
453+
- `#python-fr <http://irc.lc/freenode/python-fr>`_ — communauté python francophone,
454+
- `#python-doc <http://irc.lc/freenode/python-fr>`_ — communauté python autour de la documentation anglophone ;
455+
- les listes de diffusion relatives à la documentation (courriel) :
456+
457+
- `de l'AFPy <http://lists.afpy.org/mailman/listinfo/traductions>`_,
458+
- `de cpython <https://mail.python.org/mailman/listinfo/doc-sig>`_ ;
459+
- des glossaires et dictionnaires :
460+
461+
- le `glossaire de la documentation Python <https://docs.python.org/fr/3/glossary.html>`_, car il est déjà traduit,
462+
- les `glossaires et dictionnaires de traduc.org <https://traduc.org/Glossaires_et_dictionnaires>`_, en particulier le `grand dictionnaire terminologique <http://gdt.oqlf.gouv.qc.ca/>`_ de l'Office québécois de la langue française,
463+
- Wikipédia. En consultant un article sur la version anglaise, puis en basculant sur la version francaise pour voir comment le sujet de l'article est traduit ;
464+
- le `guide stylistique pour le français de localisation des produits Sun
465+
<https://web.archive.org/web/20160821182818/http://frenchmozilla.org/FTP/TEMP/guide_stylistique_December05.pdf>`_ donne
466+
beaucoup de conseils pour éviter une traduction trop mot à mot ;
467+
- `Petites leçons de typographie <https://jacques-andre.fr/faqtypo/lessons.pdf>`_,
468+
résumé succint de typographie, utile pour apprendre le bon usage des
469+
majuscules, des espaces, etc.
470+
471+
L'utilisation de traducteurs automatiques comme `DeepL https://www.deepl.com/` ou semi-automatiques comme
472+
`reverso https://context.reverso.net/traduction/anglais-francais/` est proscrite.
473+
Les traductions générées sont très souvent à retravailler, ils ignorent les règles énoncées sur cette
474+
page et génèrent une documentation au style très « lourd ».
475+
476+
426477
Caractères spéciaux et typographie
427478
----------------------------------
428479

@@ -531,8 +582,8 @@ En français, nous mettons une espace insécable devant nos deux-points, comme :
531582

532583
Pour saisir une espace insécable faites :kbd:`Compose SPACE SPACE`
533584

534-
Le cas des doubles-espaces
535-
~~~~~~~~~~~~~~~~~~~~~~~~~~
585+
Les doubles-espaces
586+
~~~~~~~~~~~~~~~~~~~
536587

537588
La documentation originale comporte beaucoup de doubles-espaces.
538589
Cela se fait en anglais, mais pas en français. De toute manière,
@@ -606,38 +657,8 @@ Powrap
606657
| `Lien vers le dépôt <https://github.com/JulienPalard/powrap>`__
607658
608659

609-
Ressources de traduction
610-
------------------------
611-
612-
- les canaux IRC sur freenode :
613-
614-
- `#python-docs-fr <http://irc.lc/freenode/python-docs-fr>`_ — communauté python autour de la documentation française,
615-
- `#python-fr <http://irc.lc/freenode/python-fr>`_ — communauté python francophone,
616-
- `#python-doc <http://irc.lc/freenode/python-fr>`_ — communauté python autour de la documentation anglophone ;
617-
- les listes de diffusion relatives à la documentation (courriel) :
618-
619-
- `de l'AFPy <http://lists.afpy.org/mailman/listinfo/traductions>`_,
620-
- `de cpython <https://mail.python.org/mailman/listinfo/doc-sig>`_ ;
621-
- des glossaires et dictionnaires :
622-
623-
- le `glossaire de la documentation Python <https://docs.python.org/fr/3/glossary.html>`_, car il est déjà traduit,
624-
- les `glossaires et dictionnaires de traduc.org <https://traduc.org/Glossaires_et_dictionnaires>`_, en particulier le `grand dictionnaire terminologique <http://gdt.oqlf.gouv.qc.ca/>`_ de l'Office québécois de la langue française,
625-
- Wikipédia. En consultant un article sur la version anglaise, puis en basculant sur la version francaise pour voir comment le sujet de l'article est traduit ;
626-
- le `guide stylistique pour le français de localisation des produits Sun
627-
<https://web.archive.org/web/20160821182818/http://frenchmozilla.org/FTP/TEMP/guide_stylistique_December05.pdf>`_ donne
628-
beaucoup de conseils pour éviter une traduction trop mot à mot ;
629-
- `Petites leçons de typographie <https://jacques-andre.fr/faqtypo/lessons.pdf>`_,
630-
résumé succint de typographie, utile pour apprendre le bon usage des
631-
majuscules, des espaces, etc.
632-
633-
L'utilisation de traducteurs automatiques comme `DeepL https://www.deepl.com/` ou semi-automatiques comme
634-
`reverso https://context.reverso.net/traduction/anglais-francais/` est proscrite.
635-
Les traductions générées sont très souvent à retravailler, ils ignorent les règles énoncées sur cette
636-
page et génèrent une documentation au style très « lourd ».
637-
638-
639660
Simplification des diffs git
640-
----------------------------
661+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
641662

642663
Les diffs git sont souvent encombrés de changements inutiles de numéros
643664
de ligne, comme :
@@ -698,31 +719,6 @@ Fusion des fichiers *pot* de CPython
698719
make merge
699720
700721
701-
Trouver les chaînes de caractères *fuzzy*
702-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
703-
704-
.. code-block:: bash
705-
706-
make fuzzy
707-
708-
709-
*build* local
710-
~~~~~~~~~~~~~
711-
712-
.. code-block:: bash
713-
714-
make
715-
716-
717-
Serveur de documentation en local
718-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
719-
720-
.. code-block:: bash
721-
722-
make serve
723-
724-
725-
726722
Synchronisation de la traduction avec Transifex
727723
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
728724

0 commit comments

Comments
 (0)