From dde060ded71097eac8bd0bab6cd043aecdf37a41 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Thu, 4 Jul 2019 18:26:44 +0300
Subject: [PATCH 1/9] Getting started RU translation

A human translation of 'Getting started' article to Russian.
---
 locale/ru/docs/guides/getting-started-guide.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/locale/ru/docs/guides/getting-started-guide.md b/locale/ru/docs/guides/getting-started-guide.md
index a66d897400f47..5d3c1034a35d1 100644
--- a/locale/ru/docs/guides/getting-started-guide.md
+++ b/locale/ru/docs/guides/getting-started-guide.md
@@ -8,6 +8,9 @@ layout: docs.hbs
 Once you have installed Node, let's try building our first web server.
 Create a file named "app.js", and paste the following code:
 
+После того как вы установили Node, давайте попробуем создать наш первый веб-сервер.
+Создайте файл с именем "app.js", и скопируйте следующий код:
+
 ```javascript
 const http = require('http');
 
@@ -26,3 +29,4 @@ server.listen(port, hostname, () => {
 ```
 
 After that, run your web server using ``` node app.js ```, visit http://localhost:3000, and you will see a message 'Hello World'
+После этого запуститье ваш веб-сервер используя комманду  ``` node app.js ```, откройте http://localhost:3000 в браузере, и вы увидите сообщение 'Hello World'

From e716df3f995bec8358cdef0a2656f7c5ec575ba5 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Thu, 4 Jul 2019 20:37:37 +0300
Subject: [PATCH 2/9] translation to ru

---
 .../docs/guides/anatomy-of-an-http-transaction.md | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/locale/ru/docs/guides/anatomy-of-an-http-transaction.md b/locale/ru/docs/guides/anatomy-of-an-http-transaction.md
index 289514b9c5537..7fe3034403c38 100644
--- a/locale/ru/docs/guides/anatomy-of-an-http-transaction.md
+++ b/locale/ru/docs/guides/anatomy-of-an-http-transaction.md
@@ -1,9 +1,9 @@
 ---
-title: Anatomy of an HTTP Transaction
+title: Анатомия HTTP Транзакции
 layout: docs.hbs
 ---
 
-# Anatomy of an HTTP Transaction
+# Анатомия HTTP Транзакции
 
 The purpose of this guide is to impart a solid understanding of the process of
 Node.js HTTP handling. We'll assume that you know, in a general sense, how HTTP
@@ -12,11 +12,20 @@ assume a bit of familiarity with Node.js [`EventEmitters`][] and [`Streams`][].
 If you're not quite familiar with them, it's worth taking a quick read through
 the API docs for each of those.
 
-## Create the Server
+Цель данного руководства дать твердое понимание процесса обработки HTTP в 
+Node.js. Мы предположим, что вам известно, в общих чертах, как работают HTTP
+запросы, в независимости от языка програмирования и среды разработки. Мы
+так же предположим, что у вас есть некоторое представление о [`EventEmitters`][]
+и [`Streams`][] в Node.js. Если вы недостаточно знакомы с этими модулями, стоит
+пролистать их API документацию.
+
+## Создание Сервера
 
 Any node web server application will at some point have to create a web server
 object. This is done by using [`createServer`][].
 
