[Doc FR] — All files — French Translation Done (#847)

* Review FR with officials terms

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* Update `NPM` to `npm`

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

* la devient le (@flyusfly)

Signed-off-by: Bruno Lesieur <bruno.lesieur@gmail.com>

docs/en/testing.md

@@ -212,9 +212,9 @@ mocha test-bundle.js
 
 #### Running in Browser
 
-1. Install `mocha-loader`
+1. Install `mocha-loader`.
 2. Change the `entry` from the webpack config above to `'mocha-loader!babel-loader!./test.js'`.
-3. Start `webpack-dev-server` using the config
+3. Start `webpack-dev-server` using the config.
 4. Go to `localhost:8080/webpack-dev-server/test-bundle`.
 
 #### Running in Browser with Karma + karma-webpack

docs/fr/SUMMARY.md

@@ -5,20 +5,20 @@
 <!--/email_off-->
 
 - [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)
+- [Notes de version](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)
 - [Structure d'une application](structure.md)
 - [Plugins](plugins.md)
-- [Strict Mode](strict.md)
-- [Formulaires](forms.md)
+- [Mode strict](strict.md)
+- [Gestion des formulaires](forms.md)
 - [Tests](testing.md)
-- [Hot Reloading](hot-reload.md)
-- [Documentation API](api.md)
+- [Rechargement à chaud](hot-reload.md)
+- [Documentation de l'API](api.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/api.md

@@ -1,6 +1,6 @@
-# Documentation API
+# Documentation de l'API
 
-### Vuex.Store
+### `Vuex.Store`
 
 ``` js
 import Vuex from 'vuex'
@@ -8,37 +8,37 @@ import Vuex from 'vuex'
 const store = new Vuex.Store({ ...options })
 ```
 
-### Options de constructeur de Vuex.Store
+### Options du constructeur de `Vuex.Store`
 
 - **state**
 
-  - type: `Object`
+  - type : `Object`
 
-    L'objet state racine pour le store Vuex.
+    L'objet d'état racine pour le store Vuex.
 
     [Détails](state.md)
 
 - **mutations**
 
-  - type: `{ [type: string]: Function }`
+  - type : `{ [type: string]: Function }`
 
-    Enregistrer les mutations sur le store. La fonction handler reçoit toujours `state` comme premier argument (sera le state local du module si défini dans un module), et reçoit le `payload` en second argument s'il y en a un.
+    Enregistrer les mutations sur le store. La fonction gestionnaire reçoit toujours `state` comme premier argument (sera l'état local du module si défini dans un module), et reçoit le `payload` en second argument s'il y en a un.
 
     [Détails](mutations.md)
 
 - **actions**
 
-  - type: `{ [type: string]: Function }`
+  - type : `{ [type: string]: Function }`
 
-    Enregistrer les actions sur le store. La fonction handler reçoit un objet `context` qui expose les propriétés suivantes :
+    Enregistrer les actions sur le store. La fonction gestionnaire reçoit un objet `context` qui expose les propriétés suivantes :
 
     ``` js
     {
-      state,     // identique à store.state, ou au state local si dans des modules
-      rootState, // identique à store.state, seulement dans des modules
-      commit,    // identique à store.commit
-      dispatch,  // identique à store.dispatch
-      getters    // identique à store.getters
+      state,     // identique à `store.state`, ou à l'état local si dans des modules
+      rootState, // identique à `store.state`, seulement dans des modules
+      commit,    // identique à `store.commit`
+      dispatch,  // identique à `store.dispatch`
+      getters    // identique à `store.getters`
     }
     ```
 
@@ -46,30 +46,40 @@ const store = new Vuex.Store({ ...options })
 
 - **getters**
 
-  - type: `{ [key: string]: Function }`
+  - type : `{ [key: string]: Function }`
 
-    Enregistrer les getters sur le store. La fonction getter reçoit les arguments suivants :
+    Enregistrer les accesseurs sur le store. La fonction accesseur reçoit les arguments suivants :
 
     ```
-    state,     // sera le state local du module si défini dans un module.
-    getters,   // indentique à store.getters
-    rootState  // indentique à store.state
+    state,    // sera l'état local du module si défini dans un module.
+    getters   // indentique à `store.getters`
     ```
-    Les getters enregistrés sont exposés sur `store.getters`.
+
+    Arguments spécifiques quand défini dans un module
+
+    ```
+    state,       // sera l'état local du module si défini dans un module.
+    getters,     // module local getters of the current module
+    rootState,   // état global
+    rootGetters  // tous les accesseurs
+    ```
+
+    Les accesseurs enregistrés sont exposés sur `store.getters`.
 
     [Détails](getters.md)
 
 - **modules**
 
-  - type: `Object`
+  - type : `Object`
 
-    Un objet contenant des sous-modules qui seront regroupés dans le store, de la forme suivante :
+    Un objet contenant des sous-modules qui seront regroupés dans le store, sous la forme suivante :
 
     ``` js
     {
       key: {
         state,
-        mutations,
+        namespaced?,
+        mutations?,
         actions?,
         getters?,
         modules?
@@ -78,64 +88,64 @@ const store = new Vuex.Store({ ...options })
     }
     ```
 
-    Chaque module peut contenir `state` et `mutations`, tout comme les options racine. Le state d'un module sera attaché au state racine du store en utilisant la clé du module. Les mutations et getters d'un module recevront seulement le state local du module en premier argument au lieu du state racine, et le `context.state` des actions du module pointeront également vers le state local.
+    Chaque module peut contenir `state` et `mutations`, tout comme les options racine. L'état d'un module sera attaché à l'état racine du store en utilisant la clé du module. Les mutations et accesseurs d'un module recevront seulement l'état local du module en premier argument au lieu de l'état racine, et le `context.state` des actions du module pointeront également vers l'état local.
 
     [Détails](modules.md)
 
 - **plugins**
 
-  - type: `Array<Function>`
+  - type : `Array<Function>`
 
-    Un tableau de fonctions plugin qui seront appliqués au store. Un plugin reçoit simplement le store comme seul argument et peut soit écouter les mutations (pour la persistence de données, logging ou debugging) ou dispatcher des mutations (pour les données internes, i.e. websockets ou observables).
+    Un tableau de fonctions plugins qui seront appliquées au store. Un plugin reçoit simplement le store comme seul argument et peut soit écouter les mutations (pour la persistence de données, les logs ou le débogage) ou propager des mutations (pour les données internes, c.-à-d. websockets ou observables).
 
     [Détails](plugins.md)
 
 - **strict**
 
-  - type: `Boolean`
+  - type : `Boolean`
   - default: `false`
 
-    Force le store Vuex en mode strict. En mode strict, toute mutation du state en dehors des handlers de mutation lancera une Error.
+    Force le store Vuex en mode strict. En mode strict, toute mutation de l'état en dehors des gestionnaires de mutation lancera une erreur.
 
     [Détails](strict.md)
 
-### Propriétés d'instance de Vuex.Store
+### Propriétés d'instance de `Vuex.Store`
 
 - **state**
 
-  - type: `Object`
+  - type : `Object`
 
-    Le state racine. Lecture seule.
+    L'état racine. Lecture seule.
 
 - **getters**
 
-  - type: `Object`
+  - type : `Object`
 
-    Expose les getters enregistrés. Lecture seule.
+    Expose les accesseurs enregistrés. Lecture seule.
 
-### Méthodes d'instance de Vuex.Store
+### Méthodes d'instance de `Vuex.Store`
 
-- **`commit(type: string, payload?: any) | commit(mutation: Object)`**
+- **`commit(type: string, payload?: any, options?: Object) | commit(mutation: Object, options?: Object)`**
 
-  commiter une mutation. [Détails](mutations.md)
+  Acter une mutation. `options` peut avoir `root: true` ce qui permet d'acter des mutations racines dans des [modules sous espace de nom](modules.md#namespacing). [Détails](mutations.md)
 
-- **`dispatch(type: string, payload?: any) | dispatch(action: Object)`**
+- **`dispatch(type : string, payload?: any, options?: Object) | dispatch(action: Object, options?: Object)`**
 
-  Dispatcher une action. Retourne la valeur renvoyée par le handler d'action déclenché, ou une Promise si plusieurs handlers ont été déclenchés. [Détails](actions.md)
+  Propager une action. Retourne la valeur renvoyée par le gestionnaire d'action déclenché, ou une Promesse si plusieurs gestionnaires ont été déclenchés. [Détails](actions.md)
 
 - **`replaceState(state: Object)`**
 
-  Remplacer le state racine du store. Utiliser seulement pour hydrater le state ou voir le state dans le temps.
+  Remplacer l'état racine du store. Utiliser seulement pour hydrater l'état ou dans le but de voyager dans le temps.
 
 - **`watch(getter: Function, cb: Function, options?: Object)`**
 
-  Observer de façon réactive la valeur de retour d'une fonction getter, et appeler le callback lorsque la valeur change. Le getter reçoit le state du store comme unique argument. Accepte un objet options optionnel qui prend les mêmes options que la méthode `vm.$watch` de Vue.
+  Observer de façon réactive la valeur de retour d'une fonction accesseur, et appeler la fonction de rappel lorsque la valeur change. L'accesseur reçoit l'état du store comme unique argument. Accepte un objet optionnel d'options qui prend les mêmes options que la méthode `vm.$watch` de Vue.
 
-  Pour arrêter d'observer, appeler la fonction retournée.
+  Pour arrêter d'observer, appeler la fonction gestionnaire retournée.
 
 - **`subscribe(handler: Function)`**
 
-  S'abonner aux mutations du store. Le `handler` est appelé après chaque mutation et reçoit le descripteur de mutation et le state post-mutation comme arguments :
+  S'abonner aux mutations du store. Le `handler` est appelé après chaque mutation et reçoit le descripteur de mutation et l'état post-mutation comme arguments :
 
   ``` js
   store.subscribe((mutation, state) => {
@@ -158,20 +168,28 @@ const store = new Vuex.Store({ ...options })
 
   Remplacement à la volée des nouvelles actions et mutations. [Détails](hot-reload.md)
 
-### Helpers d'attachement au composant
+### Fonctions utilitaires d'attachement au composant
+
+- **`mapState(namespace?: string, map: Array<string> | Object): Object`**
+
+  Créer des propriétés calculées qui retournent le sous arbre du store Vuex au composant. [Détails](state.md#le-helper-mapstate)
+
+  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Details](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
+
+- **`mapGetters(namespace?: string, map: Array<string> | Object): Object`**
 
-- **`mapState(map: Array<string> | Object): Object`**
+  Créer des propriétés calculées qui retournent la valeur calculée d'un accesseur. [Détails](getters.md#la-function-utilitaire-mapgetters)
 
-  Créer des computed properties qui retournent le sub tree du store Vuex au composant. [Détails](state.md#le-helper-mapstate)
+  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Details](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
-- **`mapGetters(map: Array<string> | Object): Object`**
+- **`mapActions(namespace?: string, map: Array<string> | Object): Object`**
 
-  Créer des computed properties qui retournent la valeur calculée d'un getter. [Détails](getters.md#le-helper-mapgetters)
+  Créer des méthodes de composant qui propagent une action. [Détails](actions.md#propager-des-actions-dans-les-composants)
 
-- **`mapActions(map: Array<string> | Object): Object`**
+  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Details](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)
 
-  Créer des méthodes de composant qui dispatchent une action. [Détails](actions.md#dispatcher-des-actions-dans-les-composants)
+- **`mapMutations(namespace?: string, map: Array<string> | Object): Object`**
 
-- **`mapMutations(map: Array<string> | Object): Object`**
+  Créer des méthodes de composant qui actent une mutation. [Détails](mutations.md#acter-des-mutations-dans-les-composants)
 
-  Créer des méthodes de composant qui committent une mutation. [Détails](mutations.md#commiter-des-mutations-dans-les-composants)
+  Le premier argument peut être de façon optionnel une chaîne d'espace de nom. [Details](modules.md#Fonctions-utilitaires-liées-avec-espace-de-nom)

docs/fr/book.json

@@ -1 +1,19 @@
-../book.json
+{
+  "gitbook": "2.x.x",
+  "plugins": ["edit-link", "prism", "-highlight", "github"],
+  "pluginsConfig": {
+    "edit-link": {
+      "base": "https://github.com/vuejs/vuex/tree/dev/docs",
+      "label": "Éditer cette page"
+    },
+    "github": {
+      "url": "https://github.com/vuejs/vuex/"
+    }
+  },
+  "links": {
+    "sharing": {
+      "facebook": false,
+      "twitter": false
+    }
+  }
+}

docs/fr/forms.md

@@ -1,14 +1,14 @@
-# Formulaires
+# Gestion des formulaires
 
-Lorsque l'on utilise Vuex en mode strict, il peut être compliqué d'utiliser `v-model` sur une partie du state qui appartient à Vuex :
+Lorsque l'on utilise Vuex en mode strict, il peut être compliqué d'utiliser `v-model` sur une partie de l'état qui appartient à Vuex :
 
 ``` html
 <input v-model="obj.message">
 ```
 
-Supposons que `obj` est une computed property qui retourne un Object depuis le store, le `v-model` tentera de muter directement `obj.message` lorsque l'utilisateur saisit du texte dans le champ. En mode strict, cela produira une erreur car la mutation n'est pas effectuée dans un handler de mutation Vuex explicite.
+Supposons que `obj` est une propriété calculée qui retourne un objet depuis le store, le `v-model` tentera de muter directement `obj.message` lorsque l'utilisateur saisit du texte dans le champ. En mode strict, cela produira une erreur car la mutation n'est pas effectuée dans un gestionnaire de mutation Vuex explicite.
 
-La "façon Vuex" de gérer ça est de binder la valeur de l'`input` est d'appeler une action sur l'event `input` ou `change` :
+La « méthode Vuex » pour gérer ça est de lier la valeur de l'`input` et d'appeler une action sur l'évènement `input` ou `change` :
 
 ``` html
 <input :value="message" @input="updateMessage">
@@ -27,7 +27,7 @@ methods: {
 }
 ```
 
-Et voici le handler de mutation :
+Et voici le gestionnaire de mutation :
 
 ``` js
 // ...
@@ -38,9 +38,9 @@ mutations: {
 }
 ```
 
-### Computed property bi-directionnelle
+### Propriété calculée bidirectionnelle
 
-Admettons tout de même que l'exemple ci-dessus est plus verbeux que le `v-model` couplé au state local, et on perd quelques fonctionnalités pratiques de `v-model` au passage. Une approche alternative consiste à utiliser une computed property bi-directionnelle avec un setter :
+Admettons tout de même que l'exemple ci-dessus est plus verbeux que le `v-model` couplé à l'état local (tout en perdant quelques fonctionnalités pratiques de `v-model` au passage). Une approche alternative consiste à utiliser une propriété calculée bidirectionnelle avec un mutateur :
 
 ``` html
 <input v-model="message">

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,9 +63,24 @@ 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'
@@ -72,7 +88,7 @@ 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,7 +27,7 @@ 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')
@@ -35,10 +35,10 @@ 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).

docs/fr/hot-reload.md

@@ -1,6 +1,6 @@
-# Hot Reloading
+# Rechargement à chaud
 
-Vuex prend en charge le `hot-reloading` des mutations, modules, actions et getters durant le développement, en utilisant l'[API Hot Module Replacement](https://webpack.github.io/docs/hot-module-replacement.html) de webpack. Vous pouvez également utiliser Browserify avec le plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
+Vuex prend en charge le rechargement à chaud des mutations, modules, actions et accesseurs durant le développement, en utilisant l'[API du module de remplacement à chaud](https://webpack.github.io/docs/hot-module-replacement.html) de webpack. Vous pouvez également utiliser Browserify avec le plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
 
 Pour les mutations et les modules, vous aurez besoin d'utiliser la méthode d'API `store.hotUpdate()` :
 
@@ -24,13 +24,13 @@ const store = new Vuex.Store({
 })
 
 if (module.hot) {
-  // accept actions and mutations as hot modules
+  // accepter les actions et mutations en tant que module à chaud
   module.hot.accept(['./mutations', './modules/a'], () => {
-    // require the updated modules
-    // have to add .default here due to babel 6 module output
+    // requiert les modules à jour
+    // ajout de `.default` ici pour les sorties des modules babel 6
     const newMutations = require('./mutations').default
     const newModuleA = require('./modules/a').default
-    // swap in the new actions and mutations
+    // remplacer les nouvelles actions et mutations
     store.hotUpdate({
       mutations: newMutations,
       modules: {
@@ -41,4 +41,4 @@ if (module.hot) {
 }
 ```
 
-Jetez un œil à [l'exemple counter-hot](https://github.com/vuejs/vuex/tree/dev/examples/counter-hot) pour jouer avec le hot-reload.
+Jetez un œil à [l'exemple counter-hot](https://github.com/vuejs/vuex/tree/dev/examples/counter-hot) pour jouer avec du rechargement à chaud.

docs/fr/installation.md

@@ -5,7 +5,7 @@
 [https://unpkg.com/vuex](https://unpkg.com/vuex)
 
 <!--email_off-->
-[Unpkg.com](https://unpkg.com) fournit des liens CDN basés sur NPM. Le lien ci-dessus pointera toujours vers la dernière release sur NPM. Vous pouvez aussi utiliser un tag ou une version spécifique via une URL comme `https://unpkg.com/vuex@2.0.0`.
+[Unpkg.com](https://unpkg.com) fournit des liens CDN basés sur npm. Le lien ci-dessus pointera toujours vers la dernière release sur npm. Vous pouvez aussi utiliser un tag ou une version spécifique via un URL comme `https://unpkg.com/vuex@2.0.0`.
 <!--/email_off-->
 
 Incluez `vuex` après Vue et l'installation sera automatique :
@@ -15,7 +15,7 @@ Incluez `vuex` après Vue et l'installation sera automatique :
 <script src="/path/to/vuex.js"></script>
 ```
 
-### NPM
+### npm
 
 ``` bash
 npm install vuex --save

docs/fr/intro.md

@@ -1,20 +1,20 @@
-# Qu'est-ce que Vuex ?
+# Vuex, qu'est-ce que c'est ?
 
-Vuex est un ***state management pattern* et une bibliothèque** pour des applications Vue.js. Il sert de store centralisé pour tous les composants dans une application, avec des règles pour s'assurer que l'état ne peut subir des mutations que d'une manière prévisible. Il s'intègre également avec [l'extension officielle](https://github.com/vuejs/vue-devtools) de Vue afin de fournir des fonctionnalités avancées comme voir l'état dans le temps et débugger sans configuration, ainsi que de prendre des instantanés, importer et exporter l'état.
+Vuex est un **_gestionnaire d'état (« state management pattern »)_ et une bibliothèque** pour des applications Vue.js. Il sert de zone de stockage de données centralisée pour tous les composants dans une application, avec des règles pour s'assurer que l'état ne puisse subir de mutations que d'une manière prévisible. Il s'intègre également avec [l'extension officielle](https://github.com/vuejs/vue-devtools) de Vue afin de fournir des fonctionnalités avancées comme de la visualisation d'état dans le temps et des exports et imports d’instantanés (« snapshot ») d'état.
 
-### Qu'est-ce qu'un "State Management Pattern"?
+### Un « gestionnaire d'état », qu'est-ce que c'est ?
 
-Commençons avec une simple application Vue de compteur :
+Commençons par une simple application de comptage avec Vue :
 
 ``` js
 new Vue({
-  // state
+  // état
   data () {
     return {
       count: 0
     }
   },
-  // view
+  // vue
   template: `
     <div>{{ count }}</div>
   `,
@@ -27,39 +27,37 @@ new Vue({
 })
 ```
 
-C'est une app auto-contenue avec les parties suivantes :
+C'est une application auto-suffisante avec les parties suivantes :
 
-- L'**État** (_state_), qui est la source de vérité qui dirige notre app;
-- La **Vue** (_view_), qui est juste un mapping déclaratif du **state**;
-- Les **actions**, qui sont les façons possibles pour le state de changer en réaction aux actions de l'utilisateur depuis la **vue**.
+- L'**état**, qui est la source de vérité qui pilotant votre application,
+- La **vue**, qui est une réflexion déclarative de l'**état**,
+- Les **actions**, qui sont les façons possibles pour l'état de changer en réaction aux actions utilisateurs depuis la **vue**.
 
-Voici une représentation extrèmement simple du concept de "one-way data flow" (_flux de données unidirectionnel_) :
+Voici une représentation extrèmement simple du concept de « flux de donnée unidirectionnel » :
 
 <p style="text-align: center; margin: 2em">
   <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
-Cependant, la simplicité s'évapore rapidement lorsque nous avons **de multiples composants qui partagent le même state** :
+Cependant, la simplicité s'évapore rapidement lorsque nous avons **de multiples composants qui partagent un même état global** :
 
-- Plusieurs vues peuvent dépendre de la même partie du state.
-- Des actions dans différentes vues peuvent avoir besoin de muter la même partie du state.
+- Plusieurs vues peuvent dépendre de la même partie de l'état global.
+- Des actions dans différentes vues peuvent avoir besoin de muter la même partie de l'état global.
 
-Pour le premier problème, passer des propriétés peut être fastidieux pour les composants profondément imbriqués, et ça ne fonctionne tout simplement pas pour les composants d'un même parent. Pour le deuxième problème, on se retrouve souvent à se rabattre sur des solutions telles qu'accéder aux références d'instance du parent/enfant direct ou essayer de muter et synchroniser de multiples copies du state via des events. Ces deux patterns sont fragiles et posent rapidement des problèmes de maintenabilité du code.
+Pour le premier problème, passer des props peut être fastidieux pour les composants profondément imbriqués, et ça ne fonctionne tout simplement pas pour les composants d'un même parent. Pour le deuxième problème, on se retrouve souvent à se rabattre sur des solutions telles qu'accéder aux références d'instance du parent/enfant direct ou essayer de muter et synchroniser de multiples copies de l'état via des évènements. Ces deux modèles sont fragiles et posent rapidement des problèmes de maintenabilité du code.
 
-Alors pourquoi ne pas extraire le state partagé des composants, et le gérer dans un singleton global ? De cette manière, notre arbre de composant devient une grosse "view", et n'importe-quel composant peut accéder au state ou déclencher des actions, peu importe où il se trouve dans l'arbre !
+Alors pourquoi ne pas extraire l'état global partagé des composants, et le gérer dans un singleton global ? De cette manière, notre arbre de composant devient une grosse « vue », et n'importe quel composant peut accéder à l'état global ou déclencher des actions, peu importe où il se trouve dans l'arbre !
 
-De plus, en définissant et en séparant les concepts impliqués dans la gestion d'un state et en appliquant certaines règles, on donne aussi une structure et une maintenabilité à notre code.
+De plus, en définissant et en séparant les concepts impliqués dans la gestion de l'état global et en appliquant certaines règles, on donne aussi une structure et une maintenabilité à notre code.
 
-Voilà l'idée de base derrière Vuex, inspiré par [Flux](https://facebook.github.io/flux/docs/overview.html), [Redux](http://redux.js.org/) et [l'Architecture Elm](https://guide.elm-lang.org/architecture/). À l'inverse des autres patterns, Vuex est aussi une bibliothèque d'implémentation conçue spécialement pour Vue.js afin de bénéficier de son système de réactivité granulaire pour des modifications efficaces.
+Voilà l'idée de base derrière Vuex, inspiré par [Flux](https://facebook.github.io/flux/docs/overview.html), [Redux](http://redux.js.org/) et [l'architecture Elm](https://guide.elm-lang.org/architecture/). À l'inverse des autres modèles, Vuex est aussi une bibliothèque d'implémentation conçue spécialement pour Vue.js afin de bénéficier de son système de réactivité granulaire pour des modifications efficaces.
 
 ![vuex](./images/vuex.png)
 
 ### Quand l'utiliser ?
 
-Bien que Vuex nous aide à gérer une state partagé, il apporte aussi le coût de nouveaux concepts et _boilerplate_. C'est un compromis entre la productivité à court terme et à long terme.
+Bien que Vuex nous aide à gérer un état global partagé, il apporte aussi le coût de nouveaux concepts et _abstraction de code_ (« boilerplate »). C'est un compromis entre la productivité à court terme et à long terme.
 
-Si vous n'avez jamais créé une _Single Page Application_ à grande échelle et que vous sautez directement dans Vuex, cela peut paraître verbeux et intimidant. C'est parfaitement normal &mdash; si votre application est simple, vous vous en sortirez sans doute très bien sans Vuex. Un simple [bus d'event global](http://vuejs.org/guide/components.html#Non-Parent-Child-Communication) pourrait très bien vous suffire. Mais si vous devez créer une SPA à moyenne ou grande échelle, il y a des chances que vous vous trouviez dans des situations qui vous feront penser à une meilleure façon de gérer le state en-dehors de votre composant Vue, et Vuex sera naturellement la prochaine étape pour vous. Voici une bonne citation de Dan Abramov, l'auteur de Redux :
+Si vous n'avez jamais créé une _application monopage_ à grande échelle et que vous sautez directement dans Vuex, cela peut paraître verbeux et intimidant. C'est parfaitement normal ; si votre application est simple, vous vous en sortirez sans doute très bien sans Vuex. Un simple [canal d'évènement global](https://fr.vuejs.org/v2/guide/components.html#Communication-non-parent-enfant) pourrait très bien vous suffire. Mais si vous devez créer une application monopage à moyenne ou grande échelle, il y a des chances que vous vous trouviez dans des situations qui vous feront vous interroger sur une meilleure gestion de l'état global, détaché de votre composant Vue, et Vuex sera naturellement la prochaine étape pour vous. Voici une bonne citation de Dan Abramov, l'auteur de Redux :
 
-> Flux libraries are like glasses: you’ll know when you need them.
->
-> _Les librairies Flux, c'est comme les lunettes : vous saurez quand vous en aurez besoin._
+> « Les librairies Flux, c'est comme les lunettes : vous saurez quand vous en aurez besoin. »

docs/fr/modules.md

@@ -1,8 +1,8 @@
 # Modules
 
-Parce qu'il utilise un _single state tree_, tout le state de notre application est contenu dans un seul et même gros objet. Cependant, au fur et à mesure que notre application grandit, le store peut devenir très engorgé.
+Du fait de l'utilisation d'un arbre d'état unique, tout l'état de notre application est contenu dans un seul et même gros objet. Cependant, au fur et à mesure que notre application grandit, le store peut devenir très engorgé.
 
-Pour y remédier, Vuex nous permet de diviser notre store en **modules**. Chaque module peut contenir son propre state, mutations, actions, getters, et même d'autres modules.
+Pour y remédier, Vuex nous permet de diviser notre store en **modules**. Chaque module peut contenir ses propres état, mutations, actions, accesseurs. Il peut même contenir ses propres modules internes.
 
 ``` js
 const moduleA = {
@@ -25,20 +25,20 @@ const store = new Vuex.Store({
   }
 })
 
-store.state.a // -> le state du module A
-store.state.b // -> le state du module B
+store.state.a // -> l'état du `moduleA`
+store.state.b // -> l'état du `moduleB`
 ```
 
-### State local d'un module
+### État local d'un module
 
-Dans les mutations et getters d'un module, le premier argument reçu sera le **state local du module**.
+Dans les mutations et accesseurs d'un module, le premier argument reçu sera **l'état local du module**.
 
 ``` js
 const moduleA = {
   state: { count: 0 },
   mutations: {
     increment (state) {
-      // state est le state du module local
+      // `state` est l'état du module local
       state.count++
     }
   },
@@ -51,7 +51,7 @@ const moduleA = {
 }
 ```
 
-De façon similaire, dans les actions du module, `context.state` exposera le state local, et le state racine sera disponible avec `context.rootState` :
+De façon similaire, dans les actions du module, `context.state` exposera l'état local, et l'état racine sera disponible avec `context.rootState` :
 
 ``` js
 const moduleA = {
@@ -66,7 +66,7 @@ const moduleA = {
 }
 ```
 
-Également, dans les getters du module, le state racine sera exposé en troisième argument :
+Également, dans les accesseurs du module, l'état racine sera exposé en troisième argument :
 
 ``` js
 const moduleA = {
@@ -79,60 +79,189 @@ const moduleA = {
 }
 ```
 
-### Namespacing
+### Espace de nom
 
-Notez que les actions, mutations et getters dans un module sont toujours enregistrés sous le **namespace global** — cela permet à plusieurs modules de réagir au même type de mutation/action. Vous pouvez répartir les modules dans des namespaces vous-mêmes afin d'éviter les conflits de nom en préfixant ou suffixant leurs noms. Et vous devriez probablement faire cela si vous utiliser un module Vuex réutilisable qui sera utilisé dans des environnements inconnus. Par exemple, nous voulons créer un module `todos` :
+Par défaut, les actions, mutations et accesseurs à l'intérieur d'un module sont toujours enregistrés sous l'**espace de nom global**. Cela permet à de multiples modules d'être réactifs au même type de mutation et d'action.
 
-``` js
-// types.js
+Si vous souhaitez que votre module soit auto-suffisant et réutilisable, vous pouvez le ranger sous un espace de nom avec `namespaced: true`. Quand le module est enregistré, tous ses accesseurs, actions et mutations seront automatiquement basés sur l'espace de nom du module dans lesquels ils sont rangés. Par exemple :
+
+```js
+const store = new Vuex.Store({
+  modules: {
+    account: {
+      namespaced: true,
+
+      // propriétés du module
+      state: { ... }, // l'état du module est déjà imbriqué et n'est pas affecté par l'option `namespace`
+      getters: {
+        isAdmin () { ... } // -> getters['account/isAdmin']
+      },
+      actions: {
+        login () { ... } // -> dispatch('account/login')
+      },
+      mutations: {
+        login () { ... } // -> commit('account/login')
+      },
+
+      // modules imbriqués
+      modules: {
+        // hérite de l'espace de nom du module parent
+        myPage: {
+          state: { ... },
+          getters: {
+            profile () { ... } // -> getters['account/profile']
+          }
+        },
+
+        // utilise un espace de nom imbriqué
+        posts: {
+          namespaced: true,
 
-// on définit les noms des getters, actions et mutations en tant que constantes
-// et on les préfixe du nom du module `todos`
-export const DONE_COUNT = 'todos/DONE_COUNT'
-export const FETCH_ALL = 'todos/FETCH_ALL'
-export const TOGGLE_DONE = 'todos/TOGGLE_DONE'
+          state: { ... },
+          getters: {
+            popular () { ... } // -> getters['account/posts/popular']
+          }
+        }
+      }
+    }
+  }
+})
 ```
 
+Les accesseurs et actions sous espace de nom reçoivent des `getters`, `dispatch` et `commit` localisés. En d'autres termes, vous pouvez utiliser les paramètres de module sans écrire de prefix dans ce même module. Permuter entre un espace de nom ou non n'affecte pas le code à l'intérieur du module.
+
+#### Accéder aux propriétés globales dans les modules à espace de nom
+
+Si vous voulez utiliser des états et accesseurs globaux, `rootState` et `rootGetters` sont passés en 3ième et 4ième arguments des fonctions d'accès et sont également exposés en tant que propriété de l'objet `context` passé aux fonctions d'action.
+
+Pour propager les actions ou les mutations actées dans l'espace de nom global, passez `{ root: true }` en 3ième argument à `dispatch` et `commit`.
+
 ``` js
-// modules/todos.js
-import * as types from '../types'
+modules: {
+  foo: {
+    namespaced: true,
 
-// on définit les getters, actions et mutations en utilisant des noms préfixés
-const todosModule = {
-  state: { todos: [] },
+    getters: {
+      // Les `getters` sont localisés dans le module des accesseurs
+      // vous pouvez utiliser `rootGetters` via le 4ième argument des accesseurs
+      someGetter (state, getters, rootState, rootGetters) {
+        getters.someOtherGetter // -> 'foo/someOtherGetter'
+        rootGetters.someOtherGetter // -> 'someOtherGetter'
+      },
+      someOtherGetter: state => { ... }
+    },
 
-  getters: {
-    [types.DONE_COUNT] (state) {
-      // ...
-    }
-  },
+    actions: {
+      // les actions et mutations sont aussi localisées pour ce module
+      // elles vont accepter une option `root` pour la racine des actions et mutations.
+      someAction ({ dispatch, commit, getters, rootGetters }) {
+        getters.someGetter // -> 'foo/someGetter'
+        rootGetters.someGetter // -> 'someGetter'
 
-  actions: {
-    [types.FETCH_ALL] (context, payload) {
-      // ...
-    }
-  },
+        dispatch('someOtherAction') // -> 'foo/someOtherAction'
+        dispatch('someOtherAction', null, { root: true }) // -> 'someOtherAction'
 
-  mutations: {
-    [types.TOGGLE_DONE] (state, payload) {
-      // ...
+        commit('someMutation') // -> 'foo/someMutation'
+        commit('someMutation', null, { root: true }) // -> 'someMutation'
+      },
+      someOtherAction (ctx, payload) { ... }
     }
   }
 }
 ```
 
+#### Fonctions utilitaires liées avec espace de nom
+
+Quand nous lions un module sous espace de nom à un composant avec les fonctions utilitaires `mapState`, `mapGetters`, `mapActions` and `mapMutations`, cela peut être légèrement verbeux :
+
+``` js
+computed: {
+  ...mapState({
+    a: state => state.some.nested.module.a,
+    b: state => state.some.nested.module.b
+  })
+},
+methods: {
+  ...mapActions([
+    'some/nested/module/foo',
+    'some/nested/module/bar'
+  ])
+}
+```
+
+Dans ces cas là, vous pouvez passer une chaîne de caractère représentant le nom d'espace en tant que premier argument aux fonctions utilitaires ainsi toutes les liaisons seront faites en utilisant le module comme contexte. Cela peut être simplifié comme ci-dessous :
+
+``` js
+computed: {
+  ...mapState('some/nested/module', {
+    a: state => state.a,
+    b: state => state.b
+  })
+},
+methods: {
+  ...mapActions('some/nested/module', [
+    'foo',
+    'bar'
+  ])
+}
+```
+
+#### Limitations pour les plugins des développeurs
+
+Vous devez faire attention au nom d'espace imprévisible pour vos modules quand vous créez un [plugin](plugins.md) qui fournit les modules et laisser les utilisateurs les ajouter au store de Vuex. Vos modules seront également sous espace de nom si l'utilisateur du plugin l'ajoute sous un module sous espace de nom. Pour vous adaptez à la situation, vous devez recevoir la valeur de l'espace de nom via vos options de plugin :
+
+```js
+// passer la valeur d'espace de nom via une option du plugin
+// et retourner une fonction de plugin Vuex
+export function createPlugin (options = {}) {
+  return function (store) {
+    // ajouter l'espace de nom aux types de module
+    const namespace = options.namespace || ''
+    store.dispatch(namespace + 'pluginAction')
+ }
+}
+```
+
 ### Enregistrement dynamique de module
 
 Vous pouvez enregistrer un module **après** que le store ait été créé avec la méthode `store.registerModule` :
 
 ``` js
+// enregistrer un module `myModule`
 store.registerModule('myModule', {
   // ...
 })
+
+// enregistrer un module imbriqué `nested/myModule`
+store.registerModule(['nested', 'myModule'], {
+  // ...
+})
 ```
 
-Le state du module sera disponible dans `store.state.myModule`.
+L'état des modules est disponible dans `store.state.myModule` et `store.state.nested.myModule`.
 
-L'enregistrement dynamique de module permet aux autres plugins Vue de bénéficier de la gestion de state de Vuex en attachant un module au store de l'application. Par exemple, la bibliothèque [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) intègre vue-router avec vuex en gérant le state de la route d'application dans un module enregistré dynamiquement.
+L'enregistrement dynamique de module permet aux autres plugins Vue de bénéficier de la gestion de l'état de Vuex en attachant un module au store de l'application. Par exemple, la bibliothèque [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) intègre vue-router avec vuex en gérant l'état de la route d'application dans un module enregistré dynamiquement.
 
 Vous pouvez aussi supprimer un module enregistré dynamiquement avec `store.unregisterModule(moduleName)`. Notez que vous ne pouvez pas supprimer des modules statiques (déclarés à la création du store) avec cette méthode.
+
+### Ré-utiliser un module
+
+Parfois nous devrons créer de multiples instances d'un module pour, par exemple :
+
+- créer plusieurs stores qui utilisent le même module (par ex. pour [éviter les singletons d'état avec du SSR](https://ssr.vuejs.org/fr/structure.html#avoid-stateful-singletons) quand l'option `runInNewContext` est à `false` ou `'once'`) ou
+- enregistrer le même module plusieurs fois dans le même store.
+
+Si nous utilisons un objet pour déclarer l'état du module, alors cet objet d'état sera partagé par référence et causera de contamination inter store/module quand il sera muté.
+
+C'est exactement le même problème qu'avec `data` dans un composant Vue. Ainsi la solution est là même, utiliser une fonction pour déclarer notre état de module (supporté par la 2.3.0+) :
+
+``` js
+const MyReusableModule = {
+  state () {
+    return {
+      foo: 'bar'
+    }
+  },
+  // mutations, actions, accesseurs...
+}
+```

docs/fr/mutations.md

@@ -1,6 +1,6 @@
 # Mutations
 
-La seule façon de vraiment modifier le state dans un store Vuex est de commiter une mutation. Les mutations Vuex sont très similaires aux events : chaque mutation a un **type** sous forme de chaîne de caractères et un **handler**. La fonction handler est là où nous procédons aux véritables modifications du state, et elle reçoit le state en premier argument :
+La seule façon de vraiment modifier l'état dans un store Vuex est d'acter une mutation. Les mutations Vuex sont très similaires aux évènements : chaque mutation a un **type** sous forme de chaîne de caractères et un **gestionnaire**. La fonction de gestion est en charge de procéder aux véritables modifications de l'état, et elle reçoit l'état en premier argument :
 
 ``` js
 const store = new Vuex.Store({
@@ -9,22 +9,22 @@ const store = new Vuex.Store({
   },
   mutations: {
     increment (state) {
-      // mutate state
+      // muter l'état
       state.count++
     }
   }
 })
 ```
 
-Vous ne pouvez pas appeler directement un handler de mutation. La façon de faire est plutôt comme un abonnement à un event : "Lorsqu'une mutation du type `increment` est déclenchée, appelle ce handler." Pour invoquer un handler de mutation, il faut appeler **store.commit** avec son type :
+Vous ne pouvez pas appeler directement un gestionnaire de mutation. Le parti-pris ici est proche de l'abonnement à un évènement : « Lorsqu'une mutation du type `increment` est déclenchée, appelle ce gestionnaire. » Pour invoquer un gestionnaire de mutation, il faut appeler `store.commit` avec son type :
 
 ``` js
 store.commit('increment')
 ```
 
-### commiter avec un Payload
+### Acter avec un argument additionnel
 
-Vous pouvez donner un autre argument à **store.commit** pour la mutation, qui s'appelle **payload** :
+Vous pouvez donner un argument additionnel (« payload ») à la fonction `store.commit` lors de la mutation :
 
 ``` js
 // ...
@@ -38,7 +38,7 @@ mutations: {
 store.commit('increment', 10)
 ```
 
-Dans la plupart des cas, le payload devrait être un objet, ainsi il peut contenir plusieurs champs, et les mutations enregistrées seront également plus descriptives :
+Dans la plupart des cas, l'argument additionnel devrait être un objet, ainsi il peut contenir plusieurs champs, et les mutations enregistrées seront également plus descriptives :
 
 ``` js
 // ...
@@ -54,9 +54,9 @@ store.commit('increment', {
 })
 ```
 
-### Object-Style Commit
+### Acter avec un objet
 
-Une méthode alternative pour commiter une mutation est d'utiliser directement un objet qui a une propriété `type` :
+Une méthode alternative pour acter une mutation est d'utiliser directement un objet qui a une propriété `type` :
 
 ``` js
 store.commit({
@@ -65,7 +65,7 @@ store.commit({
 })
 ```
 
-Lors de l'utlisation de l'object-style commit, l'objet entier sera fourni comme payload aux handlers de mutation, donc le handler reste inchangé :
+Lors de l'utilisation d'un objet pour acter, c'est l'objet lui-même qui ferra office d'argument pour aux gestionnaires de mutation, le gestionnaire reste donc inchangé :
 
 ``` js
 mutations: {
@@ -77,23 +77,23 @@ mutations: {
 
 ### Les mutations suivent les règles de réactivité de Vue
 
-Puisqu'un state de store de Vuex est rendu réactif par Vue, lorsque nous mutons le state, les composants Vue observant ce state seront automatiquement mis à jour. Cela signifie également que les mutations Vuex sont sujettes aux mêmes inconvénients que lorsqu'on travaille avec Vue :
+Puisqu'un état de store de Vuex est rendu réactif par Vue, lorsque nous mutons l'état, les composants Vue observant cet état seront automatiquement mis à jour. Cela signifie également que les mutations Vuex sont sujettes aux mêmes limitations qu'avec l'utilisation de Vue seul :
 
-1. Initialisez de préférence le state initial de votre state avec tous les champs désirés auparavant.
+1. Initialisez de préférence le store initial de votre état avec tous les champs désirés auparavant.
 
-2. Lorsque vous ajoutez de nouvelles propriétés à un Object, vous devriez soit :
+2. Lorsque vous ajoutez de nouvelles propriétés à un objet, vous devriez soit :
 
-  - Utiliser `Vue.set(obj, 'newProp', 123)`, ou -
+  - Utiliser `Vue.set(obj, 'newProp', 123)`, ou
 
-  - Remplacer cet Object par un nouvel Object. Par exemple, en utilisant [object spread syntax](https://github.com/sebmarkbage/ecmascript-rest-spread) (stage-2), il est possible d'écrire :
+  - Remplacer cet objet par un nouvel objet. Par exemple, en utilisant [opérateur de décomposition](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Op%C3%A9rateur_de_d%C3%A9composition) (stage-2), il est possible d'écrire :
 
     ``` js
     state.obj = { ...state.obj, newProp: 123 }
     ```
 
-### Utilisation de constante pour les noms de mutation
+### Utilisation de constante pour les types de mutation
 
-C'est une façon de faire régulière que d'utiliser des constantes pour les types de mutations dans diverses implémentations de Flux. Cela permet au code de bénéficier d'outils comme les linters, et écrire toutes ces constantes dans un seul fichier permet à vos collaborateurs d'avoir un aperçu de quelles mutations sont possibles dans toute l'application :
+C'est une façon de faire régulière que d'utiliser des constantes pour les types de mutations dans diverses implémentations de Flux. Cela permet au code de bénéficier d'outils comme les linters (des outils d'aide à l'analyse syntaxique), et écrire toutes ces constantes dans un seul fichier permet à vos collaborateurs d'avoir un aperçu de quelles mutations sont possibles dans toute l'application :
 
 ``` js
 // mutation-types.js
@@ -108,20 +108,20 @@ import { SOME_MUTATION } from './mutation-types'
 const store = new Vuex.Store({
   state: { ... },
   mutations: {
-    // we can use the ES2015 computed property name feature
-    // to use a constant as the function name
+    // nous pouvons utiliser la fonctionnalité de nom de propriété calculée
+    // pour utiliser une constante en tant que nom de fonction
     [SOME_MUTATION] (state) {
-      // mutate state
+      // muter l'état
     }
   }
 })
 ```
 
-Utiliser les constantes ou non relève de la préférence personnelle — cela peut être bénéfique sur un gros projet avec beaucoup de développeurs, mais c'est totalement optionnel si vous n'aimez pas cette pratique.
+Utiliser les constantes ou non relève de la préférence personnelle. Cela peut être bénéfique sur un gros projet avec beaucoup de développeurs, mais c'est totalement optionnel si vous n'aimez pas cette pratique.
 
 ### Les mutations doivent être synchrones
 
-Une règle importante à retenir est que **les fonctions handler de mutations doivent être synchrones**. Pourquoi ? Considérons l'exemple suivant :
+Une règle importante à retenir est que **les fonctions de gestion des mutations doivent être synchrones**. Pourquoi ? Considérons l'exemple suivant :
 
 ``` js
 mutations: {
@@ -133,11 +133,11 @@ mutations: {
 }
 ```
 
-Maintenant imaginons que nous debuggons l'application et que nous regardons dans les logs de mutation des devtools. Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané du state "avant" et un instantané "après". Cependant, le callback asynchrone de l'exemple ci-dessus rend l'opération impossible : le callback n'est pas encore appelé lorsque la mutation est committée, et il n'y a aucun moyen pour le devtool de savoir quand le callback sera véritablement appelé — toute mutation du state effectuée dans le callback est essentiellement intraçable !
+Maintenant imaginons que nous deboguons l'application et que nous regardons dans les logs de mutation des outils de développement (« devtools »). Pour chaque mutation enregistrée, le devtool aura besoin de capturer un instantané de l'état « avant » et un instantané « après ». Cependant, la fonction de rappel asynchrone de l'exemple ci-dessus rend l'opération impossible : la fonction de rappel n'est pas encore appelée lorsque la mutation est actée, et il n'y a aucun moyen pour le devtool de savoir quand la fonction de rappel sera véritablement appelée. Toute mutation d'état effectuée dans la fonction de rappel est essentiellement intraçable !
 
-### commiter des mutations dans les composants
+### Acter des mutations dans les composants
 
-Vous pouvez commiter des mutations dans les composants avec `this.$store.commit('xxx')`, ou en utilisant le helper `mapMutations` qui attache les méthodes du composant aux appels de `store.commit` (nécessite l'injection de `store` à la racine) :
+Vous pouvez acter des mutations dans les composants avec `this.$store.commit('xxx')`, ou en utilisant la fonction utilitaire `mapMutations` qui attache les méthodes du composant aux appels de `store.commit` (nécessite l'injection de `store` à la racine) :
 
 ``` js
 import { mapMutations } from 'vuex'
@@ -146,10 +146,13 @@ export default {
   // ...
   methods: {
     ...mapMutations([
-      'increment' // map this.increment() to this.$store.commit('increment')
+      'increment' // attacher `this.increment()` à `this.$store.commit('increment')`
+
+      // `mapMutations` supporte également les paramètres additionnels :
+      'incrementBy' // attacher `this.incrementBy(amount)` à `this.$store.commit('incrementBy', amount)`
     ]),
     ...mapMutations({
-      add: 'increment' // map this.add() to this.$store.commit('increment')
+      add: 'increment' // attacher `this.add()` à `this.$store.commit('increment')`
     })
   }
 }
@@ -157,12 +160,12 @@ export default {
 
 ### En avant vers les actions
 
-L'asynchronisme combiné à la mutation du state peut rendre votre programme très difficile à comprendre. Par exemple, lorsque vous appelez deux méthodes avec toutes les deux des callbacks asynchrones qui changent le state, comment savez-vous quand elles sont appelées et quel callback est appelé en premier ? C'est exactement la raison pour laquelle nous voulons séparer les deux concepts. Avec Vuex, **les mutations sont des transactions synchrones** :
+L'asynchronisme combiné à la mutation de l'état peut rendre votre programme très difficile à comprendre. Par exemple, lorsque vous appelez deux méthodes avec toutes les deux des foncitons de rappel asynchrones qui changent l'état, comment savez-vous quelle fonction de rappel est appelée en première ? C'est exactement la raison pour laquelle nous voulons séparer les deux concepts. Avec Vuex, **les mutations sont des transactions synchrones** :
 
 ``` js
 store.commit('increment')
-// any state change that the "increment" mutation may cause
-// should be done at this moment.
+// n'importe quel changement d'état de « increment » par mutation
+// devrait être faite de manière synchrone.
 ```
 
-Pour gérer les opérations asynchrones, présentons les [Actions](actions.md).
+Pour gérer les opérations asynchrones, tournons-nous vers les [Actions](actions.md).

docs/fr/plugins.md

@@ -4,10 +4,10 @@ Les stores Vuex prennent une option `plugins` qui expose des hooks pour chaque m
 
 ``` js
 const myPlugin = store => {
-  // called when the store is initialized
+  // appelé quand le store est initialisé
   store.subscribe((mutation, state) => {
-    // called after every mutation.
-    // The mutation comes in the format of { type, payload }.
+    // appelé après chaque mutation.
+    // Les mutation arrivent au format `{ type, payload }`.
   })
 }
 ```
@@ -21,11 +21,11 @@ const store = new Vuex.Store({
 })
 ```
 
-### Commiter des mutations dans des plugins
+### Acter des mutations dans des plugins
 
-Les plugins ne sont pas autorisés à muter directement le state — tout comme vos composants, ils peuvent simplement déclencher des changements en committant des mutations.
+Les plugins ne sont pas autorisés à muter directement l'état. Tout comme vos composants, ils peuvent simplement déclencher des changements en actant des mutations.
 
-En commitant des mutations, un plugin peut être utilisé pour synchroniser la source de données avec le store. Par exemple, pour synchroniser la source de données d'un websocket vers le store (c'est juste un exemple artificiel, en réalité la fonction `createPlugin` peut prendre des options additionnelles pour des tâches plus complexes) :
+En actant des mutations, un plugin peut être utilisé pour synchroniser la source de données avec le store. Par exemple, pour synchroniser la source de données d'une websocket vers le store (c'est juste un exemple artificiel, en réalité la fonction `createPlugin` peut prendre des options additionnelles pour des tâches plus complexes) :
 
 ``` js
 export default function createWebSocketPlugin (socket) {
@@ -52,9 +52,9 @@ const store = new Vuex.Store({
 })
 ```
 
-### Prendre des instantanés du state
+### Prendre des instantanés de l'état
 
-Parfois un plugin peut vouloir reçevoir des "instantanés" du state, et également comparer le state post-mutation avec le state pre-mutation. Pour faire ceci, vous aurez besoin d'effectuer une deep-copy sur l'objet du state :
+Parfois un plugin peut vouloir recevoir des « instantanés » de l'état, et également comparer l'état post-mutation avec l'état pré-mutation. Pour faire ceci, vous aurez besoin d'effectuer une copie complète de l'état :
 
 ``` js
 const myPluginWithSnapshot = store => {
@@ -62,15 +62,15 @@ const myPluginWithSnapshot = store => {
   store.subscribe((mutation, state) => {
     let nextState = _.cloneDeep(state)
 
-    // compare prevState and nextState...
+    // comparer `prevState` et `nextState`...
 
-    // save state for next mutation
+    // sauver l'état pour la prochaine mutation
     prevState = nextState
   })
 }
 ```
 
-**Les plugins qui peuvent prendre des instantanés ne devraient être utilisés que pendant le développement.** Lorsqu'on utilise webpack ou Browserify, on peut laisser nos devtools s'occuper de ça pour nous :
+**Les plugins qui peuvent prendre des instantanés ne devraient être utilisés que pendant le développement.** Lorsqu'on utilise webpack ou Browserify, on peut laisser nos outils de développement (« devtools ») s'occuper de ça pour nous :
 
 ``` js
 const store = new Vuex.Store({
@@ -83,11 +83,11 @@ const store = new Vuex.Store({
 
 Le plugin sera utilisé par défaut. Pour la production, vous aurez besoin de [DefinePlugin](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) pour webpack ou de [envify](https://github.com/hughsk/envify) pour Browserify pour convertir la valeur de `process.env.NODE_ENV !== 'production'` à `false` pour le build final.
 
-### Plugin logger intégré
+### Plugin de logs intégré
 
 > Si vous utilisez [vue-devtools](https://github.com/vuejs/vue-devtools) vous n'avez probablement pas besoin de ça.
 
-Vuex fournit un plugin de logger à des fins de debugging :
+Vuex fournit un plugin de logs à des fins de débogage :
 
 ``` js
 import createLogger from 'vuex/dist/logger'
@@ -103,23 +103,23 @@ La fonction `createLogger` prend quelques options :
 const logger = createLogger({
   collapsed: false, // auto-expand logged mutations
   filter (mutation, stateBefore, stateAfter) {
-    // returns true if a mutation should be logged
-    // `mutation` is a { type, payload }
+    // retourne `true` si une mutation devrait être logguée
+    // `mutation` est un `{ type, payload }`
     return mutation.type !== "aBlacklistedMutation"
   },
   transformer (state) {
-    // transform the state before logging it.
-    // for example return only a specific sub-tree
+    // transforme l'état avant de le logguer.
+    // retourne par exemple seulement un sous-arbre spécifique
     return state.subTree
   },
   mutationTransformer (mutation) {
-    // mutations are logged in the format of { type, payload }
-    // we can format it any way we want.
+    // les mutations sont logguées au format `{ type, payload }`
+    // nous pouvons les formater comme nous le souhaitons.
     return mutation.type
   }
 })
 ```
 
-Le fichier logger peut aussi être inclus directement via une balise `script`, et exposera la fonction `createVuexLogger` globalement.
+Le fichier de logs peut aussi être inclus directement via une balise `script`, et exposera la fonction `createVuexLogger` globalement.
 
-Notez que le plugin logger peut prendre des instantanés du state, ne l'utilisez donc que durant le développement.
+Notez que le plugin de logs peut prendre des instantanés de l'état, ne l'utilisez donc que durant le développement.

docs/fr/state.md

@@ -1,14 +1,14 @@
 # State
 
-### Single State Tree
+### Arbre d'état unique
 
-Vuex utilise un **single state tree** — cet unique objet contient tout le state au niveau applicatif et sert de "source unique de vérité". Cela signifie également que vous n'aurez qu'un seul store pour chaque application. Un _single state tree_ rend rapide la localisation d'une partie de state spécifique, et nous permet de facilement prendre des instantanés du state actuel de l'application à des fins de debugging.
+Vuex utilise un **arbre d'état unique**, c'est-à-dire que cet unique objet contient tout l'état au niveau applicatif et sert de « source de vérité unique ». Cela signifie également que vous n'aurez qu'un seul store pour chaque application. Un arbre d'état unique rend rapide la localisation d'une partie spécifique de l'état et permet de facilement prendre des instantanés de l'état actuel de l'application à des fins de débogage.
 
-Le _single state tree_ n'entre pas en conflit avec la modularité — dans les prochains chapitres, nous examinerons comment séparer votre state et vos mutations dans des sous-modules.
+L'arbre d'état unique n'entre pas en conflit avec la modularité. Dans les prochains chapitres, nous examinerons comment séparer votre état et vos mutations dans des sous-modules.
 
-### Récupérer le state Vuex dans des composants Vue
+### Récupération d'état Vuex dans des composants Vue
 
-Alors, comment affichons-nous le state du store dans nos composants Vue ? Puisque les stores Vuex sont réactifs, la façon la plus simple d'y "récupérer" le state est de simplement retourner une partie du state depuis une [computed property](http://vuejs.org/guide/computed.html) :
+Alors, comment affichons-nous l'état du store dans nos composants Vue ? Puisque les stores Vuex sont réactifs, la façon la plus simple d'y « récupérer » l'état est tout simplement de retourner une partie de l'état depuis une [une propriété calculée](http://fr.vuejs.org/guide/computed.html) :
 
 ``` js
 // créons un composant Counter
@@ -22,16 +22,16 @@ const Counter = {
 }
 ```
 
-Lorsque `store.state.count` change, cela entraînera la ré-évaluation de la computed property, et déclenchera les actions DOM associées.
+Lorsque `store.state.count` change, cela entraînera la ré-évaluation de la propriété calculée, et déclenchera les actions associées au DOM.
 
-Cependant, ce pattern oblige le composant à compter sur le singleton global du store. Lorsqu'on utilise un système de module, il est nécessaire d'importer le store dans tous les composants qui utilisent le state du store, et il est également nécessaire de créer un mock lorsque l'on teste le composant.
+Cependant, ce modèle oblige le composant à compter sur le singleton global du store. Lorsqu'on utilise un système de module, il est nécessaire d'importer le store dans tous les composants qui utilisent l'état du store, et il est également nécessaire de le simuler lorsque l'on teste le composant.
 
-Vuex fournit un méchanisme pour "injecter" le store dans tous les composants enfants du composant racine avec l'option `store` (activée par `Vue.use(Vuex)`) :
+Vuex fournit un méchanisme pour « injecter » le store dans tous les composants enfants du composant racine avec l'option `store` (activée par `Vue.use(Vuex)`) :
 
 ``` js
 const app = new Vue({
   el: '#app',
-  // fournit le store avec l'option "store".
+  // fournit le store avec l'option `store`.
   // cela injectera l'instance du store dans tous les composants enfants.
   store,
   components: { Counter },
@@ -43,7 +43,7 @@ const app = new Vue({
 })
 ```
 
-En fournissant l'option `store` à l'instance racine, le store sera injecté dans tous les composants enfants de la racine et sera disponible sur ceux-ci avec `this.$store`. Mettons à jours notre implémentation de `Counter` :
+En fournissant l'option `store` à l'instance racine, le store sera injecté dans tous les composants enfants de la racine et sera disponible dans ces derniers avec `this.$store`. Mettons à jour notre implémentation de `Counter` :
 
 ``` js
 const Counter = {
@@ -56,12 +56,12 @@ const Counter = {
 }
 ```
 
-### Le helper `mapState`
+### La fonction utilitaire `mapState`
 
-Lorsqu'un composant a besoin d'utiliser plusieurs propriétés ou getters du state du store, déclarer toutes ces computed properties peut devenir répétitif et verbeux. Afin de palier à ça, nous pouvons utiliser le helper `mapState` qui génère des fonctions getters pour nous et nous épargne quelques coups de clavier :
+Lorsqu'un composant a besoin d'utiliser plusieurs accesseurs ou propriétés de l'état du store, déclarer toutes ces propriétés calculées peut devenir répétitif et verbeux. Afin de palier à ça, nous pouvons utiliser la fonction utilitaire `mapState` qui génère des fonctions d'accession pour nous et nous épargne quelques coups de clavier :
 
 ``` js
-// dans la version standalone, les helpers sont exposés comme Vuex.mapState
+// dans la version complète, des fonctions utilitaires sont exposées tel que `Vuex.mapState`
 import { mapState } from 'vuex'
 
 export default {
@@ -73,7 +73,7 @@ export default {
     // passer la valeur littérale 'count' revient à écrire `state => state.count`
     countAlias: 'count',
 
-    // pour accéder au state local avec `this`, une fonction normale doit être utilisée
+    // pour accéder à l'état local avec `this`, une fonction normale doit être utilisée
     countPlusLocalState (state) {
       return state.count + this.localCount
     }
@@ -81,29 +81,29 @@ export default {
 }
 ```
 
-Il est également possible de fournir un tableau de chaînes de caractères à `mapState` lorsque le nom de la propriété du state du store est la même que celui du composant.
+Il est également possible de fournir un tableau de chaînes de caractères à `mapState` lorsque le nom de la propriété de l'état du store est le même que celui du composant.
 
 ``` js
 computed: mapState([
-  // attacher this.count à store.state.count
+  // attacher `this.count` à `store.state.count`
   'count'
 ])
 ```
 
-### Object Spread Operator
+### Opérateur de décomposition
 
-Notez que `mapState` renvoie un objet. Comment l'utiliser en complément des autres computed properties locales ? Normalement, il faudrait utiliser un outil pour fusionner les multiples objets en un seul afin de passer cet objet final à `computed`. Cependant avec le [object spread operator](https://github.com/sebmarkbage/ecmascript-rest-spread) (qui est une proposition stage-3 ECMASCript), nous pouvons grandement simplifier la syntaxe :
+Notez que `mapState` renvoie un objet. Comment l'utiliser en complément des autres propriétés calculées locales ? Normalement, il faudrait utiliser un outil pour fusionner les multiples objets en un seul afin de passer cet objet final à `computed`. Cependant avec l'[opérateur de décomposition](https://developer.mozilla.org/fr/docs/Web/JavaScript/Reference/Op%C3%A9rateurs/Op%C3%A9rateur_de_d%C3%A9composition) (qui est une proposition stage-3 ECMASCript), nous pouvons grandement simplifier la syntaxe :
 
 ``` js
 computed: {
   localComputed () { /* ... */ },
-  // rajouter cet objet dans l'objet `computed` avec l'object spread operator
+  // rajouter cet objet dans l'objet `computed` avec l'opérateur de décomposition
   ...mapState({
     // ...
   })
 }
 ```
 
-### Les composants peuvent toujours avoir un state local
+### Les composants peuvent toujours avoir un état local
 
-Utiliser Vuex ne signifie pas que vous devez mettre **tout** votre state dans Vuex. Bien que le fait de mettre plus de state dans Vuex rende vos mutations de state plus explicites et plus debuggables, parfois il peut aussi rendre le code plus verbeux et indirect. Si une partie de state appartient directement à un seul composant, il est parfaitement sain de la laisser dans le state local. Assurez vous de prendre en compte les avantages et inconvénients d'une telle décision afin de vous adaptez le mieux aux besoins de votre application.
+Utiliser Vuex ne signifie pas que vous devez mettre **tout** votre état dans Vuex. Bien que le fait de mettre plus d'état dans Vuex rende vos mutation d'état plus explicites et plus débogable, parfois il peut aussi rendre le code plus verbeux et indirect. Si une partie de l'état appartient directement à un seul composant, il est parfaitement sain de la laisser dans l'état local. Assurez vous de prendre en compte les avantages et inconvénients d'une telle décision afin de vous adapter au mieux aux besoins de votre application.

docs/fr/strict.md

@@ -1,6 +1,6 @@
-# Strict Mode
+# Mode strict
 
-Pour activer le mode strict, passez simplement l'option `strict: true` lorsque vous créez un store Vuex :
+Pour activer le mode strict, passez simplement l'option `strict: true` pendant la création d'un store Vuex :
 
 ``` js
 const store = new Vuex.Store({
@@ -9,11 +9,11 @@ const store = new Vuex.Store({
 })
 ```
 
-En mode strict, lorsque le state Vuex est modifié en dehors des handlers de mutation, une erreur sera lancée. Cela permet de s'assurer que toutes les mutations du state peuvent être explicitement tracées par les outils de debugging.
+En mode strict, lorsque l'état de Vuex est modifié en dehors des gestionnaires de mutation, une erreur sera lancée. Cela permet de s'assurer que toutes les mutations de l'état peuvent être explicitement tracées par les outils de débogage.
 
-### Développement vs. Production
+### Développement vs. production
 
-**N'activez pas le mode strict lorsque vous déployez en production !** Le mode strict lance une observation récursive du state tree pour détecter des mutations inappropriées — assurrez-vous de l'avoir désactivé en production pour éviter un coût sur les performances.
+**N'activez pas le mode strict lorsque vous déployez en production !** Le mode strict lance une observation récursive de l'arbre d'état pour détecter des mutations inappropriées. Assurrez-vous de l'avoir désactivé en production pour éviter un coût sur les performances.
 
 Tout comme les plugins, nous pouvons laisser nos outils de build gérer ça :
 

docs/fr/structure.md

@@ -1,14 +1,14 @@
 # Structure d'une application
 
-Vuex ne vous restreint pas vraiment dans la façon dont vous voulez structurer votre code. Il impose plutôt un set de principes de haut niveau :
+Vuex ne vous restreint pas quand à la structure de code à utiliser. Il impose plutôt de respecter des principes de haut niveau :
 
-1. Le state d'application est centralisé dans le store.
+1. L'état de l'application est centralisé dans le store.
 
-2. La seule façon de muter le state est de commiter des **mutations**, qui sont des transactions synchrones.
+2. La seule façon de muter l'état est d'acter des **mutations**, qui sont des transactions synchrones.
 
 3. La logique asynchrone doit être composée et encapsulée dans des **actions**.
 
-Tant que vous suivez ces règles, c'est à vous de structurer votre projet. Si votre fichier de store devient trop gros, commencez simplement par séparer les actions, mutations et getters dans des fichiers séparés.
+Tant que vous suivez ces règles, c'est à vous de structurer votre projet. Si votre fichier de store devient trop gros, commencez dès lors à séparer les actions, mutations et accesseurs dans des fichiers séparés.
 
 Pour une application non-triviale, nous aurons probablement besoin de faire appel à des modules. Voici un exemple de structure de projet :
 
@@ -16,17 +16,17 @@ Pour une application non-triviale, nous aurons probablement besoin de faire appe
 ├── index.html
 ├── main.js
 ├── api
-│   └── ... # abstractions for making API requests
+│   └── ... # abstraction pour faire des requêtes par API
 ├── components
 │   ├── App.vue
 │   └── ...
 └── store
-    ├── index.js          # Là où l'on assemble nos modules et exportons le store
-    ├── actions.js        # Actions racine
-    ├── mutations.js      # Mutations racine
+    ├── index.js          # là où l'on assemble nos modules et exportons le store
+    ├── actions.js        # actions racine
+    ├── mutations.js      # mutations racine
     └── modules
-        ├── cart.js       # cart module
-        └── products.js   # products module
+        ├── cart.js       # module de panier
+        └── products.js   # module de produit
 ```
 
-Vous pouvez jeter à un œil à [l'exemple Shopping Cart](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).
+Vous pouvez jeter à un œil à l'[exemple de panier d'achat](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).

docs/fr/testing.md

@@ -1,6 +1,6 @@
 # Tests
 
-Les parties principales que l'on veut couvrir par des tests unitaires en Vuex sont les mutations et les actions.
+Les parties principales que l'on veut couvrir par des tests unitaires avec Vuex sont les mutations et les actions.
 
 ### Tester les mutations
 
@@ -9,7 +9,7 @@ Les mutations sont très simples à tester, puisque ce sont de simples fonctions
 ``` js
 const state = { ... }
 
-// export mutations as a named export
+// exporter les mutations en tant qu'export nommé
 export const mutations = { ... }
 
 export default new Vuex.Store({
@@ -18,7 +18,7 @@ export default new Vuex.Store({
 })
 ```
 
-Exemple de test de mutation utilisant Mocha + Chai (vous pouvez utiliser n'importe quel framework/bibliothèque d'assertion selon votre préférence) :
+Exemple de test de mutation utilisant Mocha + Chai (vous pouvez utiliser n'importe quel framework/bibliothèque d'assertion selon vos préférences) :
 
 ``` js
 // mutations.js
@@ -32,16 +32,16 @@ export const mutations = {
 import { expect } from 'chai'
 import { mutations } from './store'
 
-// destructure assign mutations
+// assignement des mutations par déstructuration
 const { increment } = mutations
 
 describe('mutations', () => {
   it('INCREMENT', () => {
-    // mock state
+    // état simulé
     const state = { count: 0 }
-    // apply mutation
+    // appliquer la mutation
     increment(state)
-    // assert result
+    // tester le résultat
     expect(state.count).to.equal(1)
   })
 })
@@ -49,7 +49,7 @@ describe('mutations', () => {
 
 ### Tester les actions
 
-Les actions sont un peu plus compliquées car elles peuvent faire appel à des APIs externes. Lorsque l'on teste des actions, on a souvent besoin de faire du mocking — par exemple, on peut abstraire l'appel API dans un service et mocker ce service dans nos tests. Afin de mocker facilement les dépendances, on peut utiliser webpack et [inject-loader](https://github.com/plasticine/inject-loader) pour regrouper nos fichiers de test.
+Les actions sont un peu plus compliquées car elles peuvent faire appel à des APIs externes. Lorsque l'on teste des actions, on a souvent besoin de faire plusieurs niveaux de simulation. Par exemple, on peut abstraire l'appel API dans un service et simuler ce service dans nos tests. Afin de simuler facilement les dépendances, on peut utiliser webpack et [inject-loader](https://github.com/plasticine/inject-loader) pour regrouper nos fichiers de test.
 
 Exemple de test d'une action asynchrone :
 
@@ -68,28 +68,28 @@ export const getAllProducts = ({ commit }) => {
 ``` js
 // actions.spec.js
 
-// use require syntax for inline loaders.
-// with inject-loader, this returns a module factory
-// that allows us to inject mocked dependencies.
+// utilisation de la syntaxe `require` pour les loaders.
+// avec inject-loader, cela retourne un module de fabrique
+// cela nous permet d'injecter les dépendances simulées.
 import { expect } from 'chai'
-const actionsInjector = require('inject!./actions')
+const actionsInjector = require('inject-loader!./actions')
 
-// create the module with our mocks
+// créer un module avec nos simulations
 const actions = actionsInjector({
   '../api/shop': {
     getProducts (cb) {
       setTimeout(() => {
-        cb([ /* mocked response */ ])
+        cb([ /* réponse simulée */ ])
       }, 100)
     }
   }
 })
 
-// helper for testing action with expected mutations
+// fonction utilitaire pour tester des actions avec les mutations attendues
 const testAction = (action, args, state, expectedMutations, done) => {
   let count = 0
 
-  // mock commit
+  // acter une simulation
   const commit = (type, payload) => {
     const mutation = expectedMutations[count]
 
@@ -108,10 +108,10 @@ const testAction = (action, args, state, expectedMutations, done) => {
     }
   }
 
-  // call the action with mocked store and arguments
+  // appeler l'action avec le store simulé et les arguments
   action({ commit, state }, ...args)
 
-  // check if no mutations should have been dispatched
+  // vérifier qu'aucune mutations n'ai été propagée
   if (expectedMutations.length === 0) {
     expect(count).to.equal(0)
     done()
@@ -128,11 +128,11 @@ describe('actions', () => {
 })
 ```
 
-### Tester les getters
+### Tester les accesseurs
 
-Si vos getters font des calculs compliqués, il peut être judicieux de les tester. Les getters sont également très simples à tester, pour les mêmes raisons que les mutations.
+Si vos accesseurs font des calculs compliqués, il peut être judicieux de les tester. Les accesseurs sont également très simples à tester, pour les mêmes raisons que les mutations.
 
-Exemple de test d'un getter :
+Exemple de test d'un accesseur :
 
 ``` js
 // getters.js
@@ -152,7 +152,7 @@ import { getters } from './getters'
 
 describe('getters', () => {
   it('filteredProducts', () => {
-    // mock state
+    // état simulé
     const state = {
       products: [
         { id: 1, title: 'Apple', category: 'fruit' },
@@ -160,13 +160,13 @@ describe('getters', () => {
         { id: 3, title: 'Carrot', category: 'vegetable' }
       ]
     }
-    // mock getter
+    // accesseur simulé
     const filterCategory = 'fruit'
 
-    // get the result from the getter
+    // obterir le résultat depuis l'accesseur
     const result = getters.filteredProducts(state, { filterCategory })
 
-    // assert the result
+    // tester le résultat
     expect(result).to.deep.equal([
       { id: 1, title: 'Apple', category: 'fruit' },
       { id: 2, title: 'Orange', category: 'fruit' }
@@ -177,9 +177,9 @@ describe('getters', () => {
 
 ### Lancer les tests
 
-Si vos mutations et actions sont écrites comme il se doit, les tests ne devraient pas avoir de dépendance directe sur les APIs navigateur après un mocking préalable. Cela signifie que vous pouvez simplement regrouper les tests avec webpack et les lancer directement dans Node. De façon alternative, vous pouvez utiliser `mocha-loader` ou Karma + `karma-webpack` afin d'effectuer les tests dans des vrais navigateurs.
+Si vos mutations et actions sont écrites comme il se doit, les tests ne devraient pas avoir de dépendance directe sur les APIs navigateur après une simulation préalable. Cela signifie que vous pouvez simplement regrouper les tests avec webpack et les lancer directement dans Node.js. De façon alternative, vous pouvez utiliser `mocha-loader` ou Karma + `karma-webpack` afin d'effectuer les tests dans des vrais navigateurs.
 
-#### Lancer dans Node
+#### Lancer dans Node.js
 
 Créez la configuration webpack suivante (ainsi que le fichier [`.babelrc`](https://babeljs.io/docs/usage/babelrc/) qui correspond) :
 
@@ -212,10 +212,10 @@ mocha test-bundle.js
 
 #### Lancer dans un navigateur
 
-1. Installez `mocha-loader`
-2. Changez l'option `entry` de la configuration webpack ci-dessus pour `'mocha!babel!./test.js'`.
+1. Installez `mocha-loader`.
+2. Changez l'option `entry` de la configuration webpack ci-dessus pour `'mocha-loader!babel-loader!./test.js'`.
 3. Démarrez `webpack-dev-server` en utilisant cette configuration.
-4. Pointez votre navigateur sur `localhost:8080/webpack-dev-server/test-bundle`.
+4. Rendez-vous avec votre navigateur sur `localhost:8080/webpack-dev-server/test-bundle`.
 
 #### Lancer dans un navigateur avec Karma + karma-webpack