vuejs-io
diff --git a/‎docs/ru/README.md
Lines changed: 15 additions & 15 deletions b/‎docs/ru/README.md
Lines changed: 15 additions & 15 deletions
@@ -1,10 +1,10 @@
 # Что такое Vuex?
 
-Vuex — это **паттерн управления состоянием и библиотека** для приложений на Vue.js. Он служит центральным хранилищем данных для всех компонентов приложения и обеспечивает предсказуемость изменения данных при помощи определённых правил. Кроме того, Vuex интегрируется с официальным [расширением инструментов разработчика](https://github.com/vuejs/vue-devtools) Vue, предоставляя "из коробки" такие продвинутые возможности, как "машину времени" при отладке и экспорт/импорт слепков состояния данных.
+Vuex — **паттерн управления состоянием + библиотека** для приложений на Vue.js. Он служит централизованным хранилищем данных для всех компонентов приложения с правилами, гарантирующими, что состояние может быть изменено только предсказуемым образом. Vuex интегрируется с официальным расширением [vue-devtools](https://github.com/vuejs/vue-devtools), предоставляя «из коробки» такие продвинутые возможности, как «машину времени» для отладки и экспорт/импорт слепков состояния данных.
 
-### Что такое "паттерн управления состоянием"?
+### Что такое «паттерн управления состоянием»?
 
-Давайте начнём с простого приложения, реализующего счётчик с использованием Vue:
+Давайте начнём с простого приложения Vue, реализующего счётчик:
 
 ```js
 new Vue({
@@ -29,35 +29,35 @@ new Vue({
 
 Это самостоятельное приложение состоит из следующих частей:
 
-* **Состояние** — "источник истины", управляющий приложением;
-* **Представление** — декларативно заданное отображение **состояния**;
+* **Состояние** — «источник истины», управляющий приложением;
+* **Представление** — отображение **состояния** заданное декларативно;
 * **Действия** — возможные пути изменения состояния приложения в ответ на взаимодействие пользователя с **представлением**.
 
-Вот простейшее представление концепции "однонаправленного потока данных":
+Вот простейшее представление концепции «однонаправленного потока данных»:
 
 <p style="text-align: center; margin: 2em">
   <img style="width:100%;max-width:450px;" src="/ru/flow.png">
 </p>
 
-Простота, к сожалению, быстро исчезает при появлении **нескольких компонентов, основывающихся на одном и том же состоянии**, когда:
+Однако простота быстро исчезает, когда у нас появляется **нескольких компонентов, основывающихся на одном и том же состоянии**:
 
 * Несколько представлений могут зависеть от одной и той же части состояния приложения.
 * Действия из разных представлений могут оказывать влияние на одни и те же части состояния приложения.
 
-Разбираясь с первой проблемой, вам придётся передавать одни и те же данные в несколько глубоко вложенных компонентов. Это часто сложно и неприятно, а для соседних компонентов такое и вовсе не сработает. Решая вторую проблему, приходится обращаться напрямую к родителям и потомкам компонента, или синхронизировать изменения с другими местами в приложении событиями. Оба подхода хрупки и быстро приводят к появлению кода, который невозможно поддерживать.
+Решая первую проблему, придётся передавать одни и те же данные входными параметрами в глубоко вложенные компоненты. Это часто сложно и утомительно, а для соседних компонентов такое и вовсе не сработает. Решая вторую проблему, можно прийти к таким решениям, как обращение по ссылкам к родительским/дочерним экземплярам или попыткам изменять и синхронизировать несколько копий состояния через события. Оба подхода хрупки и быстро приводят к появлению кода, который невозможно поддерживать.
 
-Так почему бы не вынести всё общее состояние приложения из компонентов в глобальный синглтон? При использовании этого подхода, дерево компонентов превращается в одно большое "представление", а каждый компонент получает доступ к состоянию приложения, наряду с возможностью вызывать действия для изменения состояния, независимо от расположения этого компонента в дереве.
+Так почему бы не вынести всё общее состояние приложения из компонентов и управлять им в глобальном синглтоне? При этом наше дерево компонентов становится одним большим «представлением» и любой компонент может получить доступ к состоянию приложения или вызывать действия для изменения состояния, независимо от того, где они находятся в дереве!
 
-Кроме того, чётко определяя и разделяя концепции, возникающие при управлении состоянием, и требуя соблюдения некоторых правил, мы улучшаем структурированность и поддерживаемость нашего кода.
+Кроме того, чётко определяя и разделяя концепции, возникающие при управлении состоянием, и требуя соблюдения определённых правил, мы лучше структурируем код и облегчаем его поддержку.
 
-Такова основная идея, лежащая в основе Vuex, вдохновлённого [Flux](https://facebook.github.io/flux/docs/overview.html), [Redux](http://redux.js.org/) и [Архитектурой Elm](https://guide.elm-lang.org/architecture/). В отличие от других паттернов, Vuex реализован в виде библиотеки, специально заточенной на использование совместно с Vue.js и использующей его производительную систему реактивных обновлений.
+Это основная идея Vuex, вдохновлённого [Flux](https://facebook.github.io/flux/docs/overview.html), [Redux](http://redux.js.org/) и [Архитектурой Elm](https://guide.elm-lang.org/architecture/). В отличие от других паттернов, Vuex реализован в виде библиотеки, специально предназначенной для Vue.js, чтобы использовать его систему реактивности для эффективного обновления.
 
 ![vuex](/ru/vuex.png)
 
-### В каких случаях использовать Vuex?
+### Когда следует использовать Vuex?
 
-Vuex помогает управлять совместно используемым состоянием ценой привнесения новых концепций и вспомогательного кода. Кратковременная продуктивность страдает во благо долгосрочной.
+Хотя Vuex помогает управлять совместно используемым состоянием, это реализуется ценой привнесения новых концепций и вспомогательного кода. Компромисс, когда кратковременная продуктивность страдает на благо долгосрочной.
 
-Если вам ещё не доводилось создавать крупномасштабные одностраничные приложения, Vuex может показаться многословным и обескураживающим. Это нормально — несложные приложения вполне могут обойтись и без Vuex. Возможно, вам вполне хватит простой [глобальной шины событий](https://ru.vuejs.org/v2/guide/state-management.html#Простой-контейнер-состояния-с-нуля). Но если вы создаёте SPA среднего или крупного размера, вероятно вам уже приходилось сталкиваться с ситуациями, заставляющими задуматься о методах более эффективного управления состоянием приложения за пределами компонентов Vue, и Vuex в таком случае может оказаться вполне естественным следующим шагом. Вот неплохая цитата от Дэна Абрамова, автора Redux:
+Если ещё не приходилось создавать крупные SPA и вы лишь знакомитесь с Vuex, это может показаться многословным и сложным. Всё в порядке — простые приложения могут легко обходиться и без Vuex. Возможно, будет достаточно простого паттерна [глобальной шины событий](https://ru.vuejs.org/v2/guide/state-management.html#Простой-контейнер-состояния-с-нуля). Но если вы создаёте SPA среднего или крупного размера, то, скорее всего, уже сталкивались с ситуациями, которые заставляли задуматься о том, как лучше управлять состоянием вне компонентов Vue, а Vuex в таком случае может стать вполне естественным следующим шагом. Есть хорошая цитата от Дэна Абрамова, автора Redux:
 
-> Flux-библиотеки подобны очкам: если они вам действительно нужны, вы на этот счёт не сомневаетесь.
+> Flux-библиотеки похожи на очки: вы будете точно знать, когда они вам понадобятся.