Merge branch 'working' into mutation

Author: MachinisteWeb

docs/en/SUMMARY.md

@@ -11,7 +11,7 @@
 - [Pour commencer](getting-started.md)
 - Concepts de base
   - [État](state.md)
-  - [Getters](getters.md)
+  - [Accesseurs](getters.md)
   - [Mutations](mutations.md)
   - [Actions](actions.md)
   - [Modules](modules.md)

docs/en/getters.md

@@ -1,6 +1,6 @@
-# Getters
+# Accesseurs
 
-Sometimes we may need to compute derived state based on store state, for example filtering through a list of items and counting them:
+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: {
@@ -10,9 +10,9 @@ computed: {
 }
 ```
 
-If more than one component needs to make use of this, we have to either duplicate the function, or extract it into a shared helper and import it in multiple places - both are less than ideal.
+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 allows us to define "getters" in the store (think of them as computed properties for stores). Getters will receive the state as their 1st argument:
+Vuex nous permet de définir des accesseurs (« getters ») dans le store (oyez-les comme les propriétés calculées des stores). Les accesseurs prennent l'état en premier argument :
 
 ``` js
 const store = new Vuex.Store({
@@ -30,13 +30,13 @@ const store = new Vuex.Store({
 })
 ```
 
-The getters will be exposed on the `store.getters` object:
+Les accesseurs seront exposés sur l'objet `store.getters` :
 
 ``` js
 store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
 ```
 
-Getters will also receive other getters as the 2nd argument:
+Les accesseurs recevront également les autres accesseurs en second argument :
 
 ``` js
 getters: {
@@ -51,7 +51,7 @@ getters: {
 store.getters.doneTodosCount // -> 1
 ```
 
-We can now easily make use of it inside any component:
+Nous pouvons maintenant facilement les utiliser dans n'importe quel composant :
 
 ``` js
 computed: {
@@ -61,7 +61,8 @@ computed: {
 }
 ```
 
-You can also pass arguments to getters by returning a function. This is particularly useful when you want to query an array in the store:
+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: {
   // ...
@@ -75,18 +76,17 @@ getters: {
 store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
 ```
 
+### La fonction utilitaire `mapGetters`
 
-### The `mapGetters` Helper
-
-The `mapGetters` helper simply maps store getters to local computed properties:
+La fonction utilitaire `mapGetters` attache simplement vos accesseurs du store aux propriétés calculées locales :
 
 ``` js
 import { mapGetters } from 'vuex'
 
 export default {
   // ...
   computed: {
-    // mix the getters into computed with object spread operator
+    // rajouter les accesseurs dans `computed` avec l'opérateur de décomposition
     ...mapGetters([
       'doneTodosCount',
       'anotherGetter',
@@ -96,11 +96,11 @@ export default {
 }
 ```
 
-If you want to map a getter to a different name, use an object:
+Si vous voulez attacher un accesseur avec un nom différent, utilisez un objet :
 
 ``` js
 ...mapGetters({
-  // map this.doneCount to store.getters.doneTodosCount
+  // attacher `this.doneCount` à `store.getters.doneTodosCount`
   doneCount: 'doneTodosCount'
 })
 ```

docs/en/intro.md

@@ -36,7 +36,7 @@ C'est une application auto-suffisante avec les parties suivantes :
 Voici une représentation extrèmement simple du concept de « flux de donnée unidirectionnel » :
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <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 un même état global** :

docs/en/state.md

@@ -24,7 +24,7 @@ const Counter = {
 
 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 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 créer un jeu de test 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)`) :
 

docs/en/structure.md

@@ -1,32 +1,32 @@
-# Application Structure
+# Structure d'une application
 
-Vuex doesn't really restrict how you structure your code. Rather, it enforces a set of high-level principles:
+Vuex ne vous restreint pas quand à la structure de code à utiliser. Il impose plutôt de respecter des principes de haut niveau :
 
-1. Application-level state is centralized in the store.
+1. L'état de l'application est centralisé dans le store.
 
-2. The only way to mutate the state is by committing **mutations**, which are synchronous transactions.
+2. La seule façon de muter l'état est d'acter des **mutations**, qui sont des transactions synchrones.
 
-3. Asynchronous logic should be encapsulated in, and can be composed with **actions**.
+3. La logique asynchrone doit être composée et encapsulée dans des **actions**.
 
-As long as you follow these rules, it's up to you how to structure your project. If your store file gets too big, simply start splitting the actions, mutations and getters into separate files.
+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.
 
-For any non-trivial app, we will likely need to leverage modules. Here's an example project structure:
+Pour une application non-triviale, nous aurons probablement besoin de faire appel à des modules. Voici un exemple de structure de projet :
 
 ``` bash
 ├── index.html
 ├── main.js
 ├── api
-│   └── ... # abstractions for making API requests
+│   └── ... # abstraction pour faire des requêtes par API
 ├── components
 │   ├── App.vue
 │   └── ...
 └── store
-    ├── index.js          # where we assemble modules and export the store
-    ├── actions.js        # root actions
-    ├── mutations.js      # root mutations
+    ├── 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
 ```
 
-As a reference, check out the [Shopping Cart Example](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/intro.md

@@ -36,7 +36,7 @@ C'est une app auto-contenue avec les parties suivantes :
 Voici une représentation extrèmement simple du concept de "one-way data flow" (_flux de données unidirectionnel_) :
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <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** :

docs/ja/intro.md

@@ -38,7 +38,7 @@ new Vue({
 これらは"単方向データフロー"のコンセプトの極めてシンプルな責務です:
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
 しかし、単純さは、**共通の状態を共有する複数のコンポーネントを持ったときに**、すぐに破綻します:

docs/ja/mutations.md

@@ -179,7 +179,7 @@ export default {
 
 ### アクションへ向けて
 
-状態変更を非同期に組み合わせることは、プログラムの動きを予測することを非常に困難にします。例えば、状態を変更する非同期コールバックを持った 2つのメソッドを両方呼び出しとき、それらがいつ呼び出されたか、どちらが先に呼び出されたかを、どうやって知ればよいのでしょう？これがまさに、状態変更と非同期の 2つの概念を分離したいという理由です。Vuex では**全てのミューテーションは同期的に行う**という作法になっています:
+状態変更を非同期に組み合わせることは、プログラムの動きを予測することを非常に困難にします。例えば、状態を変更する非同期コールバックを持った 2つのメソッドを両方呼び出すとき、それらがいつ呼び出されたか、どちらが先に呼び出されたかを、どうやって知ればよいのでしょう？これがまさに、状態変更と非同期の 2つの概念を分離したいという理由です。Vuex では**全てのミューテーションは同期的に行う**という作法になっています:
 
 ``` js
 store.commit('increment')

docs/kr/intro.md

@@ -36,7 +36,7 @@ new Vue({
 이것은 "단방향 데이터 흐름" 개념의 매우 단순한 도표입니다.
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
 그러나 **공통의 상태를 공유하는 여러 컴포넌트** 가 있는 경우 단순함이 빠르게 저하됩니다.

docs/ru/intro.md

@@ -36,7 +36,7 @@ new Vue({
 Вот простейшее представление концепции "однонаправленного потока данных":
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
 Простота, к сожалению, быстро исчезает при появлении **нескольких компонентов, основывающихся на одном и том же состоянии**, когда:

docs/zh-cn/intro.md

@@ -36,7 +36,7 @@ new Vue({
 以下是一个表示“单向数据流”理念的极简示意：
 
 <p style="text-align: center; margin: 2em">
-  <img style="max-width:450px;" src="./images/flow.png">
+  <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
 但是，当我们的应用遇到**多个组件共享状态**时，单向数据流的简洁性很容易被破坏：