+Рано или поздно любое веб-сервер приложение в node должно создать объект веб-сервера.
+
 ```javascript
 const http = require('http');
 

From 0926a31ee9fa7425319d867c48ed89039e2b05f1 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Sat, 6 Jul 2019 05:05:36 +0300
Subject: [PATCH 3/9] Update blocking-vs-non-blocking.md

---
 .../docs/guides/blocking-vs-non-blocking.md   | 30 ++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index 5dad10472b700..aa0ee8fc2a65e 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -1,37 +1,65 @@
 ---
-title: Overview of Blocking vs Non-Blocking
+title: Обзор Блокирующих и Неблокирующих Вызовов
 layout: docs.hbs
 ---
 
 # Overview of Blocking vs Non-Blocking
+# Обзор Блокирующих и Неблокирующих Вызовов
 
 This overview covers the difference between **blocking** and **non-blocking**
 calls in Node.js. This overview will refer to the event loop and libuv but no
 prior knowledge of those topics is required. Readers are assumed to have a
 basic understanding of the JavaScript language and Node.js callback pattern.
 
+
+Этот обзор рассматривает разницу между **блокирующими** и **неблокирующими**
+вызовами в Node.js. Этот обзор ссылается на цикл событий (Event Loop) и библиотеку libuv,
+однако предварительное знание этих тем не требуется. Предпологается, что 
+читатели имеют базовое понимание JavaScript и паттерна обратных вызовов (callback)
+в Node.js.
+
 > "I/O" refers primarily to interaction with the system's disk and
 > network supported by [libuv](http://libuv.org/).
 
+> Обозначение "I/O" (Ввод/Вывод) в первую очередь ссылается на взаимодействие
+> с системным диском и сетью при поддержке [libuv](http://libuv.org/).
+
 
 ## Blocking
+## Блокирование
 
 **Blocking** is when the execution of additional JavaScript in the Node.js
 process must wait until a non-JavaScript operation completes. This happens
 because the event loop is unable to continue running JavaScript while a
 **blocking** operation is occurring.
 
+**Блокирование** происходит, когда исполнению оставшегося JavaScript кода в Node.js
+приходится ждать, пока не завершится сторонняя операция (напр. чтение содржания какого-нибудь файла).
+Так происходит, потомучто цикл событий не может продолжить исполнение JavaScript
+кода, пока работает **блокирующая** операция.
+
 In Node.js, JavaScript that exhibits poor performance due to being CPU intensive
 rather than waiting on a non-JavaScript operation, such as I/O, isn't typically
 referred to as **blocking**. Synchronous methods in the Node.js standard library
 that use libuv are the most commonly used **blocking** operations. Native
 modules may also have **blocking** methods.
 
+В Node.js, медленный код JavaScript, как правило, не называют **блокирующим**,
+если он является таким по причине высокой нагрузки на ЦПУ, а не по причине
+ожидания завершения сторонней операции. Синхронные методы в стандартной
+библиотеке Node.js, которые используют libuv, суть самые часто встречающиеся
+**блокирующие** операции.
+
 All of the I/O methods in the Node.js standard library provide asynchronous
 versions, which are **non-blocking**, and accept callback functions. Some
 methods also have **blocking** counterparts, which have names that end with
 `Sync`.
 
+Все I/O методы в стандартной библиотеке Node.js предоставляют асинхронные версии,
+которые являются **неблокирующими**, и которые принимаю функции обратного вызова
+в качестве аргумента. Некоторые методы также имеют свои **блокирующие** аналоги.
+Названия таких методов закнчиваются на `Sync`. 
+
 
 ## Comparing Code
 

From 8d96e7a7f7121c14ebf812fb1f27a7a7ec9f7d09 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Sat, 6 Jul 2019 18:09:57 +0300
Subject: [PATCH 4/9] ru translation of blocking vs non-blocking guide

Human translation to Russian.
---
 .../docs/guides/blocking-vs-non-blocking.md   | 31 +++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index aa0ee8fc2a65e..512a320e126fa 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -48,7 +48,7 @@ modules may also have **blocking** methods.
 если он является таким по причине высокой нагрузки на ЦПУ, а не по причине
 ожидания завершения сторонней операции. Синхронные методы в стандартной
 библиотеке Node.js, которые используют libuv, суть самые часто встречающиеся
-**блокирующие** операции.
+**блокирующие** операции. Нативные модули так же могут иметь **блокирующие** вызовы.
 
 All of the I/O methods in the Node.js standard library provide asynchronous
 versions, which are **non-blocking**, and accept callback functions. Some
@@ -62,19 +62,28 @@ methods also have **blocking** counterparts, which have names that end with
 
 
 ## Comparing Code
+## Сравнение Кода
 
 **Blocking** methods execute **synchronously** and **non-blocking** methods
 execute **asynchronously**.
 
+**Блокирующие** методы исполняются **синхронно**, а **неблокирующие** методы
+исполняются **асинхронно**.
+
 Using the File System module as an example, this is a **synchronous** file read:
 
+Для примера возмкм модуль File System. Это пример **синхронного** чтения файла:
+
 ```js
 const fs = require('fs');
