Merge pull request #593 from chimit/dev

[Russian translation] Some punctuation fixes

docs/ru/actions.md

@@ -1,8 +1,8 @@
 # Действия
 
-Действия — похожи на мутации, с несколькими отличиями:
+Действия — похожи на мутации с несколькими отличиями:
 
-- Вместо того чтобы напрямую менять состояние, действия инициируют мутации.
+- Вместо того, чтобы напрямую менять состояние, действия инициируют мутации;
 - Действия могут использоваться для асинхронных операций.
 
 Зарегистрируем простое действие:
@@ -25,7 +25,7 @@ const store = new Vuex.Store({
 })
 ```
 
-Обработчики действий получают объект контекста, содержащий те же методы и свойства, что и сам инстанс хранилища, так что вы можете вызвать `context.commit` для инициирования мутации, или обратиться к состоянию и геттерам через `context.state` и `context.getters`. Позднее, при рассмотрении [Модулей](modules.md), мы увидим, однако, что этот контекст — не то же самое, что и сам инстанс хранилища.
+Обработчики действий получают объект контекста, содержащий те же методы и свойства, что и сам инстанс хранилища, так что вы можете вызвать `context.commit` для инициирования мутации или обратиться к состоянию и геттерам через `context.state` и `context.getters`. Позднее при рассмотрении [Модулей](modules.md) мы увидим, однако, что этот контекст — не то же самое, что инстанс хранилища.
 
 На практике для упрощения кода часто используется [деструктуризация аргументов](https://github.com/lukehoban/es6features#destructuring) из ES2015 (особенно при необходимости многократного вызова `commit`):
 
@@ -57,7 +57,7 @@ actions: {
 }
 ```
 
