more spellings

Author: gingerwizard

docs/en/chdb/install/nodejs.md

@@ -3,7 +3,7 @@ title: Installing chDB for NodeJS
 sidebar_label: NodeJS
 slug: /en/chdb/install/nodejs
 description: How to install chDB for NodeJS
-keywords: [chdb, embedded, clickhouse-lite, nodejs, install]
+keywords: [chdb, embedded, clickhouse-lite, NodeJS, install]
 ---
 
 # Installing chDB for NodeJS

docs/en/cloud/security/azure-privatelink.md

@@ -16,7 +16,7 @@ This guide shows how to use Azure Private Link to provide private connectivity v
 
 ![Overview of PrivateLink](@site/docs/en/cloud/security/images/azure-pe.png)
 
-Unlike AWS and GCP, Azure supports cross-region connectivity via Private Link. This enables you to establish connections between VNETs located in different regions where you have ClickHouse services deployed.
+Unlike AWS and GCP, Azure supports cross-region connectivity via Private Link. This enables you to establish connections between VNets located in different regions where you have ClickHouse services deployed.
 
 :::note
 Additional charges may be applied to inter-region traffic. Please check latest Azure documentation.
@@ -103,7 +103,7 @@ In the following screen, specify the following options:
 
 - **Subscription** / **Resource Group**: Please choose the Azure subscription and resource group for the Private Endpoint.
 - **Name**: Set a name for the **Private Endpoint**.
-- **Region**: Choose region where the deployed VNET that will be connected to ClickHouse Cloud via Private Link.
+- **Region**: Choose region where the deployed VNet that will be connected to ClickHouse Cloud via Private Link.
 
 After you have completed the above steps, click the **Next: Resource** button.
 
@@ -113,15 +113,15 @@ After you have completed the above steps, click the **Next: Resource** button.
 
 Select the option **Connect to an Azure resource by resource ID or alias**.
 
