feat: Add french translation for 1.0.0-beta.3

content/v1.0.0-beta.3/index.fr.md

@@ -0,0 +1,179 @@
+---
+draft: false
+aliases: ["/fr/"]
+---
+
+# Conventional Commits 1.0.0-beta.3
+
+## Résumé
+
+La spécification de Conventional Commits est une convention légère pour des messages de commite au top.
+Il fournit un ensemble simple de règles pour créer un historique de commite explicite;
+Ce qui facilite l'écriture d'outils automatisés.
+Cette convention est liée à [SemVer](http://semver.org), en décrivant les fonctionnalités, les correctifs et les modifications importantes apportées aux messages des commites.
+
+Le message du commit doit être structuré comme suit:
+
+---
+
+```
+<type>[optional scope]: <description>
+
+[optional body]
+
+[optional footer]
+```
+---
+
+<br />
+Le commit contient les éléments structurels suivants, permettant de communiquer à l’intention des
+consommateurs de votre bibliothèque:
+
+1. **fix:** un commit de _type_ `fix` corrige un bogue dans le code (cela est en corrélation avec
+[`PATCH`](http://semver.org/#summary) en versioning sémantique).
+1. **feat:** un commit de _type_ `feat` introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec  [`MINOR`](http://semver.org/#summary) en versioning sémantique).
+1. **BREAKING CHANGE:** un commit qui a le texte `BREAKING CHANGE:` qui est facultatif au début du texte ou section de pied de page introduit un changement cassant l'API (cela est en corrélation avec [`MAJOR`](http://semver.org/#summary) en versioning sémantique).
+Un changement radical peut faire partie des commits de _type_. par exemple, `fix:`, `feat:` & `chore:` qui sont tous valables, même additionnés les un avec les autres _type_.
+1. Others: commit de _types_ autre que `fix:` et `feat:` sont autorisés, par exemple [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) (basé sur [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommande `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, et d'autres. Nous recommandons également `improvement` pour les commits qui améliorent une implémentation en cours sans ajouter de nouvelle fonctionnalité ou correction de bogue. Remarquez que ces types ne sont pas prescrits par la spécification de Conventional Commits et n'ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu'ils ne comportent une rupture, qui n'est PAS recommandée).
+<br />
+Un scope peut être fournie au type d'un commit, pour fournir des informations contextuelles supplémentaires et
+le contenu entre parenthèses, par exemple, `feat (analyseur): ajoute la possibilité d'analyser' des tableaux`.
+
+## Exemples
+
+### Message de commit avec description et changement radical dans le texte
+```
+feat: permet à l'objet de configuration fourni d'étendre d'autres configurations
+
+BREAKING CHANGE: la clé `extends` dans le fichier de configuration est maintenant utilisée pour étendre d'autres fichiers de configuration
+```
+
+### Message commit sans corps de texte
+```
+docs: correction d'orthographe dans CHANGELOG
+```
+
+### Message commit avec scope
+```
+feat(lang): ajout de la langue polonaise
+```
+
+### Message commit pour un correctif à l'aide d'un numéro d'un issue (facultatif).
+```
+fix: fautes de frappe mineures dans le code
+
+voir le problème pour plus de détails sur les fautes de frappe corrigées
+
+fixes issue #12
+```
+
+## Spécification
+
+Les mots clés ”DOIT” (“MUST”), “NE DOIT PAS” (“MUST NOT”), “REQUIS” (“REQUIRED”), “NE DOIT” (“SHALL”), “NE DOIT PAS” (“SHALL NOT”), “NE DEVRAIT” (“SHOULD”), “NE DEVRAIT PAS” (“SHOULD NOT”), “RECOMMANDÉ” (“RECOMMENDED”), “PEUT” (“MAY”), et “FACULTATIF” (“OPTIONAL”) dans ce document doivent être interprétés comme décrit dans [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
+
+1. Les commits DOIT être préfixés par un type, qui consiste en un nom, `feat`,` fix`, etc.,
+   suivi d'un côlon et d'un espace.
+1. Le type `feat` DOIT être utilisé lorsqu'un commit ajoute une nouvelle fonctionnalité à votre application.
+  ou bibliothèque.
+1. Le type `fix` DOIT être utilisé lorsqu'un commit représente un correctif pour votre application.
+1. Un scope facultative PEUT être fournie après un type. Un scope est une phrase décrivant
+  une section du code encadrée par des parenthèses, par exemple, `fix (analyseur)):`
+1. Une description DOIT suivre immédiatement le préfixe type/scope.
+  La description est une brève description des modifications du code, par exemple,
+  _fix: problème d'analyse d'un tableau lorsque plusieurs espaces étaient contenus dans string._
+1. Un texte plus long PEUT être fourni après la description courte, fournissant des informations contextuelles supplémentaires sur les modifications du code. Le texte DOIT commencer par une ligne vide après la description.
+1. Un pied de page PEUT être fourni une ligne vierge après le texte (ou après la description si le texte manque).
+  Le pied de page DEVRAIT contenir des références de problèmes supplémentaires concernant les modifications du code (telles que les problèmes qu’il corrige, par exemple, `Fixes #13`).
+1. Les changements de rupture DOIVENT être indiqués au tout début du pied de page ou de la section du corps de texte d'un commit. Un changement radical DOIT être dans le texte en majuscule `BREAKING CHANGE`, suivi de deux points et d'un espace.
+1. Une description DOIT être fournie après le «BREAKING CHANGE:», décrivant
+  la modification de l’API, par exemple, _BREAKING CHANGE: les variables d’environnement sont désormais prioritaires sur les fichiers de configuration._
+1. Le pied de page NE DOIT contenir que «BREAKING CHANGE», des liens externes, des références de publication et d'autres méta-informations.
+1. Des types autres que `feat` et` fix` PEUVENT être utilisés dans vos messages de commit.
+
+## Pourquoi Utiliser Conventional Commits
+
+* Génération automatique de CHANGELOGs.
+* Déterminer automatiquement un choc de version sémantique (en fonction des types de commits débarqués).
+* Communiquer la nature des changements aux coéquipiers, au public et aux autres parties prenantes.
+* Déclencher des processus de construction et de publication.
+* Faciliter la contribution des personnes à vos projets en leur permettant d’explorer
+   un historique de commit plus structurée.
+
+## FAQ
+
+### Comment dois-je gérer les messages de commit dans la phase de développement initiale ?
+
+Nous vous recommandons de procéder comme si vous aviez déjà publié un produit. Généralement *quelqu'un*, même si ce sont vos collègues développeurs de logiciels, utilise votre logiciel. Ils voudront savoir ce qui est corrigé, ce qui casse, etc.
+
+### Les types dans le titre des commites sont-ils en majuscules ou en minuscules?
+
+N'importe quel taille peut être utilisé, mais il est préférable d'être cohérent.
+
+### Que dois-je faire si le commit est conforme à plusieurs types ?
+
+Revenez en arrière et faites plusieurs commits autant que possible. Une partie des avantages de Conventional Commits réside dans sa capacité à nous amener à créer des commits et des relations publiques plus organisés.
+
+### Est-ce que cela ne décourage pas le développement rapide et l’itération rapide ?
+
+Cela décourage les commits rapides de manière désorganisée. Il vous aide à être en mesure que vous commité rapidement à long terme dans plusieurs projets avec des contributeurs variés.
+
+### Les engagements conventionnels peuvent-ils amener les développeurs à limiter le type d’engagements qu’ils font car ils penseront aux types fournis?
+
+Conventional Commits nous encouragent à utiliser davantage certains types de commits tels que les correctifs. En dehors de cela, la flexibilité de Conventional Commits permet à votre équipe de créer ses propres types et de les modifier au fil du temps.
+
+### Quel est le lien avec SemVer ?
+
+Les corrections de type `fix` devraient être traduites en` PATCH`. Les commits de type `feat` devraient être traduits en versions` MINOR`. Les commits avec `BREAKING CHANGE` dans les commits, quel que soit leur type, doivent être traduits en versions` MAJOR`.
+
+### Comment dois-je mettre à jour mes extensions de la spécification de Conventional Commits, par exemple `@jameswomack/conventionnel-commit-spec` ?
+
+Nous vous recommandons d’utiliser SemVer pour publier vos propres extensions à cette spécification (et
+vous encourage à faire ces extensions!)
+
+### Que dois-je faire si j'utilise accidentellement le type de commit incorrect ?
+
+#### Lorsque vous utilisez un type de commit incorrect, par exemple `fix` au lieu de` feat`
+
+Avant de fusionner ou de relâcher l'erreur, nous vous recommandons d'utiliser `git rebase -i` pour éditer l'historique des commits. Après la publication, le nettoyage sera différent selon les outils et les processus que vous utilisez.
+
+#### Lorsque vous utilisez un type qui n'est *pas* dans les spécifications, par exemple `pieds` au lieu de` feat`
+
+Dans le pire des cas, ce n'est pas la fin du monde si un commit atterrit sans respecter les spécifications de Conventional Commits. Cela signifie simplement que l’engagement sera raté par des outils basés sur les spécifications.
+
+### Est-ce que tous mes contributeurs doivent utiliser les spécifications de Conventional Commits ?
+
+Non! Si vous utilisez un flux de travail basé sur squash sur Git, les responsables principaux peuvent nettoyer les messages des commits au fur et à mesure de leur fusion, ce qui permet de ne pas ajouter de charge de travail aux committers occasionnels. Un processus courant consiste à ce que votre système git écrase automatiquement les commits d'une demande d'extraction et présente un formulaire permettant au responsable de la maintenance d'entrer le message du commit git approprié pour la fusion.
+
+## À Propos
+
+La spécifications de Conventional Commits s’inspire largement de [Angular Commit Guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit).
+
+La première version de ces spécifications a été rédigée en collaboration avec certains des les gens qui contribuent à:
+
+* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): Un ensemble d'outils permettant d'analyser les messages des commits classiques à partir des historiques git.
+* [bumped](https://bumped.github.io): Un outil de publication de logiciel qui facilite l'exécution d'actions avant et après la publication d'une nouvelle version de votre logiciel.
+* [unleash](https://github.com/netflix/unleash): Un outil pour automatiser le versioning d'un logiciel et du cycle de publication.
+* [lerna](https://github.com/lerna/lerna): Un outil de gestion de monorepos, qui a grandi du projet Babel.
+
+## Outils pour Conventional Commits
+
+* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): Un outil conçu pour créer des messages de commite en suivant les spécifications de Conventional Commits.
+Configurable et utilisable pour les projets PHP en tant que dépendance composer ou utilisable globalement pour les projets non-PHP.
+* [conform](https://github.com/autonomy/conform): Un outil qui peut être utilisé pour appliquer des stratégies sur les référentiels git, y compris les commites classiques.
+
+## Projets Utilisant Conventional Commits
+
+* [yargs](https://github.com/yargs/yargs): Le parseur d'arguments en ligne de commande sur le thème des pirates préféré de tous.
+* [istanbuljs](https://github.com/istanbuljs/istanbuljs): une collection d'outils open-source
+ et bibliothèques pour ajouter une couverture de test à vos tests JavaScript.
+* [standard-version](https://github.com/conventional-changelog/standard-version): Le versioning automatique et la gestion de CHANGELOG, en  utilisant le nouveau bouton squash de GitHub et le flux de travail Conventional Commits recommandé.
+* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) et [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): Amélioration optionnelle de l'interface utilisateur [Apereo uPortal](https://www.apereo.org/projects/uportal).
+* [massive.js](https://github.com/dmfay/massive-js): Une bibliothèque d'accès aux données pour Node et PostgreSQL.
+* [electron](https://github.com/electron/electron): Créez des applications de bureau multiplates-formes avec JavaScript, HTML et CSS.
+* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): Un utilitaire de défilement simple à utiliser pour le centrage des éléments et des animations fluides.
+* [Blaze UI](https://github.com/BlazeUI/blaze): Framework-free d'outilsmodulaire open source.
+* [Monica](https://github.com/monicahq/monica): Un système de gestion de relations personnelles open source.
+
+[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org)
+
+_envie d'avoir votre projet sur cette liste?_ [envoyer une pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).

content/v1.0.0-beta.3/index.md

@@ -35,6 +35,7 @@ consumers of your library:
 1. **BREAKING CHANGE:** a commit that has the text `BREAKING CHANGE:` at the beginning of its optional body or footer section introduces a breaking API change (correlating with [`MAJOR`](http://semver.org/#summary) in semantic versioning).
 A BREAKING CHANGE can be part of commits of any _type_.
 1. Others: commit _types_ other than `fix:` and `feat:` are allowed, for example [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (based on the [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) recommends `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, and others.
+
 We also recommend `improvement` for commits that improve a current implementation without adding a new feature or fixing a bug.
 Notice these types are not mandated by the conventional commits specification, and have no implicit effect in semantic versioning (unless they include a BREAKING CHANGE).
 <br />