remove /en

Author: Blargian

.github/dependabot.yml

@@ -6,13 +6,13 @@ updates:
     schedule:
       interval: "monthly"
   - package-ecosystem: "npm"
-    directory: "/docs/en/integrations"
+    directory: "/docs/integrations"
     schedule:
       interval: "monthly"
     # Disable version updates for dependencies in the code snippets
     open-pull-requests-limit: 0
   - package-ecosystem: "pip"
-    directory: "/docs/en/integrations"
+    directory: "/docs/integrations"
     schedule:
       interval: "monthly"
     # Disable version updates for dependencies in the code snippets

.github/pull_request_template.md

@@ -4,4 +4,4 @@
 ## Checklist
 - [ ] Delete items not relevant to your PR
 - [ ] URL changes should add a redirect to the old URL via https://github.com/ClickHouse/clickhouse-docs/blob/main/docusaurus.config.js
-- [ ] If adding a new integration page, also add an entry to the integrations list here: https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/en/integrations/index.mdx
+- [ ] If adding a new integration page, also add an entry to the integrations list here: https://github.com/ClickHouse/clickhouse-docs/blob/main/docs/integrations/index.mdx

images/knowledgebase/connection_timeout_remote_remoteSecure.md

@@ -5,7 +5,7 @@ description: "When using the `remote` or `remoteSecure` table functions on a nod
 # Code: 279. DB::NetException: All connection tries failed.
 
 **Problem**