-Диспетчеризация действий поддерживает такой же объектный синтаксис, как диспетчеризация мутаций:
+Диспетчеризация действий поддерживает тот же объектный синтаксис, что и диспетчеризация мутаций:
 
 ``` js
 // параметризированный вызов
@@ -120,7 +120,7 @@ export default {
 
 Раз действия зачастую асинхронны, то как узнать, что действие уже завершилось? И, что важнее, как быть со связанными между собой действиями при организации более сложных асинхронных потоков?
 
-Для начала стоит вспомнить, что `store.dispatch` возвращает значение, равное результату вызванного обработчика действия, что позволяет использовать Promise: 
+Для начала стоит вспомнить, что `store.dispatch` возвращает значение, равное результату вызванного обработчика действия, что позволяет использовать Promise:
 
 ``` js
 actions: {
@@ -156,7 +156,7 @@ actions: {
 }
 ```
 
-И, в конце концов, используя [async / await](https://tc39.github.io/ecmascript-asyncawait/) — возможности, которые вот-вот станут общедоступными, можно компоновать действия таким образом:
+И, в конце концов, используя [async / await](https://tc39.github.io/ecmascript-asyncawait/) — возможности, которые вот-вот станут общедоступны - можно компоновать действия таким образом:
 
 ``` js
 // предположим, что getData() и getOtherData() возвращают промисы

docs/ru/getting-started.md

@@ -2,7 +2,7 @@
 
 В центре любого Vuex-приложения находится **хранилище**. "Хранилище" — это, упрощённо говоря, контейнер, который хранит **состояние** вашего приложения. Два момента отличают хранилище Vuex от простого глобального объекта:
 
-1. Хранилища Vuex реактивны. Если компоненты Vue зависят от их состояния, изменения состояния хранилища спровоцирует соответствующие изменения компонентов.
+1. Хранилища Vuex реактивны. Если компоненты Vue зависят от их состояния, изменение состояния хранилища спровоцирует соответствующие изменения компонентов.
 
 2. Непосредственное изменение состояния хранилища запрещено. Единственный способ внести изменения — явно **вызвать мутацию**. Этот подход позволяет быть уверенным, что каждое изменение оставляет в системе след, и даёт возможность использовать инструменты, позволяющие лучше понять работу приложения.
 

docs/ru/mutations.md

@@ -133,7 +133,7 @@ mutations: {
 }
 ```
 
-Теперь представьте, что вы отлаживаете приложение и смотрите в лог мутаций в инструментах разработчика. Для каждой залогированной мутации devtools должен сохранить слепки состояния приложения "до" и "после" её наступления. Однако, асинхронный коллбэк внутри приведённой выше мутации делает это невозможным: мутация-то уже записана, и у devtools нет никакой возможности знать, что далее будет вызван коллбэк, а значит и инициируемые им изменения становится, по сути дела, невозможно отследить.
+Теперь представьте, что вы отлаживаете приложение и смотрите в лог мутаций в инструментах разработчика. Для каждой залогированной мутации devtools должен сохранить слепки состояния приложения "до" и "после" её наступления. Однако, асинхронный коллбэк внутри приведённой выше мутации делает это невозможным: мутация-то уже записана, и у devtools нет никакой возможности знать, что далее будет вызван коллбэк, а, значит, и инициируемые им изменения становится, по сути дела, невозможно отследить.
 
 ### Вызов мутаций из компонентов
 
@@ -157,7 +157,7 @@ export default {
 
 ### О действиях
 
-Привнесение асинхронности в мутации могло бы изрядно затруднить понимание логики программы. Например, если вызываются два метода, оба с асинхронными коллбэками, изменяющими состояние приложения — как предсказать, какой из коллбэков будет вызван первым? Именно поэтому концепции изменений и асинхронности рассматриваются по отдельности. Во Vuex, **мутации — это синхронные транзакции**:
+Привнесение асинхронности в мутации могло бы изрядно затруднить понимание логики программы. Например, если вызываются два метода, оба с асинхронными коллбэками, изменяющими состояние приложения — как предсказать, какой из коллбэков будет вызван первым? Именно поэтому концепции изменений и асинхронности рассматриваются по отдельности. Во Vuex **мутации — это синхронные транзакции**:
 
 ``` js
 store.commit('increment')

docs/ru/strict.md

@@ -1,6 +1,6 @@
 # Strict Mode
 
-Для включения strict mode, просто укажите `strict: true` при создании хранилища Vuex:
+Для включения strict mode просто укажите `strict: true` при создании хранилища Vuex:
 
 ``` js
 const store = new Vuex.Store({
@@ -9,13 +9,13 @@ const store = new Vuex.Store({
 })
 ```
 
-При использовании strict mode, любая попытка внесения изменений в состояние Vuex, кроме как через зарегистрированную мутацию, приведёт к появлению ошибки. Это позволяет быть уверенным, что все изменения с данными отслеживаются инструментами отладки.
+При использовании strict mode любая попытка внесения изменений в состояние Vuex, кроме как через зарегистрированную мутацию, приведёт к появлению ошибки. Это позволяет быть уверенным, что все изменения данных отслеживаются инструментами отладки.
 
 ### Разработка и production
 
-**Не используйте strict mode в production-окружении!** Для определения некорректных операций, strict mode использует довольно "дорогие" операции глубокого наблюдения за деревом состояния приложения, поэтому удостоверьтесь что выключили этот режим перед выкладкой на production из соображений повышения производительности!
+**Не используйте strict mode в production-окружении!** Для определения некорректных операций strict mode использует довольно "дорогие" операции глубокого наблюдения за деревом состояния приложения, поэтому удостоверьтесь, что выключили этот режим перед выкладкой на production из соображений повышения производительности!
 
-При использовании систем модульной сборки, это можно сделать так:
+При использовании систем модульной сборки это можно сделать так:
 
 ``` js
 const store = new Vuex.Store({

docs/ru/structure.md

@@ -2,9 +2,9 @@
 
 В действительности Vuex не накладывает каких-то значительных ограничений на используемую структуру кода. Однако, он требует соблюдения нескольких высокоуровневых принципов:
 
-1. Глобальное состояние приложения должно содержаться в централизованном хранилище
+1. Глобальное состояние приложения должно содержаться в централизованном хранилище;
 
-2. Единственным механизмом изменения этого состояния являются **мутации**, являющиеся синхронными транзакциями.
+2. Единственным механизмом изменения этого состояния являются **мутации**, являющиеся синхронными транзакциями;
 
 3. Асинхронные операции инкапсулирутся в **действия**, или их комбинации.