docs(ptbr): fix translations (#1885)

Co-authored-by: Erick Eduardo Petrucelli <erick.petrucelli@fatec.sp.gov.br>

docs/.vuepress/config.js

@@ -313,7 +313,7 @@ module.exports = {
           {
             text: 'v3.x',
             items: [
-              { text: 'v4.x', link: 'https://next.vuex.vuejs.org/' }
+              { text: 'v4.x', link: 'https://next.vuex.vuejs.org/ptbr/' }
             ]
           }
         ],

docs/ptbr/README.md

@@ -1,12 +1,16 @@
 # O que é Vuex?
 
+::: tip NOTE
+Esta documentação é para o Vuex 3, que funciona com Vue 2. Se você está procurando a documentação para o Vuex 4, que funciona com Vue 3, [por favor, confira aqui](https://next.vuex.vuejs.org/ptbr/).
+:::
+
 <VideoPreview />
 
-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 Vuex é um **padrão de gerenciamento de estado + biblioteca** para aplicações 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"?
 
-Vamos começar com um aplicativo simples de contador Vue:
+Vamos começar com uma aplicação simples de contador Vue:
 
 ``` js
 new Vue({
@@ -29,9 +33,9 @@ new Vue({
 })
 ```
 
-É um aplicativo independente com as seguintes partes:
+É uma aplicação independente com as seguintes partes:
 
-- O **estado** (_state_), que é a fonte da verdade que direciona nosso aplicativo;
+- O **estado** (_state_), que é a fonte da verdade que direciona nossa aplicação;
 - 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 interações dos usuários da **_view_**.
 
@@ -62,6 +66,6 @@ Se você quiser aprender Vuex de um modo interativo, você pode conferir esse cu
 
 Embora o Vuex nos ajude a lidar com o gerenciamento de estado compartilhado, ele também vem com o custo de mais conceitos e códigos repetitivos. É uma escolha de prós e contras entre produtividade de curto e longo prazo
 
-Se você nunca construiu um SPA em grande escala e for direto para o Vuex, ele pode parecer detalhado e desanimador. Isso é perfeitamente normal - se o seu aplicativo é simples, você provavelmente ficará bem sem o Vuex. Um simples [store pattern](https://br.vuejs.org/v2/guide/state-management.html#Gerenciamento-de-Estado-do-Zero) pode ser tudo que você precisa. Mas, se você está criando um SPA de médio a grande porte, é provável que tenha encontrado situações que fazem você pensar em como lidar melhor com o estado fora de seus 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:
+Se você nunca construiu um SPA em grande escala e for direto para o Vuex, ele pode parecer detalhado e desanimador. Isso é perfeitamente normal - se a sua aplicação é simples, você provavelmente ficará bem sem o Vuex. Um simples [store pattern](https://br.vuejs.org/v2/guide/state-management.html#Gerenciamento-de-Estado-do-Zero) pode ser tudo que você precisa. Mas, se você está criando um SPA de médio a grande porte, é provável que tenha encontrado situações que fazem você pensar em como lidar melhor com o estado fora de seus 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 precisar delas.

docs/ptbr/api/README.md

@@ -71,7 +71,7 @@ const store = new Vuex.Store({ ...options })
   rootGetters  // todos os getters
   ```
 
-  Os _getters_ registrados estão expostos em _store.getters_.
+  Os _getters_ registrados estão expostos em `store.getters`.
 
   [Detalhes](../guide/getters.md)
 
@@ -95,7 +95,7 @@ const store = new Vuex.Store({ ...options })
   }
   ```
 
-  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.
+  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](../guide/modules.md)
 
@@ -103,7 +103,7 @@ const store = new Vuex.Store({ ...options })
 
 - type: `Array<Function>`
 
-  Um _Array_ de funções de plug-in a serem aplicadas no _store_. O plug-in simplesmente recebe o _store_ como o único argumento e pode ouvir mutações (para persistência de dados de saída, registro ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou _observables_).
+  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, registro ou depuração) ou mutações de despacho (para dados de entrada, por exemplo, websockets ou _observables_).
 
   [Detalhes](../guide/plugins.md)
 
@@ -120,7 +120,7 @@ const store = new Vuex.Store({ ...options })
 
 - type: `boolean`
 
-  Ative ou desative as ferramentas de desenvolvedor para uma determinada instância vuex. Passar _false_ à instância diz ao _store_ Vuex para não se integrar ao _devtools_. Útil para quando se tem vários _stores_ em uma _single page_.
+  Ative ou desative as ferramentas de desenvolvedor para uma determinada instância vuex. Passar `false` à instância diz ao _store_ Vuex para não se integrar ao _devtools_. Útil para quando se tem vários _stores_ em uma _single_ _page_.
 
   ``` js
   {
@@ -149,14 +149,14 @@ const store = new Vuex.Store({ ...options })
 -  `commit(type: string, payload?: any, options?: Object)`
 -  `commit(mutation: Object, options?: Object)`
 
-  Confirma (ou faz um _Commit_ de) uma mutação. _options_ pode ter _root: true_ que permite confirmar mutações da raiz em [módulos namespaced](../guide/modules.md#namespacing). [Detalhes](../guide/mutations.md)
+  Confirma (ou faz um _Commit_ de) uma mutação. _options_ pode ter `root: true` que permite confirmar mutações da raiz em [módulos namespaced](../guide/modules.md#namespacing). [Detalhes](../guide/mutations.md)
 
 ### dispatch
 
 -  `dispatch(type: string, payload?: any, options?: Object): Promise<any>`
 -  `dispatch(action: Object, options?: Object): Promise<any>`
 
-  Despacha uma ação. _options_ pode ter _root: true_ que permite despachar ações para raiz em [módulos namespaced](../guide/modules.md#namespacing). Retorna um _Promise_ que resolve todos os manipuladores de ação acionados. [Detalhes](../guide/actions.md)
+  Despacha uma ação. _options_ pode ter `root: true` que permite despachar ações para raiz em [módulos namespaced](../guide/modules.md#namespacing). Retorna um _Promise_ que resolve todos os manipuladores de ação acionados. [Detalhes](../guide/actions.md)
 
 ### replaceState
 
@@ -229,7 +229,7 @@ const store = new Vuex.Store({ ...options })
 
   Registra um módulo dinâmico. [Detalhes](../guide/modules.md#registro-de-modulo-dinamico)
 
-  _options_ can have _preserveState: true_ que permite preservar o estado anterior. Útil com renderização do lado do servidor (_server-side-rendering_).
+  _options_ can have `preserveState: true` que permite preservar o estado anterior. Útil com renderização do lado do servidor (_server-side-rendering_).
 
 ### unregisterModule
 
@@ -287,4 +287,4 @@ const store = new Vuex.Store({ ...options })
 
 -  `createNamespacedHelpers(namespace: string): Object`
 
-  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](../guide/modules.md#usando-metodos-auxiliares-com-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](../guide/modules.md#usando-metodos-auxiliares-com-namespace)

docs/ptbr/guide/README.md

@@ -31,7 +31,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')
@@ -39,10 +39,10 @@ store.commit('increment')
 console.log(store.state.count) // -> 1
 ```
 
-Novamente, a razão pela qual estamos confirmando (ou 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, capturar momentos do estado ou mesmo realizar depuração viajando pelo histórico de estado (_time travel_).
+Novamente, a razão pela qual estamos confirmando (ou 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 sua aplicação ao ler o código. Além disso, isso nos dá a oportunidade de implementar ferramentas que podem registrar cada mutação, capturar momentos do 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. Acionar alterações simplesmente significa confirmar (ou 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/).
+Aqui está um exemplo da [aplicação 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/ptbr/guide/actions.md

@@ -27,7 +27,7 @@ const store = new Vuex.Store({
 })
 ```
 
-Os manipuladores de ação recebem um objeto _context_ 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 _context.getters_. Veremos por que esse objeto _context_ não é a própria instância do _store_ quando apresentarmos [Módulos](modules.md) mais tarde.
+Os manipuladores de ação recebem um objeto _context_ 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 `context.getters`. Veremos por que esse objeto _context_ não é a própria instância do _store_ quando apresentarmos [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 usar _commit_ várias vezes):
 
@@ -41,7 +41,7 @@ actions: {
 
 ### Ações de Despacho
 
-As ações são acionadas com o método _store.dispatch_:
+As ações são acionadas com o método `store.dispatch`:
 
 ``` js
 store.dispatch('increment')
@@ -100,7 +100,7 @@ Observe que estamos realizando um fluxo de operações assíncronas, e gravando
 
 ### 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 do componente para chamadas do _store.dispatch_ (esta ação requer injeção do _store_ na instância raiz):
+Você pode despachar ações em componentes com `this.$store.dispatch('xxx')`, ou usar o auxiliar _mapActions_ que mapeia métodos do componente para chamadas do `store.dispatch` (esta ação requer injeção do _store_ na instância raiz):
 
 ``` js
 import { mapActions } from 'vuex'
@@ -125,7 +125,7 @@ export default {
 
 As ações geralmente são assíncronas, então como sabemos quando uma ação é realizada? E mais importante, como podemos compor ações múltiplas em conjunto para lidar com fluxos assíncronos mais complexos?
 
-A primeira coisa a saber é que o _store.dispatch_ pode manipular o _Promise_ retornado pelo manipulador de ação acionado e também retorna _Promise_:
+A primeira coisa a saber é que o `store.dispatch` pode manipular o _Promise_ retornado pelo manipulador de ação acionado e também retorna _Promise_:
 
 ``` js
 actions: {
@@ -177,4 +177,4 @@ actions: {
 }
 ```
 
-> É possível para um _store.dispatch_ desencadear vários manipuladores de ação em diferentes módulos. Neste caso, o valor retornado será um _Promise_ que resolve quando todos os manipuladores desencadeados foram resolvidos.
+> É possível para um `store.dispatch` desencadear vários manipuladores de ação em diferentes módulos. Neste caso, o valor retornado será um _Promise_ que resolve quando todos os manipuladores desencadeados foram resolvidos.

docs/ptbr/guide/getters.md

@@ -36,13 +36,13 @@ const store = new Vuex.Store({
 
 ### Acesso Estilo-Propriedade
 
-Os _getters_ serão expostos no objeto _store.getters_ e você acessa valores como propriedades:
+Os _getters_ serão expostos no objeto `store.getters` e você acessa valores como propriedades:
 
 ``` js
 store.getters.doneTodos // -> [{ id: 1, text: '...', done: true }]
 ```
 
-Os _getters_ também receberão outros _getters_ como o 2º argumento:
+Os _getters_ também receberão outros `getters` como o 2º argumento:
 
 ``` js
 getters: {

docs/ptbr/guide/modules.md

@@ -2,7 +2,7 @@
 
 <div class="scrimba"><a href="https://scrimba.com/p/pnyzgAP/cqKK4psq" target="_blank" rel="noopener noreferrer">Tente esta lição no Scrimba</a></div>
 
-Devido ao uso de uma única árvore de estado, todo o estado de nossa aplicação está contido dentro de um grande objeto. No entanto, à medida que nosso aplicativo cresce em escala, o _store_ pode ficar realmente inchado.
+Devido ao uso de uma única árvore de estado, todo o estado de nossa aplicação está contido dentro de um grande objeto. 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é módulos aninhados - é todo o complexo caminho abaixo:
 
@@ -55,7 +55,7 @@ const moduleA = {
 }
 ```
 
-Da mesma forma, dentro das ações do módulo, _context.state_ irá expor o estado local, e o estado raiz será exposto como _context.rootState_:
+Da mesma forma, dentro das ações do módulo, `context.state` irá expor o estado local, e o estado raiz será exposto como `context.rootState`:
 
 ``` js
 const moduleA = {
@@ -87,7 +87,7 @@ const moduleA = {
 
 Por padrão, ações, mutações e _getters_ dentro dos módulos ainda são registrados sob o **_namespace_ global** - isso permite que vários módulos reajam ao mesmo tipo de ação/mutação.
 
-Se você quer que seus módulos sejam mais independentes ou reutilizáveis, você pode marcá-los como _namespaced_ com _namespaced: true_. Quando o módulo é registrado, todos os _getters_, ações e mutações serão automaticamente _namespaced_ com base no caminho no qual o módulo está registrado. Por exemplo:
+Se você quer que seus módulos sejam mais independentes ou reutilizáveis, você pode marcá-los como _namespaced_ com `namespaced: true`. Quando o módulo é registrado, todos os _getters_, ações e mutações serão automaticamente _namespaced_ com base no caminho no qual o módulo está registrado. Por exemplo:
 
 ``` js
 const store = new Vuex.Store({
@@ -136,7 +136,7 @@ Os _getters_ e as ações _namespaced_ receberão _getters_, _dispatch_ e _commi
 
 #### Acessando Recursos Globais em Módulos 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 despachar ações confirmar (ou fazer um _commit_ de) mutações no _namespace_ global, passe `{root: true}` como o 3º argumento para _dispatch_ e _commit_.
 
@@ -176,7 +176,7 @@ modules: {
 
 #### Registrar Ação Global em Módulos com Namespaces
 
-Se você quiser registrar ações globais em módulos com namespaces, você pode marcá-lo com _root: true_ e colocar a definição de ação na função _handler_. Por exemplo:
+Se você quiser registrar ações globais em módulos com namespaces, você pode marcá-lo com `root: true` e colocar a definição de ação na função _handler_. Por exemplo:
 
 ``` js
 {
@@ -202,7 +202,7 @@ Se você quiser registrar ações globais em módulos com namespaces, você pode
 
 #### 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: {
@@ -280,7 +280,7 @@ export function createPlugin (options = {}) {
 
 ### Registro de Módulo Dinâmico
 
-Você pode registrar um módulo **após** o _store_ ser criado com o método _store.registerModule_:
+Você pode registrar um módulo **após** o _store_ ser criado com o método `store.registerModule`:
 
 ``` js
 // registra um módulo `myModule`
@@ -294,15 +294,15 @@ store.registerModule(['nested', 'myModule'], {
 })
 ```
 
-Os estados do módulo serão expostos como _store.state.myModule_ e _store.state.nested.myModule_.
+Os estados do módulo serão expostos como `store.state.myModule` e `store.state.nested.myModule`.
 
-O registro de módulo dinâmico possibilita que outros plug-ins Vue aproveitem também 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 o vue-router com o vuex gerenciando o estado da rota do aplicativo em um módulo conectado dinamicamente.
+O registro de módulo dinâmico possibilita que outros _plugins_ Vue aproveitem também o Vuex para gerenciamento de estado, anexando um módulo ao _store_ da aplicação. Por exemplo, a biblioteca [`vuex-router-sync`](https://github.com/vuejs/vuex-router-sync) integra o vue-router com o vuex gerenciando o estado da rota da aplicação em um módulo conectado dinamicamente.
 
 Você também pode remover um módulo dinamicamente registrado com o `store.unregisterModule(moduleName)`. Note que você não pode remover módulos estáticos (declarados na criação do _store_) com este método.
 
 #### Preservando o estado
 
-É bem provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de um aplicativo Renderizado no Lado do Servidor (_Server_ _Side_ _Rendered_). Você pode fazer isso com a opção `preserveState`:`store.registerModule('a', module, {preserveState: true})`
+É bem provável que você queira preservar o estado anterior ao registrar um novo módulo, como preservar o estado de uma aplicação Renderizada no Lado do Servidor (_Server_ _Side_ _Rendered_). Você pode fazer isso com a opção `preserveState`:`store.registerModule('a', module, {preserveState: true})`
 
 Quando você informa `preserveState: true`, o módulo é registrado, as ações, mutações e _getters_ são incluídos no _store_, mas o estado não. É assumido que estado da sua _store_ já contém um estado para aquele módulo e você não quer sobrescrevê-lo.
 
@@ -310,7 +310,7 @@ Quando você informa `preserveState: true`, o módulo é registrado, as ações,
 
 Às vezes, podemos precisar criar várias instâncias de um módulo, por exemplo:
 
-- Criando multiplos _stores_ que usam o mesmo módulo (e.g. Para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-stateful-singletons) quando a opção _runInNewContext_ é _false_ ou `'_once_'`);
+- Criando multiplos _stores_ que usam o mesmo módulo (e.g. Para [evitar Singletons com informações de estado no SSR](https://ssr.vuejs.org/en/structure.html#avoid-stateful-singletons) quando a opção `runInNewContext` é `false` ou `'_once_'`);
 - Registrar o mesmo módulo várias vezes no mesmo _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 entre estados de _store_/módulo quando ele sofrer uma mutação.

docs/ptbr/guide/mutations.md

@@ -18,7 +18,7 @@ const store = new Vuex.Store({
 })
 ```
 
-Você não pode chamar diretamente um manipulador de mutação. Pense nisso mais como registro de evento: "Quando uma mutação com o tipo _increment_ é acionada, chame este manipulador." Para invocar um manipulador de mutação, você precisa chamar _store.commit_ com seu tipo:
+Você não pode chamar diretamente um manipulador de mutação. Pense nisso mais como registro de evento: "Quando uma mutação com o tipo _increment_ é acionada, chame este manipulador." Para invocar um manipulador de mutação, você precisa chamar `store.commit` com seu tipo:
 
 ``` js
 store.commit('increment')
@@ -26,7 +26,7 @@ store.commit('increment')
 
 ### Commit com Payload
 
-Você pode passar um argumento adicional para o _store.commit_, que é chamado de **_payload_** para a mutação:
+Você pode passar um argumento adicional para o `store.commit`, que é chamado de **_payload_** para a mutação:
 
 ``` js
 // ...
@@ -96,7 +96,7 @@ Como o estado de um _store_ Vuex é reativado pelo Vue, quando alteramos o estad
 
 ### Usando Constantes para Tipos de Mutação
 
-É um padrão comumente visto usar constantes para tipos de mutação em várias implementações do _Flux_. Isso permite que o código aproveite as ferramentas como os _linters_, e colocar todas as constantes em um único arquivo permite que seus colaboradores tenham uma visão geral das mutações possíveis em todo o aplicativo:
+É um padrão comumente visto usar constantes para tipos de mutação em várias implementações do _Flux_. Isso permite que o código aproveite as ferramentas como os _linters_, e colocar todas as constantes em um único arquivo permite que seus colaboradores tenham uma visão geral das mutações possíveis em toda a aplicação:
 
 ``` js
 // mutation-types.js
@@ -136,11 +136,11 @@ mutations: {
 }
 ```
 
-Agora imagine que estamos depurando o aplicativo e observando os logs de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar os momentos "antes" e "depois" do estado. No entanto, o _callback_ assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_ ainda não é chamado quando a mutação é confirmada (ou o _commit_ da mutação é feito) e não há como o devtool saber quando o _callback_ será realmente chamado - qualquer mutação de estado executada no _callback_ é essencialmente impossível de rastrear!
+Agora imagine que estamos depurando a aplicação e observando os logs de mutação do devtool. Para cada mutação registrada, o devtool precisará capturar os momentos "antes" e "depois" do estado. No entanto, o _callback_ assíncrono dentro da mutação de exemplo acima torna isso impossível: o _callback_ ainda não é chamado quando a mutação é confirmada (ou o _commit_ da mutação é feito) e não há como o devtool saber quando o _callback_ será realmente chamado - qualquer mutação de estado executada no _callback_ é essencialmente impossível de rastrear!
 
 ### Confirmando (ou fazendo Commits de) Mutações em Componentes
 
-Você pode confirmar (ou fazer _commit_ de) mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componentes para chamadas _store.commit_ (requer injeção _store_ raiz):
+Você pode confirmar (ou fazer _commit_ de) mutações em componentes com `this.$store.commit('xxx')`, ou use o auxiliar `mapMutations` que mapeia métodos de componentes para chamadas `store.commit` (requer injeção _store_ raiz):
 
 ``` js
 import { mapMutations } from 'vuex'

docs/ptbr/guide/plugins.md

@@ -83,7 +83,7 @@ const store = new Vuex.Store({
 })
 ```
 
-O _plugin_ vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.js.org/plugins/define-plugin/) para webpack ou [envify](https://github.com/hughsk/envify) para Browserify para converter o valor do `process.env.NODE_ENV !== 'production'` para _false_ no _build_ final.
+O _plugin_ vai ser usado por padrão. Para produção, você vai precisar do [DefinePlugin](https://webpack.js.org/plugins/define-plugin/) para webpack ou [envify](https://github.com/hughsk/envify) para Browserify para converter o valor do `process.env.NODE_ENV !== 'production'` para `false` no _build_ final.
 
 ### Plugin de Log Integrado
 

docs/ptbr/guide/state.md

@@ -4,7 +4,7 @@
 
 <div class="scrimba"><a href="https://scrimba.com/p/pnyzgAP/cWw3Zhb" target="_blank" rel="noopener noreferrer">Tente esta lição no Scrimba</a></div>
 
-O Vuex usa uma **árvore única de estado** - ou seja, esse único objeto contém todo o estado do seu nível de aplicação e serve como a "única fonte da verdade". Isso também significa que você terá apenas um _store_ para cada aplicativo. Uma árvore única de estado facilita a localização de uma parte específica do estado, e permite capturar facilmente momentos do estado atual do aplicativo para fins de depuração.
+O Vuex usa uma **árvore única de estado** - ou seja, esse único objeto contém todo o estado do seu nível de aplicação e serve como a "única fonte da verdade". Isso também significa que você terá apenas um _store_ para cada aplicação. Uma árvore única de estado facilita a localização de uma parte específica do estado, e permite capturar facilmente momentos do estado atual da aplicação para fins de depuração.
 
 A árvore única de 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.
 
@@ -26,9 +26,9 @@ const Counter = {
 }
 ```
 
-Sempre que o _store.state.count_ muda, fará com que o dado computado seja reavaliado e ative as atualizações de _DOM_ associadas.
+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 do _store_ _singleton_ 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.
+No entanto, esse padrão faz com que o componente dependa do _store_ _singleton_ 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 requer dados fictícios (ou _mocking_) ao testar o componente.
 
 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)`):
 
@@ -87,7 +87,7 @@ export default {
 }
 ```
 
-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.
+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([

docs/ptbr/guide/strict.md

@@ -1,6 +1,6 @@
 # Modo Estrito
 
-Para habilitar o modo estrito, simplesmente passe _strict: true_ ao criar um _store_ Vuex:
+Para habilitar o modo estrito, simplesmente passe `strict: true` ao criar um _store_ Vuex:
 
 ``` js
 const store = new Vuex.Store({

docs/ptbr/guide/structure.md

@@ -2,7 +2,7 @@
 
 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 do aplicativo é centralizado no _store_.
+1. O estado do nível da aplicação é centralizado no _store_.
 
 2. A única maneira de mudar o estado é confirmando (ou fazendo _commit_ das) **mutações**, que são transações síncronas
 
@@ -10,7 +10,7 @@ O Vuex não restringe realmente como você estrutura seu código. Em vez disso,
 
 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 aproveitar os módulos. Aqui está um exemplo de estrutura de projeto:
+Para qualquer aplicação mais complexa, provavelmente precisaremos aproveitar os módulos. Aqui está um exemplo de estrutura de projeto:
 
 ``` bash
 ├── index.html