Browse Source

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

fixed bug

fixed

ref:0ffcbbaa39985b94e92d506ffb3cadf0a961634a
bazeltsev 3 years ago
parent
commit
df0d820d39

+ 5 - 5
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)

+ 12 - 12
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, указывается ровно одно кольцо.
 
 ## Примеры конфигураций кластеров
 

+ 2 - 2
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-контейнера.

+ 2 - 2
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 встроенными средствами мониторинга и интроспекции.

+ 4 - 4
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`. В результате, по старой ссылке на статью пользователи начнут попадать на страницу "Обзор" новосозданной директории.
 
 Если без переноса никак не обойтись, то можно применить следующий механизм:
 

+ 6 - 6
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 %}
 

+ 1 - 1
ydb/docs/ru/core/how_to_edit_docs/_includes/index/basic.md

@@ -1,6 +1,6 @@
 ## Основные статьи
 
-- [Руководство по созданию контента](../../content.md) - как нужно технически офрормять статьи
+- [Руководство по созданию контента](../../content.md) - как нужно технически оформлять статьи
 - [Структура тематических каталогов](../../subjects.md) - где нужно размещать тот или иной контент
 - [Сборка документации](../../build.md) - как собирать документацию
 

+ 2 - 2
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".
 При нажатии которой начнется перераспределение.

+ 3 - 3
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`, команда выключить режим.

+ 1 - 1
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**, а ключ загружается из файла, имя которого указано в данной переменной

Some files were not shown because too many files changed in this diff