-[`remote()` or `remoteSecure()`](https://clickhouse.com/docs/en/sql-reference/table-functions/remote/) table function allows the access of remote table from another ClickHouse node.
+[`remote()` or `remoteSecure()`](https://clickhouse.com/docs/sql-reference/table-functions/remote/) table function allows the access of remote table from another ClickHouse node.
 
 When using these functions on a node that is located more than 100ms (latency wise) away from the remote node, it is common to encounter the following timeout error.
 

images/knowledgebase/delete-old-data.md

@@ -20,7 +20,7 @@ TTL can also be used to move data not only to [/dev/null](https://en.wikipedia.o
 More details on [configuring TTL](../../engines/table-engines/mergetree-family/mergetree.md#table_engine-mergetree-ttl).
 
 ## DELETE FROM
-[DELETE FROM](/docs/en/sql-reference/statements/delete.md) allows standard DELETE queries to be run in ClickHouse. The rows targeted in the filter clause are marked as deleted, and removed from future result sets.  Cleanup of the rows happens asynchronously.
+[DELETE FROM](/docs/sql-reference/statements/delete.md) allows standard DELETE queries to be run in ClickHouse. The rows targeted in the filter clause are marked as deleted, and removed from future result sets.  Cleanup of the rows happens asynchronously.
 
 :::note
 DELETE FROM is an experimental feature and must be enabled with:
@@ -31,7 +31,7 @@ SET allow_experimental_lightweight_delete = true;
 
 ## ALTER DELETE {#alter-delete}
 
-ALTER DELETE removes rows using asynchronous batch operations. Unlike DELETE FROM, queries run after the ALTER DELETE and before the batch operations complete will include the rows targeted for deletion.  For more details see the [ALTER DELETE](/docs/en/sql-reference/statements/alter/delete.md) docs.
+ALTER DELETE removes rows using asynchronous batch operations. Unlike DELETE FROM, queries run after the ALTER DELETE and before the batch operations complete will include the rows targeted for deletion.  For more details see the [ALTER DELETE](/docs/sql-reference/statements/alter/delete.md) docs.
 
 `ALTER DELETE` can be issued to flexibly remove old data. If you need to do it regularly, the main downside will be the need to have an external system to submit the query. There are also some performance considerations since mutations rewrite complete parts even there is only a single row to be deleted.
 
@@ -49,4 +49,4 @@ More details on [manipulating partitions](../../sql-reference/statements/alter/p
 
 It’s rather radical to drop all data from a table, but in some cases it might be exactly what you need.
 
-More details on [table truncation](/docs/en/sql-reference/statements/truncate.md).
+More details on [table truncation](/docs/sql-reference/statements/truncate.md).

images/knowledgebase/execute-system-queries-in-cloud.md

@@ -1,17 +1,17 @@
 # Execute SYSTEM statements on all nodes in ClickHouse Cloud
 
-In order to execute the same [query](url) on all nodes of a ClickHouse cloud service, we can use [clusterAllReplicas](https://clickhouse.com/docs/en/sql-reference/table-functions/cluster/).
+In order to execute the same [query](url) on all nodes of a ClickHouse cloud service, we can use [clusterAllReplicas](https://clickhouse.com/docs/sql-reference/table-functions/cluster/).
 E.g. in order to get entries from a (node-local) system table from all nodes, you can use:
 ```
 SELECT ... FROM clusterAllReplicas(default, system.TABLE) ...;
 ```
 
-Similarly, you can execute the same [SYSTEM statement](https://clickhouse.com/docs/en/sql-reference/statements/system/) on all nodes with a single statement, by using the [ON CLUSTER](https://clickhouse.com/docs/en/sql-reference/distributed-ddl/) clause:
+Similarly, you can execute the same [SYSTEM statement](https://clickhouse.com/docs/sql-reference/statements/system/) on all nodes with a single statement, by using the [ON CLUSTER](https://clickhouse.com/docs/sql-reference/distributed-ddl/) clause:
 ```
 SYSTEM ... ON CLUSTER default;
 ```
 
-For example for [dropping the filesystem cache](https://clickhouse.com/docs/en/sql-reference/statements/system/#drop-filesystem-cache) from all nodes, you can use:
+For example for [dropping the filesystem cache](https://clickhouse.com/docs/sql-reference/statements/system/#drop-filesystem-cache) from all nodes, you can use:
 ```
 SYSTEM DROP FILESYSTEM CACHE ON CLUSTER default;
 ```

images/knowledgebase/file-export.md

@@ -7,7 +7,7 @@ description: "Add an INTO OUTFILE clause to your query."
 
 ## Using INTO OUTFILE Clause {#using-into-outfile-clause}
 
-Add an [INTO OUTFILE](/docs/en/sql-reference/statements/select/into-outfile.md) clause to your query.
+Add an [INTO OUTFILE](/docs/sql-reference/statements/select/into-outfile.md) clause to your query.
 
 For example:
 

images/knowledgebase/improve-map-performance.md

@@ -1,13 +1,13 @@
 ---
 sidebar_position: 1
-description: "Map lookups such as `a['key']' works with linear complexity (mentioned [here](https://clickhouse.com/docs/en/sql-reference/data-types/map)) and can be inefficient."
+description: "Map lookups such as `a['key']' works with linear complexity (mentioned [here](https://clickhouse.com/docs/sql-reference/data-types/map)) and can be inefficient."
 ---
 
 # Improving Map performance
 
 **Problem**
 
-Map lookup such as `a['key']` works with linear complexity (mentioned [here](https://clickhouse.com/docs/en/sql-reference/data-types/map)) and can be inefficient. This is because selecting a value with a specific key from a table would require iterating through all keys (~M) across all rows (N) in the Map column, resulting in ~MxN lookups.
+Map lookup such as `a['key']` works with linear complexity (mentioned [here](https://clickhouse.com/docs/sql-reference/data-types/map)) and can be inefficient. This is because selecting a value with a specific key from a table would require iterating through all keys (~M) across all rows (N) in the Map column, resulting in ~MxN lookups.
 
 A lookup using Map can be 10x slower than a String column. The experiment below also shows ~10x slowdown for cold query, and difference in multiple magnitudes of data processed (7.21 MB vs 5.65 GB).
 

images/knowledgebase/ingest-parquet-files-in-s3.md

@@ -10,7 +10,7 @@ normal login users usually don't work since they may have been configured with a
 The following is a very simple example that you can use to test the mechanics of accessing your parquet files successfully prior to applying to your actual data.
 
 If you need an example of creating a user and bucket, you can follow the first two sections (create user and create bucket):
-https://clickhouse.com/docs/en/guides/sre/configuring-s3-for-clickhouse-use/
+https://clickhouse.com/docs/guides/sre/configuring-s3-for-clickhouse-use/
 
 I used this sample file: https://github.com/Teradata/kylo/tree/master/samples/sample-data/parquet
 and uploaded it to my test bucket
@@ -41,7 +41,7 @@ You can set the policy something like this on the bucket:
 ```
 
 You can run queries with this type of syntax using the S3 table engine:
-https://clickhouse.com/docs/en/sql-reference/table-functions/s3/
+https://clickhouse.com/docs/sql-reference/table-functions/s3/
 
 ```
 clickhouse-cloud :)  select count(*) from s3('https://mars-doc-test.s3.amazonaws.com/s3-parquet-test/userdata1.parquet','ABC123', 'abc+123', 'Parquet', 'first_name String');
@@ -59,7 +59,7 @@ Query id: fd4f1193-d604-4ac0-9a46-bdd2d5e14727
 ```
 
 The data types reference for parquet format are here:
-https://clickhouse.com/docs/en/interfaces/formats/#data-format-parquet
+https://clickhouse.com/docs/interfaces/formats/#data-format-parquet
 
 To bring in the data into a native ClickHouse table:
 
@@ -128,7 +128,7 @@ When you are ready to import your real data, you can use some special syntax lik
 I'd recommend to filter a few directories and files to test the import, maybe a certain year, a couple months and some date range to test first.
 
 besides the path options here, newly released is syntax `**` which specifies all subdirectories recursively.
-https://clickhouse.com/docs/en/sql-reference/table-functions/s3/
+https://clickhouse.com/docs/sql-reference/table-functions/s3/
 
 For example, assuming the paths and bucket structure is something like this:
 `https://your_s3_bucket.s3.amazonaws.com/<your_folder>/<year>/<month>/<day>/<filename>.parquet`

images/knowledgebase/production.md

@@ -60,5 +60,5 @@ Here is some guidance on how to choose between them:
 Many teams who initially think that `lts` is the way to go often switch to `stable` anyway because of some recent feature that’s important for their product.
 
 :::warning
-One more thing to keep in mind when upgrading ClickHouse: we’re always keeping an eye on compatibility across releases, but sometimes it’s not reasonable to keep and some minor details might change. So make sure you check the [changelog](/docs/en/whats-new/changelog/index.md) before upgrading to see if there are any notes about backward-incompatible changes.
+One more thing to keep in mind when upgrading ClickHouse: we’re always keeping an eye on compatibility across releases, but sometimes it’s not reasonable to keep and some minor details might change. So make sure you check the [changelog](/docs/whats-new/changelog/index.md) before upgrading to see if there are any notes about backward-incompatible changes.
 :::

images/knowledgebase/time-series.md

@@ -11,7 +11,7 @@ ClickHouse is a generic data storage solution for [OLAP](../../faq/general/olap.
 
 First of all, there are **[specialized codecs](../../sql-reference/statements/create/table#specialized-codecs)** which make typical time-series. Either common algorithms like `DoubleDelta` and `Gorilla` or specific to ClickHouse like `T64`.
 
-Second, time-series queries often hit only recent data, like one day or one week old. It makes sense to use servers that have both fast NVMe/SSD drives and high-capacity HDD drives. ClickHouse [TTL](/docs/en/engines/table-engines/mergetree-family/mergetree.md/##table_engine-mergetree-multiple-volumes) feature allows to configure keeping fresh hot data on fast drives and gradually move it to slower drives as it ages. Rollup or removal of even older data is also possible if your requirements demand it.
+Second, time-series queries often hit only recent data, like one day or one week old. It makes sense to use servers that have both fast NVMe/SSD drives and high-capacity HDD drives. ClickHouse [TTL](/docs/engines/table-engines/mergetree-family/mergetree.md/##table_engine-mergetree-multiple-volumes) feature allows to configure keeping fresh hot data on fast drives and gradually move it to slower drives as it ages. Rollup or removal of even older data is also possible if your requirements demand it.
 
 Even though it’s against ClickHouse philosophy of storing and processing raw data, you can use [materialized views](../../sql-reference/statements/create/view.md) to fit into even tighter latency or costs requirements.
 

knowledgebase/calculate_ratio_of_zero_sparse_serialization.mdx

@@ -11,7 +11,7 @@ keywords: ['Empty/Zero Ratio', 'Calculate']
 
 ## How to calculate the ratio of empty/zero values in every column in a table
 
-If a column is sparse (empty or contains mostly zeros), ClickHouse can encode it in a sparse format and automatically optimize calculations - the data does not require full decompression during queries. In fact, if you know how sparse a column is, you can define its ratio using the [`ratio_of_defaults_for_sparse_serialization` setting](https://clickhouse.com/docs/en/operations/settings/merge-tree-settings#ratio_of_defaults_for_sparse_serialization) to optimize serialization.
+If a column is sparse (empty or contains mostly zeros), ClickHouse can encode it in a sparse format and automatically optimize calculations - the data does not require full decompression during queries. In fact, if you know how sparse a column is, you can define its ratio using the [`ratio_of_defaults_for_sparse_serialization` setting](https://clickhouse.com/docs/operations/settings/merge-tree-settings#ratio_of_defaults_for_sparse_serialization) to optimize serialization.
 
 This handy query can take a while, but it analyzes every row in your table and determines the ratio of values that are zero (or the default) in every column in the specified table:
 

knowledgebase/certificate_verify_failed_error.mdx

@@ -45,4 +45,4 @@ Here is an example configuration:
 
 ## Additional resources
 
-View [https://clickhouse.com/docs/en/interfaces/cli/#configuration_files](https://clickhouse.com/docs/en/interfaces/cli/#configuration_files)
+View [https://clickhouse.com/docs/interfaces/cli/#configuration_files](https://clickhouse.com/docs/en/interfaces/cli/#configuration_files)

knowledgebase/file-export.mdx

@@ -11,7 +11,7 @@ keywords: ['Exporting Data', 'INTO OUTFILE', 'File Table Engine']
 
 ## Using INTO OUTFILE Clause {#using-into-outfile-clause}
 
-Add an [INTO OUTFILE](https://clickhouse.com/docs/en/sql-reference/statements/select/into-outfile) clause to your query.
+Add an [INTO OUTFILE](https://clickhouse.com/docs/sql-reference/statements/select/into-outfile) clause to your query.
 
 For example:
 

knowledgebase/how-to-check-my-clickhouse-cloud-sevice-state.mdx

@@ -18,7 +18,7 @@ How do I check my ClickHouse Cloud Service state? I want to check if the Service
 The [ClickHouse Cloud API](/cloud/manage/api/api-overview) is great for checking the status of a cloud service. You need to create an API Key in your service before you can use the Cloud API. You can do this in ClickHouse Cloud [clickhouse.cloud](https://console.clickhouse.cloud):
 
 - [API Overview](/cloud/manage/api/api-overview)
-- [Swagger](https://clickhouse.com/docs/en/cloud/manage/api/swagger)
+- [Swagger](https://clickhouse.com/docs/cloud/manage/api/swagger)
 
 1. To check the status of a service, run the following. Make sure to replace `Key-ID` and `Key-Secret` with your respective details:
 

knowledgebase/how-to-increase-thread-pool-size.mdx

@@ -31,4 +31,4 @@ You can also free up resources if your server has a lot of idle threads - using
 <max_thread_pool_free_size>2000</max_thread_pool_free_size>
 ```
 
-Check out the [docs](https://clickhouse.com/docs/en/operations/server-configuration-parameters/settings#max-thread-pool-size) for more details on the settings above and other settings that affect the Global Thread pool.
+Check out the [docs](https://clickhouse.com/docs/operations/server-configuration-parameters/settings#max-thread-pool-size) for more details on the settings above and other settings that affect the Global Thread pool.

knowledgebase/how_to_use_parametrised_views.mdx

@@ -87,4 +87,4 @@ Query id: 5731aae1-3e68-4e63-b57f-d50f29055744
 1 row in set. Elapsed: 0.004 sec. Processed 319.49 thousand rows, 319.49 KB (76.29 million rows/s., 76.29 MB/s.)
 ```
 
-For more info, please refer to https://clickhouse.com/docs/en/sql-reference/statements/create/view#parameterized-view
+For more info, please refer to https://clickhouse.com/docs/sql-reference/statements/create/view#parameterized-view

knowledgebase/json_extract_example.mdx

@@ -11,7 +11,7 @@ keywords: ['JSON', 'extract base types']
 
 ## JSON Extract example
 
-This is just a short example that illustrates the use of [JSONExtract](https://clickhouse.com/docs/en/sql-reference/functions/json-functions) functions.
+This is just a short example that illustrates the use of [JSONExtract](https://clickhouse.com/docs/sql-reference/functions/json-functions) functions.
 
 Create a table:
 

knowledgebase/kafka-clickhouse-json.mdx

@@ -70,7 +70,7 @@ ENGINE = Kafka(
 );
 ```
 
-Note that we're using the [`JSONAsObject`](https://clickhouse.com/docs/en/interfaces/formats#jsonasobject) format, which will ensure that incoming messages are made available as a JSON object. 
+Note that we're using the [`JSONAsObject`](https://clickhouse.com/docs/interfaces/formats#jsonasobject) format, which will ensure that incoming messages are made available as a JSON object.
 This format can only be parsed into a table that has a single column with the `JSON` type.
 
 Next, we'll create the underlying table to store the Wiki data:

knowledgebase/mysql-to-parquet-csv-json.mdx

@@ -13,7 +13,7 @@ keywords: ['MySQL', 'Parquet', 'CSV', 'JSON']
 
 The `clickhouse-local` tool makes it quick and easy to read data from MySQL and output the data into lots of different formats, including Parquet, CSV, and JSON. We are going to:
 
-- Use the [`mysql` table function](https://clickhouse.com/docs/en/sql-reference/table-functions/mysql) to read the data
+- Use the [`mysql` table function](https://clickhouse.com/docs/sql-reference/table-functions/mysql) to read the data
 - Use the `INTO OUTFILE _filename_ FORMAT` clause and specify the desired output format
 
 The `clickhouse-local` tool is a part of the ClickHouse binary. Download it using the following:

knowledgebase/olap.mdx

@@ -38,7 +38,7 @@ All database management systems could be classified into two groups: OLAP (Onlin
 
 In practice OLAP and OLTP are not categories, it’s more like a spectrum. Most real systems usually focus on one of them but provide some solutions or workarounds if the opposite kind of workload is also desired. This situation often forces businesses to operate multiple storage systems integrated, which might be not so big deal but having more systems make it more expensive to maintain. So the trend of recent years is HTAP (**Hybrid Transactional/Analytical Processing**) when both kinds of the workload are handled equally well by a single database management system.
 
-Even if a DBMS started as a pure OLAP or pure OLTP, they are forced to move towards that HTAP direction to keep up with their competition. And ClickHouse is no exception, initially, it has been designed as [fast-as-possible OLAP system](https://clickhouse.com/docs/en/faq/general/why-clickhouse-is-so-fast) and it still does not have full-fledged transaction support, but some features like consistent read/writes and mutations for updating/deleting data had to be added.
+Even if a DBMS started as a pure OLAP or pure OLTP, they are forced to move towards that HTAP direction to keep up with their competition. And ClickHouse is no exception, initially, it has been designed as [fast-as-possible OLAP system](https://clickhouse.com/docs/faq/general/why-clickhouse-is-so-fast) and it still does not have full-fledged transaction support, but some features like consistent read/writes and mutations for updating/deleting data had to be added.
 
 The fundamental trade-off between OLAP and OLTP systems remains: