1
- Guide de contribution à la documentation via GitHub
2
- ###################################################
1
+ Guide de contribution à la documentation
2
+ ########################################
3
3
4
4
Prérequis
5
5
=========
@@ -192,7 +192,7 @@ Vous pouvez commencer par des tâches faciles comme réviser les entrées
192
192
de ` ` make fuzzy` ` ). Une entrée * fuzzy* correspond à une entrée déjà traduite
193
193
mais dont la source en anglais a été modifiée depuis (correction orthographique,
194
194
changement d' un terme, ajout ou suppression d' une phrase…). Elles sont
195
- généralement plus « faciles » à traduire.
195
+ généralement plus « faciles » à traduire.
196
196
197
197
Vous pouvez également relire des entrées déjà traduites pour vous faire une
198
198
idée, et passer ensuite à la traduction de celles qui ne le sont pas encore.
@@ -215,12 +215,12 @@ Réserver le fichier
215
215
Une fois que vous avez choisi un fichier sur lequel travailler vous pouvez nous
216
216
le signaler par différents moyens :
217
217
218
- * Soit en ouvrant un `ticket sur Github <https://github.com/python /python-docs-fr/issues>`_
218
+ * Soit en ouvrant un `ticket sur Gitea <https://git.afpy.org/AFPy /python-docs-fr/issues>`_
219
219
en indiquant dans le titre ``Je travaille sur DOSSIER/FICHIER.po``
220
220
(par exemple « Je travaille sur library/sys.po »).
221
221
222
- Ceci permet à `potodo`_ de détecter via l' API Github les fichiers ` ` .po` ` réservés
223
- dans les tickets et les * pull requests * .
222
+ Ceci permet à `potodo`_ de détecter via l' API Gitea les fichiers ` ` .po` ` réservés
223
+ dans les tickets et les demandes d ' ajout .
224
224
225
225
* Soit en créant un sujet sur le
226
226
`discuss de l' AFPy < https://discuss.afpy.org/> ` _ dans la section Traduction
@@ -252,7 +252,7 @@ fichier sur lequel on travaille. Par exemple, si vous travaillez sur
252
252
253
253
.. code-block:: bash
254
254
255
- git checkout -b library-sys upstream/3.11
255
+ git switch -c library-sys upstream/3.11
256
256
257
257
258
258
@@ -300,7 +300,7 @@ compilation ne devrait pas échouer.
300
300
make
301
301
302
302
303
- Vérifiez alors le rendu de la traduction « en vrai ». Lancez un serveur de
303
+ Vérifiez alors le rendu de la traduction « en vrai ». Lancez un serveur de
304
304
documentation local :
305
305
306
306
.. code-block:: bash
@@ -317,14 +317,14 @@ Vous pouvez recommencer les étapes de cette section autant de fois que
317
317
nécessaire.
318
318
319
319
Poedit donne beaucoup d'avertissements, par exemple pour vous informer que
320
- « la traduction devrait commencer par une majuscule » car c' est le cas pour
320
+ « la traduction devrait commencer par une majuscule » car c'est le cas pour
321
321
la source. Ces avertissements ne sont pas tous fondés. En cas de doute,
322
322
*affichez et relisez la page HTML produite* avec ` ` make htmlview` ` .
323
323
324
324
Quatrième étape : publier sa traduction
325
325
=======================================
326
326
327
- Une fois que le * make verifs* ne lève pas d' erreur et que vous êtes certains de bien respecter les
327
+ Une fois que le ` ` make verifs` ` ne lève pas d'erreur et que vous êtes certains de bien respecter les
328
328
` Conventions` _ de traduction, vient le moment d'envoyer votre travail sur le dépôt local.
329
329
330
330
* ` ` git add` ` place nos modifications dans l'index de Git en attendant
@@ -343,34 +343,35 @@ Une fois que le *make verifs* ne lève pas d'erreur et que vous êtes certains d
343
343
344
344
345
345
346
- Poussez ensuite vos modifications sur votre *fork* avec ``git push``.
346
+ Poussez ensuite vos modifications sur votre bifurcation ( *fork*) avec ` ` git push` ` .
347
347
Le ` ` -u` ` n'est utile qu'une fois pour que votre client git se souvienne que cette
348
- branche est liée à votre *fork* (et donc que vos futurs ``git pull`` et
348
+ branche est liée à votre bifurcation (et donc que vos futurs ` ` git pull` ` et
349
349
` ` git push` ` sachent quoi tirer).
350
350
351
351
.. code-block:: bash
352
352
353
353
git push --set-upstream origin
354
354
355
- Sur Github
356
- ----------
355
+ Sur Gitea
356
+ ---------
357
357
358
- La commande précédente vous affiche un lien pour ouvrir une *pull request* sur
359
- Github . Si vous l' avez manqué, allez simplement sur https://github.com/python/python-docs-fr/pulls
360
- et un joli bouton « Compare & pull request » devrait apparaître au bout de
361
- quelques secondes vous indiquant que vous pouvez demander une * pull request * .
358
+ La commande précédente vous affiche un lien pour ouvrir une demande d'ajout sur
359
+ Gitea . Si vous l'avez manqué, allez simplement sur
360
+ https://git.afpy.org/AFPy/python-docs-fr/pulls et cliquez
361
+ sur le bouton « Nouvelle demande d'ajout » .
362
362
363
- Mettez dans le commentaire de la * pull request* le texte suivant :
364
- « Closes # XXXX » où XXXX est le numéro du ticket GitHub créé pour réserver le fichier traduit.
365
- Cela permet à Github de lier la *pull request* au ticket de réservation.
363
+ Mettez dans le commentaire de la demande d'ajout le texte suivant :
364
+ « Closes #XXXX » où XXXX est le numéro du ticket Gitea créé pour réserver le
365
+ fichier traduit. Cela permet à Gitea de lier la demande d'ajout au ticket de
366
+ réservation.
366
367
367
- Il peut arriver que vous ayez besoin de reprendre votre PR sur votre
368
- ordinateur après avoir fait des modifications en ligne sur GitHub ,
369
- par exemple lorsque GitHub vous offre la possibilité de faire un commit
368
+ Il peut arriver que vous ayez besoin de reprendre votre demande d'ajout sur votre
369
+ ordinateur après avoir fait des modifications en ligne sur Gitea ,
370
+ par exemple lorsque Gitea vous offre la possibilité de faire un commit
370
371
automatique contenant les suggestions proposées pendant la revue.
371
372
Cela fonctionne bien, mais le résultat n'est pas toujours accepté par
372
373
` ` powrap` ` . Si cela arrive, vous pouvez récupérer le commit fait par
373
- GitHub puis relancer ` ` powrap` ` :
374
+ Gitea puis relancer ` ` powrap` ` :
374
375
375
376
.. code-block:: bash
376
377
@@ -380,50 +381,16 @@ GitHub puis relancer ``powrap`` :
380
381
git commit -m "Formatage après commit automatique"
381
382
git push
382
383
383
- Sur une autre forge
384
- -------------------
385
-
386
- Quand vous avez poussé vos modifications, il y a plusieurs possibilités.
387
-
388
- Soit vous signalez via le ` discuss de l'AFPy <https://discuss.afpy.org/>` _ ou sur IRC que
389
- vous avez traduit une section. Nous viendrons récupérer les modifications pour les intégrer
390
- sur Github.
391
-
392
- Soit en créant un * ` bundle <https://git-scm.com/book/fr/v2/Utilitaires-Git-Empaquetage-bundling>` _* Git,
393
- pour cela, il faut créer un fichier contenant les différentes modifications effectuées.
394
-
395
- .. code-block:: bash
396
-
397
- git bundle create < name> .bundle < commit_id1> ..< commit_id2>
398
-
399
- Puis nous partager ce * bundle* sur le ` discuss de l'AFPy <https://discuss.afpy.org/>` _ pour pouvoir l' intégrer.
400
-
401
-
402
- À partir de là, quelqu' un passera en revue vos modifications, et vous fera des
403
- suggestions et corrections. Pour les prendre en compte, retournez sur votre branche
404
- contenant le fichier concerné (au cas où vous auriez commencé quelque chose d' autre
405
- sur une autre branche) :
406
-
407
- .. code-block:: bash
408
-
409
- git checkout library-sys
410
- git pull # pour rapatrier les modifications que vous auriez acceptées
411
- # sur l' interface web.
412
-
413
- # Réglez les problèmes, puis commitez à nouveau :
414
- git commit --all --message " prise en compte des remarques"
415
- git push
416
-
417
384
418
385
Vous avez peut-être remarqué que cela ressemble à un triangle, avec un
419
- segment manquant :
386
+ segment manquant :
420
387
421
- - vous récupérez depuis * upstream* (le dépôt commun public sur Github ) ;
422
- - vous poussez sur * origin* (votre clone sur Github ).
388
+ - vous récupérez depuis *upstream* (le dépôt commun public sur Gitea ) ;
389
+ - vous poussez sur *origin* (votre clone sur Gitea ).
423
390
424
391
C'est le travail de quelqu'un d'autre d'ajouter le dernier segment,
425
392
de votre *origin* au *upstream* public, pour « boucler la boucle ». C'est le
426
- rôle des personnes qui * fusionnent* les *pull requests* après les avoir relues.
393
+ rôle des personnes qui fusionnent les demandes d'ajout après les avoir relues.
427
394
428
395
Vous avez peut-être aussi remarqué que vous n'avez jamais commité sur une
429
396
branche de version (3.9, 3.10, etc.), seulement récupéré les
@@ -842,7 +809,7 @@ En novembre 2022, le dépôt de cette traduction a migré de GitHub à une
842
809
instance de Gitea hébergée par l' AFPy. Si vous contribuiez auparavant
843
810
sur GitHub, voici comment s' y prendre pour la migration :
844
811
845
- - Suivez le guide `plus haut <cloner_>`_ pour faire une copie (*fork*)
812
+ - Suivez le guide `plus haut <cloner_>`_ pour faire une bifurcation (*fork*)
846
813
du dépôt sur Gitea. De manière facultative mais recommandée, ajoutez
847
814
votre clé SSH à votre profil Gitea comme expliqué ci-dessus (vous
848
815
aviez probablement une clé sur GitHub, auquel cas il suffit de
0 commit comments