AFPy/python-docs-fr
AFPy/python-docs-fr
Fork 80
Code Issues 6 Pull requests 10 Activity

Passage à gitea (#51)

Browse source 
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: #51 Co-authored-by: Vincent Poulailleau <vpoulailleau@gmail.com> Co-committed-by: Vincent Poulailleau <vpoulailleau@gmail.com>
This commit is contained in:
Vincent Poulailleau 2023-02-16 15:07:53 +00:00 • committed by Julien Palard
commit 9a60e67cd0
1 changed files with 31 additions and 64 deletions
Download patch file Download diff file Expand all files Collapse all files

95
CONTRIBUTING.rst
View file

@ -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
dans les tickets et les *pull requests*.
Ceci permet à `potodo`_ de détecter via l'API Gitea les fichiers ``.po`` réservés
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
Github. Si vous l'avez manqué, allez simplement sur https://github.com/python/python-docs-fr/pulls
et un joli bouton « Compare & pull request » devrait apparaître au bout de
quelques secondes vous indiquant que vous pouvez demander une *pull request*.
La commande précédente vous affiche un lien pour ouvrir une demande d'ajout sur
Gitea. Si vous l'avez manqué, allez simplement sur
https://git.afpy.org/AFPy/python-docs-fr/pulls et cliquez
sur le bouton « Nouvelle demande d'ajout ».
Mettez dans le commentaire de la *pull request* le texte suivant :
« Closes #XXXX » où XXXX est le numéro du ticket GitHub créé pour réserver le fichier traduit.
Cela permet à Github de lier la *pull request* au ticket de réservation.
Mettez dans le commentaire de la demande d'ajout le texte suivant :
« Closes #XXXX » où XXXX est le numéro du ticket Gitea créé pour réserver le
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
ordinateur après avoir fait des modifications en ligne sur GitHub,
par exemple lorsque GitHub vous offre la possibilité de faire un commit
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 Gitea,
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 poussez sur *origin* (votre clone sur Github).
- vous récupérez depuis *upstream* (le dépôt commun public sur Gitea) ;
- 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