From 88c28d44da0c65db534082ce0abfa91422a3b4de Mon Sep 17 00:00:00 2001 From: Olivier Lacan Date: Tue, 10 Jan 2017 17:40:44 -0500 Subject: [PATCH] Make minor edits to French translation --- source/fr/0.3.0/index.html.haml | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/source/fr/0.3.0/index.html.haml b/source/fr/0.3.0/index.html.haml index 3477e9d..87abdd6 100644 --- a/source/fr/0.3.0/index.html.haml +++ b/source/fr/0.3.0/index.html.haml @@ -28,13 +28,13 @@ version: 0.3.0 ### Pourquoi devrais-je m’en préoccuper ? Parce que les logiciels sont pour les gens. Si vous ne vous en souciez pas, pourquoi contribuez-vous à l’open source ? Il doit sûrement y avoir un - "kernel" (ha!) d’intérêt pour cela quelque part dans votre cher petit + "kernel" (ha!) d’intérêt pour ça quelque part dans votre cher petit cerveau. J’ai [discuté avec Adam Stacoviak et Jerod Santo dans le podcast "The Changelog"][thechangelog] (approprié, non ?) des raisons pour lesquelles les mainteneurs et les contributeurs devraient s’en préoccuper ; - et des motivations derrière ce projet. + également des motivations derrière ce projet. Si vous avez le temps (1:06), l’écoute vaut le coup. ### Qu’est-ce qui fait un bon change log ? @@ -117,7 +117,7 @@ version: 0.3.0 [discussions et les suggestions d'améliorations sont les bienvenues][issues]! ### Comment doit-être nommé le fichier de change log ? - Et bien, si l'exemple ci-dessus ne vous suffit pas à le deviner, + Eh bien, si l'exemple ci-dessus ne vous suffit pas à le deviner, `CHANGELOG.md` est la meilleure convention à ce jour. Certains projets utilisent aussi `HISTORY.txt`, `HISTORY.md`, `History.md`, @@ -128,13 +128,14 @@ version: 0.3.0 repérage par les gens. ### Pourquoi les gens ne recopient pas simplement les derniers logs git ? - Parce que les logs gits sont bruités - par essence. Ils ne peuvent pas faire - office de change log convenable, même dans un hypothétique projet tenu par des - humains parfaits qui ne font jamais la moindre faute de frappe, n'oublient - jamais de committer les nouveaux fichiers, ne manquent jamais aucune partie - d'un refactoring. Le but d'un commit est de document une étape atomique dans - le processus par lequel le code évolue d'un état à un autre. Le but d'un - change log est de documenter les différences notables entre ces états. + Parce que les logs gits sont remplis de bruit - par définition. Ils ne peuvent + pas faire office de change log convenable, même dans un hypothétique projet + tenu par des humains parfaits qui ne font jamais la moindre faute de frappe, + n'oublient jamais de committer les nouveaux fichiers, ne manquent jamais + aucune partie d'un refactoring. Le but d'un commit est de documenter une étape + atomique dans le processus par lequel le code évolue d'un état à un autre. Le + but d'un change log est de documenter les différences notables entre ces + états. La différence entre des bons commentaires et le code lui-même est la même que celle entre un change log et les journaux git: l'un décrit le *pourquoi*, @@ -165,7 +166,7 @@ version: 0.3.0 fichier: journaliser les changements. ### Qu'en est-il des publications "yanked" ? - Les publications yanked sont des version qui ont dû être publiées du fait d'un + Les publications yanked sont des version qui ont dû être retirées du fait d'un sérieux bug ou d'un problème de sécurité. Souvent ces version n'apparaissent même pas dans les change logs. Elles devraient. Voilà comment les afficher: @@ -178,10 +179,10 @@ version: 0.3.0 ### Devriez-vous réécrire un change log ? Bien sûr. Il y a toujours de bonnes raisons d'améliorer un change log. J'ouvre souvent des pull requests pour ajouter des publications manquantes sur - des projets open source avec des changelogs non-maintenus. + des projets open source avec des change logs non-maintenus. - Il est aussi possible que vous découvriez que vous aviez oublié de traiter - d'un changement majeur dans les notes de version. Il est évidemment important + Il est aussi possible que vous découvriez que vous aviez oublié de mentionner + un changement majeur dans les notes de version. Il est évidemment important que vous mettiez votre change log à jour dans ce cas. ### Comment puis-je contribuer ? @@ -191,7 +192,7 @@ version: 0.3.0 je n'ai volontairement pas créé de véritable *publication* ou de liste précise de règles à suivre (comme le fait [SemVer.org][semver], par exemple). - C'est parce que je veux qu enotre communauté atteigne un consensus. Je crois + C'est parce que je veux que notre communauté atteigne un consensus. Je crois que la discussion est aussi importante que le résultat final. Donc s'il vous plaît, [**mettez-vous y**][gh].