Исправить ошибки по фидбеку переводчиков

fixed bug

fixed

ref:0ffcbbaa39985b94e92d506ffb3cadf0a961634a

20 files changed, 52 insertions, 52 deletions

diff --git a/ydb/docs/ru/core/concepts/_includes/connect.md b/ydb/docs/ru/core/concepts/_includes/connect.md
index 90a3e7dffb6..ced88597bce 100644
--- a/ydb/docs/ru/core/concepts/_includes/connect.md
+++ b/ydb/docs/ru/core/concepts/_includes/connect.md
@@ -16,7 +16,7 @@
 
 Примеры:
 - `grpc://localhost:7135` - протокол обмена данными без шифрования (gRPC), сервер запущен на том же хосте что и клиент, принимает соединения на порту 7135
-- `grpcs://ydb.somecorp-int.ru` - протокол обмена данными с шифрованием (gRPCs), сервер запущен на хосте ydb.somecorp-int.ru в изолированной корпоративной интрасети компании "SomeCorp", принмимает соединения на порту YDB по умолчанию 2135
+- `grpcs://ydb.somecorp-int.ru` - протокол обмена данными с шифрованием (gRPCs), сервер запущен на хосте ydb.somecorp-int.ru в изолированной корпоративной интрасети компании "SomeCorp", принимает соединения на порту YDB по умолчанию 2135
 - `grpcs://ydb.serverless.yandexcloud.net:2135` - протокол обмена данными с шифрованием (gRPCs), публичный сервер Serverless YDB Yandex.Cloud ydb.serverless.yandexcloud.net, порт 2135
 
 {% include [overlay/endpoint_example.md](connect_overlay/endpoint_example.md) %}
@@ -48,16 +48,16 @@
 При выборе режима аутентификации среди поддерживаемых сервером и окружением, следует руководствоваться следующими рекомендациями:
 
 - **Anonymous** обычно применяется на самостоятельно разворачиваемых локальных кластерах YDB, недоступных по сети
-- **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера, или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдываемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново.
+- **Access Token** применяется при отсутствии поддержки других режимов на стороне сервера, или в настроечных/отладочных целях. Он не требует взаимодействий клиента с IAM. Однако, если IAM поддерживает API для ротации токенов, то обычно выдаваемые таким IAM фиксированные токены имеют короткий срок жизни, что вынуждает регулярно обновлять их в IAM вручную заново.
 - **Refresh Token** может применяться при выполнении разовых ручных операций под персональной учетной записью, например, связанных с обслуживанием данных в БД, выполнением ad-hoc операций в CLI, или запусками приложений с рабочей станции. Такой токен можно получить вручную в IAM один раз на долгий срок, и сохранить в переменной окружения на личной рабочей станции для автоматического применения при запуске CLI без дополнительных параметров аутентификации.
 - **Service Account Key** применяется в первую очередь для приложений, рассчитанных на эксплуатацию в окружениях, где поддерживается режим **Metadata**, при их тестировании вне таких окружений (например, на рабочей станции). Также он может применяться для приложений вне таких окружений, работая как аналог **Refresh Token** для сервисных учетных записей.
 - **Metadata** применяется при разворачивании приложений в облаках. В настоящее время этот режим поддерживается на виртуальных машинах и в Cloud Functions Yandex.Cloud. 
 
-Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка YDB. В частности, для сервиса YDB в Yandex.Cloud применяется Yandex.Passport OAuth и севисные аккаунты Yandex.Cloud. При использовании YDB в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации.
+Токен для указания в параметрах может быть получен в системе IAM, с которой связана конкретная установка YDB. В частности, для сервиса YDB в Yandex.Cloud применяется Yandex.Passport OAuth и сервисные аккаунты Yandex.Cloud. При использовании YDB в корпоративных контекстах могут применяться стандартные для данной организации системы централизованной аутентификации.
 
 {% include [overlay/auth_choose.md](connect_overlay/auth_choose.md) %}
 
-При использовании режимов, предусматривающих обращение клиента YDB к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. По-умолчанию в существующих SDK и CLI производится попытка обращения к API IAM Yandex.Cloud, размещенному на `iam.api.cloud.yandex.net:443`.
+При использовании режимов, предусматривающих обращение клиента YDB к IAM, дополнительно может быть задан URL IAM, предоставляющий API выдачи токенов. по умолчанию в существующих SDK и CLI производится попытка обращения к API IAM Yandex.Cloud, размещенному на `iam.api.cloud.yandex.net:443`.
 
 ## Размещение базы данных {#database}
 
@@ -83,7 +83,7 @@
 
 ## Конфигурация параметров соединения на клиенте {#client-config}
 
-В специализированных статьях описано как определять параметры соединения на клиенте:
+В специализированных статьях описано, как определять параметры соединения на клиенте:
 
 * [Соединение с БД и аутентификация в YDB CLI](../../reference/ydb-cli/connect.md)
 * [Аутентификация в YDB SDK](../../reference/ydb-sdk/auth.md)
diff --git a/ydb/docs/ru/core/deploy/configuration/config.md b/ydb/docs/ru/core/deploy/configuration/config.md
index fa9ef02b47d..5be44a66189 100644
--- a/ydb/docs/ru/core/deploy/configuration/config.md
+++ b/ydb/docs/ru/core/deploy/configuration/config.md
@@ -1,12 +1,12 @@
-# Создание конфигурации для развертываня кластера
+# Создание конфигурации для развертывания кластера
 
 Для того, чтобы развернуть кластер {{ ydb-full-name }} необходимо создать конфигурацию кластера.
 В данном разделе описывается процесс создание конфигурации кластера {{ ydb-full-name }} в YAML формате.
 
 ## Описание конфигурации хостов хранилища
 
