Fixes for pt-br translation (#1245)

* Fixes pullrequest of DavidWilliamBalbino

* Added Portuguese Link in LANGS.md

* I made a revision of translation

* Added plugin translate

* I made more one revision of translation

* More one revision

* Revision

* Revision of Links

* Encoded File Revision

* Geral Revision

* Adjustment in General Revision

* Revision state file

* Revision state file

* Revision of translation getting started

* Revision of translation actions

* Revision Translation modules

* Revision Translation intro

* Revision Translation getting started

* Revision Translation Spaces

* Revision Translation getting started

* Revision Translation General

* Revision links api

* Remove redundant spaces

* Revision of some phrases

* Revision of some phrases

* General Revision using grep to find some wrong words

* Revision of more one bad translation Coming direct from google translator

* Revision of some words with grep

* Revision of some points showed by Erick

* Revision General of points showed by Erick

* Genre Revision

* more revisions with grep

* more revisions with grep

* One more

* Revision to remove duplicated spaces showed by Erick

docs/pt-br/actions.md

@@ -23,10 +23,10 @@ const store = new Vuex.Store({
 })
 ```
 
-Os manipuladores de ação recebem um objeto de contexto que expõe o mesmo conjunto de métodos / propriedades na instância da _store_ , para que você possa chamar `context.commit` para confirmar uma mutação ou acessar o estado e os getters através do `context.state` e do `contexto. getters`.
-Veremos por que esse objeto de contexto não é a própria instância da _store_  quando apresentamos [Módulos](modules.md) mais tarde.
+Os manipuladores de ação recebem um objeto de contexto que expõe o mesmo conjunto de métodos / propriedades na instância do _store_, para que você possa chamar `context.commit` para confirmar uma mutação ou acessar o estado e os _getters_ através do `context.state` e do `contexto.getters`.
+Veremos por que esse objeto de contexto não é a própria instância do _store_ quando apresentamos [Módulos](modules.md) mais tarde.
 
-Na prática, muitas vezes usamos ES2015 [desestruturação de argumentos](https://github.com/lukehoban/es6features#destructuring) para simplificar um pouco o código(especialmente quando precisamos chamar `commit` várias vezes):
+Na prática, muitas vezes usamos ES2015 [desestruturação de argumentos](https://github.com/lukehoban/es6features#destructuring) para simplificar um pouco o código (especialmente quando precisamos usar _commit_ várias vezes):
 
 ``` js
 actions: {
@@ -44,7 +44,7 @@ As ações são acionadas com o método `store.dispatch`:
 store.dispatch('increment')
 ```
 
-Isso pode parecer óbvio à primeira vista: se quisermos incrementar a contagem, por que não chamamos `store.commit ('incremento') diretamente? Lembre-se de que ** as mutações devem ser síncronas **? As ações não. Podemos executar ** operações assíncronas ** dentro de uma ação:
+Isso pode parecer óbvio à primeira vista: se quisermos incrementar a contagem, por que não chamamos `store.commit('increment')` diretamente? Você se lembra que **as mutações devem ser síncronas**? As ações não. Podemos executar **operações assíncronas** dentro de uma ação:
 
 ``` js
 actions: {
@@ -71,7 +71,7 @@ store.dispatch({
 })
 ```
 
-Um exemplo mais prático de ações reais seria uma ação para fazer check-out de um carrinho de compras, que envolve ** chamar uma API assíncrona ** e ** confirmar múltiplas mutações **:
+Um exemplo mais prático de ações reais seria uma ação para fazer _check-out_ de um carrinho de compras, que envolve **chamar uma API assíncrona** e **confirmar múltiplas mutações**:
 
 ``` js
 actions: {
@@ -81,7 +81,7 @@ actions: {
     // enviar solicitação de checkout
     // limpa o carrinho
     commit(types.CHECKOUT_REQUEST)
-    // a API da store aceita um callback bem-sucedido e um callback com falha
+    // a API do store aceita um callback bem-sucedido e um callback com falha
     shop.buyProducts(
       products,
       // callback em caso de sucesso
@@ -97,7 +97,7 @@ Observe que estamos realizando um fluxo de operações assíncronas e gravando o
 
 ### Ações de Despacho em Componentes
 
-Você pode despachar ações em componentes com `this. $store.dispatch ('xxx')`, ou usar o auxiliar `mapActions` que mapeia métodos de componente para chamadas do ` store.dispatch` (esta ação requer a injeção root `store`):
+Você pode despachar ações em componentes com `this.$store.dispatch('xxx')`, ou usar o auxiliar `mapActions` que mapeia métodos de componente para chamadas do `store.dispatch` (esta ação requer injeção do `store` na instância raiz):
 
 ``` js
 import { mapActions } from 'vuex'
@@ -108,7 +108,7 @@ export default {
     ...mapActions([
       'increment', // mapeia `this.increment()` para `this.$store.dispatch('increment')`
 
-      // `mapActions` also supports payloads:
+      // `mapActions` também suporta payloads:
       'incrementBy' // mapeia `this.incrementBy(amount)` para `this.$store.dispatch('incrementBy', amount)`
     ]),
     ...mapActions({
@@ -175,4 +175,3 @@ actions: {
 ```
 
 > É possível para um `store.dispatch` desencadear vários manipuladores de ação em diferentes módulos. Neste caso, o valor retornado será uma Promise que resolve quando todos os manipuladores desencadeados foram resolvidos.
-

docs/pt-br/api.md

@@ -8,20 +8,21 @@ import Vuex from 'vuex'
 const store = new Vuex.Store({ ...options })
 ```
 
-### Vuex.Store Opções do construtor
+### Vuex.Store Opções do Construtor
 
 - **state**
 
   - type: `Object | Function`
 
-O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
-    Se você passar uma função que retorna um objeto, o objeto retornado é usado como o estado da raiz. Isso é útil quando você deseja reutilizar o objeto de estado, especialmente para reutilização de módulos. [Detalhes](modules.md#módulo-reutilização)
+    O objeto raiz de estado para o _store_ Vuex. [Detalhes](state.md)
+
+    Se você passar uma função que retorna um objeto, o objeto retornado é usado como o estado da raiz. Isso é útil quando você deseja reutilizar o objeto de estado, especialmente para reutilização de módulos. [Detalhes](modules.md#reutilização-do-módulo)
 
 - **mutações**
 
   - type: `{ [type: string]: Function }`
 
-    Registra mutações na _store_ . A função do manipulador sempre recebe `estado` como o primeiro argumento (será o estado local do módulo se definido em um módulo) e receberá um segundo argumento `payload` se houver um.
+    Registra mutações no _store_. A função do manipulador sempre recebe `estado` como o 1º argumento (será o estado local do módulo se definido em um módulo) e receberá um 2º argumento `payload` se houver um.
 
     [Detalhes](mutations.md)
 
@@ -29,7 +30,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
   - type: `{ [type: string]: Function }`
 
-    Registra ações na _store_ . A função do manipulador recebe um objeto `context` que expõe as seguintes propriedades:
+    Registra ações no _store_. A função do manipulador recebe um objeto `context` que expõe as seguintes propriedades:
     ``` js
     {
       state,      // o mesmo que `store.state`, ou estado local se estiver em módulos
@@ -43,14 +44,14 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
     [Detalhes](actions.md)
 
-- **getters**
+- **_getters_**
 
   - type: `{ [key: string]: Function }`
 
-    Registra getters na _store_ . A função getter recebe os seguintes argumentos:
+    Registra _getters_ no _store_. A função _getter_ recebe os seguintes argumentos:
     ```
     state,     // será o estado local do módulo, se definido em um módulo.
-    getters    // o mesmo que store.getters
+    getters    // o mesmo que `store.getters`
     ```
 
     Especifique quando definido em um módulo
@@ -63,7 +64,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
     rootGetters  // todos os getters
     ```
 
-    Os getters registrados estão expostos em `store.getters`.
+    Os _getters_ registrados estão expostos em `store.getters`.
 
     [Detalhes](getters.md)
 
@@ -71,7 +72,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
   - type: `Object`
 
-    Um objeto contendo sub módulos a serem incorporados na _store_ , de forma que:
+    Um objeto contendo sub módulos a serem incorporados no _store_, de forma que:
     ``` js
     {
       key: {
@@ -86,7 +87,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
     }
     ```
 
-    Cada módulo pode conter "estado" e "mutações" semelhantes às opções raiz. O estado de um módulo será anexado ao estado da raiz da _store_  usando a chave do módulo. As mutações e getters de um módulo receberão apenas o estado local do módulo como o primeiro argumento em vez do estado da raiz e as ações do módulo 'context.state` também apontarão para o estado local.
+    Cada módulo pode conter "estado" e "mutações" semelhantes às opções raiz. O estado de um módulo será anexado ao estado da raiz do _store_ usando a chave do módulo. As mutações e _getters_ de um módulo receberão apenas o estado local do módulo como o 1º argumento em vez do estado da raiz e as ações do módulo `context.state` também apontarão para o estado local.
 
     [Detalhes](modules.md)
 
@@ -94,7 +95,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
   - type: `Array<Function>`
 
-	Um array de funções de plugin a serem aplicadas na _store_ . O plugin simplesmente recebe a _store_  como o único argumento e pode ouvir mutações (para persistência de dados de saída, log ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou observáveis).
+	Um array de funções de plugin a serem aplicadas no _store_. O plugin simplesmente recebe o _store_ como o único argumento e pode ouvir mutações (para persistência de dados de saída, log ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou observáveis).
 
     [Detalhes](plugins.md)
 
@@ -103,47 +104,47 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
   - type: `Boolean`
   - default: `false`
 
-    Força a _store_  Vuex em modo estrito. No modo estrito, qualquer mutação ao estado do Vuex fora dos manipuladores de mutação acusará um erro.
+    Força o _store_ Vuex em modo estrito. No modo estrito, qualquer mutação ao estado do Vuex fora dos manipuladores de mutação acusará um erro.
 
     [Detalhes](strict.md)
 
 ### Vuex.Store Propriedades da instância
 
-- **state**
+- **_state_**
 
   - type: `Object`
 
     O estado raiz. Apenas leitura.
 
-- **getters**
+- **_getters_**
 
   - type: `Object`
 
-    Expõe os getters registrados. Apenas leitura.
+    Expõe os _getters_ registrados. Apenas leitura.
 
-### Vuex.Store Métodos da instância
+### Vuex.Store Métodos da Instância
 
 - **`commit(type: string, payload?: any, options?: Object) | commit(mutation: Object, options?: Object)`**
 
-  Confirma uma mutação. `options` pode ter` root: true` que permite confirmar mutações da raiz em [namespaced modules](modules.md#namespacing). [Detalhes](mutations.md)
+  Confirma uma mutação. `options` pode ter `root: true` que permite confirmar mutações da raiz em [módulos namespaced](modules.md#namespacing). [Detalhes](mutations.md)
 
 - **`dispatch(type: string, payload?: any, options?: Object) | dispatch(action: Object, options?: Object)`**
 
-  Despacha uma ação. `options` pode ter `root: true` que permite enviar ações para raiz em [namespaced modules](modules.md#namespacing). Retorna Promise que resolve todos os manipuladores de ação acionados. [Detalhes](actions.md)
+  Despacha uma ação. `options` pode ter `root: true` que permite enviar ações para raiz em [módulos namespaced](modules.md#namespacing). Retorna Promise que resolve todos os manipuladores de ação acionados. [Detalhes](actions.md)
 
 - **`replaceState(state: Object)`**
 
-  Substitua o estado da raiz da _store_ . Use isso apenas para fins de hidratação / viagem no tempo.
+  Substitua o estado da raiz do _store_. Use isso apenas para fins de _hydration_ / _time-travel_.
 
 - **`watch(getter: Function, cb: Function, options?: Object)`**
 
-  Visualiza de forma reativa um valor de retorno da função getter e chame o callback para o retorno de chamada quando o valor mudar. O getter recebe o estado da _store_  como o primeiro argumento e os getters como o segundo argumento. Aceita um objeto de opções opcional que leva as mesmas opções que o método `vm. $ Watch` do Vue.
+  Visualiza de forma reativa um valor de retorno da função _getter_ e chama o callback para o retorno de chamada quando o valor mudar. O _getter_ recebe o estado do _store_ como o 1º argumento e os _getters_ como o 2º argumento. Aceita um objeto de opções opcional que leva as mesmas opções que o método `vm. $ Watch` do Vue.
 
   Para parar de visualizar, chame para a função do manipulador retornada.
 
 - **`subscribe(handler: Function)`**
 
-  Assina as mutações da _store_ . O `handler` é chamado após cada mutação e recebe o descritor de mutação e o estado pós-mutação como argumentos:
+  Assina as mutações do _store_. O `handler` é chamado após cada mutação e recebe o descritor de mutação e o estado pós-mutação como argumentos:
 
   ``` js
   store.subscribe((mutation, state) => {
@@ -158,7 +159,7 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
   > Novo em 2.5.0
 
-  Assina as ações da _store_ . O `handler` é chamado para cada ação despachada e recebe o descritor de ação e o estado atual da _store_  como argumentos:
+  Assina as ações do _store_. O `handler` é chamado para cada ação despachada e recebe o descritor de ação e o estado atual do _store_ como argumentos:
 
   ``` js
   store.subscribeAction((action, state) => {
@@ -171,48 +172,46 @@ O objeto do estado da raiz para a _store_  Vuex. [Detalhes](state.md)
 
 - **`registerModule(path: string | Array<string>, module: Module, options?: Object)`**
 
-  Registra um módulo dinâmico. [Detalhes](modules.md#dynamic-module-registration)
+  Registra um módulo dinâmico. [Detalhes](modules.md#registro-de-módulo-dinâmico)
 
   `options` pode ter `preserveState: true` que permite preservar o estado anterior. Util para renderização server-side.
 
 - **`unregisterModule(path: string | Array<string>)`**
 
-  Cancela o registro de um módulo dinâmico. [Detalhes](modules.md#dynamic-module-registration)
+  Cancela o registro de um módulo dinâmico. [Detalhes](modules.md#registro-de-módulo-dinâmico)
 
 - **`hotUpdate(newOptions: Object)`**
 
   Faz Hot swap de novas ações e mutações. [Detalhes](hot-reload.md)
 
-### Component Binding Helpers
+### Métodos Auxiliares dos Componentes
 
 - **`mapState(namespace?: string, map: Array<string> | Object): Object`**
 
-  Cria componentes computadas de opções que retornam a subárvore da _store_  Vuex. [Detalhes](state.md#the-mapstate-helper)
+  Cria componentes computadas de opções que retornam a subárvore do _store_ Vuex. [Detalhes](state.md#o-auxiliar-mapstate)
 
-  O primeiro argumnto pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](modules.md#usando-métodos-auxiliares-com-namespace)
 
 - **`mapGetters(namespace?: string, map: Array<string> | Object): Object`**
 
-  Cria componentes computadas de opções que retornam valor avaliado deo getter. [Detalhes](getters.md#the-mapgetters-helper)
+  Criar opções computadas do componente que retornam o valor avaliado de um _getter_. [Detalhes](getters.md#o-auxiliar-mapgetters)
 
-  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](modules.md#usando-métodos-auxiliares-com-namespace)
 
 - **`mapActions(namespace?: string, map: Array<string> | Object): Object`**
 
   Cria um componente com métodos e opções que despacham uma ação.
 
-[Detalhes](actions.md#dispatching-actions-in-components)
+[Detalhes](actions.md#ações-de-despacho-em-componentes)
 
-  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](modules.md#usando-métodos-auxiliares-com-namespace)
 
 - **`mapMutations(namespace?: string, map: Array<string> | Object): Object`**
 
-  Cria um componente com métodos e opções que confirmam uma mutação. [Detalhes](mutations.md#committing-mutations-in-components)
+  Cria um componente com métodos e opções que confirmam uma mutação. [Detalhes](mutations.md#fazendo-commit-de-mutações-em-componente)
 
-  O primeiro argumento pode ser opcionalmente uma string com namespace. [Detalhes](modules.md#binding-helpers-with-namespace)
+  O 1º argumento pode ser opcionalmente uma _String_ com _namespace_. [Detalhes](modules.md#usando-métodos-auxiliares-com-namespace)
 
 - **`createNamespacedHelpers(namespace: string): Object`**
 
-  Cria um component namespaced ajudante de ligação . O objeto retornado possui  `mapState`, `mapGetters`, `mapActions` e `mapMutations`, que estão conectados com o namespace dado. [Detalhes](modules.md#binding-helpers-with-namespace)
-
-
+  Cria um componente _namespaced_ dos métodos auxiliares. O objeto retornado possui _mapState_, _mapGetters_, _mapActions_ e _mapMutations_, que estão conectados com o dado _namespace_. [Detalhes](modules.md#usando-métodos-auxiliares-com-namespace)

docs/pt-br/core-concepts.md

@@ -1,6 +1,6 @@
 # Conceitos básicos
 
-Estaremos aprendendo os conceitos básicos do Vuex nestes capítulos. São eles:
+Vamos aprender os conceitos básicos do Vuex nestes capítulos. São eles:
   - [Estado](state.md)
   - [Getters](getters.md)
   - [Mutações](mutations.md)

docs/pt-br/forms.md

@@ -5,8 +5,8 @@ Ao usar o Vuex no modo estrito, pode ser um pouco complicado usar `v-model` em u
 <input v-model="obj.message">
 ```
 
-Assumindo que `obj` é um dado computado que retorna um objeto da _store_ , o` v-model` aqui tentará mutar diretamente `obj.message` quando o usuário digitar a entrada. No modo estrito, isso resultará em um erro porque a mutação não é realizada dentro de um manipulador de mutação Vuex explícito.
-O "modo Vuex" para lidar com isso é vinculando o valor do(s) `<input>`'s e chamar uma ação no evento `input` ou` change`:
+Assumindo que `obj` é um dado computado que retorna um objeto do _store_, o `v-model` aqui tentará mutar diretamente `obj.message` quando o usuário digitar a entrada. No modo estrito, isso resultará em um erro porque a mutação não é realizada dentro de um manipulador de mutação Vuex explícito.
+O "modo Vuex" para lidar com isso é vinculando o valor do(s) `<input>`'s e chamar uma ação no evento `input` ou `change`:
 ``` html
 <input :value="message" @input="updateMessage">
 ```
@@ -37,7 +37,7 @@ mutations: {
 
 ### Dados computados bidirecionais (Two-way)
 
-É certo que o acima é um pouco mais detalhado do que o `v-model` + estado local, e também perdemos alguns dos recursos úteis do `v-model`. Uma abordagem alternativa está usando uma propriedade computada bidirecional com um setter:
+É certo que o acima é um pouco mais detalhado do que o `v-model` + estado local, e também perdemos alguns dos recursos úteis do `v-model`. Uma abordagem alternativa está usando um dado computado bidirecional com um setter:
  ``` html
 <input v-model="message">
 ```
@@ -54,4 +54,3 @@ computed: {
   }
 }
 ```
-

docs/pt-br/getters.md

@@ -1,6 +1,6 @@
-# Getters
+# _Getters_
 
-Às vezes, talvez precisemos calcular o estado derivado com base no estado da _store_  , por exemplo, filtrar através de uma lista de itens e contá-los:
+Às vezes, talvez precisemos calcular o estado derivado com base no estado do _store_, por exemplo, filtrar através de uma lista de itens e contá-los:
 
 ``` js
 computed: {
@@ -11,9 +11,9 @@ computed: {
 ```
 
 Se mais do que um componente precisa fazer uso disso, temos que duplicar a função, ou extraí-lo em um auxiliar compartilhado e importá-lo em vários lugares - ambos são menos do que o ideal.
-O Vuex nos permite definir "getters" na _store_ . Você pode pensar neles como dados computados para _stores_ . Como os dados computados, o resultado de um getter é armazenado em cache com base em suas dependências e só irá avaliar novamente quando algumas de suas dependências mudarem.
+O Vuex nos permite definir _getters_ no _store_. Você pode pensar neles como dados computados para os _stores_. Como os dados computados, o resultado de um _getter_ é armazenado em cache com base em suas dependências e só irá avaliar novamente quando algumas de suas dependências mudarem.
 
-Getters receberam o estado como seu primeiro argumento:
+_Getters_ receberam o estado como seu 1º argumento:
 
 ``` js
 const store = new Vuex.Store({
@@ -31,13 +31,13 @@ const store = new Vuex.Store({
 })
 ```
 
-Os getters serão descritos no objeto `store.getters`:
+Os _getters_ serão descritos no objeto `store.getters`:
 
 ``` js
 store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
 ```
 
-Getters também receberá outros getters como o segundo argumento:
+_Getters_ também podem receber outros _getters_ como o 2º argumento:
 
 ``` js
 getters: {
@@ -62,7 +62,7 @@ computed: {
 }
 ```
 
-Você também pode passar argumentos para getters retornando uma função. Isso é particularmente útil quando você deseja consultar um _array_  na _store_ :
+Você também pode passar argumentos para os _getters_ retornando uma função. Isso é particularmente útil quando você deseja consultar um _array_ no _store_ :
 
 ```js
 getters: {
@@ -79,7 +79,7 @@ store.getters.getTodoById(2) // -> { id: 2, text: '...', done: false }
 
 ### O auxiliar `mapGetters`
 
-O auxiliar `mapGetters` simplesmente mapeia os getters da _store_  para os dados computados locais:
+O auxiliar `mapGetters` simplesmente mapeia os _getters_ do _store_ para os dados computados locais:
 
 ``` js
 import { mapGetters } from 'vuex'
@@ -97,7 +97,7 @@ export default {
 }
 ```
 
-Se você deseja mapear um getter para um nome diferente, use um objeto:
+Se você deseja mapear um _getter_ para um nome diferente, use um objeto:
 
 ``` js
 ...mapGetters({
@@ -105,4 +105,3 @@ Se você deseja mapear um getter para um nome diferente, use um objeto:
   doneCount: 'doneTodosCount'
 })
 ```
-

docs/pt-br/getting-started.md

@@ -1,19 +1,19 @@
 # Começando
 
-No centro de cada aplicação Vuex existe a ** loja **. Uma "loja" é basicamente um recipiente que contém a sua aplicação ** state **. Há duas coisas que tornam uma loja Vuex diferente de um objeto global simples:
+No centro de cada aplicação Vuex existe o **_store_**. Um "_store_" é basicamente um recipiente que contém a sua aplicação **state**. Há duas coisas que tornam um _store_ Vuex diferente de um objeto global simples:
 
-1. As lojas Vuex são reativas. Quando os componentes do Vue obtêm o estado dele, eles atualizarão de forma reativa e eficiente se o estado da loja mudar.
+1. Os _stores_ Vuex são reativos. Quando os componentes do Vue obtêm o estado dele, eles atualizarão de forma reativa e eficiente se o estado do _store_ mudar.
 
-2. Você não pode mutar diretamente o estado da loja. A única maneira de mudar o estado de uma loja é explicitamente ** comitar mutações **. Isso garante que cada mudança de estado deixe um registro rastreável e permite ferramentas que nos ajudem a entender melhor nossas aplicações.
+2. Você não pode mutar diretamente o estado do _store_. A única maneira de mudar o estado de um _store_ é explicitamente **fazer _commit_ de mutações**. Isso garante que cada mudança de estado deixe um registro rastreável e permite ferramentas que nos ajudem a entender melhor nossas aplicações.
 
-### A loja mais simples
+### Armazenamento de Estado Simples
 
-> **NOTA:** Vamos usar a sintaxe ES2015 para exemplos de código para o resto dos documentos. Se você não o pegou, [você deveria](https://babeljs.io/docs/learn-es2015/)!
+> **NOTA:** Vamos usar a sintaxe ES2015 para exemplos de código para o resto dos documentos. Se você ainda não aprendeu como usá-la, [veja aqui](https://babeljs.io/docs/learn-es2015/)!
 
-Após [instalar](installation.md) Vuex, vamos criar uma loja. É bastante direto - apenas forneça um objeto de estado inicial e algumas mutações:
+Após [instalar](installation.md) Vuex, vamos criar um _store_. É bem simples - apenas forneça um objeto de estado inicial e algumas mutações:
 
 ``` js
-// Certifique-se de chamar Vue.use(Vuex) primeiro se estiver usando um sistema de módulo
+// Certifique-se de chamar Vue.use(Vuex) primeiro se estiver usando o sistema de módulos
 const store = new Vuex.Store({
   state: {
     count: 0
@@ -26,7 +26,7 @@ const store = new Vuex.Store({
 })
 ```
 
-Agora, você pode acessar o objeto de estado como `store.state` e acionar uma mudança de estado com o método` store.commit`:
+Agora, você pode acessar o objeto de estado como `store.state` e acionar uma mudança de estado com o método `store.commit`:
 
 ``` js
 store.commit('increment')
@@ -34,10 +34,10 @@ store.commit('increment')
 console.log(store.state.count) // -> 1
 ```
 
-Novamente, a razão pela qual estamos comitando uma mutação em vez de mudar `store.state.count 'diretamente, é porque queremos rastreá-la explicitamente. Esta convenção simples torna sua intenção mais explícita, de modo que você possa argumentar sobre as mudanças de estado em seu aplicativo melhor ao ler o código. Além disso, isso nos dá a oportunidade de implementar ferramentas que podem registrar cada mutação, tirar instantâneos de estado ou mesmo realizar depuração de viagem no tempo.
-Usar o estado da loja em um componente simplesmente envolve o retorno do estado dentro de uma propriedade computada, porque o estado da loja é reativo. Acionar as mudanças simplesmente significa comprometer mutações nos métodos componentes.
+Novamente, a razão pela qual estamos fazendo _commit_ de uma mutação em vez de mudar `store.state.count` diretamente, é porque queremos rastreá-la explicitamente. Esta convenção simples torna sua intenção mais explícita, de modo que você possa ter melhores argumetos sobre as mudanças de estado em seu aplicativo ao ler o código. Além disso, isso nos dá a oportunidade de implementar ferramentas que podem registrar cada mutação, tirar _snapshots_ de estado ou mesmo realizar depuração viajando pelo histórico de estado (_time travel_).
+
+Usar o estado do _store_ em um componente simplesmente envolve o retorno do estado dentro de um dado computado, porque o estado do _store_ é reativo. Fazer alterações simplesmente significa fazer _commit_ de mutações nos métodos dos componentes.
 
 Aqui está um exemplo do [aplicativo de contador do Vuex mais básico](https://jsfiddle.net/n9jmu5v7/1269/).
 
 Em seguida, discutiremos cada conceito chave em mais detalhes, começando com [Estado](state.md).
-

docs/pt-br/hot-reload.md

@@ -1,6 +1,6 @@
 # Hot Reloading (recarregamento rapido)
 
-O Vuex suporta hot reloading de mutações, módulos, ações e getters durante o desenvolvimento, usando o pacote do webpack [Hot Module Replacement API](https://webpack.js.org/guides/hot-module-replacement/). Você também pode usá-lo em Browserify com o plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
+O Vuex suporta hot reloading de mutações, módulos, ações e _getters_ durante o desenvolvimento, usando o pacote do webpack [Hot Module Replacement API](https://webpack.js.org/guides/hot-module-replacement/). Você também pode usá-lo em Browserify com o plugin [browserify-hmr](https://github.com/AgentME/browserify-hmr/).
 
 Para mutações e módulos, você precisa usar o método da API `store.hotUpdate()`:
 

docs/pt-br/intro.md

@@ -1,7 +1,6 @@
 # O que é Vuex?
 
-O Vuex é um ** padrão de gerenciamento de estado + biblioteca ** para aplicativos Vue.js. Ele serve como uma loja centralizada para todos os componentes em uma aplicação, com regras garantindo que o estado só possa ser mutado de forma previsível.
-Ele também se integra com a versão [devtools extension](https://github.com/vuejs/vue-devtools) do Vue para fornecer recursos avançados, como depuração de tempo-viagem de zero-config e exportação / importação de instantâneo de estado.
+O Vuex é um **padrão de gerenciamento de estado + biblioteca** para aplicativos Vue.js. Ele serve como um _store_ centralizado para todos os componentes em uma aplicação, com regras garantindo que o estado só possa ser mutado de forma previsível. Ele também se integra com a extensão oficial [Vue devtools](https://github.com/vuejs/vue-devtools) para fornecer recursos avançados sem configurações adicionais, como depuração viajando pelo histórico de estado (_time travel_) e exportação/importação de registros de estado em determinado momento.
 
 ### O que é um "Padrão de Gerenciamento do Estado"?
 
@@ -30,23 +29,23 @@ new Vue({
 
 É um aplicativo autônomo com as seguintes partes:
 
-- O ** state **, que é a fonte da verdade que impulsiona nosso aplicativo;
-- A ** view **, que é apenas um mapeamento declarativo do ** estado **;
-- As ** actions **, que são as possíveis maneiras pelas quais o estado pode mudar em reação às entradas de usuários da ** view **.
+- O **estado** (_state_), que é a fonte da verdade que impulsiona nosso aplicativo;
+- A **_view_**, que é apenas um mapeamento declarativo do **estado**;
+- As **ações** (_actions_), que são as possíveis maneiras pelas quais o estado pode mudar em reação às entradas de usuários da **_view_**.
 
 Esta é uma representação extremamente simples do conceito de "fluxo de dados unidirecional":
 <p style="text-align: center; margin: 2em">
   <img style="width:100%;max-width:450px;" src="./images/flow.png">
 </p>
 
-No entanto, a simplicidade rapidamente se quebra quando temos ** múltiplos componentes que compartilham o estado comum **:
+No entanto, a simplicidade rapidamente se quebra quando temos **múltiplos componentes que compartilham o estado comum**:
 
 - Várias visualizações podem depender da mesma parte do estado.
 
-- As ações de diferentes views podem precisar mutar a mesma parte de estado
+- As ações de diferentes _views_ podem precisar mutar a mesma parte de estado
 Para o problema um, passar propriedades pode ser tediosos para componentes profundamente aninhados e simplesmente não funcionam para componentes irmãos. Para o problema dois, muitas vezes nos encontramos recorrendo a soluções como a busca de referências diretas de instâncias pai / filho ou tentando mutar e sincronizar múltiplas cópias do estado através de eventos. Ambos esses padrões são frágeis e rapidamente levam a um código não sustentável.
 
-Então, por que não extraímos o estado compartilhado dos componentes e gerenciamos isso em um singleton global? Com isso, nossa árvore de componentes se torna uma grande "view", e qualquer componente pode acessar o estado ou ações de trigger, não importa onde eles estão na árvore!
+Então, por que não extraímos o estado compartilhado dos componentes e gerenciamos isso em um singleton global? Com isso, nossa árvore de componentes se torna uma grande _view_, e qualquer componente pode acessar o estado ou ações de trigger, não importa onde eles estão na árvore!
 
 Além disso, definindo e separando os conceitos envolvidos na gestão do estado e aplicando certas regras, também damos ao nosso código mais estrutura e capacidade de manutenção.
 
@@ -55,12 +54,10 @@ Esta é a idéia básica por trás do Vuex, inspirada por
 
 ![vuex](./images/vuex.png)
 
-### Quando devo usar-lo?
+### Quando devo usá-lo?
 
 Embora o Vuex nos ajude a lidar com gerenciamento de estado compartilhado, ele também vem com o custo de mais conceitos e relatórios. É um trade-off entre produtividade a curto prazo e longo prazo.
 
-Se você nunca construiu um SPA de grande escala e pulando direito para o Vuex, pode parecer detalhista e assustador. Isso é perfeitamente normal - se o seu aplicativo for simples, você provavelmente estará bem sem o Vuex. Um simples [global event bus](https://br.vuejs.org/v2/guide/components.html#Comunicacao-Nao-Pai-Filho) pode ser tudo o que você precisa. Mas se você estiver construindo um SPA de médio a grande escala, é provável que você tenha encontrado situações que o façam pensar sobre como lidar melhor com o estado fora dos componentes do Vue e o Vuex será o próximo passo natural para você. Há uma boa citação de Dan Abramov, o autor da Redux:
+Se você nunca construiu um SPA de grande escala e pulando direito para o Vuex, pode parecer detalhista e assustador. Isso é perfeitamente normal - se o seu aplicativo for simples, você provavelmente estará bem sem o Vuex. Um simples [global event bus](https://br.vuejs.org/v2/guide/components.html#Comunicacao-Nao-Pai-Filho) pode ser tudo o que você precisa. Mas se você estiver construindo um SPA de médio a grande escala, é provável que você tenha encontrado situações que o façam pensar sobre como lidar melhor com o estado fora dos componentes do Vue e o Vuex será o próximo passo natural para você. Há uma boa citação de Dan Abramov, o autor do Redux:
 
 > As bibliotecas Flux são como óculos: você saberá quando você precisar deles.
-
-

docs/pt-br/modules.md

@@ -1,7 +1,8 @@
 # Módulos
 
-Devido ao uso de uma árvore de um único estado, todo o estado do nosso aplicativo está contido dentro de um objeto grande. No entanto, à medida que nossa aplicação cresce em escala, a _store_  pode ficar realmente inchada.
-Para ajudar com isso, o Vuex nos permite dividir nossa _store_  em ** módulos **. Cada módulo pode conter seu próprio estado, mutações, ações, getters e até mesmo módulos aninhados – tudo é "quebrado" daqui pra frente:
+Devido ao uso de uma árvore de um único estado, todo o estado do nosso aplicativo está contido dentro de um objeto grande. No entanto, à medida que nossa aplicação cresce em escala, o _store_ pode ficar realmente inchado.
+Para ajudar com isso, o Vuex nos permite dividir nosso _store_ em **módulos**. Cada módulo pode conter seu próprio estado, mutações, ações, _getters_ e até mesmo módulos aninhados – tudo é "quebrado" daqui pra frente:
+
 ``` js
 const moduleA = {
   state: { ... },
@@ -27,9 +28,9 @@ store.state.a // -> `moduleA`'s state
 store.state.b // -> `moduleB`'s state
 ```
 
-### Estado do local do modulo
+### Estado Local do Módulo
 
-Dentro das mutações e getters de um módulo, o 1º argumento recebido será ** o estado local do módulo **.
+Dentro das mutações e _getters_ de um módulo, o 1º argumento recebido será **o estado local do módulo**.
 
  ``` js
 const moduleA = {
@@ -49,7 +50,7 @@ const moduleA = {
 }
 ```
 
-Da mesma forma, dentro das ações do módulo, `context.state` irá expor o estado local e o estado da raiz será exposto como` context.rootState`:
+Da mesma forma, dentro das ações do módulo ( _actions_ ), `context.state` irá expor o estado local e o estado raiz será exposto como `context.rootState`:
 
 ``` js
 const moduleA = {
@@ -64,7 +65,7 @@ const moduleA = {
 }
 ```
 
-Além disso, dentro do módulo getters, o estado da raiz será exibido como seu 3º argumento:
+Além disso, dentro do módulo _getters_, o estado raiz será exibido como seu 3º argumento:
 
 ``` js
 const moduleA = {
@@ -79,8 +80,8 @@ const moduleA = {
 
 ### Namespacing
 
-Por padrão, ações, mutações e getters dentro de módulos ainda estão registradas no ** namespace global ** - isso permite que vários módulos reajam com o mesmo tipo de mutação / ação.
-Se você deseja que seus módulos sejam mais autônomos ou reutilizáveis, você pode marcá-lo como namespaced com `namespaced: true`. Quando o módulo é registrado, todos os seus getters, ações e mutações serão automaticamente escritos com nomes com base no caminho no qual o módulo está registrado. Por exemplo:
+Por padrão, ações, mutações e _getters_ dentro de módulos ainda estão registradas no **namespace global** - isso permite que vários módulos reajam com o mesmo tipo de mutação / ação.
+Se você deseja que seus módulos sejam mais autônomos ou reutilizáveis, você pode marcá-lo como namespaced com `namespaced: true`. Quando o módulo é registrado, todos os seus _getters_, ações e mutações serão automaticamente escritos com nomes com base no caminho no qual o módulo está registrado. Por exemplo:
 
 ``` js
 const store = new Vuex.Store({
@@ -125,13 +126,14 @@ const store = new Vuex.Store({
 })
 ```
 
-Os getters e as ações Namespaced receberão `getters`,` dispatch` e `commit` localizados. Em outras palavras, você pode usar os recursos do módulo sem prefixo de escrita no mesmo módulo. Alternar entre namespaced ou não não afeta o código dentro do módulo.
+Os _getters_ e as ações _Namespaced_ receberão _getters_, _dispatch_ e _commit_ localizados. Em outras palavras, você pode usar os recursos do módulo sem prefixo de escrita no mesmo módulo. Alternar entre _namespaced_ ou não, não afeta o código dentro do módulo.
+
+#### Acessando Assets Globais em Módulos Namespaced
 
-#### Acessando ativos globais em módulos de Namespaced
+Se você quiser usar estado global e _getters_, _rootState_ e _rootGetters_ são passados como o 3º e 4º argumentos para funções _getter_, e também expostos como propriedades no objeto _context_ passado para funções de ação.
 
-Se você quiser usar estado global e getters, `rootState` e` rootGetters` são passados como o 3º e 4º argumentos para funções getter, e também expostos como propriedades no objeto `context` passado para funções de ação.
+Para enviar ações ou fazer um _commit_ de mutações no _namespace_ global, passe `{root: true}` como o 3º argumento para _dispatch_ e _commit_.
 
-Para enviar ações ou fazer um commit de mutações no namespace global, passe `{root: true}` como o 3º argumento para `dispatch 'e' commit '.
  ``` js
 modules: {
   foo: {
@@ -167,9 +169,9 @@ modules: {
 }
 ```
 
-#### Ligando Auxiliares com namespace
+#### Usando Métodos Auxiliares com Namespace
 
-Ao vincular um módulo com namespace aos componentes com os auxiliares `mapState`,` mapGetters`, `mapActions` e` mapMutations`, ele pode ficar um pouco verboso:
+Ao vincular um módulo com namespace aos componentes com os auxiliares `mapState`, `mapGetters`, `mapActions` e `mapMutations`, ele pode ficar um pouco verboso:
 ``` js
 computed: {
   ...mapState({
@@ -185,7 +187,7 @@ methods: {
 }
 ```
 
-Nesses casos, você pode passar a string de namespace do módulo como o 1º argumento para os auxiliares para que todas as ligações sejam feitas usando esse módulo como contexto. O anterior pode ser simplificado para:
+Nesses casos, você pode passar a String de _namespace_ do módulo como o 1º argumento para os auxiliares para que todas as ligações sejam feitas usando esse módulo como contexto. O anterior pode ser simplificado para:
 
 
 ``` js
@@ -203,7 +205,7 @@ methods: {
 }
 ```
 
-Além disso, você pode criar helpers com nomes usando o `createNamespacedHelpers`. Ele retorna um objeto com novos auxiliares de ligação de componentes que estão vinculados com o valor de namespace fornecido:
+Além disso, você pode criar _helpers_ com nomes usando o `createNamespacedHelpers`. Ele retorna um objeto com novos auxiliares de ligação de componentes que estão vinculados com o valor de namespace fornecido:
 
 ``` js
 import { createNamespacedHelpers } from 'vuex'
@@ -229,7 +231,7 @@ export default {
 ```
 
 #### Advertência para desenvolvedores de plugin
-Você pode se preocupar com o namespacing imprevisível para seus módulos quando você cria um [plugin](plugins.md) que fornece os módulos e permite que os usuários os adicionem a uma _store_  Vuex. Seus módulos serão também escritos por namespacing se os usuários do plugin adicionarem seus módulos em um módulo namespace. Para adaptar esta situação, talvez seja necessário receber um valor de namespace através da opção do plugin:
+Você pode se preocupar com o namespacing imprevisível para seus módulos quando você cria um [plugin](plugins.md) que fornece os módulos e permite que os usuários os adicionem a um _store_ Vuex. Seus módulos serão também escritos por namespacing se os usuários do plugin adicionarem seus módulos em um módulo namespace. Para adaptar esta situação, talvez seja necessário receber um valor de namespace através da opção do plugin:
 
 ``` js
 // pega o valor do namespace via opção de plugin
@@ -243,32 +245,32 @@ export function createPlugin (options = {}) {
 }
 ```
 
-### Registro de módulo dinâmico
-Você pode registrar um módulo ** após ** a _store_  foi criada com o método `store.registerModule`:
+### Registro de Módulo Dinâmico
+Você pode registrar um módulo **após** o _store_ ser criado com o método `store.registerModule`:
 
 ``` js
-// register a module `myModule`
+// registrando um módulo `myModule`
 store.registerModule('myModule', {
   // ...
 })
 
-// register a nested module `nested/myModule`
+// registrando um módulo aninhado `nested/myModule`
 store.registerModule(['nested', 'myModule'], {
   // ...
 })
 ```
 
-O estado do módulo será exposto como `store.state.myModule` e` store.state.nested.myModule`.
-O registro de módulo dinâmico torna possível que outros plugins do Vue também alavancem o Vuex para gerenciamento de estado anexando um módulo à _store_  do aplicativo. Por exemplo, a biblioteca [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) integra vue-router com vuex, gerenciando o estado da rota do aplicativo em um módulo anexado dinamicamente.
+O estado do módulo será exposto como `store.state.myModule` e `store.state.nested.myModule`.
+O registro de módulo dinâmico torna possível que outros plugins do Vue também usem o Vuex para gerenciamento de estado anexando um módulo ao _store_ do aplicativo. Por exemplo, a biblioteca [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) integra vue-router com vuex, gerenciando o estado da rota do aplicativo em um módulo anexado dinamicamente.
 
-Você também pode remover um módulo registrado dinamicamente com `store.unregisterModule (moduleName)`. Observe que você não pode remover módulos estáticos (declarados na criação da _store_ ) com este método.
-Pode ser provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de um aplicativo Server Side Rendered. Você pode conseguir isso com a opção `preserveState`:` store.registerModule ('a', module, {preserveState: true}) `
+Você também pode remover um módulo registrado dinamicamente com `store.unregisterModule(moduleName)`. Observe que você não pode remover módulos estáticos (declarados na criação da _store_ ) com este método.
+Pode ser provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de um aplicativo _Server Side Rendered_. Você pode conseguir isso com a opção `preserveState`: `store.registerModule ('a', module, {preserveState: true}) `
 
 ### Reutilização do Módulo
 Às vezes, talvez precisemos criar várias instâncias de um módulo, por exemplo:
 
-- Criando várias _stores_  que usam o mesmo módulo (por exemplo, para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-statelet-singletons) quando a opção `runInNewContext` é `false` ou `'once'`);
-- Registre o mesmo módulo várias vezes na mesma _store_ .
+- Criando várias _stores_ que usam o mesmo módulo (por exemplo, para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-statelet-singletons) quando a opção `runInNewContext` é `false` ou `'once'`);
+- Registre o mesmo módulo várias vezes na mesma _store_.
 
 Se usarmos um objeto simples para declarar o estado do módulo, esse objeto de estado será compartilhado por referência e causará poluição do estado do armazenamento / módulo quando estiver mutado.
 Este é exatamente o mesmo problema com `data` dentro dos componentes do Vue. Portanto, a solução também é a mesma - use uma função para declarar o estado do módulo (suportado em 2.3.0+):
@@ -283,4 +285,3 @@ const MyReusableModule = {
   // mutações, ações, getters...
 }
 ```
-

docs/pt-br/mutations.md

@@ -1,6 +1,6 @@
 # Mutações
 
-A única maneira de mudar o estado em uma _store_  Vuex é fazendo _commit_  de uma mutação. As mutações Vuex são muito semelhantes aos eventos: cada mutação possui uma string ** tipo ** e um ** manipulador **. A função do manipulador é onde nós executamos modificações de estado reais e receberá o estado como o primeiro argumento:
+A única maneira de mudar o estado em um _store_ Vuex é fazendo _commit_ de uma mutação. As mutações Vuex são muito semelhantes aos eventos: cada mutação possui uma String **tipo** e um **manipulador**. A função do manipulador é onde nós executamos modificações de estado reais e receberá o estado como o 1º argumento:
 
 ``` js
 const store = new Vuex.Store({
@@ -22,9 +22,9 @@ Você não pode chamar diretamente um manipulador de mutação. Pense nisso mais
 store.commit('increment')
 ```
 
-### Commit com payload
+### _Commit_ com payload
 
-Você pode passar um argumento adicional para `store.commit`, que é chamado de ** payload ** para a mutação:
+Você pode passar um argumento adicional para `store.commit`, que é chamado de **payload** para a mutação:
 
 ``` js
 // ...
@@ -55,7 +55,7 @@ store.commit('increment', {
 })
 ```
 
-### Commit com Object-Style
+### _Commit_ com _Object-Style_
 
 Uma maneira alternativa de confirmar uma mutação é usando diretamente um objeto que possui uma propriedade `type`:
 ``` js
@@ -65,7 +65,7 @@ store.commit({
 })
 ```
 
-Ao fazer um _commit_  com object-style, todo o objeto será passado como payload para os manipuladores de mutação, de modo que o manipulador permaneça o mesmo:
+Ao fazer um _commit_ com object-style, todo o objeto será passado como payload para os manipuladores de mutação, de modo que o manipulador permaneça o mesmo:
 
 ``` js
 mutations: {
@@ -77,9 +77,9 @@ mutations: {
 
 ### Mutações seguem as regras de reatividade do Vue
 
-Uma vez que o estado de uma _store_  Vuex é reativo para o Vue, quando mutar o estado, os componentes Vue que observam o estado serão atualizados automaticamente. Isso também significa que as mutações Vuex estão sujeitas às mesmas ressalvas de reatividade quando se trabalha com apenas Vue:
+Uma vez que o estado de um _store_ Vuex é reativo para o Vue, quando mutar o estado, os componentes Vue que observam o estado serão atualizados automaticamente. Isso também significa que as mutações Vuex estão sujeitas às mesmas ressalvas de reatividade quando se trabalha com apenas Vue:
 
-1. Prefira inicializar o estado inicial da sua _store_  com todos os campos desejados antecipadamente.
+1. Prefira inicializar o estado inicial do seu _store_ com todos os campos desejados antecipadamente.
 
 2. Ao adicionar novas propriedades a um objeto, você deve:
 
@@ -123,7 +123,8 @@ Querer usar constantes é ,em grande parte, uma preferência - pode ser útil em
 
 ### Mutações devem ser síncronas
 
-Uma regra importante a lembrar é que ** as funções do manipulador de mutação devem ser síncronas **. Por quê? Considere o seguinte exemplo:
+Uma regra importante a lembrar é que **as funções do manipulador de mutação devem ser síncronas**. Por quê? Considere o seguinte exemplo:
+
 ``` js
 mutations: {
   someMutation (state) {
@@ -134,10 +135,10 @@ mutations: {
 }
 ```
 
-Agora imagine que estamos depurando o aplicativo e observamos os registros de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar "antes" e "depois" _snapshots_  do estado. No entanto, o retorno de chamada assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_  ainda não foi chamado quando a mutação foi comitada, e não existe nenhuma maneira para o devtool saber quando o _callback_  será chamado - qualquer mutação de estado realizada no retorno desse _callback_  é essencialmente não rastreável!
+Agora imagine que estamos depurando o aplicativo e observamos os registros de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar "antes" e "depois" _snapshots_ do estado. No entanto, o retorno de chamada assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_ ainda não foi chamado quando a mutação foi comitada, e não existe nenhuma maneira para o devtool saber quando o _callback_ será chamado - qualquer mutação de estado realizada no retorno desse _callback_ é essencialmente não rastreável!
 
-### Fazendo commit de Mutações em Componente
-Você pode fazer um commit de mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componente para chamadas` store.commit` (requer a injeção root `store`):
+### Fazendo _commit_ de Mutações em Componente
+Você pode fazer um _commit_ de mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componente para chamadas `store.commit` (requer injeção do _store_ na instância raiz):
 ``` js
 import { mapMutations } from 'vuex'
 
@@ -159,13 +160,12 @@ export default {
 
 ### Ações
 
-Assincronicidade combinada com a mutação do estado pode tornar o seu programa muito difícil de acontecer. Por exemplo, quando você chama dois métodos com retrocessos assíncronos que mutam o estado, como você sabe quando eles são chamados e qual callback foi chamado primeiro? É exatamente por isso que queremos separar os dois conceitos. No Vuex, as mutações ** são transações síncronas **:
+Assincronicidade combinada com a mutação do estado pode tornar o seu programa muito difícil de acontecer. Por exemplo, quando você chama dois métodos com retrocessos assíncronos que mutam o estado, como você sabe quando eles são chamados e qual callback foi chamado primeiro? É exatamente por isso que queremos separar os dois conceitos. No Vuex, as mutações **são transações síncronas**:
 
 ``` js
 store.commit('increment')
-// qualquer alteração de estado que a mutação "incrementar" possa causar
+// qualquer alteração de estado que a mutação "increment" possa causar
 // deve ser feita neste momento
 ```
 
 Para lidar com operações assíncronas, vamos apresentar as [Ações](actions.md).
-

docs/pt-br/plugins.md

@@ -1,11 +1,11 @@
-# Plugins
+# _Plugins_
 
-As _stores_ do Vuex aceitam a opção `plugins` que expõe hooks para cada mutação. Um plugin Vuex é simplesmente uma função que recebe uma store como seu único argumento:
+Os _stores_ do Vuex aceitam a opção _plugins_ que expõe _hooks_ para cada mutação. Um _plugin_ Vuex é simplesmente uma função que recebe um _store_ como seu único argumento:
 
 
 ``` js
 const myPlugin = store => {
-  // chamado quando a store é inicializada
+  // chamado quando o store é inicializado
   store.subscribe((mutation, state) => {
     // chamada após cada mutação
     // a mutação vem no formato `{ type, payload }`.
@@ -22,11 +22,11 @@ const store = new Vuex.Store({
 })
 ```
 
-### Fazendo Commit de Mutações dentro de Plugins
+### Fazendo _Commit_ de Mutações dentro de _Plugins_
 
-Plugins não tem permissão para mudar diretamente o estado - similar aos componentes, eles podem apenas disparar mudanças fazendo commit de mutações.
+_Plugins_ não tem permissão para mudar diretamente o estado - similar aos componentes, eles podem apenas disparar mudanças fazendo _commit_ de mutações.
 
-Ao fazer um commit de uma mutação, um plugin pode ser usado para sincronizar uma fonte de dados à _store_ . Por exemplo, para sincronizar uma fonte de dados websocket à _store_  (isso é só um exemplo inventado, na realidade a função `createPlugin` pode receber parâmetros adicionais para tarefas mais complexas):
+Ao fazer um _commit_ de uma mutação, um _plugin_ pode ser usado para sincronizar uma fonte de dados ao _store_. Por exemplo, para sincronizar uma fonte de dados _websocket_ ao _store_ (isso é só um exemplo inventado, na realidade a função _createPlugin_ pode receber parâmetros adicionais para tarefas mais complexas):
 
 
 ``` js
@@ -54,9 +54,9 @@ const store = new Vuex.Store({
 })
 ```
 
-### Gravando Snapshots do Estado
+### Gravando _Snapshots_ do Estado
 
-Às vezes, um plugin pode querer receber "snapshots" do estado, e comparar o estado pós-mutação com o pré-mutação. Para conseguir isso, você precisa fzer uma cópia profunda do objeto de estado:
+Às vezes, um _plugin_ pode querer receber _snapshots_ do estado, e comparar o estado pós-mutação com o pré-mutação. Para conseguir isso, você precisa fzer uma cópia profunda do objeto de estado:
 
 
 ``` js
@@ -73,7 +73,7 @@ const myPluginWithSnapshot = store => {
 }
 ```
 
-**Plugins que tiram snapshots do estado devem ser usados apenas durante o desenvolvimento.** Quando usamos webpack ou Browserify, podemos construir nossas próprias ferramentas que lidam com isso para nós:
+**_Plugins_ que tiram _snapshots_ do estado devem ser usados apenas durante o desenvolvimento.** Quando usamos _webpack_ ou _Browserify_, podemos construir nossas próprias ferramentas que lidam com isso para nós:
 
 ``` js
 const store = new Vuex.Store({
@@ -84,13 +84,13 @@ const store = new Vuex.Store({
 })
 ```
 
-O plugin vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) para webpack ou [envify](https://github.com/hughsk/envify) para Browserify para converter o valor de  `process.env.NODE_ENV !== 'production'` para `false` na build final.
+O _plugin_ vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.github.io/docs/list-of-plugins.html#defineplugin) para webpack ou [envify](https://github.com/hughsk/envify) para Browserify para converter o valor de  `process.env.NODE_ENV !== 'production'` para `false` na build final.
 
-### Plugin de Log Embutido
+### _Plugin_ de _Log_ Embutido
 
 > Se você está usando [vue-devtools](https://github.com/vuejs/vue-devtools) provavelmente não precisará disso.
 
-Vuex vem com um plugin de log para casos comuns de debug:
+Vuex vem com um _plugin_ de _log_ para casos comuns de depuração:
 
 
 ``` js
@@ -101,7 +101,7 @@ const store = new Vuex.Store({
 })
 ```
 
-A função `createLogger` recebe alguns argumentos:
+A função _createLogger_ recebe alguns argumentos:
 
 ``` js
 const logger = createLogger({
@@ -125,6 +125,6 @@ const logger = createLogger({
 })
 ```
 
-O arquivo de log também pode ser incluído diretamente via tag `<script>` e vai expor a função `createVuexLogger` globalmente.
+O arquivo de _log_ também pode ser incluído diretamente via _tag_ `<script>` e vai expor a função `createVuexLogger` globalmente.
 
-Perceba que esses plugins tiram snapshots do estado, então use-os apenas durante o desenvolvimento.
+Perceba que esses _plugins_ tiram _snapshots_ do estado, então use-os apenas durante o desenvolvimento.

docs/pt-br/state.md

@@ -2,12 +2,12 @@
 
 ### Árvore simples de estado
 
-O Vuex usa uma ** árvore de estado único ** - isto é, este único objeto contém todo o seu nível de aplicativo e serve como "fonte única de verdade". Isso também significa que você terá apenas uma loja para cada aplicativo. Uma única árvore de estados torna direto localizar um pedaço de estado específico e nos permite facilmente tirar instantâneos do estado do aplicativo atual para fins de depuração.
+O Vuex usa uma **árvore de estado único** - isto é, este único objeto contém todo o seu nível de aplicativo e serve como _single source of truth_ (fonte única da verdade). Isso também significa que você terá apenas um _store_ para cada aplicativo. Uma única árvore de estado torna simples localizar um pedaço específico do estado, e nos permite facilmente tirar _snapshots_ do estado do aplicativo atual para fins de depuração.
 
 A árvore de um único estado não entra em conflito com a modularidade - em capítulos posteriores, discutiremos como dividir seu estado e mutações em sub-módulos.
 ### Obtendo o Vuex State em Vue Components
 
-Então, como exibimos o estado dentro da loja em nossos componentes do Vue? Uma vez que as lojas Vuex são reativas, a maneira mais simples de "recuperar" o estado é simplesmente retornar algum estado da loja dentro de um [dado computado](https://br.vuejs.org/v2/guide/computed.html):
+Então, como exibimos o estado dentro do _store_ em nossos componentes do Vue? Uma vez que os _stores_ Vuex são reativos, a maneira mais simples de "recuperar" o estado é simplesmente retornar algum estado do _store_ dentro de um [dado computado](https://br.vuejs.org/v2/guide/computed.html):
 
 ``` js
 // vamos criar um componente de contador
@@ -21,15 +21,16 @@ const Counter = {
 }
 ```
 
-Sempre que o `store.state.count` muda, fará com que a propriedade computada seja reavaliada e ative as atualizações de DOM associadas.
-No entanto, esse padrão faz com que o componente dependa no singleton da loja global. Ao usar um sistema de módulo, ele precisa importar a loja em todos os componentes que usam o estado da loja e também requer mocking ao testar o componente.
+Sempre que o `store.state.count` muda, fará com que o dado computado seja reavaliado e ative as atualizações de DOM associadas.
+No entanto, esse padrão faz com que o componente dependa no singleton do _store_ global. Ao usar um sistema de módulo, ele precisa importar o _store_ em todos os componentes que usam o estado do _store_ e também requer _mocking_ ao testar o componente.
 
-O Vuex fornece um mecanismo para "injetar" a loja em todos os componentes filho do componente raiz com a opção `store` (habilitada por` Vue.use (Vuex) `):
+O Vuex fornece um mecanismo para "injetar" o _store_ em todos os componentes filho do componente raiz com a opção `store` (habilitada por `Vue.use(Vuex)`):
 ``` js
 const app = new Vue({
   el: '#app',
-  // forneça a loja usando a opção "store".
-  // isso irá injetar a instância da loja em todos os componentes filho.  store,
+  // forneça o store usando a opção "store".
+  // isso irá injetar a instância do _store_ em todos os componentes filho.
+  store,
   components: { Counter },
   template: `
     <div class="app">
@@ -39,7 +40,7 @@ const app = new Vue({
 })
 ```
 
-Ao fornecer a opção `store` para a instância raiz, a loja será injetada em todos os componentes filho da raiz e estará disponível neles como esta. $ Store`. Vamos atualizar a nossa implementação `Counter`:
+Ao fornecer a opção _store_ para a instância raiz, o _store_ será injetado em todos os componentes filho da raiz e estará disponível neles como `this.$store`. Vamos atualizar a nossa implementação _Counter_ :
 
 ``` js
 const Counter = {
@@ -54,18 +55,19 @@ const Counter = {
 
 ### O auxiliar `mapState`
 
-Quando um componente precisa fazer uso de várias propriedades de estado da loja ou getters, declarar que todas essas propriedades computadas podem ser repetitivas e verbosas. Para lidar com isso, podemos usar o ajudante `mapState` que gera funções getter computadas para nós, economizando algumas linhas de código:
+Quando um componente precisa fazer uso de várias propriedades do estado do _store_ ou _getters_, declarar todos esses dados computados pode ser repetitivo e verboso. Para lidar com isso, podemos usar o auxiliar `mapState` que gera funções _getter_ computadas para nós, economizando algumas linhas de código:
 
 ``` js
-// em pleno desenvolvimento, os ajudantes são expostos como Vuex.mapState
+// em pleno desenvolvimento, os auxiliares são expostos como Vuex.mapState
  import { mapState } from 'vuex'
 
 export default {
   // ...
   computed: mapState({
-    // As funções de seta podem tornar o código muito sucinto!    count: state => state.count,
+    // As arrow functions (ou funções de seta) podem tornar o código muito sucinto!
+    count: state => state.count,
 
-    // passar o valor da string 'count' é o mesmo que `state => state.count`
+    // passar o valor da String 'count' é o mesmo que `state => state.count`
     countAlias: 'count',
 
     // para acessar o estado local com `this`, uma função normal deve ser usada
@@ -76,7 +78,7 @@ export default {
 }
 ```
 
-Também podemos passar uma matriz de seqüência de caracteres para `mapState` quando o nome de uma propriedade calculada mapeada é o mesmo que um nome de árvore secundária de estado.
+Também podemos passar um _Array_ de _Strings_ para `mapState` quando o nome de um dado computado mapeado é o mesmo que um nome de árvore secundária do estado.
 
 ``` js
 computed: mapState([
@@ -87,13 +89,12 @@ computed: mapState([
 
 ### Operador de propagação de objetos (_ES2015_ _Spread_ _Operator_ )
 
-Observe que `mapState` retorna um objeto. Como usá-lo em combinação com outras propriedades locais computadas? Normalmente, teríamos que usar um utilitário para fundir vários objetos em um para que possamos passar o objeto final para `computado`. No entanto, com o [operador de propagação de objetos](https://github.com/sebmarkbage/ecmascript-rest-spread) (que é uma proposta de ECMAScript em estágio 3), podemos simplificar muito a sintaxe:
+Observe que `mapState` retorna um objeto. Como usá-lo em combinação com outras propriedades locais computadas? Normalmente, teríamos que usar um utilitário para fundir vários objetos em um para que possamos passar o objeto final para `computado`. No entanto, com o [Spread Operator](https://github.com/sebmarkbage/ecmascript-rest-spread) (que é uma proposta de ECMAScript em estágio 3), podemos simplificar muito a sintaxe:
 
 ``` js
 computed: {
   localComputed () { /* ... */ },
-  // Misture isso no objeto externo com o operador de propagação do objeto
-
+  // Misture isso no objeto externo com o Spread Operator
   ...mapState({
     // ...
   })
@@ -102,4 +103,4 @@ computed: {
 
 ### Componentes ainda podem ter um estado local
 
-O uso do Vuex não significa que você deve colocar ** all ** no estado no Vuex. Embora colocar mais estado no Vuex torna suas mutações estatais mais explícitas e devolvíveis, às vezes também pode tornar o código mais detalhado e indireto. Se um pedaço de estado pertence estritamente a um único componente, pode ser apenas bom deixá-lo como um estado local. Você deve pesar os trade-offs e tomar decisões que atendam às necessidades de desenvolvimento do seu aplicativo.
+O uso do Vuex não significa que você deve colocar **tudo** no estado do Vuex. Embora colocar mais estado no Vuex torna suas mutações estatais mais explícitas e depuráveis, às vezes também pode tornar o código mais verboso e indireto. Se um pedaço de estado pertence estritamente a um único componente, pode ser bom deixá-lo apenas como um estado local. Você deve pesar os trade-offs e tomar decisões que atendam às necessidades de desenvolvimento da sua aplicação.

docs/pt-br/strict.md

@@ -1,6 +1,6 @@
 # Modo estrito
 
-Para habilitar o modo estrito, simplesmente passe `strict: true` ao criar uma _store_  Vuex:
+Para habilitar o modo estrito, simplesmente passe `strict: true` ao criar um _store_ Vuex:
 
 ``` js
 const store = new Vuex.Store({
@@ -13,7 +13,7 @@ Em modo estrito, sempre que o estado do Vuex é mutado fora dos manipuladores de
 
 ### Desenvolvimento vs. Produção
 
-** Não habilite o modo estrito ao implantar para a produção! ** O modo estrito executa um observador profundo síncrono na árvore de estados para detectar mutações inapropriadas e pode ser bastante caro quando você faz grande quantidade de mutações no estado. Certifique-se de desligá-lo na produção para evitar o custo de desempenho.
+**Não habilite o modo estrito ao implantar para a produção!** O modo estrito executa um observador profundo síncrono na árvore de estados para detectar mutações inapropriadas e pode ser bastante caro quando você faz grande quantidade de mutações no estado. Certifique-se de desligá-lo na produção para evitar o custo de desempenho.
 
 Semelhante aos plugins, podemos deixar as ferramentas de compilação lidar com isso:
 
@@ -23,4 +23,3 @@ const store = new Vuex.Store({
   strict: process.env.NODE_ENV !== 'production'
 })
 ```
-

docs/pt-br/structure.md

@@ -2,12 +2,12 @@
 
 O Vuex não restringe realmente como você estrutura seu código. Em vez disso, ele impõe um conjunto de princípios de alto nível:
 
-1. O estado do nível de aplicativo é centralizado na _store_ .
+1. O estado do nível de aplicativo é centralizado no _store_.
 
-2. A única maneira de mudar o estado é fazendo commit das ** mutações **, que são transações síncronas.
+2. A única maneira de mudar o estado é fazendo commit das **mutações**, que são transações síncronas.
 
-3. A lógica assíncrona deve ser encapsulada e pode ser composta com ** ações **.
-Enquanto você seguir estas regras, depende de você como estruturar seu projeto. Se o arquivo da sua _store_  for muito grande, basta começar a dividir as ações, mutações e getters em arquivos separados.
+3. A lógica assíncrona deve ser encapsulada e pode ser composta com **ações**.
+Enquanto você seguir estas regras, depende de você como estruturar seu projeto. Se o arquivo do seu _store_ for muito grande, basta começar a dividir as ações, mutações e _getters_ em arquivos separados.
 
 Para qualquer aplicativo não trivial, provavelmente precisaremos alavancar módulos. Aqui está uma estrutura de projeto de exemplo:
 
@@ -28,4 +28,3 @@ Para qualquer aplicativo não trivial, provavelmente precisaremos alavancar mód
 ```
 
 Como referência, confira o [Exemplo do carrinho de compras](https://github.com/vuejs/vuex/tree/dev/examples/shopping-cart).
-

docs/pt-br/testing.md

@@ -1,8 +1,10 @@
 # Testando
 
 As partes principais que queremos testar em Vuex são mutações e ações.
+
 ### Testando Mutações
-As mutações são muito simples de testar, porque são apenas funções que dependem completamente de seus argumentos. Um truque é que se você estiver usando módulos ES2015 e colocar suas mutações dentro do arquivo `store.js`, além da exportação padrão, você também deve exportar as mutações como uma exportação nomeada:
+
+As mutações são muito simples de testar, porque são apenas funções que dependem completamente de seus argumentos. Um truque é que se você estiver usando módulos _ES2015_ e colocar suas mutações dentro do arquivo `store.js`, além da exportação padrão, você também deve exportar as mutações como uma exportação nomeada:
 
 ``` js
 const state = { ... }
@@ -47,7 +49,7 @@ describe('mutations', () => {
 
 ### Testando ações
 
-As ações podem ser um pouco mais complicadas porque podem chamar as APIs externas. Ao testar ações, geralmente precisamos fazer algum nível de _mocking_  - por exemplo, podemos resumir as chamadas da API em um serviço e simular esse serviço dentro de nossos testes. A fim de simular facilmente as dependências, podemos usar o webpack e [injetor-carregador](https://github.com/plasticine/inject-loader) para agrupar nossos arquivos de teste.
+As ações podem ser um pouco mais complicadas porque podem chamar as _APIs_ externas. Ao testar ações, geralmente precisamos fazer algum nível de _mocking_ - por exemplo, podemos resumir as chamadas da API em um serviço e simular esse serviço dentro de nossos testes. A fim de simular facilmente as dependências, podemos usar o webpack e [injetor-carregador](https://github.com/plasticine/inject-loader) para agrupar nossos arquivos de teste.
 
 Exemplo de teste de uma ação assíncrona:
 
@@ -82,7 +84,7 @@ const actions = actionsInjector({
   }
 })
 
-// ajudante para teste de ação com mutações esperadas
+// auxiliar para teste de ação com mutações esperadas
 const testAction = (action, payload, state, expectedMutations, done) => {
   let count = 0
 
@@ -105,7 +107,7 @@ const testAction = (action, payload, state, expectedMutations, done) => {
     }
   }
 
-  // chame a ação com uma loja e argumentos simulados
+  // chame a ação com store mockada e argumentos
    action({ commit, state }, payload)
 
   // verificar se nenhuma mutação deveria ter sido enviada
@@ -119,17 +121,17 @@ describe('actions', () => {
   it('getAllProducts', done => {
     testAction(actions.getAllProducts, null, {}, [
       { type: 'REQUEST_PRODUCTS' },
-      { type: 'RECEIVE_PRODUCTS', payload: { /* mocked response */ } }
+      { type: 'RECEIVE_PRODUCTS', payload: { /* retorno mockado */ } }
     ], done)
   })
 })
 ```
 
-### Testando Getters
+### Testando _Getters_
 
-Se seus getters tiverem uma computação complicada, vale a pena testá-los. Os Getters também são muito diretos para testar o mesmo motivo que as mutações.
+Se seus _getters_ tiverem uma computação complicada, vale a pena testá-los. Os _Getters_ também são muito simples de testar pelo mesmo motivo que as mutações.
 
-Exemplo testando um getter:
+Exemplo testando um _getter_ :
 ``` js
 // getters.js
 export const getters = {
@@ -173,11 +175,11 @@ describe('getters', () => {
 
 ### Execução de testes
 
-Se suas mutações e ações estiverem escritas corretamente, os testes não devem ter dependência direta das APIs do navegador após uma mudança apropriada. Assim, você pode simplesmente agrupar os testes com o webpack e executá-lo diretamente no Node. Alternativamente, você pode usar `mocha-loader` ou Karma +` karma-webpack` para executar os testes em navegadores reais.
+Se suas mutações e ações estiverem escritas corretamente, os testes não devem ter dependência direta das APIs do navegador após uma mudança apropriada. Assim, você pode simplesmente agrupar os testes com o webpack e executá-lo diretamente no Node. Alternativamente, você pode usar _mocha-loader_ ou _Karma_ + _karma-webpack_ para executar os testes em navegadores reais.
 
-#### Rodando no Node
+#### Rodando no _Node_
 
-Crie a seguinte configuração de webpack (juntamente com [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
+Crie a seguinte configuração de _webpack_ (juntamente com [`.babelrc`](https://babeljs.io/docs/usage/babelrc/)):
 
 ``` js
 // webpack.config.js
@@ -208,12 +210,11 @@ mocha test-bundle.js
 
 #### Rodando no Browser
 
-1. Instale `mocha-loader`.
-2. Mude a `entrada` da configuração do webpack acima para `'mocha-loader! Babel-loader! ./ test.js'`.
-3. Inicie `webpack-dev-server` usando a configuração.
-4. Vá para `localhost: 8080 / webpack-dev-server / test-bundle`.
+1. Instale _mocha-loader_.
+2. Mude a `entrada` da configuração do _webpack_ acima para `'mocha-loader! Babel-loader! ./ test.js'`.
+3. Inicie _webpack-dev-server_ usando a configuração.
+4. Vá para _localhost: 8080 / webpack-dev-server / test-bundle_.
 
-#### Rodando no Browser com Karma + karma-webpack
+#### Rodando no Browser com _Karma_ + _karma-webpack_
 
 Consulte a instalação na [documentação do vue-loader](https://vue-loader.vuejs.org/pt_BR/workflow/testing.html).
-