You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
93
93
94
94
Ou lancez simplement Poedit puis « Fichier » → « Ouvrir ».
95
95
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.
100
105
101
106
.. code-block:: bash
102
107
103
-
powrap -m
108
+
make spell
104
109
110
+
Vous pouvez aussi réindenter les fichiers avec :
105
111
106
-
Traduction
107
-
~~~~~~~~~~
112
+
.. code-block:: bash
108
113
109
-
Vous pouvez dès à présent commencer à traduire le fichier en respectant les `Conventions`_ du projet.
114
+
make wrap
110
115
111
-
La commande suivante lance les vérifications nécessaires :
116
+
Et pour faire les deux à la fois, lancez :
112
117
113
118
.. code-block:: bash
114
119
@@ -133,29 +138,35 @@ La documentation est publiée l'adresse `<http://localhost:8000/library/sys.html
133
138
(ou tout autre port indiqué par la sortie de la commande précédente). Vous pouvez
134
139
recommencer les étapes de cette section autant de fois que nécessaire.
135
140
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
+
136
146
*pull request*
137
147
~~~~~~~~~~~~~~
138
148
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
141
153
attendant d'être propagées dans le dépôt local.
142
154
143
155
.. code-block:: bash
144
156
145
157
git add library/sys.po
146
158
147
159
148
-
Puis on propage les modifications dans le dépôt local avec un commit.
160
+
``git commit`` permet de les propager :
149
161
150
162
.. code-block:: bash
151
163
152
164
git commit -m "Traduction de library/sys.po"# Ou un autre message plus inspiré :)
153
165
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).
159
170
160
171
.. code-block:: bash
161
172
@@ -166,13 +177,14 @@ Github. Si vous l'avez manqué, allez simplement sur https://github.com/python/p
166
177
et un joli bouton « Compare & pull request » devrait apparaître au bout de
167
178
quelques secondes vous indiquant que vous pouvez demander une pull request.
168
179
169
-
Mettez dans le commentaire de la pull request le texte suivant :
180
+
Mettez dans le commentaire de la *pull request* le texte suivant :
170
181
« 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.
171
183
172
184
À partir de là, quelqu'un passera en revue vos modifications, et vous fera des
173
185
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):
176
188
177
189
.. code-block:: bash
178
190
@@ -196,7 +208,7 @@ de votre *origin* au *upstream* public, pour « boucler la boucle ». C'est le
196
208
rôle des personnes qui *fusionnent* les *pull requests* après les avoir relues.
197
209
198
210
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
200
212
modifications à partir d'elles.
201
213
202
214
Toutes les traductions sont faites sur la dernière version.
@@ -210,20 +222,20 @@ les plus anciennes par l'`équipe de documentation
210
222
Que traduire ?
211
223
--------------
212
224
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*
214
226
à traduire. Une fois installé, utilisez la commande ``make todo`` dans votre clone
215
227
local.
216
228
217
229
Vous pouvez choisir n'importe quel fichier non réservé dans la liste
218
230
renvoyée par la commande **à l'exception** des fichiers de :
219
231
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.
223
235
224
236
Vous pouvez commencer par des tâches faciles comme réviser les entrées
225
237
*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
227
239
mais dont la source en anglais a été remodifiée depuis (correction orthographique,
228
240
changement d'un terme, ajout ou suppression d'une phrase…). Elles sont
229
241
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.
235
247
Conventions
236
248
-----------
237
249
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
+
238
303
Prototypes et exemples
239
-
~~~~~~~~~~~~~~~~~~~~~~
304
+
++++++++++++++++++++++
240
305
241
306
Il ne faut pas traduire le nom des éléments de la bibliothèque standard (noms
242
307
de fonctions, paramètres de ces fonctions, constantes etc.) mais les laisser
@@ -267,7 +332,7 @@ mais pas en
267
332
...
268
333
269
334
Liens hypertextes
270
-
~~~~~~~~~~~~~~~~~
335
+
+++++++++++++++++
271
336
272
337
Il faut transformer les liens hypertextes qui redirigent vers une page dont il
273
338
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>`_``.
278
343
279
344
280
345
Balises
281
-
~~~~~~~
346
+
+++++++
282
347
283
348
Ne traduisez pas le contenu des balises comme ``:ref:...`` ou ``:class:...``.
284
349
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>`_.
286
351
La syntaxe est ``:term:nom_français<nom_anglais>``. Par exemple, traduisez
287
352
``:term:`dictionary``` en ``:term:`dictionaire <dictionary>```.
288
353
289
354
Comme le glossaire est déjà traduit, il y a forcément une correspondance à chaque
290
355
terme que vous pouvez rencontrer.
291
356
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.
- 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
+
426
477
Caractères spéciaux et typographie
427
478
----------------------------------
428
479
@@ -531,8 +582,8 @@ En français, nous mettons une espace insécable devant nos deux-points, comme :
531
582
532
583
Pour saisir une espace insécable faites :kbd:`ComposeSPACESPACE`
533
584
534
-
Le cas des doubles-espaces
535
-
~~~~~~~~~~~~~~~~~~~~~~~~~~
585
+
Les doubles-espaces
586
+
~~~~~~~~~~~~~~~~~~~
536
587
537
588
La documentation originale comporte beaucoup de doubles-espaces.
538
589
Cela se fait en anglais, mais pas en français. De toute manière,
@@ -606,38 +657,8 @@ Powrap
606
657
|`Lien vers le dépôt <https://github.com/JulienPalard/powrap>`__
607
658
608
659
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,
- 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
-
639
660
Simplification des diffs git
640
-
----------------------------
661
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
641
662
642
663
Les diffs git sont souvent encombrés de changements inutiles de numéros
643
664
de ligne, comme :
@@ -698,31 +719,6 @@ Fusion des fichiers *pot* de CPython
0 commit comments