Passage à gitea (#51)

Closes #41

C'est ma première PR sur Gitea, j'ai donc essayé de décrire le nouveau process. N'hésitez pas à commenter…

Co-authored-by: Julien Palard <julien@palard.fr>
Reviewed-on: AFPy/python-docs-fr#51
Co-authored-by: Vincent Poulailleau <vpoulailleau@gmail.com>
Co-committed-by: Vincent Poulailleau <vpoulailleau@gmail.com>

CONTRIBUTING.rst

@@ -1,5 +1,5 @@
-Guide de contribution à la documentation via GitHub
+Guide de contribution à la documentation
-###################################################
+########################################
 
 Prérequis
 =========
@@ -192,7 +192,7 @@ Vous pouvez commencer par des tâches faciles comme réviser les entrées
 de ``make fuzzy``). Une entrée *fuzzy* correspond à une entrée déjà traduite
 mais dont la source en anglais a été modifiée depuis (correction orthographique,
 changement d'un terme, ajout ou suppression d'une phrase…). Elles sont
-généralement plus « faciles » à traduire.
+généralement plus « faciles » à traduire.
 
 Vous pouvez également relire des entrées déjà traduites pour vous faire une
 idée, et passer ensuite à la traduction de celles qui ne le sont pas encore.
@@ -215,12 +215,12 @@ Réserver le fichier
 Une fois que vous avez choisi un fichier sur lequel travailler vous pouvez nous
 le signaler par différents moyens :
 
-* Soit en ouvrant un `ticket sur Github <https://github.com/python/python-docs-fr/issues>`_
+* Soit en ouvrant un `ticket sur Gitea <https://git.afpy.org/AFPy/python-docs-fr/issues>`_
   en indiquant dans le titre ``Je travaille sur DOSSIER/FICHIER.po``
   (par exemple « Je travaille sur library/sys.po »).
 
-Ceci permet à `potodo`_ de détecter via l'API Github les fichiers ``.po`` réservés
+Ceci permet à `potodo`_ de détecter via l'API Gitea les fichiers ``.po`` réservés
-dans les tickets et les *pull requests*.
+dans les tickets et les demandes d'ajout.
 
 * Soit en créant un sujet sur le
   `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
 
 .. code-block:: bash
 
-    git checkout -b library-sys upstream/3.11
+    git switch -c library-sys upstream/3.11
 
 
 
@@ -300,7 +300,7 @@ compilation ne devrait pas échouer.
     make
 
 
-Vérifiez alors le rendu de la traduction « en vrai ». Lancez un serveur de
+Vérifiez alors le rendu de la traduction « en vrai ». Lancez un serveur de
 documentation local :
 
 .. code-block:: bash
@@ -317,14 +317,14 @@ Vous pouvez recommencer les étapes de cette section autant de fois que
 nécessaire.
 
 Poedit donne beaucoup d'avertissements, par exemple pour vous informer que
-« la traduction devrait commencer par une majuscule » car c'est le cas pour
+« la traduction devrait commencer par une majuscule » car c'est le cas pour
 la source. Ces avertissements ne sont pas tous fondés. En cas de doute,
 *affichez et relisez la page HTML produite* avec ``make htmlview``.
 
 Quatrième étape : publier sa traduction
 =======================================
 
-Une fois que le *make verifs* ne lève pas d'erreur et que vous êtes certains de bien respecter les
+Une fois que le ``make verifs`` ne lève pas d'erreur et que vous êtes certains de bien respecter les
 `Conventions`_ de traduction, vient le moment d'envoyer votre travail sur le dépôt local.
 
 * ``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
 
 
 
-Poussez ensuite vos modifications sur votre *fork* avec ``git push``.
+Poussez ensuite vos modifications sur votre bifurcation (*fork*) avec ``git push``.
 Le ``-u`` n'est utile qu'une fois pour que votre client git se souvienne que cette
-branche est liée à votre *fork* (et donc que vos futurs ``git pull`` et
+branche est liée à votre bifurcation (et donc que vos futurs ``git pull`` et
 ``git push`` sachent quoi tirer).
 
 .. code-block:: bash
 
     git push --set-upstream origin
 
-Sur Github
+Sur Gitea
-----------
+---------
 
-La commande précédente vous affiche un lien pour ouvrir une *pull request* sur
+La commande précédente vous affiche un lien pour ouvrir une demande d'ajout sur
-Github. Si vous l'avez manqué, allez simplement sur https://github.com/python/python-docs-fr/pulls
+Gitea. Si vous l'avez manqué, allez simplement sur
-et un joli bouton « Compare & pull request » devrait apparaître au bout de
+https://git.afpy.org/AFPy/python-docs-fr/pulls et cliquez
-quelques secondes vous indiquant que vous pouvez demander une *pull request*.
+sur le bouton « Nouvelle demande d'ajout ».
 
-Mettez dans le commentaire de la *pull request* le texte suivant :
+Mettez dans le commentaire de la demande d'ajout le texte suivant :
-« Closes #XXXX » où XXXX est le numéro du ticket GitHub créé pour réserver le fichier traduit.
+« Closes #XXXX » où XXXX est le numéro du ticket Gitea créé pour réserver le
-Cela permet à Github de lier la *pull request* au ticket de réservation.
+fichier traduit. Cela permet à Gitea de lier la demande d'ajout au ticket de
+réservation.
 
-Il peut arriver que vous ayez besoin de reprendre votre PR sur votre
+Il peut arriver que vous ayez besoin de reprendre votre demande d'ajout sur votre
-ordinateur après avoir fait des modifications en ligne sur GitHub,
+ordinateur après avoir fait des modifications en ligne sur Gitea,
-par exemple lorsque GitHub vous offre la possibilité de faire un commit
+par exemple lorsque Gitea vous offre la possibilité de faire un commit
 automatique contenant les suggestions proposées pendant la revue.
 Cela fonctionne bien, mais le résultat n'est pas toujours accepté par
 ``powrap``. Si cela arrive, vous pouvez récupérer le commit fait par
-GitHub puis relancer ``powrap`` :
+Gitea puis relancer ``powrap`` :
 
 .. code-block:: bash
 
@@ -380,50 +381,16 @@ GitHub puis relancer ``powrap`` :
     git commit -m "Formatage après commit automatique"
     git push
 
-Sur une autre forge
--------------------
-
-Quand vous avez poussé vos modifications, il y a plusieurs possibilités.
-
-Soit vous signalez via le `discuss de l'AFPy <https://discuss.afpy.org/>`_ ou sur IRC que
-vous avez traduit une section. Nous viendrons récupérer les modifications pour les intégrer
-sur Github.
-
-Soit en créant un *`bundle <https://git-scm.com/book/fr/v2/Utilitaires-Git-Empaquetage-bundling>`_* Git,
-pour cela, il faut créer un fichier contenant les différentes modifications effectuées.
-
-.. code-block:: bash
-
-    git bundle create <name>.bundle <commit_id1>..<commit_id2>
-
-Puis nous partager ce *bundle* sur le `discuss de l'AFPy <https://discuss.afpy.org/>`_ pour pouvoir l'intégrer.
-
-
-À partir de là, quelqu'un passera en revue vos modifications, et vous fera des
-suggestions et corrections. Pour les prendre en compte, retournez sur votre branche
-contenant le fichier concerné (au cas où vous auriez commencé quelque chose d'autre
-sur une autre branche) :
-
-.. code-block:: bash
-
-    git checkout library-sys
-    git pull  # pour rapatrier les modifications que vous auriez acceptées
-              # sur l'interface web.
-
-    # Réglez les problèmes, puis commitez à nouveau :
-    git commit --all --message "prise en compte des remarques"
-    git push
-
 
 Vous avez peut-être remarqué que cela ressemble à un triangle, avec un
-segment manquant :
+segment manquant :
 
-- vous récupérez depuis *upstream* (le dépôt commun public sur Github) ;
+- vous récupérez depuis *upstream* (le dépôt commun public sur Gitea) ;
-- vous poussez sur *origin* (votre clone sur Github).
+- vous poussez sur *origin* (votre clone sur Gitea).
 
 C'est le travail de quelqu'un d'autre d'ajouter le dernier segment,
 de votre *origin* au *upstream* public, pour « boucler la boucle ». C'est le
-rôle des personnes qui *fusionnent* les *pull requests* après les avoir relues.
+rôle des personnes qui fusionnent les demandes d'ajout après les avoir relues.
 
 Vous avez peut-être aussi remarqué que vous n'avez jamais commité sur une
 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
 instance de Gitea hébergée par l'AFPy.  Si vous contribuiez auparavant
 sur GitHub, voici comment s'y prendre pour la migration :
 
-- Suivez le guide `plus haut <cloner_>`_ pour faire une copie (*fork*)
+- Suivez le guide `plus haut <cloner_>`_ pour faire une bifurcation (*fork*)
   du dépôt sur Gitea. De manière facultative mais recommandée, ajoutez
   votre clé SSH à votre profil Gitea comme expliqué ci-dessus (vous
   aviez probablement une clé sur GitHub, auquel cas il suffit de