KIKIMR-14621 rebase

ydb docs eng review getting_started base-basic revert

ydb docs eng review - concepts

ydb docs english review - getting_started/how_to_edit_docs

ref:ef1fd27dde83950a71ec96a4743412b2d03235ec

20 files changed, 71 insertions, 70 deletions

diff --git a/ydb/docs/en/core/concepts/_includes/connect.md b/ydb/docs/en/core/concepts/_includes/connect.md
index ecd7d3dbf7c..abeea412c98 100644
--- a/ydb/docs/en/core/concepts/_includes/connect.md
+++ b/ydb/docs/en/core/concepts/_includes/connect.md
@@ -10,23 +10,23 @@ To connect to the {{ ydb-short-name }} database from the {{ ydb-short-name }} CL
 
 ## Endpoint {#endpoint}
 
-An endpoint is a string structured as `protocol://host:port` and provided by a {{ ydb-short-name }} cluster owner for proper routing of client queries to its databases by way of a network infrastructure as well as for proper network connections. Cloud databases display the endpoint in the management console on the requisite DB page and also normally send it via the cloud provider's CLI. In corporate environments, endpoint names {{ ydb-short-name }} are provided by the administration team or obtained in the internal cloud management console.
+An endpoint is a string structured as `protocol://host:port` and provided by a {{ ydb-short-name }} cluster owner for proper routing of client queries to its databases over the network infrastructure as well as for network connection initialization. Cloud databases display the endpoint in the management console on the required DB page and also normally provide it via the cloud CLI. In corporate environments, endpoint names {{ ydb-short-name }} are provided by the administration team or obtained in the internal cloud management console.
 
 {% include [overlay/endpoint.md](connect_overlay/endpoint.md) %}
 
 Examples:
 
-* `grpc://localhost:7135` is an unencrypted data interchange protocol (gRPC) with the server running on port 7135 of the same host as the client.
-* `grpcs://ydb.somecorp-int.ru` is an encrypted data interchange protocol (gRPCs) with the server running on a host called ydb.somecorp-int.ru on the SomeCorp isolated corporate network and listening for connections on YDB default port 2135.
-* `grpcs://ydb.serverless.yandexcloud.net:2135` is an encrypted data interchange protocol (gRPCs), public {{ yandex-cloud }} Serverless YDB server at ydb.serverless.yandexcloud.net, port 2135.
+* `grpc://localhost:7135` is an unencrypted data transfer protocol (gRPC) with the server running on port 7135 of the same host as the client.
+* `grpcs://ydb.somecorp-int.ru` is an encrypted data transfer protocol (gRPCs) with the server running on a host called ydb.somecorp-int.ru on the SomeCorp isolated corporate network and listening for connections on YDB default port 2135.
+* `grpcs://ydb.serverless.yandexcloud.net:2135` is an encrypted data transfer protocol (gRPCs), public {{ yandex-cloud }} Serverless YDB server at ydb.serverless.yandexcloud.net, port 2135.
 
 {% include [overlay/endpoint_example.md](connect_overlay/endpoint_example.md) %}
 
 ## Authentication information {#auth}
 
-Once a network connection is established, the server starts to accept client requests with authentication information for processing. The server uses it to identify the client's account and to verify access to execute the query.
+Once a network connection is established, the server starts to accept client requests for processing supplied with authentication information. The server uses it to identify the client's account and to verify access to execute the query.
 
-The basic operation model assumes that there is a separate system for managing credentials and permissions: [IAM (Identity and Access Management)](https://en.wikipedia.org/wiki/Identity_management). IAM issues a token linked to the account, which the {{ ydb-short-name }} client passes to the server along with a request. The {{ ydb-short-name }} server accesses IAM to verify the token and permissions to perform the requested operation and caches the result.
+The primary operation model assumes that there is a separate system for managing credentials and permissions: [IAM (Identity and Access Management)](https://en.wikipedia.org/wiki/Identity_management). IAM issues a token linked to the account, which the {{ ydb-short-name }} client passes to the server along with a request. The {{ ydb-short-name }} server accesses IAM to verify the token and permissions to perform the requested operation and caches the result.
 
 {{ ydb-short-name }} also supports username and password based authentication without interacting with IAM, but using this model in practice is limited to simple configurations, primarily local ones.
 
@@ -38,7 +38,7 @@ The basic operation model assumes that there is a separate system for managing c
 * **Access Token**: Fixed token set as a parameter for the client (SDK or CLI) and passed in requests.
 * **Refresh Token**: [OAuth token](https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/) of a user's personal account set as a parameter for the client (SDK or CLI), which the client periodically sends to the IAM API in the background to rotate a token (obtain a new one) to pass in requests.
 * **Service Account Key**: Service account attributes and a signature key set as parameters for the client (SDK or CLI), which the client periodically sends to the IAM API in the background to rotate a token (obtain a new one) to pass in requests.
-* **Metadata**: Client (SDK or CLI) periodically accessing a local service to rotate a token (obtain a new one) to pass in requests.
+* **Metadata**: Client (SDK or CLI) periodically accesses a local service to rotate a token (obtain a new one) to pass in requests.
 
 Any owner of a valid token can get access to perform operations; therefore, the principal objective of the security system is to ensure that a token remains private and to protect it from being compromised.
 
@@ -49,7 +49,7 @@ The highest level of security and performance is provided when using the **Metad
 When choosing the authentication mode among those supported by the server and environment, follow the recommendations below:
 
 * **You would normally use Anonymous** on self-deployed local {{ ydb-short-name }} clusters that are inaccessible over the network.
-* **You would use Access Token** when other modes are not supported server side or for setup/debugging purposes. It does not require that the client access IAM. However, if the IAM system supports an API for token rotation, fixed tokens issued by this IAM usually have a short validity period, which makes it necessary to update them manually in the IAM system on a regular basis.
+* **You would use Access Token** when other modes are not supported on server side or for setup/debugging purposes. It does not require that the client access IAM. However, if the IAM system supports an API for token rotation, fixed tokens issued by this IAM usually have a short validity period, which makes it necessary to update them manually in the IAM system on a regular basis.
 * **Refresh Token** can be used when performing one-time manual operations under a personal account, for example, related to DB data maintenance, performing ad-hoc operations in the CLI, or running applications from a workstation. You can manually obtain this token from IAM once to have it last a long time and save it in an environment variable on a personal workstation to use automatically and with no additional authentication parameters on CLI launch.
 * **Service Account Key** is mainly used for applications designed to run in environments where the **Metadata** mode is supported, when testing them outside these environments (for example, on a workstation). It can also be used for applications outside these environments, working as an analog of **Refresh Token** for service accounts. Unlike a personal account, service account access objects and roles can be restricted.
 * **Metadata** is used when deploying applications in clouds. Currently, this mode is supported on virtual machines and in {{ sf-name }} {{ yandex-cloud }}.
@@ -62,11 +62,11 @@ When using modes in which the {{ ydb-short-name }} client accesses the IAM syste
 
 ## Database location {#database}
 
-Database location (`database`) is a string that defines where the queried database is located in the {{ ydb-short-name }} cluster. Has the format [file paths]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Path_(computing)){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Путь_к_файлу){% endif %} and uses the `/` character as separator. It always starts with a `/`.
+Database location (`database`) is a string that defines where the queried database is located in the {{ ydb-short-name }} cluster. It has the [path to file]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Path_(computing)){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Путь_к_файлу){% endif %} format and uses the `/` character as separator. It always starts with a `/`.
 
 A {{ ydb-short-name }} cluster may have multiple databases deployed, and their location is defined by the cluster configuration. Like the endpoint, `database` for cloud databases is displayed in the management console on the desired database page, and can also be obtained via the CLI of the cloud provider.
 