-Подготовьте и опишите конфигурацию хостов. Для каждой конфигурации хоста необходимо указать порядковый номер, а так же список путей до дисков и их тип.
-Доступны следущие типы дисков: `SSD`, `NVME`, `ROT` (в данном случае под `ROT` дисками понимаются `HDD` диски).
+Подготовьте и опишите конфигурацию хостов. Для каждой конфигурации хоста необходимо указать порядковый номер, а также список путей до дисков и их тип.
+Доступны следующие типы дисков: `SSD`, `NVME`, `ROT` (в данном случае под `ROT` дисками понимаются `HDD` диски).
 
 Например:
 
@@ -20,7 +20,7 @@ host_configs:
 
 В данном примере мы можем найти ровно один тип хоста, который имеет порядковый номер 1. В данной конфигурации хоста указан ровно один диск, имеющий тип `SSD` и путь `/dev/disk/by-partlabel/ydb_disk_ssd_01`.
 
-Рассмотрим другой пример конфигурации. Предположим что у нас доступно два типа конфигурации хостов, в одной из них доступно 2 диска на хосте, а в другой 3.
+Рассмотрим другой пример конфигурации. Предположим, что у нас доступно два типа конфигурации хостов, в одной из них доступно 2 диска на хосте, а в другой 3.
 Такая конфигурация может быть задана следующим образом:
 
 ```bash
@@ -44,7 +44,7 @@ host_configs:
 ## Описание хостов кластера
 
 Перечислите список хостов, на которых необходимо запустить кластер. Для каждого хоста нужно указать порядковый номер, порт на котором будет запущен `Interconnect` на данном хосте.
-Также нужно указать физическое месторасположение хоста и так же уникальный идентификатор конфигурации хоста.
+Также нужно указать физическое месторасположение хоста и уникальный идентификатор конфигурации хоста.
 
 Например,
 
@@ -69,12 +69,12 @@ hosts:
 
 ## Описание конфигурации домена кластера
 
-Опишите конфигурацию домена кластера. Необходимо указать имя домена и типы хранилища, так же необходимо указать номера хостов, которые будут входить `StateStorage` и параметр `nto_select`.
+Опишите конфигурацию домена кластера. Необходимо указать имя домена и типы хранилища, также необходимо указать номера хостов, которые будут входить `StateStorage` и параметр `nto_select`.
 В конфигурации хранилища необходимо указать имя типа хранилища и тип отказоустойчивости хранилища (`erasure`), который будет использоваться для инициализации хранилища баз данных.
 Также необходимо указать, каким типам дисков данный тип хранилища будет соответствовать. Доступны следующие схемы отказоустойчивости хранилища:
 
-* Конфигурация `block-4-2` предполагает развертывание в 8 доменах отказа (по умолчанию доменом отказа является стойках) и выдерживает отказ не более чем 2 доменов отказа.
-* Конфигурация `mirror-3-dc` предполагает развертывание в 3 ЦОД-ах, в каждом из которых располагается 3 домена отказоустойчивости и выдерживает отказ одного ЦОД-а и еще одного домена отказойстойчивости (стойки)
+* Конфигурация `block-4-2` предполагает развертывание в 8 доменах отказа (по умолчанию доменом отказа является стойка) и выдерживает отказ не более чем 2 доменов отказа.
+* Конфигурация `mirror-3-dc` предполагает развертывание в 3 ЦОД-ах, в каждом из которых располагается 3 домена отказоустойчивости и выдерживает отказ одного ЦОД-а и еще одного домена отказоустойчивости (стойки)
 * Конфигурация `none` не предполагает отказоустойчивости, но удобна для функционального тестирования.
 
 Отказоустойчивость `StateStorage` определяется параметром `nto_select`. Конфигурация `StateStorage` является отказоустойчивой, если любое подмножество из `nto_select` серверов, входящих в `StateStorage`, является отказоустойчивым.
@@ -114,7 +114,7 @@ domains_config:
 ```
 
 В таком случае домен будет иметь имя `Root`, а в нем будет создан тип хранилища `ssd`. Данный тип хранилища будет соответствовать дискам, у которых параметр `type` будет равен значению `SSD`.
-В параметре `erasure_species: none` означениет, что хранилище будет создано без отказоустойчивости.
+В параметре `erasure_species: none` означает, что хранилище будет создано без отказоустойчивости.
 
 В случае, если кластер расположен в трех зонах доступности а в каждой из зон доступно по 3 сервера, то в таком случае конфигурация может такой:
 
@@ -142,9 +142,9 @@ domains_config:
 В таком случае домен будет иметь имя `global`, в нем также будет создан тип хранилища `ssd`. `erasure_species: mirror-3-dc` означает, что хранилище будет создано со схемой отказоустойчивости
 `mirror-3-dc`. `StateStorage` будет растянут на 9 серверов с параметром `nto_select` равным 9.
 
-## Описание конфигураци акторной системы
+## Описание конфигурации акторной системы
 
-Создайте конфигурацию акторной системы. Необходмио указать распределение ядер процессора по пулам из числа доступных ядер в системе.
+Создайте конфигурацию акторной системы. Необходимо указать распределение ядер процессора по пулам из числа доступных ядер в системе.
 
 ```bash
 actor_system_config:
@@ -203,7 +203,7 @@ blob_storage_config:
 ....
 ```
 
-Для конфигурации расположенной в 3 AZ  необходимо указать 3 кольца. Для конфигураций распложенных в одной AZ указавается ровно одно кольцо.
+Для конфигурации расположенной в 3 AZ  необходимо указать 3 кольца. Для конфигураций, расположенных в одной AZ, указывается ровно одно кольцо.
 
 ## Примеры конфигураций кластеров
 
diff --git a/ydb/docs/ru/core/getting_started/_includes/ydb_docker/01_intro.md b/ydb/docs/ru/core/getting_started/_includes/ydb_docker/01_intro.md
index b19ab6c1e0c..5c48a1144a6 100644
--- a/ydb/docs/ru/core/getting_started/_includes/ydb_docker/01_intro.md
+++ b/ydb/docs/ru/core/getting_started/_includes/ydb_docker/01_intro.md
@@ -6,8 +6,8 @@
 
 В контейнере доступны следующие службы:
 
-* `GRPC_PORT` - порт для взаимоидествия с {{ ydb-short-name }} API про gRPC без TLS. По умолчанию, порт равен 2136.
-* `GRPC_TLS_PORT` - порт для взаимоидествия с {{ ydb-short-name }} API про gRPC c поддержкой TLS. Сертификаты генерируются автоматически. Для использования сертификатов необходимо смонтировать на хост-системе директорию `/ydb_cert` Docker-контейра. По умолчанию, порт равен 2135.
+* `GRPC_PORT` - порт для взаимодействия с {{ ydb-short-name }} API по gRPC без TLS. По умолчанию, порт равен 2136.
+* `GRPC_TLS_PORT` - порт для взаимодействия с {{ ydb-short-name }} API по gRPC c поддержкой TLS. Сертификаты генерируются автоматически. Для использования сертификатов необходимо смонтировать на хост-системе директорию `/ydb_cert` Docker-контейнера. По умолчанию, порт равен 2135.
 * `MON_PORT` - порт сo встроенными средствами мониторинга и интроспекции. По умолчанию, порт равен 8765.
 
 Для локального сохранения состояния базы данных на хост-системе монтируется директория `/ydb_data` Docker-контейнера.
diff --git a/ydb/docs/ru/core/getting_started/_includes/ydb_docker/03_start.md b/ydb/docs/ru/core/getting_started/_includes/ydb_docker/03_start.md
index 125f6312817..5f4696c349c 100644
--- a/ydb/docs/ru/core/getting_started/_includes/ydb_docker/03_start.md
+++ b/ydb/docs/ru/core/getting_started/_includes/ydb_docker/03_start.md
@@ -57,6 +57,6 @@ Docker-контейнер {{ ydb-short-name }} поддерживает допо
 * `YDB_USE_IN_MEMORY_PDISKS=true` — включает возможность хранения данных целиком в памяти. В случае если данная опция включена, рестарт контейнера с локальной {{ ydb-short-name }} приведет к полной потере данных.
 * `YDB_DEFAULT_LOG_LEVEL=<уровень>` — задает уровень логирования. Доступные значения уровней: `CRIT`, `ERROR`, `WARN`, `NOTICE`, `INFO`.
 * `YDB_PDISK_SIZE=<NUM>GB` - задает размер диска для хранения данных базы данных. Например, `YDB_PDISK_SIZE=128GB`. Минимальное значение 64GB.
-* `GRPC_PORT` - порт для взаимоидествия с {{ ydb-short-name }} API про gRPC без TLS.
-* `GRPC_TLS_PORT` - порт для взаимоидествия с {{ ydb-short-name }} API про gRPC c поддержкой TLS.
+* `GRPC_PORT` - порт для взаимодействия с {{ ydb-short-name }} API по gRPC без TLS.
+* `GRPC_TLS_PORT` - порт для взаимодействия с {{ ydb-short-name }} API про gRPC c поддержкой TLS.
 * `MON_PORT` - порт сo встроенными средствами мониторинга и интроспекции.
diff --git a/ydb/docs/ru/core/how_to_edit_docs/_includes/content.md b/ydb/docs/ru/core/how_to_edit_docs/_includes/content.md
index 2dcd0cb4673..37e0b6bb162 100644
--- a/ydb/docs/ru/core/how_to_edit_docs/_includes/content.md
+++ b/ydb/docs/ru/core/how_to_edit_docs/_includes/content.md
@@ -29,7 +29,7 @@ OpenSource документация по YDB поддерживает созда
 
 ### Статья "Обзор" {#index}
 
-Каждая тематическиая директория обязана содержать статью "Обзор" с именем файла `index.md`. В статье "Обзор":
+Каждая тематическая директория обязана содержать статью "Обзор" с именем файла `index.md`. В статье "Обзор":
 
 - Описывается о чем рассказывают статьи в данной директории
 - Может даваться перечень ссылок на все или отдельные наиболее важные статьи
@@ -264,7 +264,7 @@ OpenSource документация по YDB поддерживает созда
 
 Текст внутри квадратных скобок, отображаемый при рендеринге документации, должен быть достаточно длинным, чтобы в него можно было легко попасть мышью или пальцем при клике.
 
-Существуют ситуации, ктогда URL ресурса имеет самостоятельную ценность, и должен быть отображен в документации, например, в случае публикации ссылок на репозиторий в github. В таких случаях его необходимо дублировать как внутри квадратных скобок, так и внутри обычных, так как YFM, в отличае от стандартного Markdown, не распознает автоматом URL в тексте:
+Существуют ситуации, когда URL ресурса имеет самостоятельную ценность, и должен быть отображен в документации, например, в случае публикации ссылок на репозиторий в github. В таких случаях его необходимо дублировать как внутри квадратных скобок, так и внутри обычных, так как YFM, в отличие от стандартного Markdown, не распознает автоматом URL в тексте:
 
 ``` md
 Github репозиторий YDB: [https://github.com/ydb-platform/ydb/tree/master/docs](https://github.com/ydb-platform/ydb/tree/master/docs)
@@ -292,11 +292,11 @@ Github репозиторий YDB: [https://github.com/ydb-platform/ydb/tree/mas
 
 ## Обратная совместимость {#compatibility}
 
-Развитие документации не должно приводить к тому, что у её пользователей перестанут работать сохраненные ссылки: как закладки в браузерах, так и зафиксированные на множестве неподконтрольных разработчикам документации ресурах вроде wiki-страниц.
+Развитие документации не должно приводить к тому, что у её пользователей перестанут работать сохраненные ссылки: как закладки в браузерах, так и зафиксированные на множестве неподконтрольных разработчикам документации ресурсах вроде wiki-страниц.
 
 Это означает, что переименовывать статьи, или переносить по директориям в общем случае нельзя.
 
-Если необходимо статью преобразовать в набор статей в пределах новой директории, то для сохранения совместимсти данная директория должна получить то же имя, что раньше было у статьи, а внутри должна появиться статья `index.md`. В результате, по старой ссылке на статью пользователи начнут попадать на страницу "Обзор" новосозданной директории.
+Если необходимо статью преобразовать в набор статей в пределах новой директории, то для сохранения совместимости данная директория должна получить то же имя, что раньше было у статьи, а внутри должна появиться статья `index.md`. В результате, по старой ссылке на статью пользователи начнут попадать на страницу "Обзор" новосозданной директории.
 
 Если без переноса никак не обойтись, то можно применить следующий механизм:
 
diff --git a/ydb/docs/ru/core/how_to_edit_docs/_includes/customize.md b/ydb/docs/ru/core/how_to_edit_docs/_includes/customize.md
index 5354d111343..a90cd98fa1f 100644
--- a/ydb/docs/ru/core/how_to_edit_docs/_includes/customize.md
+++ b/ydb/docs/ru/core/how_to_edit_docs/_includes/customize.md
@@ -7,7 +7,7 @@
 ### Прокси-статьи
 
 Файл со статьей в `core` никогда не содержит контента непосредственно, а только одну или несколько инструкций include блоков этого контента, размещенных в подкаталоге `_includes`. В результате, замена этого файла в `overlay` не приводит к необходимости копирования контента, но позволяет сделать следующие виды его адаптации:
-- Добавить дополнительный контент в начало или нонец статьи
+- Добавить дополнительный контент в начало или конец статьи
 - Вставить дополнительный контент между директивами include
 - Убрать из сборки часть контента исходной статьи, удалив соответствующую директиву include
 
@@ -15,24 +15,24 @@
 
 ### TOC (Table of Contents) - содержание
 
-TOC в документации YDB собирается из множества файлов, размещенных в директориях со статьями, которые иерархически включаются друг в друга директивой include. В результате, каждый из этих файлов может быть переопределен по-отдельности в адаптированной документации.
+TOC в документации YDB собирается из множества файлов, размещенных в директориях со статьями, которые иерархически включаются друг в друга директивой include. В результате каждый из этих файлов может быть переопределен по отдельности в адаптированной документации.
 
 Как и для статей, для файлов TOC применяется подход с прокси, со следующей реализацией:
 
 1. Файл с пунктами меню для core называется `toc_i.yaml`. Он никогда не переопределяется в `overlay`.
 2. Рядом с файлом `toc_i.yaml` в core находится файл `toc_p.yaml`, содержащий ссылку на `toc_i.yaml`, и предназначенный для переопределения в `overlay`.
-3. Включание TOC других разделов делается ссылкой на файл `toc_p.yaml`.
+3. Включение TOC других разделов делается ссылкой на файл `toc_p.yaml`.
 4. Если в некоторой директории не требуется корректировать содержимое TOC, то никакие файлы toc* в `overlay` не создаются, что приводит к использованию toc_p --> toc_i из core при сборке.
 5. Если в некоторой директории требуется скорректировать содержимое toc, то в `overlay` создается файл `toc_p.yaml`, в контент которого включается существовавший в core `- include: { mode: link, path: toc_i.yaml }`, а выше или ниже -- дополнительные пункты для адаптированной сборки.
 
-Хорошей практикой является исключение из toc_i.yaml пункта "Озбор", и включения его непосредственно в toc_p.yaml. Данная статья обязана быть первой в каждом подменю, и всегда имеет одно имя статьи (index.md). Включение отдельным пунктом в toc_p позволяет добавить новые статьи в адаптированной документации перед статьями из core, но с сохранением "Озбор" на первом месте:
+Хорошей практикой является исключение из toc_i.yaml пункта "Обзор", и включения его непосредственно в toc_p.yaml. Данная статья обязана быть первой в каждом подменю, и всегда имеет одно имя статьи (index.md). Включение отдельным пунктом в toc_p позволяет добавить новые статьи в адаптированной документации перед статьями из core, но с сохранением "Обзор" на первом месте:
 
 toc_p.yaml в некотором корпоративном overlay:
 ``` yaml
 items:
 - name: Обзор
   href: index.md
-- name: Роли сотруников
+- name: Роли сотрудников
   href: corp_roles.md
 - include: { mode: link, path: toc_i.yaml }
 - name: Корпоративная авторизация
@@ -47,7 +47,7 @@ items:
 
 {% note warning %}
 
-Имя файла с TOC не может быть `toc.yaml`, так как инструмент сборки ищет файлы с такими именами по всем подкаталогам, и пытается их сам добавить в TOC. Этом вариант добавления в документации YDB не используется, любое включение всегда явное директивой include из другого TOC.
+Имя файла с TOC не может быть `toc.yaml`, так как инструмент сборки ищет файлы с такими именами по всем подкаталогам, и пытается их сам добавить в TOC. Этот вариант добавления в документации YDB не используется, любое включение всегда явное директивой include из другого TOC.
 
 {% endnote %}
 
diff --git a/ydb/docs/ru/core/how_to_edit_docs/_includes/index/basic.md b/ydb/docs/ru/core/how_to_edit_docs/_includes/index/basic.md
index 39b1b24ce6e..862aeff9f88 100644
--- a/ydb/docs/ru/core/how_to_edit_docs/_includes/index/basic.md
+++ b/ydb/docs/ru/core/how_to_edit_docs/_includes/index/basic.md
@@ -1,6 +1,6 @@
 ## Основные статьи
 
-- [Руководство по созданию контента](../../content.md) - как нужно технически офрормять статьи
+- [Руководство по созданию контента](../../content.md) - как нужно технически оформлять статьи
 - [Структура тематических каталогов](../../subjects.md) - где нужно размещать тот или иной контент
 - [Сборка документации](../../build.md) - как собирать документацию
 
diff --git a/ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md b/ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md
index b5dd7d0f99b..f2e064c271f 100644
--- a/ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md
+++ b/ydb/docs/ru/core/maintenance/embedded_monitoring/hive.md
@@ -35,7 +35,7 @@ Hive бывает общим на кластер и тенантный.
   * **mem** - потребление ОЗУ таблетками
   * **net** - потребление полосы таблетками
 * **Active** - включение/отключение узла для перевоза таблеток на данный узел
-* **Freeze** - запрет для таблеткок подниматься на других узлах
+* **Freeze** - запрет для таблеток подниматься на других узлах
 * **Kick** - перевоз всех таблеток разом с узла
 * **Drain** - плавный перевоз всех таблеток с узла
 
@@ -65,5 +65,5 @@ Hive бывает общим на кластер и тенантный.
 * **Percent** - процент от общего количества каналов таблеток которые переедут в результате балансировки
 * **Inflight** - количество одновременно переезжающих на другие группы таблеток
 
-После указания всех параметров, следует нажать сначала "Query", который покажет количество каналов попавшие под переезде и разблокирует кнопку "Reassign".
+После указания всех параметров, следует нажать сначала "Query", который покажет количество каналов, попавших под переезд, и разблокирует кнопку "Reassign".
 При нажатии которой начнется перераспределение.
diff --git a/ydb/docs/ru/core/maintenance/manual/selfheal.md b/ydb/docs/ru/core/maintenance/manual/selfheal.md
index 827be98fbb6..9bbee42c3ef 100644
--- a/ydb/docs/ru/core/maintenance/manual/selfheal.md
+++ b/ydb/docs/ru/core/maintenance/manual/selfheal.md
@@ -72,7 +72,7 @@ viewer -> Cluster Management System -> CmsConfigItems
     Дальше идут настройки количества циклов обновления, через которое CMS будет изменять Статус диска. Если Состояние диска Normal, то диск переводится в Статус ACTIVE, в остальных состояниях диск переводится в статус FAULTY. Значение 0 выключает изменение Статуса для состояния (так сделано для Unknown по умолчанию).
     Например, при настройках по умолчанию, если CMS наблюдает состояние диска Initial на протяжении 5 циклов Status update interval по 60 с каждый, Статус диска будет изменен на FAULTY.
 * **Default state limit** - Для Состояний, для которых нет указана настройка, может использоваться это значение "по умолчанию". Для неизвестных Состояний PDisk, для которых нет настройки, тоже используется это значение. Это значение используется если значение не задано для Состояний Initial, InitialFormatRead, InitialSysLogRead, InitialCommonLogRead, Normal.
-* **Initail** - PDisk начинает инициализацию. Переход в FAULTY.
+* **Initial** - PDisk начинает инициализацию. Переход в FAULTY.
 * **InitialFormatRead** - PDisk читает свою запись формата. Переход в FAULTY.
 * **InitialFormatReadError** - PDisk получил ошибку при чтении своей записи формата. Переход в FAULTY.
 * **InitialSysLogRead** - PDisk читает системный лог. Переход в FAULTY.
@@ -93,7 +93,7 @@ viewer -> Cluster Management System -> CmsConfigItems
 
 При выключенных дисках донорах, при перевозе VDisk'а, его данные теряются, и их приходится восстанавливать согласно выбранному erasure.
 
-Операция восстановления дороже, чем обычный перевоз данных. Так же происходит потеря данных, что может повлечь за собой потерю данных при выходе за рамки модели отказа.
+Операция восстановления дороже, чем обычный перевоз данных. Также происходит потеря данных, что может повлечь за собой потерю данных при выходе за рамки модели отказа.
 
 Для предотвращения выше перечисленных проблем, существуют диски доноры.
 
@@ -107,4 +107,4 @@ viewer -> Cluster Management System -> CmsConfigItems
 
 `$ kikimr admin bs config invoke --proto 'Command { UpdateSettings { EnableDonorMode: true } }'`
 
-Аналогично при изменение настройки на `false`, команда выключить режим.
+Аналогично при изменении настройки на `false`, команда выключить режим.
diff --git a/ydb/docs/ru/core/reference/ydb-cli/_includes/auth/env_cloud.md b/ydb/docs/ru/core/reference/ydb-cli/_includes/auth/env_cloud.md
index cb3972f5736..faa85ce7f90 100644
--- a/ydb/docs/ru/core/reference/ydb-cli/_includes/auth/env_cloud.md
+++ b/ydb/docs/ru/core/reference/ydb-cli/_includes/auth/env_cloud.md
@@ -1,4 +1,4 @@
 - Если задано значение переменной окружения `IAM_TOKEN`, то используется режим аутентификации **Access Token**, в который передается значение данной переменной
-- Иначе, если задано значение переменной окружения `YC_TOKEN`, то используется режим аутентификаии **Refresh Token**, а токен для передачи на IAM endpoint при перезапросе берется из значения этой переменной
+- Иначе, если задано значение переменной окружения `YC_TOKEN`, то используется режим аутентификации **Refresh Token**, а токен для передачи на IAM endpoint при перезапросе берется из значения этой переменной
 - Иначе, если задано значение переменной окружения `USE_METADATA_CREDENTIALS`, равное 1, то используется режим аутентификации **Metadata**
 - Иначе, если задано значение переменной окружения `SA_KEY_FILE`, то используется режим аутентификации **Service Account Key**, а ключ загружается из файла, имя которого указано в данной переменной
diff --git a/ydb/docs/ru/core/reference/ydb-cli/_includes/commands.md b/ydb/docs/ru/core/reference/ydb-cli/_includes/commands.md
index e0d65dba4ff..1343a2a1d62 100644
--- a/ydb/docs/ru/core/reference/ydb-cli/_includes/commands.md
+++ b/ydb/docs/ru/core/reference/ydb-cli/_includes/commands.md
@@ -65,7 +65,7 @@ table ttl drop  | Удаление параметров TTL
 table ttl set  | Установка параметров TTL
 tools copy | Копирование таблиц
 tools dump | Выгрузка директории или таблицы в файловую систему
-[tools rename](../commands/tools/rename.md) | Переменование таблиц
+[tools rename](../commands/tools/rename.md) | Переименование таблиц
 tools restore | Восстановление из файловой системы
 {% if ydb-cli == "ydb" %}
 [update](../commands/service.md) | Обновление YDB CLI
diff --git a/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/operations-index/intro.md b/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/operations-index/intro.md
index 8da70e1eef8..2755f41c533 100644
--- a/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/operations-index/intro.md
+++ b/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/operations-index/intro.md
@@ -1,3 +1,3 @@
 # Работа со вторичными индексами
 
-В разделе описано как управлять вторичными индексами. Добавление вторичного индекса выполняется в асинхронном режиме. После запуска такой команды {{ ydb-short-name }} CLI сразу выдает информацию об операции и дает пользователю возможность продолжить работу.
+В разделе описано, как управлять вторичными индексами. Добавление вторичного индекса выполняется в асинхронном режиме. После запуска такой команды {{ ydb-short-name }} CLI сразу выдает информацию об операции и дает пользователю возможность продолжить работу.
diff --git a/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/tools/rename.md b/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/tools/rename.md
index 415d4dd0abe..ad2333b4ed7 100644
--- a/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/tools/rename.md
+++ b/ydb/docs/ru/core/reference/ydb-cli/commands/_includes/tools/rename.md
@@ -23,14 +23,14 @@
 
 Имя параметра | Описание параметра
 ---|---
-`--item <свойство>=<значение>,...` | Описание операции переменования. Может быть указан несколько раз, если необходимо выполнить несколько операций переименования в одной транзакции.</br></br>Обязательные свойства:</br><ul><li>`source`, `src`, `s` — путь до таблицы источника.</li><li>`destination`, `dst`, `d` —  путь до таблицы назначения. Если путь назначения содержит директории, они должны быть [созданы заранее](../../dir.md#mkdir).</li></ul>Дополнительные свойства:</br><ul> <li>`replace`, `force` — перезаписывать таблицу назначения. Если значение `True`, то таблица назначения будет перезаписана, а существованые в ней данные удалены. `False` — если таблица назначения существует, то будет выдана ошибка, и транзакция переименования будет целиком откачена. Значение по умолчанию: `False`.</li></ul>
+`--item <свойство>=<значение>,...` | Описание операции переименования. Может быть указан несколько раз, если необходимо выполнить несколько операций переименования в одной транзакции.</br></br>Обязательные свойства:</br><ul><li>`source`, `src`, `s` — путь до таблицы источника.</li><li>`destination`, `dst`, `d` —  путь до таблицы назначения. Если путь назначения содержит директории, они должны быть [созданы заранее](../../dir.md#mkdir).</li></ul>Дополнительные свойства:</br><ul> <li>`replace`, `force` — перезаписывать таблицу назначения. Если значение `True`, то таблица назначения будет перезаписана, а существующие в ней данные удалены. `False` — если таблица назначения существует, то будет выдана ошибка, и транзакция переименования будет целиком откачена. Значение по умолчанию: `False`.</li></ul>
 `--timeout <значение>` | Таймаут операции, мс. 
 
 При включении нескольких операций переименования в один вызов `tools rename` они исполняются в заданном порядке, но в рамках одной транзакции, что позволяет ротировать таблицу под нагрузкой без потери данных: первой операцией идет переименование рабочей таблицы в резервную, второй -- переименование новой таблицы в рабочую.
 
 ## Примеры {#examples}
 
-- Переменование одной таблицы:
+- Переименование одной таблицы:
 
   ```bash
   {{ ydb-cli }} tools rename --item src=old_name,dst=new_name
diff --git a/ydb/docs/ru/core/reference/ydb-sdk/example/_includes/example-go.md b/ydb/docs/ru/core/reference/ydb-sdk/example/_includes/example-go.md
index 2235b3c697f..c4157512c90 100644
--- a/ydb/docs/ru/core/reference/ydb-sdk/example/_includes/example-go.md
+++ b/ydb/docs/ru/core/reference/ydb-sdk/example/_includes/example-go.md
@@ -21,7 +21,7 @@ import (
   "github.com/ydb-platform/ydb-go-sdk/v3/table/options" // для работы с table-сервисом
   "github.com/ydb-platform/ydb-go-sdk/v3/table/result" // для работы с table-сервисом
   "github.com/ydb-platform/ydb-go-sdk/v3/table/result/named" // для работы с table-сервисом
-  "github.com/ydb-platform/ydb-go-sdk-auth-environ" // для аутентификации с использованием перменных окружения
+  "github.com/ydb-platform/ydb-go-sdk-auth-environ" // для аутентификации с использованием переменных окружения
   "github.com/ydb-platform/ydb-go-yc" // для работы с YDB в Яндекс Облаке
 )
 ```
diff --git a/ydb/docs/ru/core/reference/ydb-sdk/recipes/auth/_includes/index.md b/ydb/docs/ru/core/reference/ydb-sdk/recipes/auth/_includes/index.md
index 28ec41a6545..2763d3c1076 100644
--- a/ydb/docs/ru/core/reference/ydb-sdk/recipes/auth/_includes/index.md
+++ b/ydb/docs/ru/core/reference/ydb-sdk/recipes/auth/_includes/index.md
@@ -4,4 +4,4 @@
 
 `Ydb` поддерживает несколько способов аутентификации подключения к серверной стороне. Каждый из них, как правило, специфичен для конкретной пары окружений: где находится клиентское приложение (в доверенной зоне `Ydb` или вне ее) и серверная часть `Ydb` (докер-контейнер, yandex.Cloud, data cloud, установка на отдельном кластере)
 
-В данном разделе содержатся рецепты кода с настройкой аутентификации в разных `Ydb SDK`. Общее описание принципов аутентификации в SDK пожно прочитать в статье [Аутентификация в SDK](../../../auth.md).
+В данном разделе содержатся рецепты кода с настройкой аутентификации в разных `Ydb SDK`. Общее описание принципов аутентификации в SDK можно прочитать в статье [Аутентификация в SDK](../../../auth.md).
diff --git a/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md b/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
index b8b2f00c935..b48644de259 100644
--- a/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
+++ b/ydb/docs/ru/core/reference/ydb-sdk/recipes/session_pool_limit/index.md
@@ -5,8 +5,8 @@
 Размер пула сессий на клиенте влияет на потребление ресурсов (память, процессор) на серверной стороне YDB.
 Простая математика: если `1000` клиентов одной базы данных имеют по `1000` сессий, то на серверной стороне создается `100000` акторов (воркеров, исполнителей сессий). Если не лимитировать количество сессий на клиенте, то можно получить "задумчивый" кластер в полу-аварийном состоянии.
 По умолчанию в `Ydb SDK` установлен лимит в `50` сессий.
-Хорошая рекомендация - устаналивать лимит на количество сессий на клиенте в минимальное-необходимое для штатной работы клиентского приложения. Следует иметь в виду, что сессия однопоточная что на серверной стороне, что на клиентской. Соответственно, если для расчетной нагрузки приложению необходимо выполнять  `1000` одновременных запросов (`inflight`) в `Ydb` - значит следует установить лимит в `1000` сессий.
-Тут надо отличать расчетный `RPS` (requests per second, запросов в секунду) и `inflight`. В первом случае это общее колличество выполненных запросов к `Ydb` за `1` секунду. Например, для `RPS`=`10000` и средним `latency` (задержка исполнения запроса) в `100`мс достаточно установить лимит в `1000` сессий. То есть каждая сессия за расчетную секунду выполнит в среднем `10` последовательных запросов.
+Хорошая рекомендация - устанавливать лимит на количество сессий на клиенте в минимальное-необходимое для штатной работы клиентского приложения. Следует иметь в виду, что сессия однопоточная что на серверной стороне, что на клиентской. Соответственно, если для расчетной нагрузки приложению необходимо выполнять  `1000` одновременных запросов (`inflight`) в `Ydb` - значит следует установить лимит в `1000` сессий.
+Тут надо отличать расчетный `RPS` (requests per second, запросов в секунду) и `inflight`. В первом случае это общее количество выполненных запросов к `Ydb` за `1` секунду. Например, для `RPS`=`10000` и средним `latency` (задержка исполнения запроса) в `100`мс достаточно установить лимит в `1000` сессий. То есть каждая сессия за расчетную секунду выполнит в среднем `10` последовательных запросов.
 
 Ниже приведены примеры кода установки лимита на пул сессий в разных `Ydb SDK`
 
diff --git a/ydb/docs/ru/core/troubleshooting/_includes/system_views/distributed_storage.md b/ydb/docs/ru/core/troubleshooting/_includes/system_views/distributed_storage.md
index e720208c582..745fea75f74 100644
--- a/ydb/docs/ru/core/troubleshooting/_includes/system_views/distributed_storage.md
+++ b/ydb/docs/ru/core/troubleshooting/_includes/system_views/distributed_storage.md
@@ -1,6 +1,6 @@
 ## Distributed Storage
 
-Информация о работе распределённого хранилища содержится в нескольких взаимосвязаных таблицах, каждая из которых отвечает за описание своей сущности, а именно:
+Информация о работе распределённого хранилища содержится в нескольких взаимосвязанных таблицах, каждая из которых отвечает за описание своей сущности, а именно:
 * PDisk
 * VSlot
 * Group
@@ -17,7 +17,7 @@
 | Type                  | String    |          | Тип носителя (ROT, SSD, NVME)                                                                                                                                    |
 | Kind                  | Uint64    |          | Числовой идентификатор, задаваемый пользователем, который нужен для объединения дисков с одинаковым типом носителя в разные подгруппы                            |
 | Path                  | String    |          | Путь к блочному устройству внутри машины                                                                                                                         |
-| Guid                  | Uint64    |          | Уникальный идентификатор, генерируемый случайно при добавлении диска в систему, предназначенный для преотвращения потери данных в случае перемены дисков местами |
+| Guid                  | Uint64    |          | Уникальный идентификатор, генерируемый случайно при добавлении диска в систему, предназначенный для предотвращения потери данных в случае перемены дисков местами |
 | BoxId                 | Uint64    |          | Идентификатор Box, в который входит данный PDisk                                                                                                                 |
 | SharedWithOs          | Bool      |          | Булевой признак, который используется для фильтрации дисков при создании новых групп                                                                             |
 | ReadCentric           | Bool      |          | Булевой признак, который используется для фильтрации дисков при создании новых групп                                                                             |
@@ -76,7 +76,7 @@
 | Name           | String  |          | Название пула хранения, задаваемое пользователем (используется при связывании таблеток и пулов хранения)    |
 | Generation     | Uint64  |          | Поколение конфигурации пула хранения (количество изменений)                                                 |
 | ErasureSpecies | String  |          | Режим кодирования избыточности для всех групп внутри данного пула хранения                                  |
-| VDiskKind      | String  |          | Предустаноленная настройка режима работы всех VDisk для данного пула хранения                               |
+| VDiskKind      | String  |          | Предустановленная настройка режима работы всех VDisk для данного пула хранения                               |
 | Kind           | String  |          | Строковое описание предназначения пула, задаваемое пользователем, также может использоваться для фильтрации |
 | NumGroups      | Uint32  |          | Количество групп внутри данного пула хранения                                                               |
 | EncryptionMode | Uint32  |          | Настройка шифрования данных для всех групп (аналогично ds_groups.EncryptionMode)                            |
diff --git a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/alter_table.md b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/alter_table.md
index 95dec82b1cc..87254812086 100644
--- a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/alter_table.md
+++ b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/alter_table.md
@@ -55,7 +55,7 @@ ALTER TABLE old_table_name RENAME TO new_table_name;
 
 Если в YQL запросе содержится несколько команд `ALTER TABLE ... RENAME TO ...`, то каждая будет выполнена в режиме автокоммита в отдельной транзакции. С точки зрения внешнего процесса, таблицы будут переименованы последовательно одна за другой. Чтобы переименовать несколько таблиц в одной транзакции, используйте специализированные методы, доступные в CLI и SDK.
 
-Переменование может использоваться для перемещения таблицы из одной директории внутри БД в другую, например:
+Переименование может использоваться для перемещения таблицы из одной директории внутри БД в другую, например:
 
 ``` sql
 ALTER TABLE `table1` RENAME TO `/backup/table1`;
diff --git a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/group_by/session_window.md b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/group_by/session_window.md
index 6b15f69a7e1..cccff86f6d2 100644
--- a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/group_by/session_window.md
+++ b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/syntax/_includes/group_by/session_window.md
@@ -43,7 +43,7 @@ GROUP BY user, SessionWindow(<time_expr>, <timeout_expr>) AS session_start
 $max_len = 1000; -- максимальная длина сессии
 $timeout = 100; -- таймаут (timeout_expr в упрощенном варианте SessionWindow)
 
-$init = ($row) -> (AsTuple($row.ts, $row.ts)); -- состояние сеессии - тапл из 1) значения временной колонки ts на первой строчке сессии и 2) на текущей строчке
+$init = ($row) -> (AsTuple($row.ts, $row.ts)); -- состояние сессии - тапл из 1) значения временной колонки ts на первой строчке сессии и 2) на текущей строчке
 $update = ($row, $state) -> {
   $is_end_session = $row.ts - $state.0 > $max_len OR $row.ts - $state.1 > $timeout;
   $new_state = AsTuple(IF($is_end_session, $row.ts, $state.0), $row.ts);
diff --git a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/types/_includes/datatypes_primitive_datetime.md b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/types/_includes/datatypes_primitive_datetime.md
index ecb010112f7..5f904b40ac3 100644
--- a/ydb/docs/ru/core/yql/reference/yql-docs-core-2/types/_includes/datatypes_primitive_datetime.md
+++ b/ydb/docs/ru/core/yql/reference/yql-docs-core-2/types/_includes/datatypes_primitive_datetime.md
@@ -1,6 +1,6 @@
 Тип | Описание | Примечания
 ----- | ----- | -----
-`Date` | Дата, точность до дней | Диапазон значений для всех временных типов кроме `Interval` - от нуля часов 01.01.1970 до нуля часов 01.01.2106. Внутреннее предсталение `Date` – беззнаковое целое 16 бит  | 
+`Date` | Дата, точность до дней | Диапазон значений для всех временных типов кроме `Interval` - от нуля часов 01.01.1970 до нуля часов 01.01.2106. Внутреннее представление `Date` – беззнаковое целое 16 бит  | 
 `Datetime` | Дата/время, точность до секунд | Внутреннее представление – беззнаковое целое 32 бит |
 `Timestamp` | Дата/время, точность до микросекунд | Внутреннее представление – беззнаковое целое 64 бит |
 `Interval` | Интервал времени (знаковый), точность до микросекунд | Диапазон значений – от -136 лет до +136 лет. Внутреннее представление – знаковое целое 64 бит. {% if feature_map_tables %}Не может быть использован в первичном ключе{% endif %}