[Translation WIP] Official French Translation from Vuejs-FR

docs/fr/SUMMARY.md

@@ -7,11 +7,11 @@
 - [Vous cherchez la documentation de la v1.0 ?](https://github.com/vuejs/vuex/tree/1.0/docs)
 - [Release Notes](https://github.com/vuejs/vuex/releases)
 - [Installation](installation.md)
-- [Qu'est-ce que Vuex ?](intro.md)
-- [Débuter](getting-started.md)
+- [Vuex, qu'est-ce que c'est ?](intro.md)
+- [Pour commencer](getting-started.md)
 - Concepts de base
-  - [State](state.md)
-  - [Getters](getters.md)
+  - [État](state.md)
+  - [Accesseurs](getters.md)
   - [Mutations](mutations.md)
   - [Actions](actions.md)
   - [Modules](modules.md)

docs/fr/actions.md

@@ -2,7 +2,7 @@
 
 Les actions sont similaires aux mutations, à la différence que :
 
-- Au lieu de modifier le state, les actions committent des mutations.
+- Au lieu de modifier l'état, les actions actent des mutations.
 - Les actions peuvent contenir des opérations asynchrones.
 
 Enregistrons une simple action :
@@ -25,9 +25,9 @@ const store = new Vuex.Store({
 })
 ```
 
-Les handlers d'action reçoivent un objet contexte qui expose le même set de méthodes/propriétés que l'instance du store, donc vous pouvez appeler `context.commit` pour commiter une mutation, ou accéder au state et aux getters via `context.state` et `context.getters`. Nous verrons pourquoi cet objet contexte n'est pas l'instance du store elle-même lorsque nous présenterons les [Modules](moduels.md) plus tard.
+Les gestionnaires d'action reçoivent un objet contexte qui expose le même ensemble de méthodes et propriétés que l'instance du store, donc vous pouvez appeler `context.commit` pour acter une mutation, ou accéder à l'état et aux accesseurs via `context.state` et `context.getters`. Nous verrons pourquoi cet objet contexte n'est pas l'instance du store elle-même lorsque nous présenterons les [Modules](modules.md) plus tard.
 
-En pratique, nous utilisons souvent la [destructuration d'argument](https://github.com/lukehoban/es6features#destructuring) (*argument destructuring*) pour simplifier quelque peu le code (particulièrement si nous avons besoin d'appeler `commit` plusieurs fois) :
+En pratique, nous utilisons souvent la [destructuration d'argument](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Affecter_par_d%C3%A9composition) pour simplifier quelque peu le code (particulièrement si nous avons besoin d'appeler `commit` plusieurs fois) :
 
 ``` js
 actions: {
@@ -37,7 +37,7 @@ actions: {
 }
 ```
 
-### Dispatcher des actions dans les composants
+### Propager des actions dans les composants
 
 Les actions sont déclenchées par la méthode `store.dispatch` :
 
@@ -57,47 +57,48 @@ actions: {
 }
 ```
 
-Les actions prennent en charge le même format de payload et *object-style dispatch* :
+Les actions prennent également en charge les paramètres additionnels (« payload ») et les objets pour propager :
 
 ``` js
-// dispatcher avec un payload
+// propager avec un paramètre additionnel
 store.dispatch('incrementAsync', {
   amount: 10
 })
 
-// dispatcher avec un object
+// propager avec un objet
 store.dispatch({
   type: 'incrementAsync',
   amount: 10
 })
 ```
 
-Un exemple plus pratique d'une application du monde réel serait une action pour check-out un panier d'achats, ce qui implique **d'appeler une API asynchrone** et de **comitter de multiples mutations** :
+Un exemple concret d'application serait une action pour vider un panier d'achats, ce qui implique **d'appeler une API asynchrone** et d'**acter de multiples mutations** :
 
 ``` js
 actions: {
   checkout ({ commit, state }, products) {
     // sauvegarder les articles actuellement dans le panier
     const savedCartItems = [...state.cart.added]
-    // envoyer la requête de checkout, et vider le panier
+    // envoyer la requête de checkout,
+    // et vider le panier
     commit(types.CHECKOUT_REQUEST)
-    // l'API du shop prend un callback success et un callback failure
+    // l'API de la boutique en ligne prend une fonction de rappel en cas de succès et une autre en cas d'échec
     shop.buyProducts(
       products,
-      // handle success
+      // gérer le succès
       () => commit(types.CHECKOUT_SUCCESS),
-      // handle failure
+      // gérer l'échec
       () => commit(types.CHECKOUT_FAILURE, savedCartItems)
     )
   }
 }
 ```
 
-Notez que nous procédons à un flux d'opérations asynchrones, et enregistrons les effets de bord (mutation du state) de l'action en les committant.
+Notez que nous procédons à un flux d'opérations asynchrones, et enregistrons les effets de bord (mutation de l'état) de l'action en les actant.
 
-### Dispatcher des actions dans les composants
+### Propager des actions dans les composants
 
-Vous pouvez dispatcher des actions dans les composants avec `this.$store.dispatch('xxx')`, ou en utilisant le helper `mapActions` qui attache les méthodes du composant aux appels de `store.dispatch` (nécessite l'injection de `store` à la racine) :
+Vous pouvez propager des actions dans les composants avec `this.$store.dispatch('xxx')`, ou en utilisant la fonction utilitaire `mapActions` qui attache les méthodes du composant aux appels de `store.dispatch` (nécessite l'injection de `store` à la racine) :
 
 ``` js
 import { mapActions } from 'vuex'
@@ -106,10 +107,13 @@ export default {
   // ...
   methods: {
     ...mapActions([
-      'increment' // attacher this.increment() à this.$store.dispatch('increment')
+      'increment' // attacher `this.increment()` à `this.$store.dispatch('increment')`
+
+      // `mapActions` supporte également les paramètres additionnels :
+      'incrementBy' // attacher `this.incrementBy(amount)` à `this.$store.dispatch('incrementBy', amount)`
     ]),
     ...mapActions({
-      add: 'increment' // attacher this.add() à this.$store.dispatch('increment')
+      add: 'increment' // attacher `this.add()` à `this.$store.dispatch('increment')`
     })
   }
 }
@@ -119,7 +123,7 @@ export default {
 
 Les actions sont souvent asynchrones, donc comment savoir lorsqu'une action est terminée ? Et plus important, comment composer plusieurs actions ensemble pour manipuler des flux asynchrones plus complexes ?
 
-La première chose à savoir est que `store.dispatch` retourne la valeur retournée par le handler de l'action déclenchée, vous pouvez donc retourner une Promise :
+La première chose à savoir est que `store.dispatch` peut gérer la Promesse (« Promise ») retournée par le gestionnaire d'action déclenché et par conséquent vous pouvez également retourner une Promesse :
 
 ``` js
 actions: {
@@ -158,17 +162,17 @@ actions: {
 Pour finir, nous pouvons utiliser de [async / await](https://tc39.github.io/ecmascript-asyncawait/), une fonctionnalité JavaScript qui sera disponible très bientôt, nous pouvons composer nos actions ainsi :
 
 ``` js
-// sachant que getData() et getOtherData() retournent des Promises
+// sachant que `getData()` et `getOtherData()` retournent des Promesses.
 
 actions: {
   async actionA ({ commit }) {
     commit('gotData', await getData())
   },
   async actionB ({ dispatch, commit }) {
-    await dispatch('actionA') // wait for actionA to finish
+    await dispatch('actionA') // attendre que `actionA` soit finie
     commit('gotOtherData', await getOtherData())
   }
 }
 ```
 
-> Il est possible pour un `store.dispatch` de déclencher plusieurs handlers d'action dans différents modules. Dans ce genre de cas, la valeur retournée sera une Promise qui se résoud quand tous les handlers déclenchés ont été résolus.
+> Il est possible pour un `store.dispatch` de déclencher plusieurs gestionnaires d'action dans différents modules. Dans ce genre de cas, la valeur retournée sera une Promesse qui se résoud quand tous les gestionnaires déclenchés ont été résolus.

docs/fr/getters.md

@@ -1,7 +1,6 @@
+# Accesseurs
 
-# Getters
-
-Parfois nous avons besoin de calculer des valeurs basées sur le state du store, par exemple pour filtrer une liste d'éléments et les compter :
+Parfois nous avons besoin de calculer des valeurs basées sur l'état du store, par exemple pour filtrer une liste d'éléments et les compter :
 
 ``` js
 computed: {
@@ -11,9 +10,11 @@ computed: {
 }
 ```
 
-Si plus d'un composant a besoin d'utiliser cela, il nous faut ou bien dupliquer cette fonction, ou bien l'extraire dans un helper séparé et l'importer aux endroits nécessaires — les deux idées sont loin d'être idéales.
+Si plus d'un composant a besoin d'utiliser cela, il nous faut ou bien dupliquer cette fonction, ou bien l'extraire dans une fonction utilitaire séparée et l'importer aux endroits nécessaires. Les deux idées sont loin d'être idéales.
+
+Vuex nous permet de définir des accesseurs (« getters ») dans le store. Voyez-les comme les propriétés calculées des stores. Comme pour les propriétés calculées, le résultat de l'accesseur est mis en cache en se basant sur ses dépendances et il ne sera ré-évalué quand l'une de ses dépendances aura changé.
 
-Vuex nous permet de définir des "getters" dans le store (voyez-les comme les computed properties des store). Les getters prennent le state en premier argument :
+Les accesseurs prennent l'état en premier argument :
 
 ``` js
 const store = new Vuex.Store({
@@ -31,13 +32,13 @@ const store = new Vuex.Store({
 })
 ```
 
-Les getters seront exposé sur l'objet `store.getters` :
+Les accesseurs seront exposés sur l'objet `store.getters` :
 
 ``` js
 store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
 ```
 
-Les getters recevront également les autres getters en second argument :
+Les accesseurs recevront également les autres accesseurs en second argument :
 
 ``` js
 getters: {
@@ -62,17 +63,32 @@ computed: {
 }
 ```
 
-### Le helper `mapGetters`
+Vous pouvez aussi passer des arguments aux accesseurs en retournant une fonction. Cela est particulièrement utile quand vous souhaitez interroger un tableau dans le store :
+
+```js
+getters: {
+  // ...
+  getTodoById: (state, getters) => (id) => {
+    return state.todos.find(todo => todo.id === id)
+  }
+}
+```
+
+``` js
+store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
+```
+
+### La fonction utilitaire `mapGetters`
 
-Le helper `mapGetters` attache simplement vos getters du store aux computed properties locales :
+La fonction utilitaire `mapGetters` attache simplement vos accesseurs du store aux propriétés calculées locales :
 
 ``` js
 import { mapGetters } from 'vuex'
 
 export default {
   // ...
   computed: {
-    // rajouter les getters dans computed avec l'object spread operator
+    // rajouter les accesseurs dans `computed` avec l'opérateur de décomposition
     ...mapGetters([
       'doneTodosCount',
       'anotherGetter',
@@ -82,11 +98,11 @@ export default {
 }
 ```
 
-Si vous voulez attacher un getter avec un nom différent, utilisez un objet :
+Si vous voulez attacher un accesseur avec un nom différent, utilisez un objet :
 
 ``` js
-mapGetters({
-  // attacher this.doneCount à store.getters.doneTodosCount
+...mapGetters({
+  // attacher `this.doneCount` à `store.getters.doneTodosCount`
   doneCount: 'doneTodosCount'
 })
 ```

docs/fr/getting-started.md

@@ -1,19 +1,19 @@
-# Débuter
+# Pour commencer
 
-Au cœur de chaque application Vuex, il y a le **store**. Un "store" est tout simplement un conteneur avec le **state** de votre application. Il y a deux choses qui différencient un store Vuex d'un simple objet global :
+Au cœur de chaque application Vuex, il y a la **zone de stockage (« store »)**. Un « store » est tout simplement un conteneur avec l'**état (« state »)** de votre application. Il y a deux choses qui différencient un store Vuex d'un simple objet global :
 
-1. Les stores Vuex sont réactifs. Quand les composants Vue y récupèrent le state, ils modifieront efficacement et de façon réactive si le state du store change.
+1. Les stores Vuex sont réactifs. Quand les composants Vue y récupèrent l'état, ils se mettront à jour de façon réactive et efficace si l'état du store a changé.
 
-2. Vous ne pouvez pas muter directement le state du store. La seule façon de modifier le state d'un store est de **commiter** explicitement des **mutations**. Cela assure que chaque état laisse un enregistrement traçable, et permette à des outils de mieux nous aider à comprendre nos applications.
+2. Vous ne pouvez pas muter directement l'état du store. La seule façon de modifier l'état d'un store est d'**acter (« commit »)** explicitement des **mutations**. Cela assure que chaque état laisse un enregistrement traçable, et permet à des outils de nous aider à mieux appréhender nos applications.
 
 ### Le store le plus simple
 
 > **NOTE:** Nous allons utiliser la syntaxe ES2015 dans les exemples de code pour le reste de la documentation. Si vous ne vous êtes pas encore penché dessus, [vous devriez](https://babeljs.io/docs/learn-es2015/) !
 
-Après [avoir installé](installation.md) Vuex, nous allons créer un store. C'est assez simple — définissez juste un objet state initial et quelques mutations :
+Après [avoir installé](installation.md) Vuex, nous allons créer un store. C'est assez simple ; définissez juste un objet d'état initial et quelques mutations :
 
 ``` js
-// Make sure to call Vue.use(Vuex) first if using a module system
+// Assurez vous d'appeler `Vuex.use(Vuex)` en premier lieu si vous utilisez un système de module
 
 const store = new Vuex.Store({
   state: {
@@ -27,18 +27,18 @@ const store = new Vuex.Store({
 })
 ```
 
-Maintenant, vous pouvez accéder à l'objet state avec `store.state`, et déclencher un changement de state avec la méthode `store.commit` :
+Maintenant, vous pouvez accéder à l'objet d'état avec `store.state`, et déclencher un changement d'état avec la méthode `store.commit` :
 
 ``` js
 store.commit('increment')
 
 console.log(store.state.count) // -> 1
 ```
 
-Encore une fois, la raison pour laquelle nous committons une mutation au lieu de modifier `store.state.count` directement, c'est parce que nous voulons le tracer explicitement. Cette simple convention rend votre intention plus explicite, ainsi vous pouvez raisonner plus facilement les changements de state en lisant votre code. De plus, cela nous donne l'opportunité d'implémenter des outils qui peuvent enregistrer chaque mutation, prendre des instantanés du state, ou même procéder à du debugging dans le temps.
+Encore une fois, la raison pour laquelle nous actons une mutation au lieu de modifier `store.state.count` directement, c'est parce que nous voulons le tracer explicitement. Cette simple convention rend votre intention plus explicite, ainsi vous pouvez raisonner plus facilement les les changements d'état en lisant votre code. De plus, cela nous donne l'opportunité d'implémenter des outils qui peuvent enregistrer chaque mutation, prendre des instantanés de l'état, ou même procéder à de la visualisation d'état dans le temps.
 
-Utiliser le state du store dans un composant implique simplement de retourner le state dans une *computed property*, car le state du store est réactif. Déclencher des changements signifie simplement commiter des mutations dans les méthodes du composant.
+Utiliser l'état du store dans un composant implique simplement de retourner l'état dans une *propriété calculée*, car l'état du store est réactif. Déclencher des changements signifie simplement d'acter des mutations dans les méthodes du composant.
 
-Voici un exemple de la [plus basique app Vuex de compteur](https://jsfiddle.net/n9jmu5v7/1269/).
+Voici un exemple de l'[application de comptage Vuex la plus basique](https://jsfiddle.net/n9jmu5v7/1269/).
 
-Ensuite, nous allons examiner chaque concept de base plus en détails, et commençons avec le [State](state.md).
+Ensuite, nous allons examiner chaque concept de base plus en détails, et commençons avec l'[État](state.md).