-For cloud solutions, databases are created and hosted on the {{ ydb-short-name }} cluster in self-service mode, with no need in attendance of the cluster owner or administrators.
+For cloud solutions, databases are created and hosted on the {{ ydb-short-name }} cluster in self-service mode, with no need in involvement of the cluster owner or administrators.
 
 {% include [overlay/database.md](connect_overlay/database.md) %}
 
@@ -94,9 +94,9 @@ For information about how to define connection parameters on the client, see the
 
 ### A root certificate for TLS {#tls-cert}
 
-When using an encrypted protocol ([gRPC over TLS](https://grpc.io/docs/guides/auth/), or gRPCS), a network connection can only be continued if the client is sure that it receives a response from the genuine server that it is trying to connect to, rather than someone in-between intercepting its request on the network. This is assured by verifications through a [chain of trust]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Chain_of_trust){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Цепочка_доверия){% endif %} which requires the client to have a root certificate installed to operate.
+When using an encrypted protocol ([gRPC over TLS](https://grpc.io/docs/guides/auth/), or gRPCS), a network connection can only be continued if the client is sure that it receives a response from the genuine server that it is trying to connect to, rather than someone in-the-middle intercepting its request on the network. This is assured by verifications through a [chain of trust]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Chain_of_trust){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/Цепочка_доверия){% endif %} which requires the client to have a root certificate installed to operate.
 
-The OS that the client runs on already include a set of root certificates from the world's major certification authorities. However, the {{ ydb-short-name }} cluster owner can use its own CA that is not associated with any of the global ones, which is often the case in corporate environments, and is almost always used for self-deployment of clusters with connection encryption support. In this case, the cluster owner must somehow transfer its root certificate for use on the client side. This certificate may be installed in the operating system's certificate store where the client runs (manually by a user or by a corporate OS administration team) or built into the client itself (as is the case for {{ yandex-cloud }} in {{ ydb-short-name }} CLI and SDK).
+The OS that the client runs on already include a set of root certificates from the world's major certification authorities. However, the {{ ydb-short-name }} cluster owner can use its own CA that is not associated with any of the global ones, which is often the case in corporate environments, and is almost always used for self-hosted deployment of clusters with connection encryption support. In this case, the cluster owner must somehow transfer its root certificate for use on the client side. This certificate may be installed in the operating system's certificate store where the client runs (manually by a user or by a corporate OS administration team) or built into the client itself (as is the case for {{ yandex-cloud }} in {{ ydb-short-name }} CLI and SDK).
 
 ### API for getting IAM tokens {#token-refresh-api}
 
diff --git a/ydb/docs/en/core/concepts/_includes/databases/cluster.md b/ydb/docs/en/core/concepts/_includes/databases/cluster.md
index d707b991084..c9a2ac6d19c 100644
--- a/ydb/docs/en/core/concepts/_includes/databases/cluster.md
+++ b/ydb/docs/en/core/concepts/_includes/databases/cluster.md
@@ -2,5 +2,5 @@
 
 _A {{ ydb-short-name }} cluster_ is a set of interconnected {{ ydb-short-name }} nodes that distribute the load among themselves. A single cluster may host multiple databases, and specific cluster nodes are allocated for each database. One database is fully hosted in one cluster.
 
-There are {{ ydb-short-name }} clusters with a single data center and geo-distributed clusters. The smallest single-datacenter cluster consists of a single node.
+{{ ydb-short-name }} clusters can be deployed within a single data center, or in a geo-distributed manner. The smallest single-datacenter cluster consists of a single node.
 
diff --git a/ydb/docs/en/core/concepts/_includes/datamodel/table.md b/ydb/docs/en/core/concepts/_includes/datamodel/table.md
index c80147a4197..eb0765d99f5 100644
--- a/ydb/docs/en/core/concepts/_includes/datamodel/table.md
+++ b/ydb/docs/en/core/concepts/_includes/datamodel/table.md
@@ -4,9 +4,9 @@ A table in {{ ydb-short-name }} is a [relational table](https://en.wikipedia.org
 
 ![Datamodel_of_a_relational_table](../../_assets/datamodel_rtable.png)
 
-{{ ydb-short-name }} uses [YQL](../../datatypes.md) as its data type. Columns may use [simple YQL data types](../../../yql/reference/types/primitive.md). All columns may contain the special `NULL` value to signify that a value is missing.
+{{ ydb-short-name }} uses [YQL datatypes](../../datatypes.md). Columns may use [simple YQL data types](../../../yql/reference/types/primitive.md). All columns may contain the special `NULL` value to signify that a value is missing.
 
-{{ ydb-short-name }} tables always have one or more columns that make up the key ([primary key](https://en.wikipedia.org/wiki/Unique_key)). Each table row has a unique key value, so there can be no more than one row per key value. {{ ydb-short-name }} tables are always ordered by key. This means that you can efficiently make point reads by key and range-based queries by key or key prefix (actually using an index). In the example above, the key columns are highlighted in gray and marked with a special sign. Tables consisting only of key columns are supported. However, you can't create tables without a primary key.
+{{ ydb-short-name }} tables always have one or more columns that make up the [primary key](https://en.wikipedia.org/wiki/Unique_key). Each table row has a unique key value, so there can be no more than one row per key value. {{ ydb-short-name }} tables are always ordered by key. This means that you can efficiently make point reads by key and range-based queries by key or key prefix (actually using an index). In the example above, the key columns are highlighted in gray and marked with a special sign. Tables consisting only of key columns are supported. However, you can't create tables without a primary key.
 
 Often, when you design a table schema, you already have a set of fields, which can naturally serve as the primary key. Be careful when selecting the key to avoid hotspots. For example, if you insert data into a table with a monotonically increasing key, you write the data to the end of the table. But since {{ ydb-short-name }} splits table data by key range, your inserts are always processed by the same server, so you lose the main benefits of a distributed database. To distribute the load evenly across different servers and to avoid hotspots when processing large tables, we recommend hashing the natural key and using the hash as the first component of the primary key as well as changing the order of the primary key components.
 
@@ -20,7 +20,7 @@ The size-based shard split threshold and automatic splitting can be configured (
 
 In addition to automatically splitting shards, you can create an empty table with a predefined number of shards. You can manually set the exact shard key split range or evenly split it into a predefined number of shards. In this case, ranges are created based on the first component of the primary key. You can set even splitting for tables that have a Uint64 or Uint32 integer as the first component of the primary key.
 
-Partitioning parameters refer to the table itself rather than to secondary indexes built from its data. Each index is served by its own set of shards and decisions to split or merge its partitions are made independently based on the default settings. These settings may become available to users in the future like the settings of the main table.
+Partitioning parameters refer to the table itself rather than to secondary indexes built on its data. Each index is served by its own set of shards and decisions to split or merge its partitions are made independently based on the default settings. These settings may become available to users in the future like the settings of the main table.
 
 A split or a merge usually takes about 500 milliseconds. During this time, the data involved in the operation becomes temporarily unavailable for reads and writes. Without raising it to the application level, special wrapper methods in the {{ ydb-short-name }} SDK make automatic retries when they discover that a shard is being split or merged. Please note that if the system is overloaded for some reason (for example, due to a general shortage of CPU or insufficient DB disk throughput), split and merge operations may take longer.
 
@@ -63,7 +63,7 @@ Partitions are only merged if their actual number exceeds the value specified by
 * Type: `Uint64`.
 * Default value: `50`.
 
-Partitions are only split if their number doesn't exceed the value specified by this parameter. With any automatic partitioning mode enabled, we recommend that you set a meaningful value for this parameter and monitor when the actual number of partitions approaches this value, otherwise splitting of partitions will sooner or later stop under an increase in data or load, which will lead to a failure.
+Partitions are only split if their number doesn't exceed the value specified by this parameter. With any automatic partitioning mode enabled, we recommend that you set a meaningful value for this parameter and monitor when the actual number of partitions approaches this value, otherwise splitting of partitions will stop sooner or later under an increase in data or load, which will lead to a failure.
 
 #### UNIFORM_PARTITIONS
 
@@ -72,7 +72,7 @@ Partitions are only split if their number doesn't exceed the value specified by
 
 The number of partitions for uniform initial table partitioning. The primary key's first column must have type `Uint64` or `Uint32`. A created table is immediately divided into the specified number of partitions.
 
-When automatic partitioning is enabled, make sure to set the correct value for [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count) so as not to merge all partitions into one immediately after creating the table.
+When automatic partitioning is enabled, make sure to set the correct value for [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count) to avoid merging all partitions into one immediately after creating the table.
 
 #### PARTITION_AT_KEYS
 
@@ -81,7 +81,7 @@ When automatic partitioning is enabled, make sure to set the correct value for [
 
 Boundary values of keys for initial table partitioning. It's a list of boundary values separated by commas and surrounded with brackets. Each boundary value can be either a set of values of key columns (also separated by commas and surrounded with brackets) or a single value if only the values of the first key column are specified. Examples: `(100, 1000)`, `((100, "abc"), (1000, "cde"))`.
 
-When automatic partitioning is enabled, make sure to set the correct value for [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count) so as not to merge all partitions into one immediately after creating the table.
+When automatic partitioning is enabled, make sure to set the correct value for [AUTO_PARTITIONING_MIN_PARTITIONS_COUNT](#auto_partitioning_min_partitions_count) to avoid merging all partitions into one immediately after creating the table.
 
 ### Reading data from replicas {#read_only_replicas}
 
@@ -89,10 +89,10 @@ When making queries in {{ ydb-short-name }}, the actual execution of a query to
 
 Reading data from followers allows you:
 
-* To serve clients demanding minimal delay, which is otherwise unachievable in a multi-DC cluster. This is accomplished by executing queries soon after they are formulated, which eliminates the delay associated with inter-DC transfers. As a result, you can both preserve all the storage reliability guarantees of a multi-DC cluster and respond to occasional read queries in milliseconds.
+* To serve clients demanding minimal delay, which is otherwise unachievable in a multi-DC cluster. This is accomplished by executing queries soon after they are formulated, which eliminates the delay associated with inter-DC transfers. As a result, you can both preserve all the storage reliability guarantees of a multi-DC cluster and respond to point read queries in milliseconds.
 * To handle read queries from followers without affecting modifying queries running on a shard. This can be useful both for isolating different scenarios and for increasing the partition bandwidth.
-* To ensuring continued service when moving a partition leader (both in a planned manner for load balancing and in an emergency). It lets the processes in the cluster survive without affecting the reading clients.
-* To increasing the overall shard read performance if many read queries access the same keys.
+* To ensure continued service when moving a partition leader (both in a planned manner for load balancing and in an emergency). It lets the processes in the cluster survive without affecting the reading clients.
+* To increase the overall shard read performance if many read queries access the same keys.
 
 You can enable running read replicas for each shard of the table in the table data schema. The read replicas (followers) are typically accessed without leaving the data center network, which ensures response delays in milliseconds.
 
@@ -102,13 +102,13 @@ You can enable running read replicas for each shard of the table in the table da
 
 The internal state of each of the followers is restored exactly and fully consistently from the leader state.
 
-Besides the data status in storage, followers also receive a stream of updates from the leader. Updates are sent in real time, immediately after the commit to the log. However, they are sent asynchronously, resulting in some delay (usually no more than dozens of milliseconds, but sometimes longer in the event of cluster connectivity issues) in applying updates to followers relative to their commit on the leader. Therefore, reading data from followers is only supported in the [transaction mode](../transactions.md#modes) `StaleReadOnly()`.
+Besides the data state in storage, followers also receive a stream of updates from the leader. Updates are sent in real time, immediately after the commit to the log. However, they are sent asynchronously, resulting in some delay (usually no more than dozens of milliseconds, but sometimes longer in the event of cluster connectivity issues) in applying updates to followers relative to their commit on the leader. Therefore, reading data from followers is only supported in the [transaction mode](../transactions.md#modes) `StaleReadOnly()`.
 
 If there are multiple followers, their delay from the leader may vary: although each follower of each of the shards retains internal consistency, artifacts may be observed from shard to shard. Please provide for this in your application code. For that same reason, it's currently impossible to perform cross-shard transactions from followers.
 
 ### Deleting expired data (TTL) {#ttl}
 
-{{ ydb-short-name }} supports automatic background deletion of expired data. A table data schema may define a column containing a `Datetime` or a `Timestamp` value. A comparison of this value with the current time for all rows will be performed in the background. Rows for which the current time becomes greater than the column value, factoring in the specified delay, will be deleted.
+{{ ydb-short-name }} supports automatic background deletion of expired data. A table data schema may define a column containing a `Datetime` or a `Timestamp` value. A comparison of this value with the current time for all rows will be performed in the background. Rows for which the current time becomes greater than the column value plus specified delay, will be deleted.
 
 | Parameter name | Type | Acceptable values | Update possibility | Reset capability |
 | ------------- | --- | ------------------- | --------------------- | ------------------ |
diff --git a/ydb/docs/en/core/concepts/_includes/index/intro.md b/ydb/docs/en/core/concepts/_includes/index/intro.md
index 73347477a01..30fa9eb378b 100644
--- a/ydb/docs/en/core/concepts/_includes/index/intro.md
+++ b/ydb/docs/en/core/concepts/_includes/index/intro.md
@@ -18,11 +18,11 @@ To interact with {{ ydb-short-name }}, you can use the [{{ ydb-short-name }} CLI
 
 {{ ydb-short-name }} supports a relational [data model](../../../concepts/datamodel.md) and manages tables with a predefined schema. To make it easier to organize tables, directories can be created like in the file system.
 
-Database commands are mainly written in YQL, an SQL dialect. This gives the user a powerful and already familiar way to interact with the database.
+Database commands are mainly written in YQL, an SQL dialect. This gives the user a powerful and familiar way to interact with the database.
 
 {{ ydb-short-name }} supports high-performance distributed [ACID](https://en.wikipedia.org/wiki/ACID_(computer_science)) transactions that may affect multiple records in different tables. It provides the serializable isolation level, which is the strictest transaction isolation. You can also lower the level of isolation to raise performance.
 
-{{ ydb-short-name }} natively supports different processing options, such as [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) and [OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing). The current version offers limited analytical query support. This is why we can say that {{ ydb-short-name }} is currently an OLTP database.
+{{ ydb-short-name }} is designed to service different workload types, such as [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) and [OLAP](https://en.wikipedia.org/wiki/Online_analytical_processing). The current version offers limited analytical query support. This is why we can say that {{ ydb-short-name }} is currently an OLTP database.
 
 {{ ydb-short-name }} is used in Yandex services as a high-performance [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) DBMS. In particular, {{ yandex-cloud }} {{ objstorage-full-name}} use {{ ydb-short-name }} to store data and are based on its components.
 
diff --git a/ydb/docs/en/core/concepts/_includes/limits-ydb.md b/ydb/docs/en/core/concepts/_includes/limits-ydb.md
index 4471c342956..686cf6c35ea 100644
--- a/ydb/docs/en/core/concepts/_includes/limits-ydb.md
+++ b/ydb/docs/en/core/concepts/_includes/limits-ydb.md
@@ -4,7 +4,7 @@ This section describes the parameters of limits set in {{ ydb-short-name }}.
 
 ## Schema object limits
 
-The table below shows the limits that apply to schema objects: tables, databases, and columns. The_Object_ column specifies the type of schema object that the limit applies to.
+The table below shows the limits that apply to schema objects: tables, databases, and columns. The _Object_ column specifies the type of schema object that the limit applies to.
 The _Error type_ column shows the status that the query ends with if an error occurs. For more information about statuses, see [Error handling in the API](../../reference/ydb-sdk/error_handling.md).
 
 | Object | Limit | Value | Explanation | Internal<br>name | Error<br>type |
diff --git a/ydb/docs/en/core/concepts/_includes/transactions.md b/ydb/docs/en/core/concepts/_includes/transactions.md
index c0152c78409..0d62e63bf35 100644
--- a/ydb/docs/en/core/concepts/_includes/transactions.md
+++ b/ydb/docs/en/core/concepts/_includes/transactions.md
@@ -14,7 +14,7 @@ If consistency or freshness requirement for data read by a transaction can be re
 
 * *Online Read-Only*. Each of the reads in the transaction reads data that is most recent at the time of its execution. The consistency of retrieved data depends on the *allow_inconsistent_reads* setting:
   * *false* (consistent reads). In this mode, each individual read returns consistent data, but no consistency between different reads is guaranteed. Reading the same table range twice may return different results.
-  * *true* (inconsistent reads). In this mode, even data from separately taken reads may contain inconsistent results.
+  * *true* (inconsistent reads). In this mode, even a single read operation may contain inconsistent data.
 * *Stale Read Only*. Data reads in a transaction return results with a possible delay (fractions of a second). Each individual read returns consistent data, but no consistency between different reads is guaranteed.
 
 The transaction execution mode is specified in its settings when creating the transaction.
diff --git a/ydb/docs/en/core/getting_started/_includes/auth.md b/ydb/docs/en/core/getting_started/_includes/auth.md
index 4dba70099c2..3f2ada3c872 100644
--- a/ydb/docs/en/core/getting_started/_includes/auth.md
+++ b/ydb/docs/en/core/getting_started/_includes/auth.md
@@ -1,10 +1,10 @@
 # Authentication - Getting started
 
-A local YDB database with self-deployment does not require authentication, that is, runs in [anonymous mode](../../concepts/connect.md#auth-modes).
+A local YDB database deployed with one of the self-hosted 'Getting started' scenarios does not require authentication, that is, runs in [anonymous mode](../../concepts/connect.md#auth-modes).
 
 Full information about all available authentication methods is given in the [DB connection](../../concepts/connect.md) article under "Concepts".
 
-## Learn more about YDB {#next}
+## Next step {#next}
 
-Go to [YDB CLI: Getting started](../cli.md) to learn more about YDB.
+Go to [YDB CLI: Getting started](../cli.md) to proceed with the 'Getting started' scenario.
 
diff --git a/ydb/docs/en/core/getting_started/_includes/cli.md b/ydb/docs/en/core/getting_started/_includes/cli.md
index f0690672089..60757a1bb3c 100644
--- a/ydb/docs/en/core/getting_started/_includes/cli.md
+++ b/ydb/docs/en/core/getting_started/_includes/cli.md
@@ -2,7 +2,7 @@
 
 ## Prerequisites {#prerequisites}
 
-To run commands via the CLI, you will need database connection settings you can retrieve when [creating](../create_db.md) a connection:
+To run commands via the CLI, you will need database connection settings you can get when [creating](../create_db.md) a database:
 
 * [Endpoint](../../concepts/connect.md#endpoint)
 * [Database name](../../concepts/connect.md#database)
@@ -44,7 +44,7 @@ To test connection, you can use the command for [listing objects](../../referenc
 {{ ydb-cli }} -e <endpoint> -d <database> scheme ls
 ```
 
-If the command is successful, a list of objects in the database is shown in response. If you haven't created anything in the database yet, the output will only contain the `.sys` and `.sys_health` system directories with [diagnostic representations of YDB](../../troubleshooting/system_views_db.md).
+If the command is successful, a list of objects in the database is shown in response. If you haven't created anything in the database yet, the output will only contain the `.sys` and `.sys_health` system directories with [diagnostic views of YDB](../../troubleshooting/system_views_db.md).
 
 {% include [cli/ls_examples.md](cli/ls_examples.md) %}
 
@@ -102,7 +102,7 @@ Executing commands via `ydb yql` is a nice and easy way to get started. However,
 
 The YDB CLI supports individual commands with complete sets of options for any existing YDB API. For a full list of commands, see the [YDB CLI reference](../../reference/ydb-cli/index.md).
 
-## Learn more about YDB {#next}
+## Next step {#next}
 
-Proceed to the [YQL - Getting started](../yql.md) article to learn more about YDB.
+Go to [YQL - Getting started](../yql.md) to proceed with the 'Getting started' scenario.
 
diff --git a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md b/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md
index 2e1419bff71..bde2582ec51 100644
--- a/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md
+++ b/ydb/docs/en/core/getting_started/_includes/cli/ls_example_local.md
@@ -1,6 +1,6 @@
 ### Connecting to a local database
 
-If you deployed a local YDB using a scenario for self-deployment [in Docker](../../self_hosted/ydb_docker.md) with the suggested configuration, you can check a YDB connection using the command:
+If you deployed a local YDB using a scenario for self-hosted deployment [in Docker](../../self_hosted/ydb_docker.md) with the suggested configuration, you can check a YDB connection using the command:
 
 ```bash
 {{ ydb-cli }} -e grpc://localhost:2136 -d /local scheme ls
diff --git a/ydb/docs/en/core/getting_started/_includes/create_db.md b/ydb/docs/en/core/getting_started/_includes/create_db.md
index c5712846208..0e45be06e69 100644
--- a/ydb/docs/en/core/getting_started/_includes/create_db.md
+++ b/ydb/docs/en/core/getting_started/_includes/create_db.md
@@ -4,7 +4,7 @@ Detailed information about databases can be found in the article [Terms and defi
 
 {% include [create_db_overlay.md](create_db_overlay.md) %}
 
-## Self-deployment {#self-hosted}
+## Self-hosted deployment {#self-hosted}
 
 There are three methods you can use to deploy {{ ydb-short-name }}:
 
@@ -12,7 +12,7 @@ There are three methods you can use to deploy {{ ydb-short-name }}:
 * [In Kubernetes](../../deploy/orchestrated/concepts.md).
 * [Locally, from a downloaded executable file](../self_hosted/ydb_local.md).
 
-## Learn more about YDB {#next}
+## Next step {#next}
 
-After creating your database, proceed to the [Authentication - Getting started](../auth.md) article to learn more about YDB.
+After creating your database, proceed to the [Authentication - Getting started](../auth.md) article.
 
diff --git a/ydb/docs/en/core/getting_started/_includes/yql.md b/ydb/docs/en/core/getting_started/_includes/yql.md
index dc151d6ce9b..20fb083bb5c 100644
--- a/ydb/docs/en/core/getting_started/_includes/yql.md
+++ b/ydb/docs/en/core/getting_started/_includes/yql.md
@@ -24,7 +24,7 @@ In {{ ydb-short-name }}, you can make YQL queries to a database using:
 
 ### {{ ydb-short-name }} CLI {#cli}
 
-To execute scripts using the {{ ydb-short-name }} CLI, first do the following:
+To enable scripts execution using the {{ ydb-short-name }} CLI, ensure you have completed the following prerequisites:
 
 * [Install the CLI](../cli.md#install).
 * Define and check [DB connection settings](../cli#scheme-ls)
@@ -80,7 +80,7 @@ For a description of everything you can do when working with tables, review the
 * [ALTER TABLE](../../yql/reference/syntax/alter_table.md): Modify a table's column structure and properties.
 * [DROP TABLE](../../yql/reference/syntax/drop_table.md): Delete a table.
 
-To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) below.
+To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) above.
 
 ### Getting a list of existing DB tables {#scheme-ls}
 
@@ -88,7 +88,7 @@ Check that the tables are actually created in the database.
 
 {% include [yql/ui_scheme_ls.md](yql/ui_scheme_ls.md) %}
 
-To get a list of existing DB tables via the {{ ydb-short-name }} CLI, make sure that the prerequisites under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) below are complete and run the [`scheme ls` statement](../cli.md#ping):
+To get a list of existing DB tables via the {{ ydb-short-name }} CLI, make sure that the prerequisites under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) above are complete and run the [`scheme ls` statement](../cli.md#ping):
 
 ```bash
 {{ ydb-cli }} --profile db1 scheme ls
@@ -100,9 +100,9 @@ Commands for running YQL queries and scripts in the YDB CLI and the web interfac
 
 ### UPSERT: Adding data {#upsert}
 
-The most efficient way to add data to {{ ydb-short-name }} is through the [`UPSERT`](../../yql/reference/syntax/upsert_into.md) statement. It inserts new data by primary keys regardless of whether data by these keys previously existed in the table. As a result, unlike regular `INSERT` and `UPDATE`, it does not require a data pre-fetch from the server to verify that a key is unique before it runs. When working with {{ ydb-short-name }}, always consider `UPSERT` as the main way to add data and only use other statements when absolutely necessary.
+The most efficient way to add data to {{ ydb-short-name }} is through the [`UPSERT`](../../yql/reference/syntax/upsert_into.md) statement. It inserts new data by primary keys regardless of whether data by these keys previously existed in the table. As a result, unlike regular `INSERT` and `UPDATE`, it does not require a data pre-fetch on the server to verify that a key is unique. When working with {{ ydb-short-name }}, always consider `UPSERT` as the main way to add data and only use other statements when absolutely necessary.
 
-All statements that write data to {{ ydb-short-name }} support working with both samples and multiple entries passed directly in a query.
+All statements that write data to {{ ydb-short-name }} support working with both subqueries and multiple entries passed directly in a query.
 
 Let's add data to the previously created tables:
 
@@ -139,7 +139,7 @@ VALUES
 ;
 ```
 
-To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) below.
+To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) above.
 
 To learn more about commands for writing data, see the YQL reference:
 
@@ -168,7 +168,7 @@ SELECT * FROM episodes;
 
 If there are several `SELECT` statements in the YQL script, its execution will return several samples, each of which can be accessed separately. Run the above `SELECT` statements as a single script.
 
-To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) below.
+To execute a script via the {{ ydb-short-name }} CLI, follow the instructions provided under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) above.
 
 To learn more about the commands for selecting data, see the YQL reference:
 
@@ -178,7 +178,7 @@ To learn more about the commands for selecting data, see the YQL reference:
 
 ### Parameterized queries {#param}
 
-Transactional applications working with a database are characterized by the execution of multiple similar queries that only differ in parameters. Like most databases, {{ ydb-short-name }} will work more efficiently if you define updateable parameters and their types and then initiate the execution of a query by passing the parameter values separately from its text.
+Transactional applications working with a database are characterized by the execution of multiple similar queries that only differ in parameters. Like most databases, {{ ydb-short-name }} will work more efficiently if you define variable parameters and their types and then initiate the execution of a query by passing the parameter values separately from its text.
 
 To define parameters in the text of a YQL query, use the [DECLARE](../../yql/reference/syntax/declare.md) statement.
 
@@ -198,7 +198,7 @@ INNER JOIN series AS sr ON sa.series_id = sr.series_id
 WHERE sa.series_id = $seriesId AND sa.season_id = $seasonId;
 ```
 
-To run a parameterized select query, make sure to complete the prerequisites under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) below and run:
+To run a parameterized select query, make sure to complete the prerequisites under [Executing YQL scripts in the {{ ydb-short-name }} CLI](#cli) above and run:
 
 ```bash
 {{ ydb-cli }} --profile db1 yql -f script.yql -p '$seriesId=1' -p '$seasonId=1'
@@ -210,7 +210,8 @@ For a full description of the ways to pass parameters, see [the {{ ydb-short-nam
 
 You can learn more about YQL use cases by completing tasks from the [YQL tutorial](../../yql/tutorial/index.md).
 
-## Learn more about YDB {#next}
+## Next step {#next}
+
+Go to [YDB SDK - Getting started](../sdk.md) to proceed with the 'Getting started' scenario.
 
-Proceed to the [YDB SDK - Getting started](../sdk.md) article to learn more about YDB.
 
diff --git a/ydb/docs/en/core/getting_started/_includes/yql/ui_embedded_execute.md b/ydb/docs/en/core/getting_started/_includes/yql/ui_embedded_execute.md
index 88f68d5b2e1..97e6c72adbf 100644
--- a/ydb/docs/en/core/getting_started/_includes/yql/ui_embedded_execute.md
+++ b/ydb/docs/en/core/getting_started/_includes/yql/ui_embedded_execute.md
@@ -1,6 +1,6 @@
 ### Built-in YDB web interface {#embedded}
 
-To execute YQL queries and scripts on self-deployed YDB databases, you can use the [built-in YDB web interface](../../../maintenance/embedded_monitoring/overview.md). For a local deployment [using Docker](../../self_hosted/ydb_docker.md) with the default parameters, it is available at [http://localhost:8765](http://localhost:8765).
+To execute YQL queries and scripts on self-hosted YDB databases, you can use the [built-in YDB web interface](../../../maintenance/embedded_monitoring/overview.md). For a local deployment [using Docker](../../self_hosted/ydb_docker.md) with the default parameters, it is available at [http://localhost:8765](http://localhost:8765).
 
 Select **Databases** in the menu on the left, click on the database in the list, and switch to the **Query** tab:
 
diff --git a/ydb/docs/en/core/getting_started/self_hosted/_includes/index.md b/ydb/docs/en/core/getting_started/self_hosted/_includes/index.md
index 709cc7f1676..931dd9b4f0f 100644
--- a/ydb/docs/en/core/getting_started/self_hosted/_includes/index.md
+++ b/ydb/docs/en/core/getting_started/self_hosted/_includes/index.md
@@ -1,4 +1,4 @@
-# Self-deployment of a database {{ ydb-short-name }}
+# Self-hosted deployment of a database {{ ydb-short-name }}
 
 This section contains articles describing simple YDB deployment scenarios. They can be used by application developers to quickly deploy their own YDB database for development or testing purposes.
 
diff --git a/ydb/docs/en/core/getting_started/self_hosted/_includes/ydb_local.md b/ydb/docs/en/core/getting_started/self_hosted/_includes/ydb_local.md
index af31c91b0f7..018f4ece5bf 100644
--- a/ydb/docs/en/core/getting_started/self_hosted/_includes/ydb_local.md
+++ b/ydb/docs/en/core/getting_started/self_hosted/_includes/ydb_local.md
@@ -4,7 +4,7 @@ This section describes how to deploy a local {{ ydb-short-name }} cluster using
 
 ## Connection parameters {#conn}
 
-As a result of completing the steps below, you'll get a YDB database running on a local VM instance that you can connect to using the following:
+As a result of completing the steps below, you'll get a YDB database running on a local machine that you can connect to using the following:
 
 - [Endpoint](../../../concepts/connect.md#endpoint): `grpc://localhost:2136`
 - [Database location](../../../concepts/connect.md#database): `/Root/test`
@@ -22,7 +22,7 @@ curl https://binaries.ydb.tech/local_scripts/install.sh | bash
 
 ## Starting {#start}
 
-The local YDB server can be started in disk or in-memory mode:
+The local YDB server can be started in two modes:
 
 {% list tabs %}
 
@@ -38,7 +38,7 @@ The local YDB server can be started in disk or in-memory mode:
 
 - Storing data in memory
 
-  - Under in-memory data storage, the data is lost when stopping the server.
+  - When using in-memory data storage, the data is lost when stopping the server.
 
   - Run the following command from the working directory:
 
diff --git a/ydb/docs/en/core/getting_started/toc_i.yaml b/ydb/docs/en/core/getting_started/toc_i.yaml
index 7beb9f70ede..b39c640eea5 100644
--- a/ydb/docs/en/core/getting_started/toc_i.yaml
+++ b/ydb/docs/en/core/getting_started/toc_i.yaml
@@ -10,7 +10,7 @@ items:
   href: yql.md
 - name: YDB SDK
   href: sdk.md
-- name: Self-deployment
+- name: Self-hosted deployment
   include: { mode: link, path: self_hosted/toc_p.yaml }
 - name: Useful links
   href: useful_links.md
\ No newline at end of file
diff --git a/ydb/docs/en/core/getting_started/toc_p.yaml b/ydb/docs/en/core/getting_started/toc_p.yaml
index 7064fde1cb1..9c5e8dce09b 100644
--- a/ydb/docs/en/core/getting_started/toc_p.yaml
+++ b/ydb/docs/en/core/getting_started/toc_p.yaml
@@ -2,5 +2,5 @@ items:
 - name: Overview
   href: index.md
 - include: { mode: link, path: toc_i.yaml }
-- name: How to update the documentation
+- name: How to edit the documentation
   include: { mode: link, path: ../how_to_edit_docs/toc_p.yaml }
\ No newline at end of file
diff --git a/ydb/docs/en/core/how_to_edit_docs/_includes/build/local_oss.md b/ydb/docs/en/core/how_to_edit_docs/_includes/build/local_oss.md
index a66faa8b82d..d9af4985fd6 100644
--- a/ydb/docs/en/core/how_to_edit_docs/_includes/build/local_oss.md
+++ b/ydb/docs/en/core/how_to_edit_docs/_includes/build/local_oss.md
@@ -15,7 +15,7 @@ Where:
 - `source_dir` is the directory where the contents of [https://github.com/ydb-platform/ydb/tree/master/docs](https://github.com/ydb-platform/ydb/tree/master/docs) is cloned.
 - `output_dir` is the output directory for HTML files.
 
-Building the documentation takes a few seconds and there should be no errors logged to the stdout log.
+Building the documentation takes a few seconds and there should be no errors logged to the stdout.
 
 You can specify `.` (a dot) as `source_dir` if the yfm command is called directly from `source_dir`. For example:
 
diff --git a/ydb/docs/en/core/how_to_edit_docs/_includes/build/tech.md b/ydb/docs/en/core/how_to_edit_docs/_includes/build/tech.md
index e5dc523a8e5..f671bc04a37 100644
--- a/ydb/docs/en/core/how_to_edit_docs/_includes/build/tech.md
+++ b/ydb/docs/en/core/how_to_edit_docs/_includes/build/tech.md
@@ -5,10 +5,10 @@
 Any version of the documentation is built using a common template:
 
 1. The basic build directory contains two directories: `core` and `overlay`.
-2. The `core` directory stores the basic documentation that can be added as an external dependency (such as git submodule).
-2. The `overlay` directory stores content that is specific for this build.
-2. The contents of the core directory are copied to the working directory.
-3. The contents of the overlay directory are copied to the working directory, replacing any file whose relative path in the overlay directory matches that of any file from the core directory.
+1. The `core` directory stores the basic documentation that can be added as an external dependency (such as git submodule).
+1. The `overlay` directory stores content that is specific for this build.
+1. The contents of the core directory are copied to the working directory.
+1. The contents of the overlay directory are copied to the working directory, replacing any file whose relative path in the overlay directory matches that of any file from the core directory.
 
 As a result, the working directory of the build contains the content from the core directory, in which the files present in the overlay directory are replaced. If a certain file is missing in `overlay`, a file from `core` gets to the build.
 
diff --git a/ydb/docs/en/core/how_to_edit_docs/_includes/content.md b/ydb/docs/en/core/how_to_edit_docs/_includes/content.md
index 3444477d98f..dfcf7b62842 100644
--- a/ydb/docs/en/core/how_to_edit_docs/_includes/content.md
+++ b/ydb/docs/en/core/how_to_edit_docs/_includes/content.md
@@ -16,7 +16,7 @@ When adding content, you should first choose where to add it: to the OpenSource
 
 {% include [custom_extension.md](content/custom_extension.md) %}
 
-In the sections where the requirements differ for basic content and customization, there are two corresponding bookmarks:
+In the sections below where the requirements differ for basic content and customization, there are two corresponding tabs:
 
 - **Core**: The core of any documentation, the basic content.
 - **Overlay**: Content that is overlaid on top of the core and adapting it to a custom build.
@@ -43,7 +43,7 @@ The presence of the "Overview" article lets you refer to the entire directory ra
 
 - Core
 
-  Any article in the basic OpenSource documentation is created with a view to extend or adjust it in the customized documentation created on its basis. At the same time, improvements to the basic documentation should be applied in a customized version with no manual merge of content changes, otherwise maintaining a lot of derived documentation versions becomes a very labor-intensive task and monitoring the completeness of manual adaptations becomes impossible.
+  Any article in the basic OpenSource documentation is created with a perspective to extend or adjust it in the customized documentation created on its basis. At the same time, improvements to the base documentation should be applied in a customized version with no manual merge of content changes, otherwise maintaining a lot of derived documentation versions becomes a very labor-intensive task and monitoring the completeness of manual adaptations becomes impossible.
 
   To achieve this goal using the existing tools, a file with an article inside a subject directory does not directly contain any content and is designed to be redefined when customizing the documentation. The content is located in one or more files with content blocks included in the article file through include directives.
 
@@ -162,9 +162,9 @@ The presence of the "Overview" article lets you refer to the entire directory ra
 
 ### Other use cases for include {#include-reuse}
 
-The `{% include ... %}` directive can technically be used both to support the creation of derivative documentation versions and just to reuse content in several articles. However, this is undesirable, since the appearance of the same content in different articles confuses the user, and editing the included content without understanding the context it is given in can easily lead to loss of meaning.
+The `{% include ... %}` directive can technically be used not just to support the creation of derivative documentation versions, but also to reuse content in several articles. However, this is undesirable, since the appearance of the same content in different articles confuses the user, and editing the included content without understanding the context it is given in can easily lead to loss of meaning.
 
-An acceptable and good way to use the reused content is to provide the same information in different grouping options within the same context. For example, the FAQ section contains both articles on certain topics and the "All questions on all topics" article. Similarly, information about prices can be given both in specialized articles on some chargeable functions and in the general article of the price list.
+An acceptable and good way to leverage the reusable content is to provide the same information in different grouping options within the same context. For example, the FAQ section contains both articles on certain topics and the "All questions on all topics" article. Similarly, information about prices can be given both in specialized articles on some chargeable functions and in the general article with the price list.
 
 ## Table of contents {#toc}
 
@@ -265,7 +265,7 @@ There are two types of links:
    ```md
    To keep a kitten active, you [need to feed it] (../feeding/index.md).
    ```
-2. To resources external to the documentation. These are fully-qualified URLs in which no index is ever added:
+2. To resources external to the documentation. These are fully-qualified URLs in which no `index` is ever added:
 
    ```md
    You can find a good choice of cat food at the [Pushok store](http://www.pushok.ru/catalog).
@@ -291,7 +291,7 @@ The text specified in square brackets is displayed in the browser until the imag
 
 Desirable image formats:
 
-- Charts: [.SVG]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Scalable_Vector_Graphics){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/SVG){% endif %}
+- Diagrams: [.SVG]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Scalable_Vector_Graphics){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/SVG){% endif %}
 - Screenshots: [.PNG]{% if lang == "en" %}(https://en.wikipedia.org/wiki/Portable_Network_Graphics){% endif %}{% if lang == "ru" %}(https://ru.wikipedia.org/wiki/PNG){% endif %}
 
 Since an image is part of an article, it is impossible to post the image without this article. If there is no text of the article yet, determine the subject directory for its placement and the file name of the future article and only specify a link to the image in the text (keep in mind that the [text of the article is placed in the `_includes` subdirectory](#articles)!), and do not include the article itself in the TOC until it is ready for publication.
@@ -303,7 +303,7 @@ When inserting images, you can also specify:
 
 ## Backward compatibility {#compatibility}
 
-The development of documentation should not lead to a situation when users encounter saved links that are broken: both in browser tabs and those fixed in a variety of resources that are not controlled by the documentation developers, such as wiki pages.
+The development of documentation should not lead to a situation when users encounter saved links that are broken: both in browser bookmarks and those recorded in a variety of resources that are not controlled by the documentation developers, such as wiki pages.
 
 This means that you generally can't rename articles or move them across directories.
 
diff --git a/ydb/docs/en/core/how_to_edit_docs/_includes/subjects.md b/ydb/docs/en/core/how_to_edit_docs/_includes/subjects.md
index 5d1daa1266b..6f3a9b4ecf0 100644
--- a/ydb/docs/en/core/how_to_edit_docs/_includes/subjects.md
+++ b/ydb/docs/en/core/how_to_edit_docs/_includes/subjects.md
@@ -12,7 +12,7 @@ A topic description includes:
    - {{ ydb-short-name }} developer/contributor
 2. Purpose: The reader's task or problem the solution of which is described in the content.
 
-Basically, the directory structure directly affects the structure of the documentation table of contents. Typical exceptions are:
+In general, the directory structure directly affects the structure of the documentation table of contents. Typical exceptions are:
 
 - Intermediate stages of documentation creation. A new directory is created immediately to preserve the referential integrity in the future, but its content is still insufficient to be designed as a separate submenu in the table of contents. In this case, articles can be temporarily included in existing submenus.
 - Historically established directories whose transfer is undesirable due to the loss of referential integrity.