More updates to Russian guide translation

docs/guide-ru/rest-routing.md

@@ -73,6 +73,19 @@
 ```
 
 Как вы могли заметить, ID контроллера `user` в этих точках входа используется в форме множественного числа (как `users`).
-Это происходит потому, что [[yii\rest\UrlRule]] автоматически приводит идентификаторы контроллеров к множественной форме для использования в точках входа.
-Вы можете отключить такое поведение, назначив свойству [[yii\rest\UrlRule::pluralize]] значение false, или, если вы хотите использовать 
-какие-то особые имена, вы можете настроить свойство [[yii\rest\UrlRule::controller]].
+Это происходит потому, что [[yii\rest\UrlRule]] автоматически приводит идентификаторы контроллеров к множественной форме.
+Вы можете отключить такое поведение, назначив свойству [[yii\rest\UrlRule::pluralize]] значение false.
+
+> Информация: Приведение ID контроллера к множественной форме производится в методе [[yii\helpers\Inflector::pluralize()]].
+  При этом соблюдаются правила английского языка. Например, `box` будет преобразован в `boxes`, а не в `boxs`.
+
+В том случае, если автоматическое приведение к множественному числу вам не подходит, вы можете настроить 
+свойство [[yii\rest\UrlRule::controller]], где указать явное соответствие имени в URL и ID контроллера.
+Например, код ниже ставит в соответствие имя `u` и ID контроллера `user`.  
+
+```php
+[
+    'class' => 'yii\rest\UrlRule',
+    'controller' => ['u' => 'user'],
+]
+```

docs/guide-ru/rest-versioning.md

@@ -1,17 +1,28 @@
 Версионирование
 ===============
 
-Свои API вам следует версионировать. В отличие от Web-приложений, где у вас есть полный контроль и над серверным, и над клиентским кодом,
-при работе с API у вас обычно нет контроля над клиентским кодом, работающим с вашими API. Поэтому всегда, когда это только возможно, 
-должна поддерживаться обратная совместимость API, и если в API должны быть внесены изменения, ломающие обратную совместимость,
-следует увеличить номер версии. Почитайте про [семантическое версионирование](http://semver.org/)
-для получения более подробной информации о возможных способах нумерации различных версий ваших API.
+Хороший API должен быть *версионирован*: изменения и новые возможности реализуются в новых версиях API, а не в одной и
+той же версии. В отличие от Web-приложений, где у вас есть полный контроль и над серверным, и над клиентским кодом,
+API используются клиентами, код которых вы не контролируете. Поэтому, обратная совместимость (BC) должна по возможности
+сохраняться. Если ломающее её изменение необходимо, делать его нужно в новой версии API. Существующие клиенты могут
+продолжать использовать старую, совместимую с ними версию API. Новые или обновлённые клиенты могут использовать новую
+версию. 
+
 
 Общей практикой при реализации версионирования API является включение номера версии в URL-адрес вызова API-метода.
 Например, `http://example.com/v1/users` означает вызов API `/users` версии 1. Другой способ версионирования API,
 получивший недавно широкое распространение, состоит в добавлении номера версии в HTTP-заголовки запроса, 
 обычно в заголовок `Accept`:
 
+> Подсказка: Чтобы узнать больше о выборе версий обратитесь к [Semantic Versioning](http://semver.org/).
+
+Один из типичных способов реализации версионирования — указание версии в URL. Например, `http://example.com/v1/users`
+соответствует `/users` версии 1. 
+
+Ещё один способ, ставший сейчас популярным — передача версии через заголовок HTTP. Чаще всего для этого используется
+заголовок `Accept`:
+
+
 ```
 // как параметр
 Accept: application/json; version=v1
@@ -51,13 +62,15 @@ api/
             models/
                 User.php
                 Post.php
+            Module.php
         v2/
             controllers/
                 UserController.php
                 PostController.php
             models/
                 User.php
                 Post.php
+            Module.php
 ```
 
 Конфигурация вашего приложения могла бы выглядеть так:
@@ -66,10 +79,10 @@ api/
 return [
     'modules' => [
         'v1' => [
-            'basePath' => '@app/modules/v1',
+            'class' => 'app\modules\v1\Module',
         ],
         'v2' => [
-            'basePath' => '@app/modules/v2',
+            'class' => 'app\modules\v2\Module',
         ],
     ],
     'components' => [
@@ -89,7 +102,7 @@ return [
 В результате `http://example.com/v1/users` возвратит список пользователей API версии 1, в то время как
 `http://example.com/v2/users` вернет список пользователей версии 2.
 
-При использовании модулей код API различных мажорных версий может быть хорошо изолирован. И по-прежнему возможно
+Благодаря использованию модулей код API различных мажорных версий может быть хорошо изолирован. И по-прежнему возможно
 повторное использование кода между модулями через общие базовые классы и другие разделяемые классы.
 
 Для работы с минорными номерами версий вы можете использовать преимущества согласования содержимого,
@@ -100,8 +113,8 @@ return [
 Например, если запрос посылается с HTTP-заголовком `Accept: application/json; version=v1`, то после согласования содержимого
 свойство [[yii\web\Response::acceptParams]] будет содержать значение `['version' => 'v1']`.
 
-На основе информации о версии из `acceptParams` вы можете написать условный код в таких местах,
-как действия, классы ресурсов, сериализаторы и т.д.
+На основе информации о версии из `acceptParams` вы можете выбирать поведение в действиях, классах ресурсов,
+сериализаторах и т.д.
 
 Так как минорные версии требуют поддержания обратной совместимости, будем надеяться, что в вашем коде не так уж много
 проверок на номер версии. В противном случае велики шансы, что вам нужна новая мажорная версия.

docs/guide-ru/runtime-bootstrapping.md

@@ -27,7 +27,11 @@
 участвовать в полном жизненном цикле процесса обработки запроса. Например, если модуль должен зарегистрировать дополнительные правила парсинга URL, 
 то он должен быть указан в свойстве [предзагрузка](structure-applications.md#bootstrap), чтобы новые правила URL были учтены при обработке запроса.
 
-В производственном режиме включите байткод кэшеры, такие как APC, для минимизации времени необходимого на подключение и парсинг php файлов.
+В производственном режиме включите байткод кэшеры, такие как [PHP OPcache] или [APC], для минимизации времени 
+подключения и парсинг php файлов.
+
+[PHP OPcache]: http://php.net/manual/ru/intro.opcache.php
+[APC]: http://php.net/manual/ru/book.apc.php
 
 Некоторые большие приложения могут иметь сложную [конфигурацию](concept-configurations.md), которая разделена на несколько мелких файлов.
 Если это тот самый случай, возможно вам стоит кэшировать весь конфигурационный файл и загружать его прямо из кэша до создания объекта