From 289868301f5c658be82212e1db6cfef17df467d0 Mon Sep 17 00:00:00 2001 From: zapashcanon Date: Wed, 21 Jun 2017 00:21:18 +0200 Subject: [PATCH] Fix french translation --- source/fr/1.0.0/index.html.haml | 60 ++++++++++++++++----------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/source/fr/1.0.0/index.html.haml b/source/fr/1.0.0/index.html.haml index c90ff33..c5b3a62 100644 --- a/source/fr/1.0.0/index.html.haml +++ b/source/fr/1.0.0/index.html.haml @@ -33,7 +33,7 @@ version: 1.0.0 Qu'est-ce qu'un changelog ? %p - Un changelog (journal de modifications) est un fichier qui contient + Un changelog (journal des modifications) est un fichier qui contient une liste triée chronologiquement des changements notables pour chaque version d’un projet @@ -42,8 +42,8 @@ version: 1.0.0 Pourquoi tenir un changelog ? %p - Pour permettre aux utilisateurs et contributeurs de voir précisement - quel changements notables ont été faits entre chaque publication + Pour permettre aux utilisateurs et contributeurs de voir précisément + quels changements notables ont été faits entre chaque publication (ou version) d'un projet. %h3#who @@ -51,10 +51,10 @@ version: 1.0.0 Qui a besoin d'un changelog ? %p - Tout le monde. Qu'ils soient consomateurs ou developeurs, les + Tout le monde. Qu'ils soient consommateurs ou développeurs, les utilisateurs de logiciels sont des êtres humains qui se soucient de connaître le contenu des logiciels qu'ils utilisent. Quand un - logiciel change, ces même personnes veulent savoir comment et pourquoi. + logiciel change, ces mêmes personnes veulent savoir comment et pourquoi. .good-practices %h3#how @@ -69,7 +69,7 @@ version: 1.0.0 %li Les changelogs sont pour les êtres humains, pas les machines. %li - Il doit il y avoir une section pour chaque version. + Il doit y avoir une section pour chaque version. %li Les changements similaires doivent être groupés. %li @@ -102,7 +102,7 @@ version: 1.0.0 pour les corrections de bugs. %li %code Security - en cas de vulnerabilités. + en cas de vulnérabilités. .effort @@ -114,11 +114,11 @@ version: 1.0.0 Gardez une section Unreleased en haut du fichier afin de lister tous les changements qui n'ont pas encore été publiés. - %p Cela rempli deux objectifs: + %p Cela permet deux choses: %ul %li - Les gens peuvent voir les changements auxquels ils peuvent s’attendrent + Les gens peuvent voir les changements auxquels ils peuvent s’attendre dans les prochaines publications. %li Au moment de la publication, vous pouvez déplacer les changements listés @@ -134,12 +134,12 @@ version: 1.0.0 %h4#log-diffs %a.anchor{ href: "#log-diffs", aria_hidden: "true" } - Diffs de journaux git + Diffs de journaux gits %p - Utiliser des diffs de journaux git en tant que changelogs est une mauvaise - idée: ils sont remplis de bruit. Les journaux git sont remplis de choses - comme des commits de merge, des commits avec des titres obscures, des + Utiliser des diffs de journaux gits en tant que changelogs est une mauvaise + idée: ils sont remplis de bruit. Les journaux gits sont remplis de choses + comme des commits de merge, des commits avec des titres obscurs, des changements concernant la documentation, etc. %p @@ -147,9 +147,9 @@ version: 1.0.0 source. Certains projets nettoient leurs commits, d'autres non. %p - Le but d'une section de changelog est de documenter la difference notable - entre deux versions, souvent à travers de multiples commits, afin de la - communiquer clairement aux utilisateurs. + Le but d'une section de changelog est de documenter les différences + notables entre deux versions, souvent à travers de multiples + commits, afin de les communiquer clairement aux utilisateurs. %h4#ignoring-deprecations %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } @@ -157,7 +157,7 @@ version: 1.0.0 %p Lorsque l'on passe d'une version d'un logiciel à une autre, il devrait être - très clair si quelque chose peut ne pas fonctionner. Il devrait être + très clair si quelque chose peut ne plus fonctionner. Il devrait être possible de mettre à jour vers un version qui offre une liste des fonctionnalités dépréciées, de retirer ce qui est déprécié, puis de mettre à jour vers la version où les dépréciations deviennent des suppressions de @@ -180,10 +180,10 @@ version: 1.0.0 prononcent différement. 2012-06-02 fonctionne logiquement, du plus grand au plus petit, ne laisse pas place à la confusion avec un autre format et est un #{link_to "standard ISO", iso}. C'est pour cela que ce format de date - est recommandé pour les change logs. + est recommandé pour les changelogs. %aside - Il y en a d’autres. Aidez-moi à collecter ces anti-patrons en + Il y en a d’autres. Aidez-moi à collecter ces antipatrons en #{link_to "ouvrant une issue", "#issues"} ou une pull request. .frequently-asked-questions @@ -198,7 +198,7 @@ version: 1.0.0 %p Pas vraiment. Il y a le guide de style GNU pour les changelogs, ou les instructions GNU de deux paragraphes pour les fichiers NEWS. Ces deux - resources sont inappropriées et insuffisantes. + ressources sont inappropriées et insuffisantes. %p Ce projet vise à devenir @@ -213,16 +213,16 @@ version: 1.0.0 %h4#filename %a.anchor{ href: "#filename", aria_hidden: "true" } - Comment doit-être nommé le fichier de change log ? + Comment doit-être nommé le fichier de changelog ? %p - Nommez le CHANGELOG.md. Certains projects utilisent + Nommez-le CHANGELOG.md. Certains projets utilisent HISTORY, NEWS ou RELEASES. %p Même s'il est facile d'imaginer que le nom d'un fichier de changelog n'a - pas grant interêt, pourquoi rendre la tâche difficile que nécessaire pour - les utilisateurs qui cherchent à trouver les changements notables de votre + pas grand intérêt, pourquoi rendre la tâche plus difficile que nécessaire + aux utilisateurs qui cherchent à trouver les changements notables de votre projet ? %h4#github-releases @@ -238,19 +238,19 @@ version: 1.0.0 %p GitHub Releases crée un changelog non-portable qui n'est visible par les - utilisateurs qu'à l'interieur du context de GitHub. Il est possible de + utilisateurs qu'à l'intérieur du contexte de GitHub. Il est possible de suivre le même format que Keep a Changelog, mais c'est plus difficile. %p La version actuelle de GitHub Releases est également difficile à découvrir pour les utilisateurs, contrairement aux fichiers en majuscules typiques - (README, CONTRIBUTING, etc.). Un autre soucis - mineur est que l'interface ne permet pas actuellement d'offrir des liens - vers les journaux git entre chaque publication. + (README, CONTRIBUTING, etc.). Un autre souci + mineur est que l'interface n'offre actuellement pas de lien vers les + journaux gits entre chaque publication. %h4#automatic %a.anchor{ href: "#automatic", aria_hidden: "true" } - Les change logs peuvent-ils être parsés automatiquement ? + Les changelogs peuvent-ils être parsés automatiquement ? %p C'est difficile, parce que les gens suivent des formats et utilisent des noms @@ -258,7 +258,7 @@ version: 1.0.0 %p #{link_to "Vandamme", vandamme} est une Ruby gem créée par l'équipe - #{link_to "Gemnasium", gemnasium} qui parse les change logs de + #{link_to "Gemnasium", gemnasium} qui parse les changelogs de beaucoup (mais pas tous) de projets open source.