Add changes after @haeresis and @kokal review.

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

docs/en/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
 
-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 du 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 callack 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,23 +146,26 @@ 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')`
     })
   }
 }
 ```
 
 ### 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).