-For the **Resource ID or alias**, use the **endpointServiceId** you have obtained from the [Obtain Azure connection alias for Private Link](#obtain-azure-connection-alias-for-private-link) step.
+For the **Resource ID or alias**, use the `endpointServiceId` you have obtained from the [Obtain Azure connection alias for Private Link](#obtain-azure-connection-alias-for-private-link) step.
 
 Click **Next: Virtual Network** button.
 
 ![PE resource](@site/docs/en/cloud/security/images/azure-pe-resource.png)
 
 ---
 
-- **Virtual network**: Choose the VNET you want to connect to ClickHouse Cloud using Private Link
+- **Virtual network**: Choose the VNet you want to connect to ClickHouse Cloud using Private Link
 - **Subnet**: Choose the subnet where Private Endpoint will be created
 
 Optional: 
@@ -189,7 +189,7 @@ Under properties, find `resourceGuid` field and copy this value:
 
 ## Setting up DNS for Private Link
 
-You need will need to create a Private DNS zone (`${location_code}.privatelink.azure.clickhouse.cloud`) and attach it to your VNET to access resources via Private Link.
+You need will need to create a Private DNS zone (`${location_code}.privatelink.azure.clickhouse.cloud`) and attach it to your VNet to access resources via Private Link.
 
 ### Create Private DNS zone
 
@@ -214,7 +214,7 @@ Create a wildcard record and point to your Private Endpoint:
 
 **Option 1: Using Azure Portal**
 
-1. Open the MyAzureResourceGroup resource group and select the `${region_code}.privatelink.azure.clickhouse.cloud` private zone.
+1. Open the `MyAzureResourceGroup` resource group and select the `${region_code}.privatelink.azure.clickhouse.cloud` private zone.
 2. Select + Record set.
 3. For Name, type `*`.
 4. For IP Address, type the IP address you see for Private Endpoint.
@@ -259,7 +259,7 @@ resource "azurerm_private_dns_zone_virtual_network_link" "example" {
 
 ### Verify DNS setup
 
-Any record within the westus3.privatelink.azure.clickhouse.cloud domain should be pointed to the Private Endpoint IP. (10.0.0.4 in this example). 
+Any record within the `westus3.privatelink.azure.clickhouse.cloud` domain should be pointed to the Private Endpoint IP. (10.0.0.4 in this example). 
 
 ```bash
 nslookup instance-id.westus3.privatelink.azure.clickhouse.cloud.
@@ -408,7 +408,7 @@ curl --silent --user ${KEY_ID:?}:${KEY_SECRET:?} -X PATCH -H "Content-Type: appl
 Each service with Private Link enabled has a public and private endpoint. In order to connect using Private Link, you need to use a private endpoint which will be `privateDnsHostname`.
 
 :::note
-Private DNS hostname is only available from your Azure VNET. Do not try to resolve the DNS host from a machine that resides outside of Azure VNET.
+Private DNS hostname is only available from your Azure VNet. Do not try to resolve the DNS host from a machine that resides outside of Azure VNet.
 :::
 
 ### Obtaining the Private DNS Hostname

docs/en/faq/operations/production.md

@@ -34,7 +34,7 @@ Here are some key points to get reasonable fidelity in a pre-production environm
 
 The second area to invest in is **automated testing infrastructure**. Don’t assume that if some kind of query has executed successfully once, it’ll continue to do so forever. It’s OK to have some unit tests where ClickHouse is mocked, but make sure your product has a reasonable set of automated tests that are run against real ClickHouse and check that all important use cases are still working as expected.
 
-An extra step forward could be contributing those automated tests to [ClickHouse’s open-source test infrastructure](https://github.com/ClickHouse/ClickHouse/tree/master/tests) that are continuously used in its day-to-day development. It definitely will take some additional time and effort to learn [how to run it](../../development/tests.md) and then how to adapt your tests to this framework, but it’ll pay off by ensuring that ClickHouse releases are already tested against them when they are announced stable, instead of repeatedly losing time on reporting the issue after the fact and then waiting for a bugfix to be implemented, backported and released. Some companies even have such test contributions to infrastructure by its use as an internal policy, (called [Beyonce’s Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well) at Google).
+An extra step forward could be contributing those automated tests to [ClickHouse’s open-source test infrastructure](https://github.com/ClickHouse/ClickHouse/tree/master/tests) that are continuously used in its day-to-day development. It definitely will take some additional time and effort to learn [how to run it](../../development/tests.md) and then how to adapt your tests to this framework, but it’ll pay off by ensuring that ClickHouse releases are already tested against them when they are announced stable, instead of repeatedly losing time on reporting the issue after the fact and then waiting for a bugfix to be implemented, backported and released. Some companies even have such test contributions to infrastructure by its use as an internal policy, (called [Beyonce's Rule](https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ch01.html#policies_that_scale_well) at Google).
 
 When you have your pre-production environment and testing infrastructure in place, choosing the best version is straightforward:
 
@@ -54,7 +54,7 @@ If you look into the contents of the ClickHouse package repository, you’ll see
 
 Here is some guidance on how to choose between them:
 
-- `stable` is the kind of package we recommend by default. They are released roughly monthly (and thus provide new features with reasonable delay) and three latest stable releases are supported in terms of diagnostics and backporting of bugfixes.
+- `stable` is the kind of package we recommend by default. They are released roughly monthly (and thus provide new features with reasonable delay) and three latest stable releases are supported in terms of diagnostics and backporting of bug fixes.
 - `lts` are released twice a year and are supported for a year after their initial release. You might prefer them over `stable` in the following cases:
     - Your company has some internal policies that do not allow for frequent upgrades or using non-LTS software.
     - You are using ClickHouse in some secondary products that either do not require any complex ClickHouse features or do not have enough resources to keep it updated.

docs/en/guides/sre/configuring-ssl.md

@@ -23,9 +23,9 @@ This guide was written using Ubuntu 20.04 and ClickHouse installed on the follow
 
 |Host |IP Address|
 |--------|-------------|
-|chnode1 |192.168.1.221|
-|chnode2 |192.168.1.222|
-|chnode3 |192.168.1.223|
+|`chnode1` |192.168.1.221|
+|`chnode2` |192.168.1.222|
+|`chnode3` |192.168.1.223|
 
 
 :::note

docs/en/guides/sre/keeper/index.md

@@ -680,7 +680,7 @@ This guide provides simple and minimal settings to configure ClickHouse Keeper w
 
 ### 1. Configure Nodes with Keeper settings
 
-1. Install 3 ClickHouse instances on 3 hosts (chnode1, chnode2, chnode3). (View the [Quick Start](/docs/en/getting-started/install.md) for details on installing ClickHouse.)
+1. Install 3 ClickHouse instances on 3 hosts (`chnode1`, `chnode2`, `chnode3`). (View the [Quick Start](/docs/en/getting-started/install.md) for details on installing ClickHouse.)
 
 2. On each node, add the following entry to allow external communication through the network interface.
     ```xml
@@ -731,7 +731,7 @@ This guide provides simple and minimal settings to configure ClickHouse Keeper w
     |server    |definition of server participating|list of each server definition|
     |raft_configuration| settings for each server in the keeper cluster| server and settings for each|
     |id      |numeric id of the server for keeper services|1|
-    |hostname   |hostname, IP or FQDN of each server in the keeper cluster|chnode1.domain.com|
+    |hostname   |hostname, IP or FQDN of each server in the keeper cluster|`chnode1.domain.com`|
     |port|port to listen on for interserver keeper connections|9234|
 
 
@@ -758,7 +758,7 @@ This guide provides simple and minimal settings to configure ClickHouse Keeper w
     |Parameter |Description                   |Example              |
     |----------|------------------------------|---------------------|
     |node   |list of nodes for ClickHouse Keeper connections|settings entry for each server|
-    |host|hostname, IP or FQDN of each ClickHouse keeper node| chnode1.domain.com|
+    |host|hostname, IP or FQDN of each ClickHouse keeper node| `chnode1.domain.com`|
     |port|ClickHouse Keeper client port| 9181|
 
 5. Restart ClickHouse and verify that each Keeper instance is running. Execute the following command on each server. The `ruok` command returns `imok` if Keeper is running and healthy:
@@ -814,10 +814,10 @@ This guide provides simple and minimal settings to configure ClickHouse Keeper w
     |----------|------------------------------|---------------------|
     |shard   |list of replicas on the cluster definition|list of replicas for each shard|
     |replica|list of settings for each replica|settings entries for each replica|
-    |host|hostname, IP or FQDN of server that will host a replica shard|chnode1.domain.com|
+    |host|hostname, IP or FQDN of server that will host a replica shard|`chnode1.domain.com`|
     |port|port used to communicate using the native tcp protocol|9000|
     |user|username that will be used to authenticate to the cluster instances|default|
-    |password|password for the user define to allow connections to cluster instances|ClickHouse123!|
+    |password|password for the user define to allow connections to cluster instances|`ClickHouse123!`|
 
 
 2. Restart ClickHouse and verify the cluster was created:
@@ -956,9 +956,9 @@ a single ClickHouse shard made up of two replicas.
 
 |node|description|
 |-----|-----|
-|chnode1.marsnet.local|data node - cluster cluster_1S_2R|
-|chnode2.marsnet.local|data node - cluster cluster_1S_2R|
-|chnode3.marsnet.local| ClickHouse Keeper tie breaker node|
+|`chnode1.marsnet.local`|data node - cluster `cluster_1S_2R`|
+|`chnode2.marsnet.local`|data node - cluster `cluster_1S_2R`|
+|`chnode3.marsnet.local`| ClickHouse Keeper tie breaker node|
 
 Example config for cluster:
 ```xml

docs/en/integrations/data-ingestion/apache-spark/index.md

@@ -3,7 +3,7 @@ sidebar_label: Integrating Apache Spark with ClickHouse
 sidebar_position: 1
 slug: /en/integrations/apache-spark
 description: Introduction to Apache Spark with ClickHouse
-keywords: [ clickhouse, apache, spark, migrating, data ]
+keywords: [ clickhouse, Apache Spark, migrating, data ]
 ---
 
 import Tabs from '@theme/Tabs';

docs/en/integrations/data-ingestion/apache-spark/spark-native-connector.md

@@ -3,7 +3,7 @@ sidebar_label: Spark Native Connector
 sidebar_position: 2
 slug: /en/integrations/apache-spark/spark-native-connector
 description: Introduction to Apache Spark with ClickHouse
-keywords: [ clickhouse, apache, spark, migrating, data ]
+keywords: [ clickhouse, Apache Spark, migrating, data ]
 ---
 
 import Tabs from '@theme/Tabs';

docs/en/integrations/data-ingestion/data-formats/parquet.md

@@ -125,7 +125,7 @@ DESCRIBE TABLE imported_from_parquet;
 └──────┴──────────────────┴──────────────┴────────────────────┴─────────┴──────────────────┴────────────────┘
 ```
 
-By default, ClickHouse is strict with column names, types, and values. But sometimes, we can skip unexistent columns or unsupported values during import. This can be managed with [Parquet settings](/docs/en/interfaces/formats.md/#parquet-format-settings).
+By default, ClickHouse is strict with column names, types, and values. But sometimes, we can skip nonexistent columns or unsupported values during import. This can be managed with [Parquet settings](/docs/en/interfaces/formats.md/#parquet-format-settings).
 
 
 ## Exporting to Parquet format

docs/en/integrations/data-ingestion/data-sources-index.md

@@ -1,6 +1,6 @@
 ---
 slug: /en/integrations/index
-keywords: [AWS S3, PostgreSQL, Kafka, Apache Spark, MySQL, Cassandra, Redis, RabbitMQ, MongoDB, Google Cloud Storage, Hive, Hudi, Iceberg, MiniIO, Delta Lake, RocksDB, Splunk, SQlite, NATS, EMQX, local files, JDBC, ODBC]
+keywords: [AWS S3, PostgreSQL, Kafka, Apache Spark, MySQL, Cassandra, Redis, RabbitMQ, MongoDB, Google Cloud Storage, Hive, Hudi, Iceberg, MinIO, Delta Lake, RocksDB, Splunk, SQLite, NATS, EMQX, local files, JDBC, ODBC]
 description: Datasources overview page
 ---
 
@@ -28,7 +28,7 @@ For further information see the pages listed below:
 | [Delta Lake](/docs/en/integrations/deltalake)                                 |
 | [RocksDB](/docs/en/integrations/rocksdb)                                      |
 | [Splunk](/docs/en/integrations/splunk)                                        |
-| [SQlite](/docs/en/integrations/sqlite)                                        |
+| [SQLite](/docs/en/integrations/sqlite)                                        |
 | [NATS](/docs/en/integrations/nats)                                            |
 | [EMQX](/docs/en/integrations/emqx)                                            |
 | [Insert Local Files](/docs/en/integrations/data-ingestion/insert-local-files) |

docs/en/integrations/data-ingestion/dbms/dynamodb/index.md

@@ -27,7 +27,7 @@ Data will be ingested into a `ReplacingMergeTree`. This table engine is commonly
 First, you will want to enable a Kinesis stream on your DynamoDB table to capture changes in real-time. We want to do this before we create the snapshot to avoid missing any data.
 Find the AWS guide located [here](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/kds.html).
 
-![DynamoDB Kenesis Stream](../images/dynamodb-kinesis-stream.png)
+![DynamoDB Kinesis Stream](../images/dynamodb-kinesis-stream.png)
 
 ## 2. Create the snapshot