-const data = fs.readFileSync('/file.md'); // blocks here until file is read
+const data = fs.readFileSync('/file.md'); // blocks here until file is read 
+const data = fs.readFileSync('/file.md'); // исполнение кода заблокированно, пока файл полностью не прочтен
 ```
 
 And here is an equivalent **asynchronous** example:
 
+А здесь эквивалентный **асинхронный** пример:
+
 ```js
 const fs = require('fs');
 fs.readFile('/file.md', (err, data) => {
@@ -89,16 +98,26 @@ thrown it will need to be caught or the process will crash. In the asynchronous
 version, it is up to the author to decide whether an error should throw as
 shown.
 
+Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка 
+**блокирует** исполнение лиюбого нижеследующего кода, пока весь файл не будет считан.
+Обратите внимание, если синхронная версия кода сгененирует исключение (throws an exception),
+его нужно поймать, иначе процесс Node.js "упадёт". 
+
 Let's expand our example a little bit:
 
+Давайте немного расширем наш пример:
+
 ```js
 const fs = require('fs');
 const data = fs.readFileSync('/file.md'); // blocks here until file is read
+const data = fs.readFileSync('/file.md'); // исполнение кода заблокированно, пока файл полностью не прочтен
 console.log(data);
 moreWork(); // will run after console.log
+moreWork(); // функция будет исполнена, после console.log
 ```
 
 And here is a similar, but not equivalent asynchronous example:
+А вот похожий, но не эквивалентный асинхронный пример:
 
 ```js
 const fs = require('fs');
@@ -107,6 +126,7 @@ fs.readFile('/file.md', (err, data) => {
   console.log(data);
 });
 moreWork(); // will run before console.log
+moreWork(); // функция будет исполнена до console.log
 ```
 
 In the first example above, `console.log` will be called before `moreWork()`. In
@@ -115,6 +135,13 @@ can continue and `moreWork()` will be called first. The ability to run
 `moreWork()` without waiting for the file read to complete is a key design
 choice that allows for higher throughput.
 
+В первом примере метод `console.log` будет вызван до срабатывания функции `moreWork()`.
+Во втором примере метод `fs.readFile()` является **неблокирующим**, поэтому исполнение
+JavaScript кода может продолжаться не дожидаясь окончания его работы, как следствие 
+функция `moreWork()` сработает раньше `console.log`. Эта возможность — отсутствие необходимости 
+дожидаться окончания чтения файла и т.п. системных вызовов — ключевое
+инженерное решение, которое обеспечивает высокую пропускную способность Node.js.
+
 
 ## Concurrency and Throughput
 

From 1c44feb5a0a4563c99fb1c69166b10244623a2b5 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Sat, 6 Jul 2019 18:34:55 +0300
Subject: [PATCH 5/9] patch #1

---
 .../docs/guides/blocking-vs-non-blocking.md   | 29 ++++++++++---------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index 512a320e126fa..6574e28401a50 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -13,7 +13,7 @@ basic understanding of the JavaScript language and Node.js callback pattern.
 
 
 Этот обзор рассматривает разницу между **блокирующими** и **неблокирующими**
-вызовами в Node.js. Этот обзор ссылается на цикл событий (Event Loop) и библиотеку libuv,
+вызовами в Node.js. Он ссылается на цикл событий (event loop) и библиотеку libuv,
 однако предварительное знание этих тем не требуется. Предпологается, что 
 читатели имеют базовое понимание JavaScript и паттерна обратных вызовов (callback)
 в Node.js.
@@ -33,9 +33,9 @@ process must wait until a non-JavaScript operation completes. This happens
 because the event loop is unable to continue running JavaScript while a
 **blocking** operation is occurring.
 
-**Блокирование** происходит, когда исполнению оставшегося JavaScript кода в Node.js
-приходится ждать, пока не завершится сторонняя операция (напр. чтение содржания какого-нибудь файла).
-Так происходит, потомучто цикл событий не может продолжить исполнение JavaScript
+О **блокировании** говорят, когда выполнение оставшегося JavaScript кода в Node.js
+приостановленно до тех пор, пока не завершится работа сторонней операции (напр., чтение
+какого-нибудь файла). Поскольку цикл событий не может продолжить исполнение оставшегося JavaScript
 кода, пока работает **блокирующая** операция.
 
 In Node.js, JavaScript that exhibits poor performance due to being CPU intensive
@@ -44,19 +44,19 @@ referred to as **blocking**. Synchronous methods in the Node.js standard library
 that use libuv are the most commonly used **blocking** operations. Native
 modules may also have **blocking** methods.
 
-В Node.js, медленный код JavaScript, как правило, не называют **блокирующим**,
-если он является таким по причине высокой нагрузки на ЦПУ, а не по причине
-ожидания завершения сторонней операции. Синхронные методы в стандартной
-библиотеке Node.js, которые используют libuv, суть самые часто встречающиеся
-**блокирующие** операции. Нативные модули так же могут иметь **блокирующие** вызовы.
+В Node.js, медленный код JavaScript, не принято называть **блокирующим**,
+если причиной тому высокая нагрузка на процессор, а не ожидание завершения 
+сторонней операции. Синхронные методы в стандартной библиотеке Node.js, 
+которые используют libuv, наиболее часто встречающиеся **блокирующие** операции. 
+Нативные модули также могут иметь **блокирующие** вызовы.
 
 All of the I/O methods in the Node.js standard library provide asynchronous
 versions, which are **non-blocking**, and accept callback functions. Some
 methods also have **blocking** counterparts, which have names that end with
 `Sync`.
 
-Все I/O методы в стандартной библиотеке Node.js предоставляют асинхронные версии,
-которые являются **неблокирующими**, и которые принимаю функции обратного вызова
+Все I/O методы в стандартной библиотеке Node.js предоставляют свои асинхронные версии,
+которые являются **неблокирующими**, и которые принимают функции обратного вызова
 в качестве аргумента. Некоторые методы также имеют свои **блокирующие** аналоги.
 Названия таких методов закнчиваются на `Sync`. 
 
@@ -72,7 +72,7 @@ execute **asynchronously**.
 
 Using the File System module as an example, this is a **synchronous** file read:
 
-Для примера возмкм модуль File System. Это пример **синхронного** чтения файла:
+Для примера возмем модуль File System. Вот пример **синхронного** чтения файла:
 
 ```js
 const fs = require('fs');
@@ -82,7 +82,7 @@ const data = fs.readFileSync('/file.md'); // исполнение кода за
 
 And here is an equivalent **asynchronous** example:
 
-А здесь эквивалентный **асинхронный** пример:
+А вот эквивалентный **асинхронный** пример:
 
 ```js
 const fs = require('fs');
@@ -101,7 +101,7 @@ shown.
 Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка 
 **блокирует** исполнение лиюбого нижеследующего кода, пока весь файл не будет считан.
 Обратите внимание, если синхронная версия кода сгененирует исключение (throws an exception),
-его нужно поймать, иначе процесс Node.js "упадёт". 
+его нужно обработать, иначе процесс Node.js "упадёт". 
 
 Let's expand our example a little bit:
 
@@ -144,6 +144,7 @@ JavaScript кода может продолжаться не дожидаясь
 
 
 ## Concurrency and Throughput
+## Конкурентность и Пропускная Способность
 
 JavaScript execution in Node.js is single threaded, so concurrency refers to the
 event loop's capacity to execute JavaScript callback functions after completing

From e2cc4a5bad0a0c2f480afb90b0984cb402a0182b Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Sat, 6 Jul 2019 19:19:39 +0300
Subject: [PATCH 6/9] patch #2

---
 .../docs/guides/blocking-vs-non-blocking.md   | 28 ++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index 6574e28401a50..8ed084c21faa6 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -152,6 +152,11 @@ other work. Any code that is expected to run in a concurrent manner must allow
 the event loop to continue running as non-JavaScript operations, like I/O, are
 occurring.
 
+Исполнение JavaScript в Node.js является однопоточным. Поэтому, говоря о конкурентности
+в Node.js, подразумевают, что после того как цикл событий обработал синхронный код, он также
+способен обработать обратные вызовы JavaScript. Подобно сторонним операциям, любой конкурентный
+код должен позволять циклу событий продолжать свою работу. ??????
+
 As an example, let's consider a case where each request to a web server takes
 50ms to complete and 45ms of that 50ms is database I/O that can be done
 asynchronously. Choosing **non-blocking** asynchronous operations frees up that
@@ -159,15 +164,28 @@ asynchronously. Choosing **non-blocking** asynchronous operations frees up that
 capacity just by choosing to use **non-blocking** methods instead of
 **blocking** methods.
 
+В качестве примера возьмем запросы к веб-серверу. Допустим обработк сервером одного запроса
+занимает 50мс. Из этих 50мс, 45мс уходит на операции чтения/записи в базу данных.
+С базой данных можно взаимодействовать и **асинхронно**. При таком подходе, на каждый запрос
+к веб-серверу **неблокирующая** асинхронная операция высвободит 45мс для обработки других
+запросов, а это существенная разница.
+
+
 The event loop is different than models in many other languages where additional
 threads may be created to handle concurrent work.
 
+Цикл событий отличается от способов во многих других языках программирования,
+где для исполнения конкурентной  работы могу создаваться дополнительные потоки.
+
 
 ## Dangers of Mixing Blocking and Non-Blocking Code
+## Опасность Смешивания Блокирующего и Неблокирующего Кода
 
 There are some patterns that should be avoided when dealing with I/O. Let's look
 at an example:
 
+Существует паттерны, которые следует избегать при работе с I/O. Взглянем на пример:
+
 ```js
 const fs = require('fs');
 fs.readFile('/file.md', (err, data) => {
@@ -182,6 +200,10 @@ In the above example, `fs.unlinkSync()` is likely to be run before
 better way to write this, which is completely **non-blocking** and guaranteed to
 execute in the correct order is:
 
+В данном примере, метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
+`fs.readFile()`. Что привед к удаленнию файла, до его прочтения. Лучше переписать
+весь этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения:
+
 
 ```js
 const fs = require('fs');
@@ -197,8 +219,12 @@ fs.readFile('/file.md', (readFileErr, data) => {
 The above places a **non-blocking** call to `fs.unlink()` within the callback of
 `fs.readFile()` which guarantees the correct order of operations.
 
+В примере выше **неблокирующий** вызов метода `fs.unlink()` расположен в обратном вызове
+`fs.readFile()`. Такой подход гаррантирует парвильную последовательность операций.
+
 
 ## Additional Resources
+## Дополнительные рессурсы
 
 - [libuv](http://libuv.org/)
-- [About Node.js](https://nodejs.org/en/about/)
+- [О Node.js](https://nodejs.org/en/about/)

From 35d43960bb2ee9dbe4e0674331f7060d41b93367 Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@users.noreply.github.com>
Date: Sat, 6 Jul 2019 19:45:40 +0300
Subject: [PATCH 7/9] patch #3

---
 .../docs/guides/blocking-vs-non-blocking.md   | 37 +++++++++----------
 1 file changed, 18 insertions(+), 19 deletions(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index 8ed084c21faa6..a05e50f30f41d 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -72,12 +72,12 @@ execute **asynchronously**.
 
 Using the File System module as an example, this is a **synchronous** file read:
 
-Для примера возмем модуль File System. Вот пример **синхронного** чтения файла:
+Для примера возьмем модуль File System. Вот пример **синхронного** чтения файла:
 
 ```js
 const fs = require('fs');
-const data = fs.readFileSync('/file.md'); // blocks here until file is read 
-const data = fs.readFileSync('/file.md'); // исполнение кода заблокированно, пока файл полностью не прочтен
+// исполнение кода заблокированно, пока файл будет полностью не считан
+const data = fs.readFileSync('/file.md'); 
 ```
 
 And here is an equivalent **asynchronous** example:
@@ -99,7 +99,7 @@ version, it is up to the author to decide whether an error should throw as
 shown.
 
 Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка 
-**блокирует** исполнение лиюбого нижеследующего кода, пока весь файл не будет считан.
+**блокирует** исполнение лиюбого нижеследующего JavaScript кода, пока весь файл не будет считан.
 Обратите внимание, если синхронная версия кода сгененирует исключение (throws an exception),
 его нужно обработать, иначе процесс Node.js "упадёт". 
 
@@ -109,10 +109,9 @@ Let's expand our example a little bit:
 
 ```js
 const fs = require('fs');
-const data = fs.readFileSync('/file.md'); // blocks here until file is read
-const data = fs.readFileSync('/file.md'); // исполнение кода заблокированно, пока файл полностью не прочтен
+// исполнение кода заблокированно, пока файл не будет полностью не считан
+const data = fs.readFileSync('/file.md'); 
 console.log(data);
-moreWork(); // will run after console.log
 moreWork(); // функция будет исполнена, после console.log
 ```
 
@@ -125,7 +124,6 @@ fs.readFile('/file.md', (err, data) => {
   if (err) throw err;
   console.log(data);
 });
-moreWork(); // will run before console.log
 moreWork(); // функция будет исполнена до console.log
 ```
 
@@ -152,10 +150,10 @@ other work. Any code that is expected to run in a concurrent manner must allow
 the event loop to continue running as non-JavaScript operations, like I/O, are
 occurring.
 
-Исполнение JavaScript в Node.js является однопоточным. Поэтому, говоря о конкурентности
-в Node.js, подразумевают, что после того как цикл событий обработал синхронный код, он также
-способен обработать обратные вызовы JavaScript. Подобно сторонним операциям, любой конкурентный
-код должен позволять циклу событий продолжать свою работу. ??????
+Исполнение JavaScript кода в Node.js является однопоточным. Поэтому, говоря о конкурентности 
+(параллельности) в Node.js, подразумевают, что после того как цикл событий обработал синхронный код,
+он также способен обработать функции обратного вызова. Подобно сторонним операциям, 
+любой конкурентный код должен позволять циклу событий продолжать свою работу.
 
 As an example, let's consider a case where each request to a web server takes
 50ms to complete and 45ms of that 50ms is database I/O that can be done
@@ -164,7 +162,7 @@ asynchronously. Choosing **non-blocking** asynchronous operations frees up that
 capacity just by choosing to use **non-blocking** methods instead of
 **blocking** methods.
 
-В качестве примера возьмем запросы к веб-серверу. Допустим обработк сервером одного запроса
+В качестве примера возьмем запросы к веб-серверу. Допустим обработка сервером одного запроса
 занимает 50мс. Из этих 50мс, 45мс уходит на операции чтения/записи в базу данных.
 С базой данных можно взаимодействовать и **асинхронно**. При таком подходе, на каждый запрос
 к веб-серверу **неблокирующая** асинхронная операция высвободит 45мс для обработки других
@@ -174,8 +172,9 @@ capacity just by choosing to use **non-blocking** methods instead of
 The event loop is different than models in many other languages where additional
 threads may be created to handle concurrent work.
 
-Цикл событий отличается от способов во многих других языках программирования,
-где для исполнения конкурентной  работы могу создаваться дополнительные потоки.
+Обработка конкурентной (параллельной) работы при помощи цикла событий в Node.js
+отличается от подходов во многих других языках программрования, в которых могут
+создаваться дополнительные потоки.
 
 
 ## Dangers of Mixing Blocking and Non-Blocking Code
@@ -201,8 +200,8 @@ better way to write this, which is completely **non-blocking** and guaranteed to
 execute in the correct order is:
 
 В данном примере, метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
-`fs.readFile()`. Что привед к удаленнию файла, до его прочтения. Лучше переписать
-весь этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения:
+`fs.readFile()`. Это приведет к удалению файла до его прочтения. Лучше переписать 
+этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения:
 
 
 ```js
@@ -219,8 +218,8 @@ fs.readFile('/file.md', (readFileErr, data) => {
 The above places a **non-blocking** call to `fs.unlink()` within the callback of
 `fs.readFile()` which guarantees the correct order of operations.
 
-В примере выше **неблокирующий** вызов метода `fs.unlink()` расположен в обратном вызове
-`fs.readFile()`. Такой подход гаррантирует парвильную последовательность операций.
+В примере выше **неблокирующий** вызов метода `fs.unlink()` расположен в функции обратного вызова
+`fs.readFile()`. Такой подход гарантирует парвильную последовательность операций.
 
 
 ## Additional Resources

From 85e9e2c0ad0da39231f57822b6de0f2a3dfc441e Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@gmail.com>
Date: Sun, 14 Jul 2019 06:57:56 +0300
Subject: [PATCH 8/9] patch

---
 .../docs/guides/blocking-vs-non-blocking.md   | 124 +++---------------
 1 file changed, 21 insertions(+), 103 deletions(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index a05e50f30f41d..d2bced819c268 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -1,87 +1,51 @@
----
-title: Обзор Блокирующих и Неблокирующих Вызовов
+title: Блокирующие и Неблокирующие Вызовы
 layout: docs.hbs
 ---
 
-# Overview of Blocking vs Non-Blocking
 # Обзор Блокирующих и Неблокирующих Вызовов
 
-This overview covers the difference between **blocking** and **non-blocking**
-calls in Node.js. This overview will refer to the event loop and libuv but no
-prior knowledge of those topics is required. Readers are assumed to have a
-basic understanding of the JavaScript language and Node.js callback pattern.
-
-
 Этот обзор рассматривает разницу между **блокирующими** и **неблокирующими**
 вызовами в Node.js. Он ссылается на цикл событий (event loop) и библиотеку libuv,
 однако предварительное знание этих тем не требуется. Предпологается, что 
 читатели имеют базовое понимание JavaScript и паттерна обратных вызовов (callback)
 в Node.js.
 
-> "I/O" refers primarily to interaction with the system's disk and
-> network supported by [libuv](http://libuv.org/).
-
 > Обозначение "I/O" (Ввод/Вывод) в первую очередь ссылается на взаимодействие
 > с системным диском и сетью при поддержке [libuv](http://libuv.org/).
 
 
-## Blocking
 ## Блокирование
 
-**Blocking** is when the execution of additional JavaScript in the Node.js
-process must wait until a non-JavaScript operation completes. This happens
-because the event loop is unable to continue running JavaScript while a
-**blocking** operation is occurring.
-
 О **блокировании** говорят, когда выполнение оставшегося JavaScript кода в Node.js
-приостановленно до тех пор, пока не завершится работа сторонней операции (напр., чтение
-какого-нибудь файла). Поскольку цикл событий не может продолжить исполнение оставшегося JavaScript
+приостановленно до тех пор, пока не завершится работа сторонней операции (например, чтение
+какого-нибудь файла). Так происходит, потому что цикл событий не может продолжить исполнение оставшегося JavaScript
 кода, пока работает **блокирующая** операция.
 
-In Node.js, JavaScript that exhibits poor performance due to being CPU intensive
-rather than waiting on a non-JavaScript operation, such as I/O, isn't typically
-referred to as **blocking**. Synchronous methods in the Node.js standard library
-that use libuv are the most commonly used **blocking** operations. Native
-modules may also have **blocking** methods.
-
-В Node.js, медленный код JavaScript, не принято называть **блокирующим**,
-если причиной тому высокая нагрузка на процессор, а не ожидание завершения 
+В Node.js медленный код JavaScript не принято называть **блокирующим**,
+если причиной тому высокая нагрузка кода на процессор, а не ожидание завершения 
 сторонней операции. Синхронные методы в стандартной библиотеке Node.js, 
-которые используют libuv, наиболее часто встречающиеся **блокирующие** операции. 
-Нативные модули также могут иметь **блокирующие** вызовы.
-
-All of the I/O methods in the Node.js standard library provide asynchronous
-versions, which are **non-blocking**, and accept callback functions. Some
-methods also have **blocking** counterparts, which have names that end with
-`Sync`.
+которые используют libuv, наиболее часто применимые **блокирующие** операции. 
+Нативные модули также могут иметь **блокирующие** методы.
 
 Все I/O методы в стандартной библиотеке Node.js предоставляют свои асинхронные версии,
-которые являются **неблокирующими**, и которые принимают функции обратного вызова
+которые являются **неблокирующими** и которые принимают функции обратного вызова
 в качестве аргумента. Некоторые методы также имеют свои **блокирующие** аналоги.
 Названия таких методов закнчиваются на `Sync`. 
 
 
-## Comparing Code
 ## Сравнение Кода
 
-**Blocking** methods execute **synchronously** and **non-blocking** methods
-execute **asynchronously**.
-
 **Блокирующие** методы исполняются **синхронно**, а **неблокирующие** методы
 исполняются **асинхронно**.
 
-Using the File System module as an example, this is a **synchronous** file read:
-
-Для примера возьмем модуль File System. Вот пример **синхронного** чтения файла:
+Возьмем модуль File System для примера. Вот пример **синхронного** чтения файла:
 
 ```js
 const fs = require('fs');
-// исполнение кода заблокированно, пока файл будет полностью не считан
+// исполнение кода заблокированно, пока файл не будет полностью считан
 const data = fs.readFileSync('/file.md'); 
 ```
 
-And here is an equivalent **asynchronous** example:
-
 А вот эквивалентный **асинхронный** пример:
 
 ```js
@@ -91,31 +55,22 @@ fs.readFile('/file.md', (err, data) => {
 });
 ```
 
-The first example appears simpler than the second but has the disadvantage of
-the second line **blocking** the execution of any additional JavaScript until
-the entire file is read. Note that in the synchronous version if an error is
-thrown it will need to be caught or the process will crash. In the asynchronous
-version, it is up to the author to decide whether an error should throw as
-shown.
-
 Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка 
-**блокирует** исполнение лиюбого нижеследующего JavaScript кода, пока весь файл не будет считан.
-Обратите внимание, если синхронная версия кода сгененирует исключение (throws an exception),
-его нужно обработать, иначе процесс Node.js "упадёт". 
-
-Let's expand our example a little bit:
+**блокирует** исполнение любого нижеследующего JavaScript кода, пока весь file.md не будет считан.
+Обратите внимание, если синхронная версия кода сгенерирует исключение,
+его нужно обработать, иначе процесс Node.js "упадёт". В асинхронном варианте
+выбор сгенерировать исключение или нет оставлено на усмотрение программиста.
 
-Давайте немного расширем наш пример:
+Давайте немного расширим наш пример:
 
 ```js
 const fs = require('fs');
-// исполнение кода заблокированно, пока файл не будет полностью не считан
+// исполнение кода заблокированно, пока файл не будет полностью считан
 const data = fs.readFileSync('/file.md'); 
 console.log(data);
 moreWork(); // функция будет исполнена, после console.log
 ```
 
-And here is a similar, but not equivalent asynchronous example:
 А вот похожий, но не эквивалентный асинхронный пример:
 
 ```js
@@ -127,12 +82,6 @@ fs.readFile('/file.md', (err, data) => {
 moreWork(); // функция будет исполнена до console.log
 ```
 
-In the first example above, `console.log` will be called before `moreWork()`. In
-the second example `fs.readFile()` is **non-blocking** so JavaScript execution
-can continue and `moreWork()` will be called first. The ability to run
-`moreWork()` without waiting for the file read to complete is a key design
-choice that allows for higher throughput.
-
 В первом примере метод `console.log` будет вызван до срабатывания функции `moreWork()`.
 Во втором примере метод `fs.readFile()` является **неблокирующим**, поэтому исполнение
 JavaScript кода может продолжаться не дожидаясь окончания его работы, как следствие 
@@ -141,48 +90,26 @@ JavaScript кода может продолжаться не дожидаясь
 инженерное решение, которое обеспечивает высокую пропускную способность Node.js.
 
 
-## Concurrency and Throughput
 ## Конкурентность и Пропускная Способность
 
-JavaScript execution in Node.js is single threaded, so concurrency refers to the
-event loop's capacity to execute JavaScript callback functions after completing
-other work. Any code that is expected to run in a concurrent manner must allow
-the event loop to continue running as non-JavaScript operations, like I/O, are
-occurring.
-
 Исполнение JavaScript кода в Node.js является однопоточным. Поэтому, говоря о конкурентности 
-(параллельности) в Node.js, подразумевают, что после того как цикл событий обработал синхронный код,
-он также способен обработать функции обратного вызова. Подобно сторонним операциям, 
+(параллельности вычислений) в Node.js, подразумевают, что после того как цикл событий обработал синхронный код,
+он способен обработать функции обратного вызова. Подобно сторонним операциям (таким как I/O), 
 любой конкурентный код должен позволять циклу событий продолжать свою работу.
 
-As an example, let's consider a case where each request to a web server takes
-50ms to complete and 45ms of that 50ms is database I/O that can be done
-asynchronously. Choosing **non-blocking** asynchronous operations frees up that
-45ms per request to handle other requests. This is a significant difference in
-capacity just by choosing to use **non-blocking** methods instead of
-**blocking** methods.
-
-В качестве примера возьмем запросы к веб-серверу. Допустим обработка сервером одного запроса
+В качестве примера возьмем запросы к веб-серверу. Допустим, обработка сервером одного запроса
 занимает 50мс. Из этих 50мс, 45мс уходит на операции чтения/записи в базу данных.
 С базой данных можно взаимодействовать и **асинхронно**. При таком подходе, на каждый запрос
 к веб-серверу **неблокирующая** асинхронная операция высвободит 45мс для обработки других
 запросов, а это существенная разница.
 
-
-The event loop is different than models in many other languages where additional
-threads may be created to handle concurrent work.
-
 Обработка конкурентной (параллельной) работы при помощи цикла событий в Node.js
 отличается от подходов во многих других языках программрования, в которых могут
 создаваться дополнительные потоки.
 
 
-## Dangers of Mixing Blocking and Non-Blocking Code
 ## Опасность Смешивания Блокирующего и Неблокирующего Кода
 
-There are some patterns that should be avoided when dealing with I/O. Let's look
-at an example:
-
 Существует паттерны, которые следует избегать при работе с I/O. Взглянем на пример:
 
 ```js
@@ -194,14 +121,9 @@ fs.readFile('/file.md', (err, data) => {
 fs.unlinkSync('/file.md');
 ```
 
-In the above example, `fs.unlinkSync()` is likely to be run before
-`fs.readFile()`, which would delete `file.md` before it is actually read. A
-better way to write this, which is completely **non-blocking** and guaranteed to
-execute in the correct order is:
-
-В данном примере, метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
+В примере выше, метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
 `fs.readFile()`. Это приведет к удалению файла до его прочтения. Лучше переписать 
-этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения:
+этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения методов:
 
 
 ```js
@@ -215,14 +137,10 @@ fs.readFile('/file.md', (readFileErr, data) => {
 });
 ```
 
-The above places a **non-blocking** call to `fs.unlink()` within the callback of
-`fs.readFile()` which guarantees the correct order of operations.
-
 В примере выше **неблокирующий** вызов метода `fs.unlink()` расположен в функции обратного вызова
 `fs.readFile()`. Такой подход гарантирует парвильную последовательность операций.
 
 
-## Additional Resources
 ## Дополнительные рессурсы
 
 - [libuv](http://libuv.org/)

From 652582b7cb6efdcabac5a0963f194cf246fc125b Mon Sep 17 00:00:00 2001
From: Yevgeny <unstoo@gmail.com>
Date: Sun, 14 Jul 2019 13:40:01 +0300
Subject: [PATCH 9/9] patch #2

---
 .../docs/guides/blocking-vs-non-blocking.md   | 21 ++++++++++---------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/locale/ru/docs/guides/blocking-vs-non-blocking.md b/locale/ru/docs/guides/blocking-vs-non-blocking.md
index d2bced819c268..741a423dc54c7 100644
--- a/locale/ru/docs/guides/blocking-vs-non-blocking.md
+++ b/locale/ru/docs/guides/blocking-vs-non-blocking.md
@@ -1,3 +1,4 @@
+---
 title: Блокирующие и Неблокирующие Вызовы
 layout: docs.hbs
 ---
@@ -19,16 +20,16 @@ layout: docs.hbs
 О **блокировании** говорят, когда выполнение оставшегося JavaScript кода в Node.js
 приостановленно до тех пор, пока не завершится работа сторонней операции (например, чтение
 какого-нибудь файла). Так происходит, потому что цикл событий не может продолжить исполнение оставшегося JavaScript
-кода, пока работает **блокирующая** операция.
+кода, так как работает **блокирующая** операция.
 
 В Node.js медленный код JavaScript не принято называть **блокирующим**,
 если причиной тому высокая нагрузка кода на процессор, а не ожидание завершения 
 сторонней операции. Синхронные методы в стандартной библиотеке Node.js, 
-которые используют libuv, наиболее часто применимые **блокирующие** операции. 
+которые используют libuv, наиболее часто применяемые **блокирующие** операции. 
 Нативные модули также могут иметь **блокирующие** методы.
 
 Все I/O методы в стандартной библиотеке Node.js предоставляют свои асинхронные версии,
-которые являются **неблокирующими** и которые принимают функции обратного вызова
+которые являются **неблокирующими** и принимают функции обратного вызова
 в качестве аргумента. Некоторые методы также имеют свои **блокирующие** аналоги.
 Названия таких методов закнчиваются на `Sync`. 
 
@@ -56,9 +57,9 @@ fs.readFile('/file.md', (err, data) => {
 ```
 
 Первый пример выглядит проще чем второй, но он имеет один недостаток: вторая строка 
-**блокирует** исполнение любого нижеследующего JavaScript кода, пока весь file.md не будет считан.
-Обратите внимание, если синхронная версия кода сгенерирует исключение,
-его нужно обработать, иначе процесс Node.js "упадёт". В асинхронном варианте
+**блокирует** исполнение любого нижеследующего JavaScript кода, до тех пор, пока
+весь file.md не будет считан. Обратите внимание, если синхронная версия кода сгенерирует
+исключение, его нужно обработать, иначе процесс Node.js "упадёт". В асинхронном варианте
 выбор сгенерировать исключение или нет оставлено на усмотрение программиста.
 
 Давайте немного расширим наш пример:
@@ -84,7 +85,7 @@ moreWork(); // функция будет исполнена до console.log
 
 В первом примере метод `console.log` будет вызван до срабатывания функции `moreWork()`.
 Во втором примере метод `fs.readFile()` является **неблокирующим**, поэтому исполнение
-JavaScript кода может продолжаться не дожидаясь окончания его работы, как следствие 
+JavaScript кода может продолжаться, не дожидаясь окончания его работы. Как следствие 
 функция `moreWork()` сработает раньше `console.log`. Эта возможность — отсутствие необходимости 
 дожидаться окончания чтения файла и т.п. системных вызовов — ключевое
 инженерное решение, которое обеспечивает высокую пропускную способность Node.js.
@@ -93,7 +94,7 @@ JavaScript кода может продолжаться не дожидаясь
 ## Конкурентность и Пропускная Способность
 
 Исполнение JavaScript кода в Node.js является однопоточным. Поэтому, говоря о конкурентности 
-(параллельности вычислений) в Node.js, подразумевают, что после того как цикл событий обработал синхронный код,
+(параллельности вычислений) в Node.js, подразумевают, что после того, как цикл событий обработал синхронный код,
 он способен обработать функции обратного вызова. Подобно сторонним операциям (таким как I/O), 
 любой конкурентный код должен позволять циклу событий продолжать свою работу.
 
@@ -121,7 +122,7 @@ fs.readFile('/file.md', (err, data) => {
 fs.unlinkSync('/file.md');
 ```
 
-В примере выше, метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
+В вышеукзанном примере метод `fs.unlinkSync()`, с высокой вероятностью, будет исполнен до
 `fs.readFile()`. Это приведет к удалению файла до его прочтения. Лучше переписать 
 этот код в **неблокирующем** виде, что гарантирует правильный порядок исполнения методов:
 
@@ -137,7 +138,7 @@ fs.readFile('/file.md', (readFileErr, data) => {
 });
 ```
 
-В примере выше **неблокирующий** вызов метода `fs.unlink()` расположен в функции обратного вызова
+В последнем примере  **неблокирующий** вызов метода `fs.unlink()` расположен в функции обратного вызова
 `fs.readFile()`. Такой подход гарантирует парвильную последовательность операций.