Merge branch '3.0' into feature/topic_grammar

Jenkinsfile2

@@ -269,7 +269,7 @@ pipeline {
                     }
                 }
                 stage('linux test') {
-                    agent{label " slave3_0 || slave15 || slave16 || slave17 "}
+                    agent{label " worker03 || slave215 || slave217 || slave219 "}
                     options { skipDefaultCheckout() } 
                     when {
                         changeRequest()
@@ -287,9 +287,9 @@ pipeline {
                                 '''
                                 sh '''
                                     cd ${WKC}/tests/parallel_test
-                                    export DEFAULT_RETRY_TIME=1
+                                    export DEFAULT_RETRY_TIME=2
                                     date
-                                    timeout 2100 time ./run.sh -e -m /home/m.json -t /tmp/cases.task -b ${BRANCH_NAME} -l ${WKDIR}/log -o 480
+                                    timeout 2100 time ./run.sh -e -m /home/m.json -t /tmp/cases.task -b ${BRANCH_NAME}_${BUILD_ID} -l ${WKDIR}/log -o 480
                                 '''
                             }
                         }

cmake/cmake.options

@@ -49,7 +49,7 @@ IF(${TD_WINDOWS})
     option(
         BUILD_TEST 
         "If build unit tests using googletest" 
-        OFF
+        ON
     )
 ELSE ()
 

contrib/test/craft/raftMain.c

@@ -243,7 +243,7 @@ void console(SRaftServer *pRaftServer) {
 
 
 		} else if (strcmp(cmd, "dropnode") == 0) {
-			char host[HOST_LEN];
+			char host[HOST_LEN] = {0};
 			uint32_t port;
 			parseAddr(param1, host, HOST_LEN, &port);
 			uint64_t rid = raftId(host, port);
@@ -258,7 +258,7 @@ void console(SRaftServer *pRaftServer) {
 
 
 		} else if (strcmp(cmd, "put") == 0) {
-			char buf[256];
+			char buf[256] = {0};
 			snprintf(buf, sizeof(buf), "%s--%s", param1, param2);
 			putValue(&pRaftServer->raft, buf);
 

docs-cn/02-intro.md

@@ -62,7 +62,7 @@ TDengine的主要功能如下：
 
 <figure>
 
-![TDengine技术生态图](eco_system.webp)
+![TDengine Database 技术生态图](eco_system.webp)
 
 </figure>
 <center>图 1. TDengine技术生态图</center>

docs-cn/07-develop/03-insert-data/01-sql-writing.mdx

@@ -52,7 +52,7 @@ INSERT INTO d1001 VALUES (1538548685000, 10.3, 219, 0.31) (1538548695000, 12.6,
 
 :::info
 
-- 要提高写入效率，需要批量写入。一批写入的记录条数越多，插入效率就越高。但一条记录不能超过 16K，一条 SQL 语句总长度不能超过 1M 。
+- 要提高写入效率，需要批量写入。一批写入的记录条数越多，插入效率就越高。但一条记录不能超过 48K，一条 SQL 语句总长度不能超过 1M 。
 - TDengine 支持多线程同时写入，要进一步提高写入速度，一个客户端需要打开 20 个以上的线程同时写。但线程数达到一定数量后，无法再提高，甚至还会下降，因为线程频繁切换，带来额外开销。
 
 :::

docs-cn/07-develop/06-subscribe.mdx

@@ -145,7 +145,7 @@ void subscribe_callback(TAOS_SUB* tsub, TAOS_RES *res, void* param, int code) {
 taos_unsubscribe(tsub, keep);
 ```
 
-其第二个参数，用于决定是否在客户端保留订阅的进度信息。如果这个参数是**false**（**0**），那无论下次调用 `taos_subscribe` 时的 `restart` 参数是什么，订阅都只能重新开始。另外，进度信息的保存位置是 _{DataDir}/subscribe/_ 这个目录下，每个订阅有一个与其 `topic` 同名的文件，删掉某个文件，同样会导致下次创建其对应的订阅时只能重新开始。
+其第二个参数，用于决定是否在客户端保留订阅的进度信息。如果这个参数是**false**（**0**），那无论下次调用 `taos_subscribe` 时的 `restart` 参数是什么，订阅都只能重新开始。另外，进度信息的保存位置是 _{DataDir}/subscribe/_ 这个目录下（注：`taos.cfg` 配置文件中 `DataDir` 参数值默认为 **/var/lib/taos/**,但是 Windows 服务器上本身不存在该目录，所以需要在 Windows 的配置文件中修改 `DataDir` 参数值为相应的已存在目录"），每个订阅有一个与其 `topic` 同名的文件，删掉某个文件，同样会导致下次创建其对应的订阅时只能重新开始。
 
 代码介绍完毕，我们来看一下实际的运行效果。假设：
 

docs-cn/10-cluster/01-deploy.md

@@ -22,7 +22,7 @@ title: 集群部署
 
 ### 第二步
 
-建议关闭所有物理节点的防火墙，至少保证端口：6030 - 6042 的 TCP 和 UDP 端口都是开放的。强烈建议先关闭防火墙，集群搭建完毕之后，再来配置端口；
+确保集群中所有主机在端口 6030-6042 上的 TCP/UDP 协议能够互通。
 
 ### 第三步
 

docs-cn/12-taos-sql/03-table.md

@@ -12,7 +12,7 @@ CREATE TABLE [IF NOT EXISTS] tb_name (timestamp_field_name TIMESTAMP, field1_nam
 
 1. 表的第一个字段必须是 TIMESTAMP，并且系统自动将其设为主键；
 2. 表名最大长度为 192；
-3. 表的每行长度不能超过 16k 个字符;（注意：每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置）
+3. 表的每行长度不能超过 48KB;（注意：每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置）
 4. 子表名只能由字母、数字和下划线组成，且不能以数字开头，不区分大小写
 5. 使用数据类型 binary 或 nchar，需指定其最长的字节数，如 binary(20)，表示 20 字节；
 6. 为了兼容支持更多形式的表名，TDengine 引入新的转义符 "\`"，可以让表名与关键词不冲突，同时不受限于上述表名称合法性约束检查。但是同样具有长度限制要求。使用转义字符以后，不再对转义字符中的内容进行大小写统一。

docs-cn/12-taos-sql/04-stable.md

@@ -86,7 +86,7 @@ ALTER STABLE stb_name MODIFY COLUMN field_name data_type(length);
 ALTER STABLE stb_name ADD TAG new_tag_name tag_type;
 ```
 
-为 STable 增加一个新的标签，并指定新标签的类型。标签总数不能超过 128 个，总长度不超过 16k 个字符。
+为 STable 增加一个新的标签，并指定新标签的类型。标签总数不能超过 128 个，总长度不超过 16KB 。
 
 ### 删除标签
 

docs-cn/12-taos-sql/07-function.md

@@ -698,7 +698,7 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } WHERE ts='timestamp' [FILL
 SELECT TAIL(field_name, k, offset_val) FROM {tb_name | stb_name} [WHERE clause];
 ```
 
-**功能说明**：返回跳过最后 offset_value 个，然后取连续 k 个记录，不忽略 NULL 值。offset_val 可以不输入。此时返回最后的 k 个记录。当有 offset_val 输入的情况下，该函数功能等效于 `order by ts desc LIMIT k OFFSET offset_val`。
+**功能说明**：返回跳过最后 offset_val 个，然后取连续 k 个记录，不忽略 NULL 值。offset_val 可以不输入。此时返回最后的 k 个记录。当有 offset_val 输入的情况下，该函数功能等效于 `order by ts desc LIMIT k OFFSET offset_val`。
 
 **参数范围**：k: [1,100] offset_val: [0,100]。
 
@@ -1766,6 +1766,8 @@ SELECT TIMEDIFF(ts_val1 | datetime_string1 | ts_col1, ts_val2 | datetime_string2
           1u(微秒)，1a(毫秒)，1s(秒)，1m(分)，1h(小时)，1d(天)。
 - 如果时间单位 time_unit 未指定， 返回的时间差值精度与当前 DATABASE 设置的时间精度一致。
 
+**支持的版本**：2.6.0.0 及以后的版本。
+
 **示例**：
 
 ```sql

docs-cn/12-taos-sql/08-interval.md

@@ -11,7 +11,7 @@ TDengine 支持按时间段窗口切分方式进行聚合结果查询，比如
 
 INTERVAL 子句用于产生相等时间周期的窗口，SLIDING 用以指定窗口向前滑动的时间。每次执行的查询是一个时间窗口，时间窗口随着时间流动向前滑动。在定义连续查询的时候需要指定时间窗口（time window ）大小和每次前向增量时间（forward sliding times）。如图，[t0s, t0e] ，[t1s , t1e]， [t2s, t2e] 是分别是执行三次连续查询的时间窗口范围，窗口的前向滑动的时间范围 sliding time 标识 。查询过滤、聚合等操作按照每个时间窗口为独立的单位执行。当 SLIDING 与 INTERVAL 相等的时候，滑动窗口即为翻转窗口。
 
-![时间窗口示意图](./timewindow-1.webp)
+![TDengine Database 时间窗口示意图](./timewindow-1.webp)
 
 INTERVAL 和 SLIDING 子句需要配合聚合和选择函数来使用。以下 SQL 语句非法：
 
@@ -33,7 +33,7 @@ _ 从 2.1.5.0 版本开始，INTERVAL 语句允许的最短时间间隔调整为
 
 使用整数（布尔值）或字符串来标识产生记录时候设备的状态量。产生的记录如果具有相同的状态量数值则归属于同一个状态窗口，数值改变后该窗口关闭。如下图所示，根据状态量确定的状态窗口分别是[2019-04-28 14:22:07，2019-04-28 14:22:10]和[2019-04-28 14:22:11，2019-04-28 14:22:12]两个。（状态窗口暂不支持对超级表使用）
 
-![时间窗口示意图](./timewindow-3.webp)
+![TDengine Database 时间窗口示意图](./timewindow-3.webp)
 
 使用 STATE_WINDOW 来确定状态窗口划分的列。例如：
 
@@ -45,7 +45,7 @@ SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status);
 
 会话窗口根据记录的时间戳主键的值来确定是否属于同一个会话。如下图所示，如果设置时间戳的连续的间隔小于等于 12 秒，则以下 6 条记录构成 2 个会话窗口，分别是：[2019-04-28 14:22:10，2019-04-28 14:22:30]和[2019-04-28 14:23:10，2019-04-28 14:23:30]。因为 2019-04-28 14:22:30 与 2019-04-28 14:23:10 之间的时间间隔是 40 秒，超过了连续时间间隔（12 秒）。
 
-![时间窗口示意图](./timewindow-2.webp)
+![TDengine Database 时间窗口示意图](./timewindow-2.webp)
 
 在 tol_value 时间间隔范围内的结果都认为归属于同一个窗口，如果连续的两条记录的时间超过 tol_val，则自动开启下一个窗口。（会话窗口暂不支持对超级表使用）
 

docs-cn/12-taos-sql/09-limit.md

@@ -7,9 +7,9 @@ title: 边界限制
 
 - 数据库名最大长度为 32。
 - 表名最大长度为 192，不包括数据库名前缀和分隔符
-- 每行数据最大长度 16k 个字符, 从 2.1.7.0 版本开始，每行数据最大长度 48k 个字符（注意：数据行内每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置）。
+- 每行数据最大长度 48KB （注意：数据行内每个 BINARY/NCHAR 类型的列还会额外占用 2 个字节的存储位置）。
 - 列名最大长度为 64，最多允许 4096 列，最少需要 2 列，第一列必须是时间戳。注：从 2.1.7.0 版本（不含)以前最多允许 4096 列
-- 标签名最大长度为 64，最多允许 128 个，至少要有 1 个标签，一个表中标签值的总长度不超过 16k 个字符。
+- 标签名最大长度为 64，最多允许 128 个，至少要有 1 个标签，一个表中标签值的总长度不超过 16KB 。
 - SQL 语句最大长度 1048576 个字符，也可通过客户端配置参数 maxSQLLength 修改，取值范围 65480 ~ 1048576。
 - SELECT 语句的查询结果，最多允许返回 4096 列（语句中的函数调用可能也会占用一些列空间），超限时需要显式指定较少的返回数据列，以避免语句执行报错。注： 2.1.7.0 版本（不含）之前为最多允许 1024 列
 - 库的数目，超级表的数目、表的数目，系统不做限制，仅受系统资源限制。

docs-cn/12-taos-sql/12-keywords/index.md

@@ -23,17 +23,17 @@ title: TDengine 参数限制与保留关键字
 去掉了 `` ‘“`\ `` (单双引号、撇号、反斜杠、空格)
 
 - 数据库名：不能包含“.”以及特殊字符，不能超过 32 个字符
-- 表名：不能包含“.”以及特殊字符，与所属数据库名一起，不能超过 192 个字符，每行数据最大长度 16k 个字符
-- 表的列名：不能包含特殊字符，不能超过 64 个字符
+- 表名：不能包含“.”以及特殊字符，与所属数据库名一起，不能超过 192 个字节 ，每行数据最大长度 48KB
+- 表的列名：不能包含特殊字符，不能超过 64 个字节
 - 数据库名、表名、列名，都不能以数字开头，合法的可用字符集是“英文字符、数字和下划线”
 - 表的列数：不能超过 1024 列，最少需要 2 列，第一列必须是时间戳（从 2.1.7.0 版本开始，改为最多支持 4096 列）
-- 记录的最大长度：包括时间戳 8 byte，不能超过 16KB（每个 BINARY/NCHAR 类型的列还会额外占用 2 个 byte 的存储位置）
-- 单条 SQL 语句默认最大字符串长度：1048576 byte，但可通过系统配置参数 maxSQLLength 修改，取值范围 65480 ~ 1048576 byte
+- 记录的最大长度：包括时间戳 8 字节，不能超过 48KB（每个 BINARY/NCHAR 类型的列还会额外占用 2 个 字节 的存储位置）
+- 单条 SQL 语句默认最大字符串长度：1048576 字节，但可通过系统配置参数 maxSQLLength 修改，取值范围 65480 ~ 1048576 字节
 - 数据库副本数：不能超过 3
-- 用户名：不能超过 23 个 byte
-- 用户密码：不能超过 15 个 byte
+- 用户名：不能超过 23 个 字节
+- 用户密码：不能超过 15 个 字节
 - 标签(Tags)数量：不能超过 128 个，可以 0 个
-- 标签的总长度：不能超过 16K byte
+- 标签的总长度：不能超过 16KB
 - 记录条数：仅受存储空间限制
 - 表的个数：仅受节点个数限制
 - 库的个数：仅受节点个数限制

docs-cn/12-taos-sql/index.md

@@ -7,8 +7,6 @@ description: "TAOS SQL 支持的语法规则、主要查询功能、支持的 SQ
 
 TAOS SQL 是用户对 TDengine 进行数据写入和查询的主要工具。TAOS SQL 为了便于用户快速上手，在一定程度上提供与标准 SQL 类似的风格和模式。严格意义上，TAOS SQL 并不是也不试图提供标准的 SQL 语法。此外，由于 TDengine 针对的时序性结构化数据不提供删除功能，因此在 TAO SQL 中不提供数据删除的相关功能。
 
-TAOS SQL 不支持关键字的缩写，例如 DESCRIBE 不能缩写为 DESC。
-
 本章节 SQL 语法遵循如下约定：
 
 - <\> 里的内容是用户需要输入的，但不要输入 <\> 本身
@@ -37,4 +35,4 @@ import DocCardList from '@theme/DocCardList';
 import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
 
 <DocCardList items={useCurrentSidebarCategory().items}/>
-```
\ No newline at end of file
+```

docs-cn/14-reference/03-connector/03-connector.mdx

@@ -4,7 +4,7 @@ title: 连接器
 
 TDengine 提供了丰富的应用程序开发接口，为了便于用户快速开发自己的应用，TDengine 支持了多种编程语言的连接器，其中官方连接器包括支持 C/C++、Java、Python、Go、Node.js、C# 和 Rust 的连接器。这些连接器支持使用原生接口（taosc）和 REST 接口（部分语言暂不支持）连接 TDengine 集群。社区开发者也贡献了多个非官方连接器，例如 ADO.NET 连接器、Lua 连接器和 PHP 连接器。
 
-![image-connector](./connector.webp)
+![TDengine Database connector architecture](./connector.webp)
 
 ## 支持的平台
 

docs-cn/14-reference/03-connector/java.mdx

@@ -11,7 +11,7 @@ import TabItem from '@theme/TabItem';
 
 `taos-jdbcdriver` 是 TDengine 的官方 Java 语言连接器，Java 开发人员可以通过它开发存取 TDengine 数据库的应用软件。`taos-jdbcdriver` 实现了 JDBC driver 标准的接口，并提供两种形式的连接器。一种是通过 TDengine 客户端驱动程序（taosc）原生连接 TDengine 实例，支持数据写入、查询、订阅、schemaless 接口和参数绑定接口等功能，一种是通过 taosAdapter 提供的 REST 接口连接 TDengine 实例（2.4.0.0 及更高版本）。REST 连接实现的功能集合和原生连接有少量不同。
 
-![tdengine-connector](tdengine-jdbc-connector.webp)
+![TDengine Database Connector Java](tdengine-jdbc-connector.webp)
 
 上图显示了两种 Java 应用使用连接器访问 TDengine 的两种方式：
 

docs-cn/14-reference/03-connector/node.mdx

@@ -14,7 +14,6 @@ import NodeInfluxLine from "../../07-develop/03-insert-data/_js_line.mdx";
 import NodeOpenTSDBTelnet from "../../07-develop/03-insert-data/_js_opts_telnet.mdx";
 import NodeOpenTSDBJson from "../../07-develop/03-insert-data/_js_opts_json.mdx";
 import NodeQuery from "../../07-develop/04-query-data/_js.mdx";
-import NodeAsyncQuery from "../../07-develop/04-query-data/_js_async.mdx";
 
 `td2.0-connector` 和 `td2.0-rest-connector` 是 TDengine 的官方 Node.js 语言连接器。Node.js 开发人员可以通过它开发可以存取 TDengine 集群数据的应用软件。
 
@@ -189,14 +188,8 @@ let cursor = conn.cursor();
 
 ### 查询数据
 
-#### 同步查询
-
 <NodeQuery />
 
-#### 异步查询
-
-<NodeAsyncQuery />
-
 ## 更多示例程序
 
 | 示例程序                                                                                                                                   | 示例程序描述                           |

docs-cn/14-reference/04-taosadapter.md

@@ -24,7 +24,7 @@ taosAdapter 提供以下功能：
 
 ## taosAdapter 架构图
 
-![taosAdapter Architecture](taosAdapter-architecture.webp)
+![TDengine Database taosAdapter Architecture](taosAdapter-architecture.webp)
 
 ## taosAdapter 部署方法
 

docs-cn/14-reference/07-tdinsight/index.md

@@ -233,25 +233,25 @@ sudo systemctl enable grafana-server
 
 指向 **Configurations** -> **Data Sources** 菜单，然后点击 **Add data source** 按钮。
 
-![添加数据源按钮](./assets/howto-add-datasource-button.webp)
+![TDengine Database TDinsight 添加数据源按钮](./assets/howto-add-datasource-button.webp)
 
 搜索并选择**TDengine**。
 
-![添加数据源](./assets/howto-add-datasource-tdengine.webp)
+![TDengine Database TDinsight 添加数据源](./assets/howto-add-datasource-tdengine.webp)
 
 配置 TDengine 数据源。
 
-![数据源配置](./assets/howto-add-datasource.webp)
+![TDengine Database TDinsight 数据源配置](./assets/howto-add-datasource.webp)
 
 保存并测试，正常情况下会报告 'TDengine Data source is working'。
 
-![数据源测试](./assets/howto-add-datasource-test.webp)
+![TDengine Database TDinsight 数据源测试](./assets/howto-add-datasource-test.webp)
 
 ### 导入仪表盘
 
 指向 **+** / **Create** - **import**（或 `/dashboard/import` url）。
 
-![导入仪表盘和配置](./assets/import_dashboard.webp)
+![TDengine Database TDinsight 导入仪表盘和配置](./assets/import_dashboard.webp)
 
 在 **Import via grafana.com** 位置键入仪表盘 ID `15167` 并 **Load**。
 
@@ -259,7 +259,7 @@ sudo systemctl enable grafana-server
 
 导入完成后，TDinsight 的完整页面视图如下所示。
 
-![显示](./assets/TDinsight-full.webp)
+![TDengine Database TDinsight 显示](./assets/TDinsight-full.webp)
 
 ## TDinsight 仪表盘详细信息
 
@@ -269,7 +269,7 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### 集群状态
 
-![tdinsight-mnodes-overview](./assets/TDinsight-1-cluster-status.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-1-cluster-status.webp)
 
 这部分包括集群当前信息和状态，告警信息也在此处（从左到右，从上到下）。
 
@@ -289,7 +289,7 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### DNodes 状态
 
-![tdinsight-mnodes-overview](./assets/TDinsight-2-dnodes.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-2-dnodes.webp)
 
 - **DNodes Status**：`show dnodes` 的简单表格视图。
 - **DNodes Lifetime**：从创建 dnode 开始经过的时间。
@@ -298,14 +298,14 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### MNode 概述
 
-![tdinsight-mnodes-overview](./assets/TDinsight-3-mnodes.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-3-mnodes.webp)
 
 1. **MNodes Status**：`show mnodes` 的简单表格视图。
 2. **MNodes Number**：类似于`DNodes Number`，MNodes 数量变化。
 
 ### 请求
 
-![tdinsight-requests](./assets/TDinsight-4-requests.webp)
+![TDengine Database TDinsight requests](./assets/TDinsight-4-requests.webp)
 
 1. **Requests Rate(Inserts per Second)**：平均每秒插入次数。
 2. **Requests (Selects)**：查询请求数及变化率（count of second）。
@@ -313,7 +313,7 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### 数据库
 
-![tdinsight-database](./assets/TDinsight-5-database.webp)
+![TDengine Database TDinsight database](./assets/TDinsight-5-database.webp)
 
 数据库使用情况，对变量 `$database` 的每个值即每个数据库进行重复多行展示。
 
@@ -325,7 +325,7 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### DNode 资源使用情况
 
-![dnode-usage](./assets/TDinsight-6-dnode-usage.webp)
+![TDengine Database TDinsight dnode-usage](./assets/TDinsight-6-dnode-usage.webp)
 
 数据节点资源使用情况展示，对变量 `$fqdn` 即每个数据节点进行重复多行展示。包括：
 
@@ -346,13 +346,13 @@ TDinsight 仪表盘旨在提供 TDengine 相关资源使用情况[dnodes, mnodes
 
 ### 登录历史
 
-![登录历史](./assets/TDinsight-7-login-history.webp)
+![TDengine Database TDinsight 登录历史](./assets/TDinsight-7-login-history.webp)
 
 目前只报告每分钟登录次数。
 
 ### 监控 taosAdapter
 
-![taosadapter](./assets/TDinsight-8-taosadapter.webp)
+![TDengine Database TDinsight monitor taosadapter](./assets/TDinsight-8-taosadapter.webp)
 
 支持监控 taosAdapter 请求统计和状态详情。包括：
 

docs-cn/14-reference/12-config/index.md

@@ -80,7 +80,7 @@ taos --dump-config
 | 补充说明 | RESTful 服务在 2.4.0.0 之前（不含）由 taosd 提供，默认端口为 6041; 在 2.4.0.0 及后续版本由 taosAdapter，默认端口为 6041 |
 
 :::note
-对于端口，TDengine 会使用从 serverPort 起 13 个连续的 TCP 和 UDP 端口号，请务必在防火墙打开。因此如果是缺省配置，需要打开从 6030 到 6042 共 13 个端口，而且必须 TCP 和 UDP 都打开。（详细的端口情况请参见下表）
+确保集群中所有主机在端口 6030-6042 上的 TCP/UDP 协议能够互通。（详细的端口情况请参见下表）
 :::
 | 协议 | 默认端口 | 用途说明 | 修改方法 |
 | :--- | :-------- | :---------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- |
@@ -590,7 +590,7 @@ charset 的有效值是 UTF-8。
 | 适用范围 | 仅服务端适用                         |
 | 含义     | 每个 DB 中 能够使用的最大 vnode 个数 |
 | 取值范围 | 0-8192                               |
-| 缺省值   |                                      |
+| 缺省值   | 0                                     |
 
 ### maxTablesPerVnode
 

docs-cn/14-reference/13-schemaless/13-schemaless.md

@@ -82,7 +82,7 @@ st,t1=3,t2=4,t3=t3 c1=3i64,c3="passit",c2=false,c4=4f64 1626006833639000000
 
 :::tip
 无模式所有的处理逻辑，仍会遵循 TDengine 对数据结构的底层限制，例如每行数据的总长度不能超过
-16k 字节。这方面的具体限制约束请参见 [TAOS SQL 边界限制](/taos-sql/limit)
+48KB。这方面的具体限制约束请参见 [TAOS SQL 边界限制](/taos-sql/limit)
 
 :::
 

docs-cn/20-third-party/01-grafana.mdx

@@ -64,15 +64,15 @@ GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=tdengine-datasource
 
 用户可以直接通过 http://localhost:3000 的网址，登录 Grafana 服务器（用户名/密码：admin/admin），通过左侧 `Configuration -> Data Sources` 可以添加数据源，如下图所示：
 
-![img](./add_datasource1.webp)
+![TDengine Database Grafana plugin add data source](./add_datasource1.webp)
 
 点击 `Add data source` 可进入新增数据源页面，在查询框中输入 TDengine 可选择添加，如下图所示：
 
-![img](./add_datasource2.webp)
+![TDengine Database Grafana plugin add data source](./add_datasource2.webp)
 
 进入数据源配置页面，按照默认提示修改相应配置即可：
 
-![img](./add_datasource3.webp)
+![TDengine Database Grafana plugin add data source](./add_datasource3.webp)
 
 - Host： TDengine 集群中提供 REST 服务 （在 2.4 之前由 taosd 提供， 从 2.4 开始由 taosAdapter 提供）的组件所在服务器的 IP 地址与 TDengine REST 服务的端口号(6041)，默认 http://localhost:6041。
 - User：TDengine 用户名。
@@ -80,13 +80,13 @@ GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=tdengine-datasource
 
 点击 `Save & Test` 进行测试，成功会有如下提示：
 
-![img](./add_datasource4.webp)
+![TDengine Database Grafana plugin add data source](./add_datasource4.webp)
 
 ### 创建 Dashboard
 
 回到主界面创建 Dashboard，点击 Add Query 进入面板查询页面：
 
-![img](./create_dashboard1.webp)
+![TDengine Database Grafana plugin create dashboard](./create_dashboard1.webp)
 
 如上图所示，在 Query 中选中 `TDengine` 数据源，在下方查询框可输入相应 SQL 进行查询，具体说明如下：
 
@@ -96,7 +96,7 @@ GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=tdengine-datasource
 
 按照默认提示查询当前 TDengine 部署所在服务器指定间隔系统内存平均使用量如下：
 
-![img](./create_dashboard2.webp)
+![TDengine Database Grafana plugin create dashboard](./create_dashboard2.webp)
 
 > 关于如何使用 Grafana 创建相应的监测界面以及更多有关使用 Grafana 的信息，请参考 Grafana 官方的[文档](https://grafana.com/docs/)。
 

docs-cn/20-third-party/09-emq-broker.md

@@ -45,25 +45,25 @@ MQTT 是流行的物联网数据传输协议，[EMQX](https://github.com/emqx/em
 
 使用浏览器打开网址 http://IP:18083 并登录 EMQX Dashboard。初次安装用户名为 `admin` 密码为：`public`
 
-![img](./emqx/login-dashboard.webp)
+![TDengine Database EMQX login dashboard](./emqx/login-dashboard.webp)
 
 ### 创建规则（Rule）
 
 选择左侧“规则引擎（Rule Engine）”中的“规则（Rule）”并点击“创建（Create）”按钮：
 
-![img](./emqx/rule-engine.webp)
+![TDengine Database EMQX rule engine](./emqx/rule-engine.webp)
 
 ### 编辑 SQL 字段
 
-![img](./emqx/create-rule.webp)
+![TDengine Database EMQX create rule](./emqx/create-rule.webp)
 
 ### 新增“动作（action handler）”
 
-![img](./emqx/add-action-handler.webp)
+![TDengine Database EMQX](./emqx/add-action-handler.webp)
 
 ### 新增“资源（Resource）”
 
-![img](./emqx/create-resource.webp)
+![TDengine Database EMQX create resource](./emqx/create-resource.webp)
 
 选择“发送数据到 Web 服务“并点击“新建资源”按钮：
 
@@ -71,13 +71,13 @@ MQTT 是流行的物联网数据传输协议，[EMQX](https://github.com/emqx/em
 
 选择“发送数据到 Web 服务“并填写 请求 URL 为 运行 taosAdapter 的服务器地址和端口（默认为 6041）。其他属性请保持默认值。
 
-![img](./emqx/edit-resource.webp)
+![TDengine Database EMQX edit resource](./emqx/edit-resource.webp)
 
 ### 编辑“动作（action）”
 
 编辑资源配置，增加 Authorization 认证的键/值配对项，相关文档请参考[ TDengine REST API 文档](https://docs.taosdata.com/reference/rest-api/)。在消息体中输入规则引擎替换模板。
 
-![img](./emqx/edit-action.webp)
+![TDengine Database EMQX edit action](./emqx/edit-action.webp)
 
 ## 编写模拟测试程序
 
@@ -164,7 +164,7 @@ MQTT 是流行的物联网数据传输协议，[EMQX](https://github.com/emqx/em
 
 注意：代码中 CLIENT_NUM 在开始测试中可以先设置一个较小的值，避免硬件性能不能完全处理较大并发客户端数量。
 
-![img](./emqx/client-num.webp)
+![TDengine Database EMQX client num](./emqx/client-num.webp)
 
 ## 执行测试模拟发送 MQTT 数据
 
@@ -173,19 +173,19 @@ npm install mqtt mockjs --save --registry=https://registry.npm.taobao.org
 node mock.js
 ```
 
-![img](./emqx/run-mock.webp)
+![TDengine Database EMQX run-mock](./emqx/run-mock.webp)
 
 ## 验证 EMQX 接收到数据
 
 在 EMQX Dashboard 规则引擎界面进行刷新，可以看到有多少条记录被正确接收到：
 
-![img](./emqx/check-rule-matched.webp)
+![TDengine Database EMQX rule matched](./emqx/check-rule-matched.webp)
 
 ## 验证数据写入到 TDengine
 
 使用 TDengine CLI 程序登录并查询相应数据库和表，验证数据是否被正确写入到 TDengine 中：
 
-![img](./emqx/check-result-in-taos.webp)
+![TDengine Database EMQX result in taos](./emqx/check-result-in-taos.webp)
 
 TDengine 详细使用方法请参考 [TDengine 官方文档](https://docs.taosdata.com/)。
 EMQX 详细使用方法请参考 [EMQX 官方文档](https://www.emqx.io/docs/zh/v4.4/rule/rule-engine.html)。

docs-cn/20-third-party/11-kafka.md

@@ -9,11 +9,11 @@ TDengine Kafka Connector 包含两个插件: TDengine Source Connector 和 TDeng
 
 Kafka Connect 是 Apache Kafka 的一个组件，用于使其它系统，比如数据库、云服务、文件系统等能方便地连接到 Kafka。数据既可以通过 Kafka Connect 从其它系统流向 Kafka, 也可以通过 Kafka Connect 从 Kafka 流向其它系统。从其它系统读数据的插件称为 Source Connector, 写数据到其它系统的插件称为 Sink Connector。Source Connector 和 Sink Connector 都不会直接连接 Kafka Broker，Source Connector 把数据转交给 Kafka Connect。Sink Connector 从 Kafka Connect 接收数据。
 
-![](kafka/Kafka_Connect.webp)
+![TDengine Database Kafka Connector -- Kafka Connect structure](kafka/Kafka_Connect.webp)
 
 TDengine Source Connector 用于把数据实时地从 TDengine 读出来发送给 Kafka Connect。TDengine Sink Connector 用于 从 Kafka Connect 接收数据并写入 TDengine。
 
-![](kafka/streaming-integration-with-kafka-connect.webp)
+![TDengine Database Kafka Connector -- streaming integration with kafka connect](kafka/streaming-integration-with-kafka-connect.webp)
 
 ## 什么是 Confluent？
 
@@ -26,7 +26,7 @@ Confluent 在 Kafka 的基础上增加很多扩展功能。包括：
 5. 管理和监控 Kafka 的 GUI —— Confluent 控制中心
 
 这些扩展功能有的包含在社区版本的 Confluent 中，有的只有企业版能用。
-![](kafka/confluentPlatform.webp)
+![TDengine Database Kafka Connector -- Confluent introduction](kafka/confluentPlatform.webp)
 
 Confluent 企业版提供了 `confluent` 命令行工具管理各个组件。
 

docs-cn/21-tdinternal/01-arch.md

@@ -11,7 +11,7 @@ TDengine 的设计是基于单个硬件、软件系统不可靠，基于任何
 
 TDengine 分布式架构的逻辑结构图如下：
 
-![TDengine架构示意图](./structure.webp)
+![TDengine Database 架构示意图](./structure.webp)
 
 <center> 图 1 TDengine架构示意图  </center>
 
@@ -41,7 +41,7 @@ TDengine 分布式架构的逻辑结构图如下：
 - 集群数据节点对外提供 RESTful 服务占用一个 TCP 端口，是 serverPort+11。
 - 集群内数据节点与 Arbitrator 节点之间通讯占用一个 TCP 端口，是 serverPort+12。
 
-因此一个数据节点总的端口范围为 serverPort 到 serverPort+12，总共 13 个 TCP/UDP 端口。使用时，需要确保防火墙将这些端口打开。每个数据节点可以配置不同的 serverPort。详细的端口情况请参见 [TDengine 2.0 端口说明](/train-faq/faq#port)
+因此一个数据节点总的端口范围为 serverPort 到 serverPort+12，总共 13 个 TCP/UDP 端口。确保集群中所有主机在端口 6030-6042 上的 TCP/UDP 协议能够互通。详细的端口情况请参见 [TDengine 2.0 端口说明](/train-faq/faq#port)
 
 **集群对外连接：**TDengine 集群可以容纳单个、多个甚至几千个数据节点。应用只需要向集群中任何一个数据节点发起连接即可，连接需要提供的网络参数是一数据节点的 End Point（FQDN 加配置的端口号）。通过命令行 CLI 启动应用 taos 时，可以通过选项-h 来指定数据节点的 FQDN，-P 来指定其配置的端口号，如果端口不配置，将采用 TDengine 的系统配置参数 serverPort。
 
@@ -63,7 +63,7 @@ TDengine 分布式架构的逻辑结构图如下：
 
 为解释 vnode、mnode、taosc 和应用之间的关系以及各自扮演的角色，下面对写入数据这个典型操作的流程进行剖析。
 
-![TDengine典型的操作流程](./message.webp)
+![TDengine Database 典型的操作流程](./message.webp)
 
 <center> 图 2 TDengine 典型的操作流程 </center>
 
@@ -135,7 +135,7 @@ TDengine 除 vnode 分片之外，还对时序数据按照时间段进行分区
 
 Master Vnode 遵循下面的写入流程：
 
-![TDengine Master写入流程](./write_master.webp)
+![TDengine Database Master写入流程](./write_master.webp)
 
 <center> 图 3 TDengine Master 写入流程  </center>
 
@@ -150,7 +150,7 @@ Master Vnode 遵循下面的写入流程：
 
 对于 slave vnode，写入流程是：
 
-![TDengine Slave 写入流程](./write_slave.webp)
+![TDengine Database Slave 写入流程](./write_slave.webp)
 
 <center> 图 4 TDengine Slave 写入流程  </center>
 
@@ -284,7 +284,7 @@ SELECT COUNT(*) FROM d1001 WHERE ts >= '2017-7-14 00:00:00' AND ts < '2017-7-14
 
 TDengine 对每个数据采集点单独建表，但在实际应用中经常需要对不同的采集点数据进行聚合。为高效的进行聚合操作，TDengine 引入超级表（STable）的概念。超级表用来代表一特定类型的数据采集点，它是包含多张表的表集合，集合里每张表的模式（schema）完全一致，但每张表都带有自己的静态标签，标签可以有多个，可以随时增加、删除和修改。应用可通过指定标签的过滤条件，对一个 STable 下的全部或部分表进行聚合或统计操作，这样大大简化应用的开发。其具体流程如下图所示：
 
-![多表聚合查询原理图](./multi_tables.webp)
+![TDengine Database 多表聚合查询原理图](./multi_tables.webp)
 
 <center> 图 5 多表聚合查询原理图  </center>
 

docs-cn/25-application/01-telegraf.md

@@ -16,7 +16,7 @@ IT 运维监测数据通常都是对时间特性比较敏感的数据，例如
 
 本文介绍不需要写一行代码，通过简单修改几行配置文件，就可以快速搭建一个基于 TDengine + Telegraf + Grafana 的 IT 运维系统。架构如下图：
 
-![IT-DevOps-Solutions-Telegraf.webp](./IT-DevOps-Solutions-Telegraf.webp)
+![TDengine Database IT-DevOps-Solutions-Telegraf](./IT-DevOps-Solutions-Telegraf.webp)
 
 ## 安装步骤
 
@@ -75,7 +75,7 @@ sudo systemctl start telegraf
 点击左侧齿轮图标并选择 `Plugins`，应该可以找到 TDengine data source 插件图标。
 点击左侧加号图标并选择 `Import`，从 `https://github.com/taosdata/grafanaplugin/blob/master/examples/telegraf/grafana/dashboards/telegraf-dashboard-v0.1.0.json` 下载 dashboard JSON 文件后导入。之后可以看到如下界面的仪表盘：
 
-![IT-DevOps-Solutions-telegraf-dashboard.webp]./IT-DevOps-Solutions-telegraf-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-telegraf-dashboard](./IT-DevOps-Solutions-telegraf-dashboard.webp)
 
 ## 总结
 

docs-cn/25-application/02-collectd.md

@@ -16,7 +16,7 @@ IT 运维监测数据通常都是对时间特性比较敏感的数据，例如
 
 本文介绍不需要写一行代码，通过简单修改几行配置文件，就可以快速搭建一个基于 TDengine + collectd / statsD + Grafana 的 IT 运维系统。架构如下图：
 
-![IT-DevOps-Solutions-Collectd-StatsD.webp](./IT-DevOps-Solutions-Collectd-StatsD.webp)
+![TDengine Database IT-DevOps-Solutions-Collectd-StatsD](./IT-DevOps-Solutions-Collectd-StatsD.webp)
 
 ## 安装步骤
 
@@ -81,12 +81,12 @@ repeater 部分添加 { host:'<TDengine server/cluster host>', port: <port for S
 
 从 https://github.com/taosdata/grafanaplugin/blob/master/examples/collectd/grafana/dashboards/collect-metrics-with-tdengine-v0.1.0.json 下载 dashboard json 文件，点击左侧加号图标并选择 `Import`，按照界面提示选择 JSON 文件导入。之后可以看到如下界面的仪表盘：
 
-![IT-DevOps-Solutions-collectd-dashboard.webp](./IT-DevOps-Solutions-collectd-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-collectd-dashboard](./IT-DevOps-Solutions-collectd-dashboard.webp)
 
 #### 导入 StatsD 仪表盘
 
 从 `https://github.com/taosdata/grafanaplugin/blob/master/examples/statsd/dashboards/statsd-with-tdengine-v0.1.0.json` 下载 dashboard json 文件，点击左侧加号图标并选择 `Import`，按照界面提示导入 JSON 文件。之后可以看到如下界面的仪表盘：
-![IT-DevOps-Solutions-statsd-dashboard.webp](./IT-DevOps-Solutions-statsd-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-statsd-dashboard](./IT-DevOps-Solutions-statsd-dashboard.webp)
 
 ## 总结
 

docs-cn/25-application/03-immigrate.md

@@ -27,7 +27,7 @@ title: OpenTSDB 应用迁移到 TDengine 的最佳实践
 一个典型的 DevOps 应用场景的系统整体的架构如下图（图 1） 所示。
 
 **图 1. DevOps 场景中典型架构**
-![IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch.webp "图1. DevOps 场景中典型架构")
+![TDengine Database IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch.webp "图1. DevOps 场景中典型架构")
 
 在该应用场景中，包含了部署在应用环境中负责收集机器度量（Metrics）、网络度量（Metrics）以及应用度量（Metrics）的 Agent 工具、汇聚 Agent 收集信息的数据收集器，数据持久化存储和管理的系统以及监控数据可视化工具（例如：Grafana 等）。
 
@@ -70,7 +70,7 @@ LoadPlugin write_tsdb
 TDengine 提供了默认的两套 Dashboard 模板，用户只需要将 Grafana 目录下的模板导入到 Grafana 中即可激活使用。
 
 **图 2. 导入 Grafana 模板**
-![](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard.webp "图2. 导入 Grafana 模板")
+![TDengine Database IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard.webp "图2. 导入 Grafana 模板")
 
 操作完以上步骤后，就完成了将 OpenTSDB 替换成为 TDengine 的迁移工作。可以看到整个流程非常简单，不需要写代码，只需要对某些配置文件进行调整即可完成全部的迁移工作。
 
@@ -83,7 +83,7 @@ TDengine 提供了默认的两套 Dashboard 模板，用户只需要将 Grafana
 如果你的应用特别复杂，或者应用领域并不是 DevOps 场景，你可以继续阅读后续的章节，更加全面深入地了解将 OpenTSDB 的应用迁移到 TDengine 的高级话题。
 
 **图 3. 迁移完成后的系统架构**
-![IT-DevOps-Solutions-Immigrate-TDengine-Arch](./IT-DevOps-Solutions-Immigrate-TDengine-Arch.webp "图 3. 迁移完成后的系统架构")
+![TDengine Database IT-DevOps-Solutions-Immigrate-TDengine-Arch](./IT-DevOps-Solutions-Immigrate-TDengine-Arch.webp "图 3. 迁移完成后的系统架构")
 
 ## 其他场景的迁移评估与策略
 

docs-cn/27-train-faq/01-faq.md

@@ -33,15 +33,15 @@ title: 常见问题及反馈
 
 ### 2. Windows 平台下 JDBCDriver 找不到动态链接库，怎么办？
 
-请看为此问题撰写的[技术博客](https://www.taosdata.com/blog/2019/12/03/950.html)。
+请看为此问题撰写的 [技术博客](https://www.taosdata.com/blog/2019/12/03/950.html)。
 
 ### 3. 创建数据表时提示 more dnodes are needed
 
-请看为此问题撰写的[技术博客](https://www.taosdata.com/blog/2019/12/03/965.html)。
+请看为此问题撰写的 [技术博客](https://www.taosdata.com/blog/2019/12/03/965.html)。
 
 ### 4. 如何让 TDengine crash 时生成 core 文件？
 
-请看为此问题撰写的[技术博客](https://www.taosdata.com/blog/2019/12/06/974.html)。
+请看为此问题撰写的 [技术博客](https://www.taosdata.com/blog/2019/12/06/974.html)。
 
 ### 5. 遇到错误“Unable to establish connection” 怎么办？
 
@@ -61,7 +61,7 @@ title: 常见问题及反馈
 
 5. ping 服务器 FQDN，如果没有反应，请检查你的网络，DNS 设置，或客户端所在计算机的系统 hosts 文件。如果部署的是 TDengine 集群，客户端需要能 ping 通所有集群节点的 FQDN。
 
-6. 检查防火墙设置（Ubuntu 使用 ufw status，CentOS 使用 firewall-cmd --list-port），确认 TCP/UDP 端口 6030-6042 是打开的
+6. 检查防火墙设置（Ubuntu 使用 ufw status，CentOS 使用 firewall-cmd --list-port），确保集群中所有主机在端口 6030-6042 上的 TCP/UDP 协议能够互通。
 
 7. 对于 Linux 上的 JDBC（ODBC, Python, Go 等接口类似）连接, 确保*libtaos.so*在目录*/usr/local/taos/driver*里, 并且*/usr/local/taos/driver*在系统库函数搜索路径*LD_LIBRARY_PATH*里
 
@@ -128,19 +128,30 @@ properties.setProperty(TSDBDriver.LOCALE_KEY, "UTF-8");
 Connection = DriverManager.getConnection(url, properties);
 ```
 
-### 13.JDBC 报错： the executed SQL is not a DML or a DDL？
+### 13.  Windows 系统下客户端无法正常显示中文字符？
+
+Windows 系统中一般是采用 GBK/GB18030 存储中文字符，而 TDengine 的默认字符集为 UTF-8 ，在 Windows 系统中使用 TDengine 客户端时，客户端驱动会将字符统一转换为 UTF-8 编码后发送到服务端存储，因此在应用开发过程中，调用接口时正确配置当前的中文字符集即可。
+
+【 v2.2.1.5以后版本 】在 Windows 10 环境下运行 TDengine 客户端命令行工具 taos 时，若无法正常输入、显示中文，可以对客户端 taos.cfg 做如下配置：
+
+```
+locale C 
+charset UTF-8
+```
+
+### 14. JDBC 报错： the executed SQL is not a DML or a DDL？
 
 请更新至最新的 JDBC 驱动，参考 [Java 连接器](/reference/connector/java)
 
-### 14. taos connect failed, reason: invalid timestamp
+### 15. taos connect failed, reason: invalid timestamp
 
 常见原因是服务器和客户端时间没有校准，可以通过和时间服务器同步的方式（Linux 下使用 ntpdate 命令，Windows 在系统时间设置中选择自动同步）校准。
 
-### 15. 表名显示不全
+### 16. 表名显示不全
 
 由于 taos shell 在终端中显示宽度有限，有可能比较长的表名显示不全，如果按照显示的不全的表名进行相关操作会发生 Table does not exist 错误。解决方法可以是通过修改 taos.cfg 文件中的设置项 maxBinaryDisplayWidth， 或者直接输入命令 set max_binary_display_width 100。或者在命令结尾使用 \G 参数来调整结果的显示方式。
 
-### 16. 如何进行数据迁移？
+### 17. 如何进行数据迁移？
 
 TDengine 是根据 hostname 唯一标志一台机器的，在数据文件从机器 A 移动机器 B 时，注意如下两件事：
 
@@ -148,7 +159,7 @@ TDengine 是根据 hostname 唯一标志一台机器的，在数据文件从机
  - 2.0.7.0 及以后的版本，到/var/lib/taos/dnode 下，修复 dnodeEps.json 的 dnodeId 对应的 FQDN，重启。确保机器内所有机器的此文件是完全相同的。
  - 1.x 和 2.x 版本的存储结构不兼容，需要使用迁移工具或者自己开发应用导出导入数据。
 
-### 17. 如何在命令行程序 taos 中临时调整日志级别
+### 18. 如何在命令行程序 taos 中临时调整日志级别
 
 为了调试方便，从 2.0.16 版本开始，命令行程序 taos 新增了与日志记录相关的两条指令：
 
@@ -169,7 +180,7 @@ ALTER LOCAL RESETLOG;
 
 <a class="anchor" id="timezone"></a>
 
-### 18. go 语言编写组件编译失败怎样解决？
+### 19. go 语言编写组件编译失败怎样解决？
 
 TDengine 2.3.0.0 及之后的版本包含一个使用 go 语言开发的 taosAdapter 独立组件，需要单独运行，取代之前 taosd 内置的 httpd ，提供包含原 httpd 功能以及支持多种其他软件（Prometheus、Telegraf、collectd、StatsD 等）的数据接入功能。
 使用最新 develop 分支代码编译需要先 `git submodule update --init --recursive` 下载 taosAdapter 仓库代码后再编译。
@@ -184,7 +195,7 @@ go env -w GOPROXY=https://goproxy.cn,direct
 如果希望继续使用之前的内置 httpd，可以关闭 taosAdapter 编译，使用
 `cmake .. -DBUILD_HTTP=true` 使用原来内置的 httpd。
 
-### 19. 如何查询数据占用的存储空间大小？
+### 20. 如何查询数据占用的存储空间大小？
 
 默认情况下，TDengine 的数据文件存储在 /var/lib/taos ，日志文件存储在 /var/log/taos 。
 
@@ -193,3 +204,38 @@ go env -w GOPROXY=https://goproxy.cn,direct
 若想查看单个数据库占用的大小，可在命令行程序 taos 内指定要查看的数据库后执行 `show vgroups;` ，通过得到的 VGroup id 去 /var/lib/taos/vnode 下查看包含的文件夹大小。
 
 若仅仅想查看指定（超级）表的数据块分布及大小，可查看[_block_dist 函数](https://docs.taosdata.com/taos-sql/select/#_block_dist-%E5%87%BD%E6%95%B0)
+
+### 21. 客户端连接串如何保证高可用？
+
+请看为此问题撰写的 [技术博客](https://www.taosdata.com/blog/2021/04/16/2287.html)
+
+### 22. 时间戳的时区信息是怎样处理的？
+
+TDengine 中时间戳的时区总是由客户端进行处理，而与服务端无关。具体来说，客户端会对 SQL 语句中的时间戳进行时区转换，转为 UTC 时区（即 Unix 时间戳——Unix Timestamp）再交由服务端进行写入和查询；在读取数据时，服务端也是采用 UTC 时区提供原始数据，客户端收到后再根据本地设置，把时间戳转换为本地系统所要求的时区进行显示。
+
+客户端在处理时间戳字符串时，会采取如下逻辑：
+
+1. 在未做特殊设置的情况下，客户端默认使用所在操作系统的时区设置。
+2. 如果在 taos.cfg 中设置了 timezone 参数，则客户端会以这个配置文件中的设置为准。
+3. 如果在 C/C++/Java/Python 等各种编程语言的 Connector Driver 中，在建立数据库连接时显式指定了 timezone，那么会以这个指定的时区设置为准。例如 Java Connector 的 JDBC URL 中就有 timezone 参数。
+4. 在书写 SQL 语句时，也可以直接使用 Unix 时间戳（例如 `1554984068000`）或带有时区的时间戳字符串，也即以 RFC 3339 格式（例如 `2013-04-12T15:52:01.123+08:00`）或 ISO-8601 格式（例如 `2013-04-12T15:52:01.123+0800`）来书写时间戳，此时这些时间戳的取值将不再受其他时区设置的影响。
+
+### 23. TDengine 2.0 都会用到哪些网络端口？
+
+使用到的网络端口请看文档：[serverport](/reference/config/#serverport)
+
+需要注意，文档上列举的端口号都是以默认端口 6030 为前提进行说明，如果修改了配置文件中的设置，那么列举的端口都会随之出现变化，管理员可以参考上述的信息调整防火墙设置。
+
+### 24. 为什么 RESTful 接口无响应、Grafana 无法添加 TDengine 为数据源、TDengineGUI 选了 6041 端口还是无法连接成功？？
+
+taosAdapter 从 TDengine 2.4.0.0 版本开始成为 TDengine 服务端软件的组成部分，是 TDengine 集群和应用程序之间的桥梁和适配器。在此之前 RESTful 接口等功能是由 taosd 内置的 HTTP 服务提供的，而如今要实现上述功能需要执行：```systemctl start taosadapter``` 命令来启动 taosAdapter 服务。
+
+需要说明的是，taosAdapter 的日志路径 path 需要单独配置，默认路径是 /var/log/taos ；日志等级 logLevel 有 8 个等级，默认等级是 info ，配置成 panic 可关闭日志输出。请注意操作系统 / 目录的空间大小，可通过命令行参数、环境变量或配置文件来修改配置，默认配置文件是 /etc/taos/taosadapter.toml 。
+
+有关 taosAdapter 组件的详细介绍请看文档：[taosAdapter](https://docs.taosdata.com/reference/taosadapter/)
+
+### 25. 发生了 OOM 怎么办？
+
+OOM 是操作系统的保护机制，当操作系统内存(包括 SWAP )不足时，会杀掉某些进程，从而保证操作系统的稳定运行。通常内存不足主要是如下两个原因导致，一是剩余内存小于 vm.min_free_kbytes ；二是程序请求的内存大于剩余内存。还有一种情况是内存充足但程序占用了特殊的内存地址，也会触发 OOM 。
+
+TDengine 会预先为每个 VNode 分配好内存，每个 Database 的 VNode 个数受 maxVgroupsPerDb 影响，每个 VNode 占用的内存大小受 Blocks 和 Cache 影响。要防止 OOM，需要在项目建设之初合理规划内存，并合理设置 SWAP ，除此之外查询过量的数据也有可能导致内存暴涨，这取决于具体的查询语句。TDengine 企业版对内存管理做了优化，采用了新的内存分配器，对稳定性有更高要求的用户可以考虑选择企业版。

docs-en/02-intro/index.md

@@ -54,7 +54,7 @@ With TDengine, the total cost of ownership of your time-series data platform can
 ## Technical Ecosystem
 This is how TDengine would be situated, in a typical time-series data processing platform:
 
-![TDengine Technical Ecosystem ](eco_system.webp)
+![TDengine Database Technical Ecosystem ](eco_system.webp)
 
 <center>Figure 1. TDengine Technical Ecosystem</center>
 

docs-en/05-get-started/index.md

@@ -130,7 +130,7 @@ After TDengine server is running，execute `taosBenchmark` (previously named tao
 taosBenchmark
 ```
 
-This command will create a super table "meters" under database "test". Under "meters", 10000 tables are created with names from "d0" to "d9999". Each table has 10000 rows and each row has four columns (ts, current, voltage, phase). Time stamp is starting from "2017-07-14 10:40:00 000" to "2017-07-14 10:40:09 999". Each table has tags "location" and "groupId". groupId is set 1 to 10 randomly, and location is set to "California.SanFrancisco" or "California.SanDieo".
+This command will create a super table "meters" under database "test". Under "meters", 10000 tables are created with names from "d0" to "d9999". Each table has 10000 rows and each row has four columns (ts, current, voltage, phase). Time stamp is starting from "2017-07-14 10:40:00 000" to "2017-07-14 10:40:09 999". Each table has tags "location" and "groupId". groupId is set 1 to 10 randomly, and location is set to "California.SanFrancisco" or "California.SanDiego".
 
 This command will insert 100 million rows into the database quickly. Time to insert depends on the hardware configuration, it only takes a dozen seconds for a regular PC server.            
 

docs-en/07-develop/01-connect/index.md

 ---
-sidebar_label: Connection
-title: Connect to TDengine
+sidebar_label: Connect
+title: Connect
 description: "This document explains how to establish connections to TDengine, and briefly introduces how to install and use TDengine connectors."
 ---
 

docs-en/07-develop/02-model/index.mdx

@@ -2,19 +2,26 @@
 title: Data Model
 ---
 
-The data model employed by TDengine is similar to a relational database, you need to create databases and tables. Design the data model based on your own application scenarios and you should design the STable (abbreviation for super table) schema to fit your data. This chapter will explain the big picture without getting into syntax details.
+The data model employed by TDengine is similar to that of a relational database. You have to create databases and tables. You must design the data model based on your own business and application requirements. You should design the STable (an abbreviation for super table) schema to fit your data. This chapter will explain the big picture without getting into syntactical details.
 
 ## Create Database
 
-The characteristics of data from different data collection points may be different, such as collection frequency, days to keep, number of replicas, data block size, whether it's allowed to update data, etc. For TDengine to operate with the best performance, it's strongly suggested to put the data with different characteristics into different databases because different storage policies can be set for each database. When creating a database, there are a lot of parameters that can be configured, such as the days to keep data, the number of replicas, the number of memory blocks, time precision, the minimum and maximum number of rows in each data block, compress or not, the time range of the data in single data file, etc. Below is an example of the SQL statement for creating a database.
+The [characteristics of time-series data](https://www.taosdata.com/blog/2019/07/09/86.html) from different data collection points may be different. Characteristics include collection frequency, retention policy and others which determine how you create and configure the database. For e.g. days to keep, number of replicas, data block size, whether data updates are allowed and other configurable parameters would be determined by the characteristics of your data and your business requirements. For TDengine to operate with the best performance, we strongly recommend that you create and configure different databases for data with different characteristics. This allows you, for example, to set up different storage and retention policies. When creating a database, there are a lot of parameters that can be configured such as, the days to keep data, the number of replicas, the number of memory blocks, time precision, the minimum and maximum number of rows in each data block, whether compression is enabled, the time range of the data in single data file and so on. Below is an example of the SQL statement to create a database.
 
 ```sql
 CREATE DATABASE power KEEP 365 DAYS 10 BLOCKS 6 UPDATE 1;
 ```
 
-In the above SQL statement, a database named "power" will be created, the data in it will be kept for 365 days, which means the data older than 365 days will be deleted automatically, a new data file will be created every 10 days, the number of memory blocks is 6, data is allowed to be updated. For more details please refer to [Database](/taos-sql/database).
+In the above SQL statement:
+- a database named "power" will be created
+- the data in it will be kept for 365 days, which means that data older than 365 days will be deleted automatically
+- a new data file will be created every 10 days
+- the number of memory blocks is 6
+- data is allowed to be updated
 
-After creating a database, the current database in use can be switched using SQL command `USE`, for example below SQL statement switches the current database to `power`. Without the current database specified, table name must be preceded with the corresponding database name.
+For more details please refer to [Database](/taos-sql/database).
+
+After creating a database, the current database in use can be switched using SQL command `USE`. For example the SQL statement below switches the current database to `power`. Without the current database specified, table name must be preceded with the corresponding database name.
 
 ```sql
 USE power;
@@ -30,7 +37,7 @@ USE power;
 
 ## Create STable
 
-In a time-series application, there may be multiple kinds of data collection points. For example, in the electrical power system there are meters, transformers, bus bars, switches, etc. For easy and efficient aggregation of multiple tables, one STable needs to be created for each kind of data collection point. For example, for the meters in [table 1](/tdinternal/arch#model_table1), the below SQL statement can be used to create the super table.
+In a time-series application, there may be multiple kinds of data collection points. For example, in the electrical power system there are meters, transformers, bus bars, switches, etc. For easy and efficient aggregation of multiple tables, one STable needs to be created for each kind of data collection point. For example, for the meters in [table 1](/tdinternal/arch#model_table1), the SQL statement below can be used to create the super table.
 
 ```sql
 CREATE STable meters (ts timestamp, current float, voltage int, phase float) TAGS (location binary(64), groupId int);
@@ -41,15 +48,15 @@ If you are using versions prior to 2.0.15, the `STable` keyword needs to be repl
 
 :::
 
-Similar to creating a regular table, when creating a STable, the name and schema need to be provided. In the STable schema, the first column must be timestamp (like ts in the example), and the other columns (like current, voltage and phase in the example) are the data collected. The column type can be integer, float, double, string ,etc. Besides, the schema for tags need to be provided, like location and groupId in the example. The tag type can be integer, float, string, etc. The static properties of a data collection point can be defined as tags, like the location, device type, device group ID, manager ID, etc. Tags in the schema can be added, removed or updated. Please refer to [STable](/taos-sql/stable) for more details.
+Similar to creating a regular table, when creating a STable, the name and schema need to be provided. In the STable schema, the first column must always be a timestamp (like ts in the example), and the other columns (like current, voltage and phase in the example) are the data collected. The remaining columns can [contain data of type](/taos-sql/data-type/) integer, float, double, string etc. In addition, the schema for tags, like location and groupId in the example, must be provided. The tag type can be integer, float, string, etc. Tags are essentially the static properties of a data collection point. For example, properties like the location, device type, device group ID, manager ID are tags. Tags in the schema can be added, removed or updated. Please refer to [STable](/taos-sql/stable) for more details.
 
-For each kind of data collection point, a corresponding STable must be created. There may be many STables in an application. For electrical power system, we need to create a STable respectively for meters, transformers, busbars, switches. There may be multiple kinds of data collection points on a single device, for example there may be one data collection point for electrical data like current and voltage and another point for environmental data like temperature, humidity and wind direction, multiple STables are required for such kind of device.
+For each kind of data collection point, a corresponding STable must be created. There may be many STables in an application. For electrical power system, we need to create a STable respectively for meters, transformers, busbars, switches. There may be multiple kinds of data collection points on a single device, for example there may be one data collection point for electrical data like current and voltage and another data collection point for environmental data like temperature, humidity and wind direction. Multiple STables are required for these kinds of devices.
 
 At most 4096 (or 1024 prior to version 2.1.7.0) columns are allowed in a STable. If there are more than 4096 of metrics to be collected for a data collection point, multiple STables are required. There can be multiple databases in a system, while one or more STables can exist in a database.
 
 ## Create Table
 
-A specific table needs to be created for each data collection point. Similar to RDBMS, table name and schema are required to create a table. Beside, one or more tags can be created for each table. To create a table, a STable needs to be used as template and the values need to be specified for the tags. For example, for the meters in [Table 1](/tdinternal/arch#model_table1), the table can be created using below SQL statement.
+A specific table needs to be created for each data collection point. Similar to RDBMS, table name and schema are required to create a table. Additionally, one or more tags can be created for each table. To create a table, a STable needs to be used as template and the values need to be specified for the tags. For example, for the meters in [Table 1](/tdinternal/arch#model_table1), the table can be created using below SQL statement.
 
 ```sql
 CREATE TABLE d1001 USING meters TAGS ("California.SanFrancisco", 2);
@@ -57,17 +64,17 @@ CREATE TABLE d1001 USING meters TAGS ("California.SanFrancisco", 2);
 
 In the above SQL statement, "d1001" is the table name, "meters" is the STable name, followed by the value of tag "Location" and the value of tag "groupId", which are "California.SanFrancisco" and "2" respectively in the example. The tag values can be updated after the table is created. Please refer to [Tables](/taos-sql/table) for details.
 
-In TDengine system, it's recommended to create a table for a data collection point via STable. A table created via STable is called subtable in some parts of the TDengine documentation. All SQL commands applied on regular tables can be applied on subtables.
+In the TDengine system, it's recommended to create a table for a data collection point via STable. A table created via STable is called subtable in some parts of the TDengine documentation. All SQL commands applied on regular tables can be applied on subtables.
 
 :::warning
 It's not recommended to create a table in a database while using a STable from another database as template.
 
 :::tip
-It's suggested to use the global unique ID of a data collection point as the table name, for example the device serial number. If there isn't such a unique ID, multiple IDs that are not global unique can be combined to form a global unique ID. It's not recommended to use a global unique ID as tag value.
+It's suggested to use the globally unique ID of a data collection point as the table name. For example the device serial number could be used as a unique ID. If a unique ID doesn't exist, multiple IDs that are not globally unique can be combined to form a globally unique ID. It's not recommended to use a globally unique ID as tag value.
 
 ## Create Table Automatically
 
-In some circumstances, it's unknown whether the table already exists when inserting rows. The table can be created automatically using the SQL statement below, and nothing will happen if the table already exist.
+In some circumstances, it's unknown whether the table already exists when inserting rows. The table can be created automatically using the SQL statement below, and nothing will happen if the table already exists.
 
 ```sql
 INSERT INTO d1001 USING meters TAGS ("California.SanFrancisco", 2) VALUES (now, 10.2, 219, 0.32);
@@ -79,6 +86,8 @@ For more details please refer to [Create Table Automatically](/taos-sql/insert#a
 
 ## Single Column vs Multiple Column
 
-A multiple columns data model is supported in TDengine. As long as multiple metrics are collected by the same data collection point at the same time, i.e. the timestamp are identical, these metrics can be put in a single STable as columns. However, there is another kind of design, i.e. single column data model, a table is created for each metric, which means a STable is required for each kind of metric. For example, 3 STables are required for current, voltage and phase.
+A multiple columns data model is supported in TDengine. As long as multiple metrics are collected by the same data collection point at the same time, i.e. the timestamps are identical, these metrics can be put in a single STable as columns. 
+
+However, there is another kind of design, i.e. single column data model in which a table is created for each metric. This means that a STable is required for each kind of metric. For example in a single column model, 3 STables would be required for current, voltage and phase.
 
-It's recommended to use a multiple column data model as much as possible because it's better in the performance of inserting or querying rows. In some cases, however, the metrics to be collected vary frequently and correspondingly the STable schema needs to be changed frequently too. In such case, it's more convenient to use single column data model.
+It's recommended to use a multiple column data model as much as possible because insert and query performance is higher. In some cases, however, the collected metrics may vary frequently and so the corresponding STable schema needs to be changed frequently too. In such cases, it's more convenient to use single column data model.

docs-en/07-develop/03-insert-data/01-sql-writing.mdx

 ---
-sidebar_label: SQL
+sidebar_label: Insert Using SQL
 title: Insert Using SQL
 ---
 
@@ -52,7 +52,7 @@ For more details about `INSERT` please refer to [INSERT](/taos-sql/insert).
 
 :::info
 
-- Inserting in batches can improve performance. Normally, the higher the batch size, the better the performance. Please note that a single row can't exceed 16K bytes and each SQL statement can't exceed 1MB.
+- Inserting in batches can improve performance. Normally, the higher the batch size, the better the performance. Please note that a single row can't exceed 48K bytes and each SQL statement can't exceed 1MB.
 - Inserting with multiple threads can also improve performance. However, depending on the system resources on the application side and the server side, when the number of inserting threads grows beyond a specific point the performance may drop instead of improving. The proper number of threads needs to be tested in a specific environment to find the best number.
 
 :::

docs-en/07-develop/03-insert-data/02-influxdb-line.mdx

@@ -15,13 +15,13 @@ import CLine from "./_c_line.mdx";
 
 ## Introduction
 
-A single line of text is used in InfluxDB Line protocol format represents one row of data, each line contains 4 parts as shown below.
+In the InfluxDB Line protocol format, a single line of text is used to represent one row of data. Each line contains 4 parts as shown below.
 
 ```
 measurement,tag_set field_set timestamp
 ```
 
-- `measurement` will be used as the STable name
+- `measurement` will be used as the name of the STable
 - `tag_set` will be used as tags, with format like `<tag_key>=<tag_value>,<tag_key>=<tag_value>`
 - `field_set`will be used as data columns, with format like `<field_key>=<field_value>,<field_key>=<field_value>`
 - `timestamp`  is the primary key timestamp corresponding to this row of data
@@ -34,8 +34,8 @@ meters,location=California.LoSangeles,groupid=2 current=13.4,voltage=223,phase=0
 
 :::note
 
-- All the data in `tag_set` will be converted to ncahr type automatically .
-- Each data in `field_set` must be self-description for its data type. For example 1.2f32 means a value 1.2 of float type, it will be treated as double without the "f" type suffix.
+- All the data in `tag_set` will be converted to nchar type automatically .
+- Each data in `field_set` must be self-descriptive for its data type. For example 1.2f32 means a value 1.2 of float type. Without the "f" type suffix, it will be treated as type double.
 - Multiple kinds of precision can be used for the `timestamp` field. Time precision can be from nanosecond (ns) to hour (h).
 
 :::

docs-en/07-develop/03-insert-data/03-opentsdb-telnet.mdx

@@ -15,7 +15,7 @@ import CTelnet from "./_c_opts_telnet.mdx";
 
 ## Introduction
 
-A single line of text is used in OpenTSDB line protocol to represent one row of data. OpenTSDB employs single column data model, so one line can only contain a single data column. There can be multiple tags. Each line contains 4 parts as below:
+A single line of text is used in OpenTSDB line protocol to represent one row of data. OpenTSDB employs a single column data model, so each line can only contain a single data column. There can be multiple tags. Each line contains 4 parts as below:
 
 ```
 <metric> <timestamp> <value> <tagk_1>=<tagv_1>[ <tagk_n>=<tagv_n>]
@@ -60,7 +60,7 @@ Please refer to [OpenTSDB Telnet API](http://opentsdb.net/docs/build/html/api_te
   </TabItem>
 </Tabs>
 
-2 STables will be crated automatically while each STable has 4 rows of data in the above sample code.
+2 STables will be created automatically and each STable has 4 rows of data in the above sample code.
 
 ```cmd
 taos> use test;

docs-en/07-develop/03-insert-data/04-opentsdb-json.mdx

@@ -47,7 +47,7 @@ Please refer to [OpenTSDB HTTP API](http://opentsdb.net/docs/build/html/api_http
 
 :::note
 - In JSON protocol, strings will be converted to nchar type and numeric values will be converted to double type.
-- Only data in array format is accepted, array must be used even there is only one row.
+- Only data in array format is accepted and so an array must be used even if there is only one row.
 
 :::
 

docs-en/07-develop/03-insert-data/index.md

 ---
-title: Insert
+title: Insert Data
 ---
 
 TDengine supports multiple protocols of inserting data, including SQL, InfluxDB Line protocol, OpenTSDB Telnet protocol, and OpenTSDB JSON protocol. Data can be inserted row by row, or in batches. Data from one or more collection points can be inserted simultaneously. Data can be inserted with multiple threads, and out of order data and historical data can be inserted as well. InfluxDB Line protocol, OpenTSDB Telnet protocol and OpenTSDB JSON protocol are the 3 kinds of schemaless insert protocols supported by TDengine. It's not necessary to create STables and tables in advance if using schemaless protocols, and the schemas can be adjusted automatically based on the data being inserted.

docs-en/07-develop/04-query-data/_category_.yml

-label: Select Data
+label: Query Data

docs-en/07-develop/04-query-data/index.mdx

 ---
-Sidebar_label: Select
-title: Select
+Sidebar_label: Query data
+title: Query data
 description: "This chapter introduces major query functionalities and how to perform sync and async query using connectors."
 ---
 
@@ -20,7 +20,7 @@ import CAsync from "./_c_async.mdx";
 
 ## Introduction
 
-SQL is used by TDengine as the query language. Application programs can send SQL statements to TDengine through REST API or connectors. TDengine CLI `taos` can also be used to execute SQL Ad-Hoc queries. Here is the list of major query functionalities supported by TDengine：
+SQL is used by TDengine as its query language. Application programs can send SQL statements to TDengine through REST API or connectors. TDengine's CLI `taos` can also be used to execute ad hoc SQL queries. Here is the list of major query functionalities supported by TDengine：
 
 - Query on single column or multiple columns
 - Filter on tags or data columns：>, <, =, <\>, like
@@ -31,7 +31,7 @@ SQL is used by TDengine as the query language. Application programs can send SQL
 - Join query with timestamp alignment
 - Aggregate functions: count, max, min, avg, sum, twa, stddev, leastsquares, top, bottom, first, last, percentile, apercentile, last_row, spread, diff
 
-For example, the SQL statement below can be executed in TDengine CLI `taos` to select the rows whose voltage column is bigger than 215 and limit the output to only 2 rows.
+For example, the SQL statement below can be executed in TDengine CLI `taos` to select records with voltage greater than 215 and limit the output to only 2 rows.
 
 ```sql
 select * from d1001 where voltage > 215 order by ts desc limit 2;
@@ -46,46 +46,46 @@ taos> select * from d1001 where voltage > 215 order by ts desc limit 2;
 Query OK, 2 row(s) in set (0.001100s)
 ```
 
-To meet the requirements of many use cases, some special functions have been added in TDengine, for example `twa` (Time Weighted Average), `spared` (The difference between the maximum and the minimum), and `last_row` (the last row). Furthermore, continuous query is also supported in TDengine.
+To meet the requirements of varied use cases, some special functions have been added in TDengine. Some examples are `twa` (Time Weighted Average), `spread` (The difference between the maximum and the minimum), and `last_row` (the last row). Furthermore, continuous query is also supported in TDengine.
 
 For detailed query syntax please refer to [Select](/taos-sql/select).
 
 ## Aggregation among Tables
 
-In many use cases, there are always multiple kinds of data collection points. A new concept, called STable (abbreviated for super table), is used in TDengine to represent a kind of data collection point, and a subtable is used to represent a specific data collection point. Tags are used by TDengine to represent the static properties of data collection points. A specific data collection point has its own values for static properties. By specifying filter conditions on tags, aggregation can be performed efficiently among all the subtables created via the same STable, i.e. same kind of data collection points. Aggregate functions applicable for tables can be used directly on STables, the syntax is exactly the same.
+In most use cases, there are always multiple kinds of data collection points. A new concept, called STable (abbreviation for super table), is used in TDengine to represent one type of data collection point, and a subtable is used to represent a specific data collection point of that type. Tags are used by TDengine to represent the static properties of data collection points. A specific data collection point has its own values for static properties. By specifying filter conditions on tags, aggregation can be performed efficiently among all the subtables created via the same STable, i.e. same type of data collection points. Aggregate functions applicable for tables can be used directly on STables; the syntax is exactly the same.
 
-In summary, for a STable, its subtables can be aggregated by a simple query on the STable, it's a kind of join operation. But tables belong to different STables can not be aggregated. 
+In summary, records across subtables can be aggregated by a simple query on their STable. It is like a join operation. However, tables belonging to different STables can not be aggregated. 
 
 ### Example 1
 
-In TDengine CLI `taos`, use below SQL to get the average voltage of all the meters in California grouped by location.
+In TDengine CLI `taos`, use the SQL below to get the average voltage of all the meters in California grouped by location.
 
 ```
 taos> SELECT AVG(voltage) FROM meters GROUP BY location;
        avg(voltage)        |            location            |
 =============================================================
-             222.000000000 | California.LoSangeles                |
+             222.000000000 | California.LosAngeles                |
              219.200000000 | California.SanFrancisco               |
 Query OK, 2 row(s) in set (0.002136s)
 ```
 
 ### Example 2
 
-In TDengine CLI `taos`, use below SQL to get the number of rows and the maximum current in the past 24 hours from meters whose groupId is 2.
+In TDengine CLI `taos`, use the SQL below to get the number of rows and the maximum current in the past 24 hours from meters whose groupId is 2.
 
 ```
 taos> SELECT count(*), max(current) FROM meters where groupId = 2 and ts > now - 24h;
-     cunt(*)  |    max(current)  |
+     count(*)  |    max(current)  |
 ==================================
             5 |             13.4 |
 Query OK, 1 row(s) in set (0.002136s)
 ```
 
-Join queries are only allowed between the subtables of the same STable. In [Select](/taos-sql/select), all query operations are marked as to whether they supports STables or not.
+Join queries are only allowed between subtables of the same STable. In [Select](/taos-sql/select), all query operations are marked as to whether they support STables or not.
 
 ## Down Sampling and Interpolation
 
-In IoT use cases, down sampling is widely used to aggregate the data by time range. The `INTERVAL` keyword in TDengine can be used to simplify the query by time window. For example, the SQL statement below can be used to get the sum of current every 10 seconds from meters table d1001.
+In IoT use cases, down sampling is widely used to aggregate data by time range. The `INTERVAL` keyword in TDengine can be used to simplify the query by time window. For example, the SQL statement below can be used to get the sum of current every 10 seconds from meters table d1001.
 
 ```
 taos> SELECT sum(current) FROM d1001 INTERVAL(10s);
@@ -169,7 +169,7 @@ In the section describing [Insert](/develop/insert-data/sql-writing), a database
 
 ### Asynchronous Query
 
-Besides synchronous queries, an asynchronous query API is also provided by TDengine to insert or query data more efficiently. With a similar hardware and software environment, the async API is 2~4 times faster than sync APIs. Async API works in non-blocking mode, which means an operation can be returned without finishing so that the calling thread can switch to other works to improve the performance of the whole application system. Async APIs perform especially better in the case of poor networks.
+Besides synchronous queries, an asynchronous query API is also provided by TDengine to insert or query data more efficiently. With a similar hardware and software environment, the async API is 2~4 times faster than sync APIs. Async API works in non-blocking mode, which means an operation can be returned without finishing so that the calling thread can switch to other work to improve the performance of the whole application system. Async APIs perform especially better in the case of poor networks.
 
 Please note that async query can only be used with a native connection.
 

docs-en/07-develop/05-continuous-query.mdx

 ---
 sidebar_label: Continuous Query
-description: "Continuous query is a query that's executed automatically according to predefined frequency to provide aggregate query capability by time window, it's actually a simplified time driven stream computing."
+description: "Continuous query is a query that's executed automatically at a predefined frequency to provide aggregate query capability by time window. It is essentially simplified, time driven, stream computing."
 title: "Continuous Query"
 ---
 
-Continuous query is a query that's executed automatically according to a predefined frequency to provide aggregate query capability by time window, it's actually a simplified time driven stream computing. Continuous query can be performed on a table or STable in TDengine. The result of continuous query can be pushed to clients or written back to TDengine. Each query is executed on a time window, which moves forward with time. The size of time window and the forward sliding time need to be specified with parameter `INTERVAL` and `SLIDING` respectively.
+A continuous query is a query that's executed automatically at a predefined frequency to provide aggregate query capability by time window. It is essentially simplified, time driven, stream computing. A continuous query can be performed on a table or STable in TDengine. The results of a continuous query can be pushed to clients or written back to TDengine. Each query is executed on a time window, which moves forward with time. The size of time window and the forward sliding time need to be specified with parameter `INTERVAL` and `SLIDING` respectively.
 
-Continuous query in TDengine is time driven, and can be defined using TAOS SQL directly without any extra operations. With continuous query, the result can be generated according to a time window to achieve down sampling of the original data. Once a continuous query is defined using TAOS SQL, the query is automatically executed at the end of each time window and the result is pushed back to clients or written to TDengine.
+A continuous query in TDengine is time driven, and can be defined using TAOS SQL directly without any extra operations. With a continuous query, the result can be generated based on a time window to achieve down sampling of the original data. Once a continuous query is defined using TAOS SQL, the query is automatically executed at the end of each time window and the result is pushed back to clients or written to TDengine.
 
 There are some differences between continuous query in TDengine and time window computation in stream computing：
 
@@ -35,7 +35,7 @@ In this section the use case of meters will be used to introduce how to use cont
 ```sql
 create table meters (ts timestamp, current float, voltage int, phase float) tags (location binary(64), groupId int);
 create table D1001 using meters tags ("California.SanFrancisco", 2);
-create table D1002 using meters tags ("California.LoSangeles", 2);
+create table D1002 using meters tags ("California.LosAngeles", 2);
 ```
 
 The SQL statement below retrieves the average voltage for a one minute time window, with each time window moving forward by 30 seconds.
@@ -68,7 +68,7 @@ taos> select * from avg_vol;
  2020-07-29 13:39:00.000 |            223.0800000 |
 ```
 
-Please note that the minimum allowed time window is 10 milliseconds, and no upper limit.
+Please note that the minimum allowed time window is 10 milliseconds, and there is no upper limit.
 
 It's possible to specify the start and end time of a continuous query. If the start time is not specified, the timestamp of the first row will be considered as the start time; if the end time is not specified, the continuous query will be performed indefinitely, otherwise it will be terminated once the end time is reached. For example, the continuous query in the SQL statement below will be started from now and terminated one hour later.
 

docs-en/07-develop/06-subscribe.mdx

 ---
-sidebar_label: Subscription
-description: "Lightweight service for data subscription and pushing, the time series data inserted into TDengine continuously can be pushed automatically to the subscribing clients."
+sidebar_label: Data Subscription
+description: "Lightweight service for data subscription and publishing. Time series data inserted into TDengine continuously can be pushed automatically to subscribing clients."
 title: Data Subscription
 ---
 
@@ -16,9 +16,9 @@ import CDemo from "./_sub_c.mdx";
 
 ## Introduction
 
-Due to the nature of time series data, data inserting in TDengine is similar to data publishing in message queues. Data is stored in ascending order of timestamp inside TDengine, so each table in TDengine can essentially be considered as a message queue.
+Due to the nature of time series data, data insertion into TDengine is similar to data publishing in message queues. Data is stored in ascending order of timestamp inside TDengine, and so each table in TDengine can essentially be considered as a message queue.
 
-A lightweight service for data subscription and pushing is built in TDengine. With the API provided by TDengine, client programs can use `select` statements to subscribe to data from one or more tables. The subscription and state maintenance is performed on the client side, the client programs poll the server to check whether there is new data, and if so the new data will be pushed back to the client side. If the client program is restarted, where to start for retrieving new data is up to the client side.
+A lightweight service for data subscription and publishing is built into TDengine. With the API provided by TDengine, client programs can use `select` statements to subscribe to data from one or more tables. The subscription and state maintenance is performed on the client side. The client programs poll the server to check whether there is new data, and if so the new data will be pushed back to the client side. If the client program is restarted, where to start retrieving new data is up to the client side.
 
 There are 3 major APIs related to subscription provided in the TDengine client driver.
 
@@ -32,7 +32,7 @@ For more details about these APIs please refer to [C/C++ Connector](/reference/c
 
 If we want to get a notification and take some actions if the current exceeds a threshold, like 10A, from some meters, there are two ways:
 
-The first way is to query on each sub table and record the last timestamp matching the criteria, then after some time query on the data later than recorded timestamp and repeat this process. The SQL statements for this way are as below.
+The first way is to query each sub table and record the last timestamp matching the criteria. Then after some time, query the data later than the recorded timestamp, and repeat this process. The SQL statements for this way are as below.
 
 ```sql
 select * from D1001 where ts > {last_timestamp1} and current > 10;
@@ -50,7 +50,7 @@ select * from meters where ts > {last_timestamp} and current > 10;
 
 However, this presents a new problem in how to choose `last_timestamp`. First, the timestamp when the data is generated is different from the timestamp when the data is inserted into the database, sometimes the difference between them may be very big. Second, the time when the data from different meters arrives at the database may be different too. If the timestamp of the "slowest" meter is used as `last_timestamp` in the query, the data from other meters may be selected repeatedly; but if the timestamp of the "fastest" meter is used as `last_timestamp`, some data from other meters may be missed.
 
-All the problems mentioned above can be resolved thoroughly using subscription provided by TDengine.
+All the problems mentioned above can be resolved easily using the subscription functionality provided by TDengine.
 
 The first step is to create subscription using `taos_subscribe`.
 
@@ -65,31 +65,33 @@ if (async) {
 }
 ```
 
-The subscription in TDengine can be either synchronous or asynchronous. In the above sample code, the value of variable `async` is determined from the CLI input, then it's used to create either an async or sync subscription. Sync subscription means the client program needs to invoke `taos_consume` to retrieve data, and async subscription means another thread created by `taos_subscribe` internally invokes `taos_consume` to retrieve data and pass the data to `subscribe_callback` for processing, `subscribe_callback` is a call back function provided by the client program and it's suggested not to do time consuming operation in the call back function.
+The subscription in TDengine can be either synchronous or asynchronous. In the above sample code, the value of variable `async` is determined from the CLI input, then it's used to create either an async or sync subscription. Sync subscription means the client program needs to invoke `taos_consume` to retrieve data, and async subscription means another thread created by `taos_subscribe` internally invokes `taos_consume` to retrieve data and pass the data to `subscribe_callback` for processing. `subscribe_callback` is a callback function provided by the client program. You should not perform time consuming operations in the callback function.
 
-The parameter `taos` is an established connection. There is nothing special in sync subscription mode. In async subscription, it should be exclusively by current thread, otherwise unpredictable error may occur.
+The parameter `taos` is an established connection. Nothing special needs to be done for thread safety for synchronous subscription. For asynchronous subscription, the taos_subscribe function should be called exclusively by the current thread, to avoid unpredictable errors.
 
-The parameter `sql` is a `select` statement in which `where` clause can be used to specify filter conditions. In our example, the data whose current exceeds 10A needs to be subscribed like below SQL statement:
+The parameter `sql` is a `select` statement in which the `where` clause can be used to specify filter conditions. In our example, we can subscribe to the records in which the current exceeds 10A, with the following SQL statement:
 
 ```sql
 select * from meters where current > 10;
 ```
 
-Please note that, all the data will be processed because no start time is specified. If only the data from one day ago needs to be processed, a time related condition can be added:
+Please note that, all the data will be processed because no start time is specified. If we only want to process data for the past day, a time related condition can be added:
 
 ```sql
 select * from meters where ts > now - 1d and current > 10;
 ```
 
-The parameter `topic` is the name of the subscription, it needs to be guaranteed unique in the client program, but it's not necessary to be globally unique because subscription is implemented in the APIs on the client side.
+The parameter `topic` is the name of the subscription. The client application must guarantee that the name is unique. However, it doesn't have to be globally unique because subscription is implemented in the APIs on the client side.
 
-If the subscription named as `topic` doesn't exist, the parameter `restart` will be ignored. If the subscription named as `topic` has been created before by the client program, when the client program is restarted with the subscription named `topic`, parameter `restart` is used to determine whether to retrieve data from the beginning or from the last point where the subscription was broken. If the value of `restart` is **true** (i.e. a non-zero value), the data will be retrieved from beginning, or if it is **false** (i.e. zero), the data already consumed before will not be processed again.
+If the subscription named as `topic` doesn't exist, the parameter `restart` will be ignored. If the subscription named as `topic` has been created before by the client program, when the client program is restarted with the subscription named `topic`, parameter `restart` is used to determine whether to retrieve data from the beginning or from the last point where the subscription was broken.
 
-The last parameter of `taos_subscribe` is the polling interval in unit of millisecond. In sync mode, if the time difference between two continuous invocations to `taos_consume` is smaller than the interval specified by `taos_subscribe`, `taos_consume` will be blocked until the interval is reached. In async mode, this interval is the minimum interval between two invocations to the call back function.
+If the value of `restart` is **true** (i.e. a non-zero value), data will be retrieved from the beginning. If it is **false** (i.e. zero), the data already consumed before will not be processed again.
+
+The last parameter of `taos_subscribe` is the polling interval in units of millisecond. In sync mode, if the time difference between two continuous invocations to `taos_consume` is smaller than the interval specified by `taos_subscribe`, `taos_consume` will be blocked until the interval is reached. In async mode, this interval is the minimum interval between two invocations to the call back function.
 
 The second to last parameter of `taos_subscribe` is used to pass arguments to the call back function. `taos_subscribe` doesn't process this parameter and simply passes it to the call back function. This parameter is simply ignored in sync mode.
 
-After a subscription is created, its data can be consumed and processed, below is the sample code of how to consume data in sync mode, in the else part if `if (async)`.
+After a subscription is created, its data can be consumed and processed. Shown below is the sample code to consume data in sync mode, in the else condition of `if (async)`.
 
 ```c
 if (async) {
@@ -106,7 +108,7 @@ if (async) {
 }
 ```
 
-In the above sample code, there is an infinite loop, each time carriage return is entered `taos_consume` is invoked, the return value of `taos_consume` is the selected result set, exactly as the input of `taos_use_result`, in the above sample `print_result` is used instead to simplify the sample. Below is the implementation of `print_result`.
+In the above sample code in the else condition, there is an infinite loop. Each time carriage return is entered `taos_consume` is invoked. The return value of `taos_consume` is the selected result set. In the above sample, `print_result` is used to simplify the printing of the result set. It is similar to `taos_use_result`. Below is the implementation of `print_result`.
 
 ```c
 void print_result(TAOS_RES* res, int blockFetch) {
@@ -133,9 +135,9 @@ void print_result(TAOS_RES* res, int blockFetch) {
 }
 ```
 
-In the above code `taos_print_row` is used to process the data consumed. All the matching rows will be printed.
+In the above code `taos_print_row` is used to process the data consumed. All matching rows are printed.
 
-In async mode, the data consuming is simpler as below.
+In async mode, consuming data is simpler as shown below.
 
 ```c
 void subscribe_callback(TAOS_SUB* tsub, TAOS_RES *res, void* param, int code) {
@@ -149,7 +151,7 @@ void subscribe_callback(TAOS_SUB* tsub, TAOS_RES *res, void* param, int code) {
 taos_unsubscribe(tsub, keep);
 ```
 
-The second parameter `keep` is used to specify whether to keep the subscription progress on the client sde. If it is **false**, i.e. **0**, then subscription will be restarted from beginning regardless of the `restart` parameter's value when `taos_subscribe` is invoked again. The subscription progress information is stored in _{DataDir}/subscribe/_ , under which there is a file with the same name as `topic` for each subscription, the subscription will be restarted from the beginning if the corresponding progress file is removed.
+The second parameter `keep` is used to specify whether to keep the subscription progress on the client sde. If it is **false**, i.e. **0**, then subscription will be restarted from beginning regardless of the `restart` parameter's value when `taos_subscribe` is invoked again. The subscription progress information is stored in _{DataDir}/subscribe/_ , under which there is a file with the same name as `topic` for each subscription(Note: The default value of `DataDir` in the `taos.cfg` file is **/var/lib/taos/**. However, **/var/lib/taos/** does not exist on the Windows server. So you need to change the `DataDir` value to the corresponding existing directory."), the subscription will be restarted from the beginning if the corresponding progress file is removed.
 
 Now let's see the effect of the above sample code, assuming below prerequisites have been done.
 
@@ -175,7 +177,7 @@ Then, this row of data will be shown by the example program on the first termina
 
 ## Examples
 
-Below example program demonstrates how to subscribe the data rows whose current exceeds 10A using connectors.
+The example program below demonstrates how to subscribe, using connectors, to data rows in which current exceeds 10A.
 
 ### Prepare Data
 
@@ -250,7 +252,7 @@ taos> use power;
 taos> insert into d1001 values(now, 12.4, 220, 1);
 ```
 
-Because the current in inserted row exceeds 10A, it will be consumed by the example program.
+Because the current in the inserted row exceeds 10A, it will be consumed by the example program.
 
 ```
 ts: 1651146662805	current: 12.4	voltage: 220	phase: 1	location: California.SanFrancisco	groupid: 2

docs-en/07-develop/07-cache.md

@@ -4,15 +4,15 @@ title: Cache
 description: "The latest row of each table is kept in cache to provide high performance query of latest state."
 ---
 
-The cache management policy in TDengine is First-In-First-Out (FIFO), which is also known as insert driven cache management policy and different from read driven cache management, i.e. Least-Recent-Used (LRU). It simply stores the latest data in cache and flushes the oldest data in cache to disk when the cache usage reaches a threshold. In IoT use cases, the most cared about data is the latest data, i.e. current state. The cache policy in TDengine is based the nature of IoT data.
+The cache management policy in TDengine is First-In-First-Out (FIFO). FIFO is also known as insert driven cache management policy and it is different from read driven cache management, which is more commonly known as Least-Recently-Used (LRU). FIFO simply stores the latest data in cache and flushes the oldest data in cache to disk, when the cache usage reaches a threshold. In IoT use cases, it is the current state i.e. the latest or most recent data that is important. The cache policy in TDengine, like much of the design and architecture of TDengine, is based on the nature of IoT data.
 
-Caching the latest data provides the capability of retrieving data in milliseconds. With this capability, TDengine can be configured properly to be used as caching system without deploying another separate caching system to simplify the system architecture and minimize the operation cost. The cache will be emptied after TDengine is restarted, TDengine doesn't reload data from disk into cache like a real key-value caching system.
+Caching the latest data provides the capability of retrieving data in milliseconds. With this capability, TDengine can be configured properly to be used as a caching system without deploying another separate caching system. This simplifies the system architecture and minimizes operational costs. The cache is emptied after TDengine is restarted. TDengine does not reload data from disk into cache, like a key-value caching system.
 
-The memory space used by TDengine cache is fixed in size, according to the configuration based on application requirement and system resources. Independent memory pool is allocated for and managed by each vnode (virtual node) in TDengine, there is no sharing of memory pools between vnodes. All the tables belonging to a vnode share all the cache memory of the vnode.
+The memory space used by the TDengine cache is fixed in size and configurable. It should be allocated based on application requirements and system resources. An independent memory pool is allocated for and managed by each vnode (virtual node) in TDengine. There is no sharing of memory pools between vnodes. All the tables belonging to a vnode share all the cache memory of the vnode.
 
-Memory pool is divided into blocks and data is stored in row format in memory and each block follows FIFO policy. The size of each block is determined by configuration parameter `cache`, the number of blocks for each vnode is determined by `blocks`. For each vnode, the total cache size is `cache * blocks`.  A cache block needs to ensure that each table can store at least dozens of records to be efficient.
+The memory pool is divided into blocks and data is stored in row format in memory and each block follows FIFO policy. The size of each block is determined by configuration parameter `cache` and the number of blocks for each vnode is determined by the parameter `blocks`. For each vnode, the total cache size is `cache * blocks`.  A cache block needs to ensure that each table can store at least dozens of records, to be efficient.
 
-`last_row` function can be used to retrieve the last row of a table or a STable to quickly show the current state of devices on monitoring screen. For example the below SQL statement retrieves the latest voltage of all meters in San Francisco of California.
+`last_row` function can be used to retrieve the last row of a table or a STable to quickly show the current state of devices on monitoring screen. For example the below SQL statement retrieves the latest voltage of all meters in San Francisco, California.
 
 ```sql
 select last_row(voltage) from meters where location='California.SanFrancisco';

docs-en/07-develop/08-udf.md

 ---
 sidebar_label: UDF
-title: User Defined Functions
-description: "Scalar functions and aggregate functions developed by users can be utilized by the query framework to expand the query capability"
+title: User Defined Functions(UDF)
+description: "Scalar functions and aggregate functions developed by users can be utilized by the query framework to expand query capability"
 ---
 
-In some use cases, the query capability required by application programs can't be achieved directly by builtin functions. With UDF, the functions developed by users can be utilized by query framework to meet some special requirements. UDF normally takes one column of data as input, but can also support the result of sub query as input.
+In some use cases, built-in functions are not adequate for the query capability required by application programs. With UDF, the functions developed by users can be utilized by the query framework to meet business and application requirements. UDF normally takes one column of data as input, but can also support the result of a sub-query as input.
 
-From version 2.2.0.0, UDF programmed in C/C++ language can be supported by TDengine.
+From version 2.2.0.0, UDF written in C/C++ are supported by TDengine.
 
-Two kinds of functions can be implemented by UDF: scalar function and aggregate function.
 
-## Define UDF
+## Types of UDF
+
+Two kinds of functions can be implemented by UDF: scalar functions and aggregate functions.
+
+Scalar functions return multiple rows and aggregate functions return either 0 or 1 row.
+
+In the case of a scalar function you only have to implement the "normal" function template.
+
+In the case of an aggregate function, in addition to the "normal" function, you also need to implement the "merge" and "finalize" function templates even if the implementation is empty. This will become clear in the sections below.
 
 ### Scalar Function
 
-Below function template can be used to define your own scalar function.
+As mentioned earlier, a scalar UDF only has to implement the "normal" function template. The function template below can be used to define your own scalar function.
 
 `void udfNormalFunc(char* data, short itype, short ibytes, int numOfRows, long long* ts, char* dataOutput, char* interBuf, char* tsOutput, int* numOfOutput, short otype, short obytes, SUdfInit* buf)`
 
-`udfNormalFunc` is the place holder of function name, a function implemented based on the above template can be used to perform scalar computation on data rows. The parameters are fixed to control the data exchange between UDF and TDengine.
+`udfNormalFunc` is the place holder for a function name. A function implemented based on the above template can be used to perform scalar computation on data rows. The parameters are fixed to control the data exchange between UDF and TDengine.
 
 - Definitions of the parameters:
 
@@ -30,20 +37,24 @@ Below function template can be used to define your own scalar function.
   - numOfRows：the number of rows in the input data
   - ts: the column of timestamp corresponding to the input data
   - dataOutput：the buffer for output data, total size is `oBytes * numberOfRows`
-  - interBuf：the buffer for intermediate result, its size is specified by `BUFSIZE` parameter when creating a UDF. It's normally used when the intermediate result is not same as the final result, it's allocated and freed by TDengine.
+  - interBuf：the buffer for an intermediate result. Its size is specified by the `BUFSIZE` parameter when creating a UDF. It's normally used when the intermediate result is not same as the final result. This buffer is allocated and freed by TDengine.
   - tsOutput：the column of timestamps corresponding to the output data; it can be used to output timestamp together with the output data if it's not NULL
   - numOfOutput：the number of rows in output data
   - buf：for the state exchange between UDF and TDengine
 
-  [add_one.c](https://github.com/taosdata/TDengine/blob/develop/tests/script/sh/add_one.c) is one example of the simplest UDF implementations, i.e. one instance of the above `udfNormalFunc` template. It adds one to each value of a column passed in which can be filtered using `where` clause and outputs the result.
+  [add_one.c](https://github.com/taosdata/TDengine/blob/develop/tests/script/sh/add_one.c) is one example of a very simple UDF implementation, i.e. one instance of the above `udfNormalFunc` template. It adds one to each value of a passed in column, which can be filtered using the `where` clause, and outputs the result.
 
 ### Aggregate Function
 
-Below function template can be used to define your own aggregate function.
+For aggregate UDF, as mentioned earlier you must implement a "normal" function template (described above) and also implement the "merge" and "finalize" templates.
 
-`void abs_max_merge(char* data, int32_t numOfRows, char* dataOutput, int32_t* numOfOutput, SUdfInit* buf)`
+#### Merge Function Template
 
-`udfMergeFunc` is the place holder of function name, the function implemented with the above template is used to aggregate the intermediate result, only can be used in the aggregate query for STable.
+The function template below can be used to define your own merge function for an aggregate UDF.
+
+`void udfMergeFunc(char* data, int32_t numOfRows, char* dataOutput, int32_t* numOfOutput, SUdfInit* buf)`
+
+`udfMergeFunc` is the place holder for a function name. The function implemented with the above template is used to aggregate intermediate results and can only be used in the aggregate query for STable.
 
 Definitions of the parameters:
 
@@ -53,17 +64,11 @@ Definitions of the parameters:
 - numOfOutput：number of rows in the output data
 - buf：for the state exchange between UDF and TDengine
 
-[abs_max.c](https://github.com/taosdata/TDengine/blob/develop/tests/script/sh/abs_max.c) is an user defined aggregate function to get the maximum from the absolute value of a column.
-
-The internal processing is that the data affected by the select statement will be divided into multiple row blocks and `udfNormalFunc`, i.e. `abs_max` in this case, is performed on each row block to generate the intermediate of each sub table, then `udfMergeFunc`, i.e. `abs_max_merge` in this case, is performed on the intermediate result of sub tables to aggregate to generate the final or intermediate result of STable. The intermediate result of STable is finally processed by `udfFinalizeFunc` to generate the final result, which contain either 0 or 1 row.
-
-Other typical scenarios, like covariance, can also be achieved by aggregate UDF.
+#### Finalize Function Template
 
-### Finalize
+The function template below can be used to finalize the result of your own UDF, normally used when interBuf is used.
 
-Below function template can be used to finalize the result of your own UDF, normally used when interBuf is used.
-
-`void abs_max_finalize(char* dataOutput, char* interBuf, int* numOfOutput, SUdfInit* buf)`
+`void udfFinalizeFunc(char* dataOutput, char* interBuf, int* numOfOutput, SUdfInit* buf)`
 
 `udfFinalizeFunc` is the place holder of function name, definitions of the parameter are as below:
 
@@ -72,47 +77,64 @@ Below function template can be used to finalize the result of your own UDF, norm
 - numOfOutput：number of output data, can only be 0 or 1 for aggregate function
 - buf：for state exchange between UDF and TDengine
 
-## UDF Conventions
+### Example abs_max.c
+
+[abs_max.c](https://github.com/taosdata/TDengine/blob/develop/tests/script/sh/abs_max.c) is an example of a user defined aggregate function to get the maximum from the absolute values of a column.
+
+The internal processing happens as follows. The results of the select statement are divided into multiple row blocks and `udfNormalFunc`, i.e. `abs_max` in this case, is performed on each row block to generate the intermediate results for each sub table. Then `udfMergeFunc`, i.e. `abs_max_merge` in this case, is performed on the intermediate result of sub tables to aggregate and generate the final or intermediate result of STable. The intermediate result of STable is finally processed by `udfFinalizeFunc`, i.e. `abs_max_finalize` in this example, to generate the final result, which contains either 0 or 1 row.
+
+Other typical aggregation functions such as covariance, can also be implemented using aggregate UDF.
 
-The naming of 3 kinds of UDF, i.e. udfNormalFunc, udfMergeFunc, and udfFinalizeFunc is required to have same prefix, i.e. the actual name of udfNormalFunc, which means udfNormalFunc doesn't need a suffix following the function name. While udfMergeFunc should be udfNormalFunc followed by `_merge`, udfFinalizeFunc should be udfNormalFunc followed by `_finalize`. The naming convention is part of UDF framework, TDengine follows this convention to invoke corresponding actual functions.\
+## UDF Naming Conventions
 
-According to the kind of UDF to implement, the functions that need to be implemented are different.
+The naming convention for the 3 kinds of function templates required by UDF is as follows:
+ - udfNormalFunc, udfMergeFunc, and udfFinalizeFunc are required to have same prefix, i.e. the actual name of udfNormalFunc. The udfNormalFunc doesn't need a suffix following the function name. 
+ - udfMergeFunc should be udfNormalFunc followed by `_merge`
+ - udfFinalizeFunc should be udfNormalFunc followed by `_finalize`. 
+ 
+The naming convention is part of TDengine's UDF framework. TDengine follows this convention to invoke the corresponding actual functions.
 
-- Scalar function：udfNormalFunc is required
-- Aggregate function：udfNormalFunc, udfMergeFunc (if query on STable) and udfFinalizeFunc are required
+Depending on whether you are creating a scalar UDF or aggregate UDF, the functions that you need to implement are different.
 
-To be more accurate, assuming we want to implement a UDF named "foo". If the function is a scalar function, what we really need to implement is `foo`; if the function is aggregate function, we need to implement `foo`, `foo_merge`, and `foo_finalize`. For aggregate UDF, even though one of the three functions is not necessary, there must be an empty implementation.
+- Scalar function：udfNormalFunc is required.
+- Aggregate function：udfNormalFunc, udfMergeFunc (if query on STable) and udfFinalizeFunc are required.
+
+For clarity, assuming we want to implement a UDF named "foo":
+- If the function is a scalar function, we only need to implement the "normal" function template and it should be named simply `foo`. 
+- If the function is an aggregate function, we need to implement `foo`, `foo_merge`, and `foo_finalize`. Note that for aggregate UDF, even though one of the three functions is not necessary, there must be an empty implementation.
 
 ## Compile UDF
 
-The source code of UDF in C can't be utilized by TDengine directly. UDF can only be loaded into TDengine after compiling to dynamically linked library.
+The source code of UDF in C can't be utilized by TDengine directly. UDF can only be loaded into TDengine after compiling to dynamically linked library (DLL).
 
-For example, the example UDF `add_one.c` mentioned in previous sections need to be compiled into DLL using below command on Linux Shell.
+For example, the example UDF `add_one.c` mentioned earlier, can be compiled into DLL using the command below, in a Linux Shell.
 
 ```bash
 gcc -g -O0 -fPIC -shared add_one.c -o add_one.so
 ```
 
-The generated DLL file `dd_one.so` can be used later when creating UDF. It's recommended to use GCC not older than 7.5.
+The generated DLL file `add_one.so` can be used later when creating a UDF. It's recommended to use GCC not older than 7.5.
 
 ## Create and Use UDF
 
+When a UDF is created in a TDengine instance, it is available across the databases in that instance.
+
 ### Create UDF
 
-SQL command can be executed on the same hos where the generated UDF DLL resides to load the UDF DLL into TDengine, this operation can't be done through REST interface or web console. Once created, all the clients of the current TDengine can use these UDF functions in their SQL commands. UDF are stored in the management node of TDengine. The UDFs loaded in TDengine would be still available after TDengine is restarted.
+SQL command can be executed on the host where the generated UDF DLL resides to load the UDF DLL into TDengine. This operation cannot be done through REST interface or web console. Once created, any client of the current TDengine can use these UDF functions in their SQL commands. UDF are stored in the management node of TDengine. The UDFs loaded in TDengine would be still available after TDengine is restarted.
 
-When creating UDF, it needs to be clarified as either scalar function or aggregate function. If the specified type is wrong, the SQL statements using the function would fail with error. Besides, the input type and output type don't need to be same in UDF, but the input data type and output data type need to be consistent with the UDF definition.
+When creating UDF, the type of UDF, i.e. a scalar function or aggregate function must be specified. If the specified type is wrong, the SQL statements using the function would fail with errors. The input type and output type don't need to be the same in UDF, but the input data type and output data type must be consistent with the UDF definition.
 
 - Create Scalar Function
 
 ```sql
-CREATE FUNCTION ids(X) AS ids(Y) OUTPUTTYPE typename(Z) [ BUFSIZE B ];
+CREATE FUNCTION userDefinedFunctionName AS "/absolute/path/to/userDefinedFunctionName.so" OUTPUTTYPE <supported TDengine type> [BUFSIZE B];
 ```
 
-- ids(X)：the function name to be sued in SQL statement, must be consistent with the function name defined by `udfNormalFunc`
-- ids(Y)：the absolute path of the DLL file including the implementation of the UDF, the path needs to be quoted by single or double quotes
-- typename(Z)：the output data type, the value is the literal string of the type
-- B：the size of intermediate buffer, in bytes; it's an optional parameter and the range is [0,512]
+- userDefinedFunctionName：The function name to be used in SQL statement which must be consistent with the function name defined by `udfNormalFunc` and is also the name of the compiled DLL (.so file).
+- path：The absolute path of the DLL file including the name of the shared object file (.so). The path must be quoted with single or double quotes.
+- outputtype：The output data type, the value is the literal string of the supported TDengine data type.
+- B：the size of intermediate buffer, in bytes; it is an optional parameter and the range is [0,512].
 
 For example, below SQL statement can be used to create a UDF from `add_one.so`.
 
@@ -123,17 +145,17 @@ CREATE FUNCTION add_one AS "/home/taos/udf_example/add_one.so" OUTPUTTYPE INT;
 - Create Aggregate Function
 
 ```sql
-CREATE AGGREGATE FUNCTION ids(X) AS ids(Y) OUTPUTTYPE typename(Z) [ BUFSIZE B ];
+CREATE AGGREGATE FUNCTION userDefinedFunctionName AS "/absolute/path/to/userDefinedFunctionName.so" OUTPUTTYPE <supported TDengine data type> [ BUFSIZE B ];
 ```
 
-- ids(X)：the function name to be sued in SQL statement, must be consistent with the function name defined by `udfNormalFunc`
-- ids(Y)：the absolute path of the DLL file including the implementation of the UDF, the path needs to be quoted by single or double quotes
-- typename(Z)：the output data type, the value is the literal string of the type
+- userDefinedFunctionName：the function name to be used in SQL statement which must be consistent with the function name defined by `udfNormalFunc` and is also the name of the compiled DLL (.so file).
+- path：the absolute path of the DLL file including the name of the shared object file (.so). The path needs to be quoted by single or double quotes.
+- OUTPUTTYPE：the output data type, the value is the literal string of the type
 - B：the size of intermediate buffer, in bytes; it's an optional parameter and the range is [0,512]
 
 For details about how to use intermediate result, please refer to example program [demo.c](https://github.com/taosdata/TDengine/blob/develop/tests/script/sh/demo.c).
 
-For example, below SQL statement can be used to create a UDF rom `demo.so`.
+For example, below SQL statement can be used to create a UDF from `demo.so`.
 
 ```sql
 CREATE AGGREGATE FUNCTION demo AS "/home/taos/udf_example/demo.so" OUTPUTTYPE DOUBLE bufsize 14;
@@ -176,11 +198,11 @@ In current version there are some restrictions for UDF
 1. Only Linux is supported when creating and invoking UDF for both client side and server side
 2. UDF can't be mixed with builtin functions
 3. Only one UDF can be used in a SQL statement
-4. Single column is supported as input for UDF
+4. Only a single column is supported as input for UDF
 5. Once created successfully, UDF is persisted in MNode of TDengineUDF
 6. UDF can't be created through REST interface
 7. The function name used when creating UDF in SQL must be consistent with the function name defined in the DLL, i.e. the name defined by `udfNormalFunc`
-8. The name name of UDF name should not conflict with any of builtin functions
+8. The name of a UDF should not conflict with any of TDengine's built-in functions
 
 ## Examples
 

docs-en/10-cluster/01-deploy.md

@@ -6,29 +6,35 @@ title: Deployment
 
 ### Step 1
 
-The FQDN of all hosts needs to be setup properly, all the FQDNs need to be configured in the /etc/hosts of each host. It must be confirmed that each FQDN can be accessed (by ping, for example) from any other hosts.
+The FQDN of all hosts must be setup properly. For e.g. FQDNs may have to be configured in the /etc/hosts file on each host. You must confirm that each FQDN can be accessed from any other host. For e.g. you can do this by using the `ping` command. 
 
-On each host the command `hostname -f` can be executed to get the hostname. `ping` command can be executed on each host to check whether any other host is accessible from it. If any host is not accessible, the network configuration, like /etc/hosts or DNS configuration, need to be checked and revised to make any two hosts accessible to each other.
+To get the hostname on any host, the command `hostname -f` can be executed. `ping <FQDN>` command can be executed on each host to check whether any other host is accessible from it. If any host is not accessible, the network configuration, like /etc/hosts or DNS configuration, needs to be checked and revised, to make any two hosts accessible to each other.
 
 :::note
 
 - The host where the client program runs also needs to be configured properly for FQDN, to make sure all hosts for client or server can be accessed from any other. In other words, the hosts where the client is running are also considered as a part of the cluster.
 
-- It's suggested to disable the firewall for all hosts in the cluster. At least TCP/UDP for port 6030~6042 need to be open if a firewall is enabled.
+- Please ensure that your firewall rules do not block TCP/UDP on ports 6030-6042 on all hosts in the cluster.
 
 :::
 
 ### Step 2
 
-If any previous version of TDengine has been installed and configured on any host, the installation needs to be removed and the data needs to be cleaned up. For details about uninstalling please refer to [Install and Uninstall](/operation/pkg-install). To clean up the data, please use `rm -rf /var/lib/taos/\*` assuming the `dataDir` is configured as `/var/lib/taos`.
+If any previous version of TDengine has been installed and configured on any host, the installation needs to be removed and the data needs to be cleaned up. For details about uninstalling please refer to [Install and Uninstall](/operation/pkg-install). To clean up the data, please use `rm -rf /var/lib/taos/\*` assuming the `dataDir` is configured as `/var/lib/taos`. 
+
+:::note
+
+As a best practice, before cleaning up any data files or directories, please ensure that your data has been backed up correctly, if required by your data integrity, backup, security, or other standard operating protocols (SOP).
+
+:::
 
 ### Step 3
 
-Now it's time to install TDengine on all hosts without starting `taosd`, the versions on all hosts should be same. If it's prompted to input the existing TDengine cluster, simply press carriage return to ignore it. `install.sh -e no` can also be used to disable this prompt. For details please refer to [Install and Uninstall](/operation/pkg-install).
+Now it's time to install TDengine on all hosts but without starting `taosd`. Note that the versions on all hosts should be same. If you are prompted to input the existing TDengine cluster, simply press carriage return to ignore the prompt. `install.sh -e no` can also be used to disable this prompt. For details please refer to [Install and Uninstall](/operation/pkg-install).
 
 ### Step 4
 
-Now each physical node (referred to as `dnode` hereinafter, it's abbreviation for "data node") of TDengine needs to be configured properly. Please note that one dnode doesn't stand for one host, multiple TDengine nodes can be started on single host as long as they are configured properly without conflicting. More specifically each instance of the configuration file `taos.cfg` stands for a dnode. Assuming the first dnode of TDengine cluster is "h1.taosdata.com:6030", its `taos.cfg` is configured as following.
+Now each physical node (referred to, hereinafter, as `dnode` which is an abbreviation for "data node") of TDengine needs to be configured properly. Please note that one dnode doesn't stand for one host. Multiple TDengine dnodes can be started on a single host as long as they are configured properly without conflicting. More specifically each instance of the configuration file `taos.cfg` stands for a dnode. Assuming the first dnode of TDengine cluster is "h1.taosdata.com:6030", its `taos.cfg` is configured as following.
 
 ```c
 // firstEp is the end point to connect to when any dnode starts
@@ -67,9 +73,11 @@ Prior to version 2.0.19.0, besides the above parameters, `locale` and `charset`
 
 ## Start Cluster
 
+In the following example we assume that first dnode has FQDN h1.taosdata.com and the second dnode has FQDN h2.taosdata.com.
+
 ### Start The First DNODE
 
-The first dnode can be started following the instructions in [Get Started](/get-started/), for example h1.taosdata.com. Then TDengine CLI `taos` can be launched to execute command `show dnodes`, the output is as following for example:
+The first dnode can be started following the instructions in [Get Started](/get-started/). Then TDengine CLI `taos` can be launched to execute command `show dnodes`, the output is as following for example:
 
 ```
 Welcome to the TDengine shell from Linux, Client Version:2.0.0.0
@@ -80,27 +88,41 @@ Copyright (c) 2017 by TAOS Data, Inc. All rights reserved.
 taos> show dnodes;
  id |       end_point    | vnodes | cores | status | role |      create_time        |
 =====================================================================================
-  1 |  h1.taos.com:6030  |      0 |     2 |  ready |  any | 2020-07-31 03:49:29.202 |
+  1 |  h1.taosdata.com:6030  |      0 |     2 |  ready |  any | 2020-07-31 03:49:29.202 |
 Query OK, 1 row(s) in set (0.006385s)
 
 taos>
 ```
 
-From the above output, it is shown that the end point of the started dnode is "h1.taos.com:6030", which is the `firstEp` of the cluster.
+From the above output, it is shown that the end point of the started dnode is "h1.taosdata.com:6030", which is the `firstEp` of the cluster.
 
 ### Start Other DNODEs
 
 There are a few steps necessary to add other dnodes in the cluster.
 
-First, start `taosd` as instructed in [Get Started](/get-started/), assuming it's for the second dnode. Before starting `taosd`, please making sure the configuration is correct, especially `firstEp`, `FQDN` and `serverPort`, `firstEp` must be same as the dnode shown in the section "Start First DNODE", i.e. "h1.taosdata.com" in this example.
+Let's assume we are starting the second dnode with FQDN, h2.taosdata.com. First we make sure the configuration is correct.
+
+```c
+// firstEp is the end point to connect to when any dnode starts
+firstEp               h1.taosdata.com:6030
+
+// must be configured to the FQDN of the host where the dnode is launched
+fqdn                  h2.taosdata.com
+
+// the port used by the dnode, default is 6030
+serverPort            6030
+
+```
+
+Second, we can start `taosd` as instructed in [Get Started](/get-started/).
 
-Then, on the first dnode, use TDengine CLI `taos` to execute below command to add the end point of the dnode in the cluster. In the command "fqdn:port" should be quoted using double quotes.
+Then, on the first dnode i.e. h1.taosdata.com in our example, use TDengine CLI `taos` to execute the following command to add the end point of the dnode in the cluster. In the command "fqdn:port" should be quoted using double quotes.
 
 ```sql
 CREATE DNODE "h2.taos.com:6030";
 ```
 
-Then on the first dnode, execute `show dnodes` in `taos` to show whether the second dnode has been added in the cluster successfully or not.
+Then on the first dnode h1.taosdata.com, execute `show dnodes` in `taos` to show whether the second dnode has been added in the cluster successfully or not.
 
 ```sql
 SHOW DNODES;

docs-en/10-cluster/02-cluster-mgmt.md

@@ -3,16 +3,16 @@ sidebar_label: Operation
 title: Manage DNODEs
 ---
 
-The previous section [Deployment](/cluster/deploy) introduced how to deploy and start a cluster from scratch. Once a cluster is ready, the dnode status in the cluster can be shown at any time, new dnode can be added to scale out the cluster, an existing dnode can be removed, even load balance can be performed manually.
+The previous section, [Deployment],(/cluster/deploy) showed you how to deploy and start a cluster from scratch. Once a cluster is ready, the status of dnode(s) in the cluster can be shown at any time. Dnodes can be managed from the TDengine CLI. New dnode(s) can be added to scale out the cluster, an existing dnode can be removed and you can even perform load balancing manually, if necessary.
 
 :::note
-All the commands to be introduced in this chapter need to be run through TDengine CLI, sometimes it's necessary to use root privilege.
+All the commands introduced in this chapter must be run in the TDengine CLI - `taos`. Note that sometimes it is necessary to use root privilege.
 
 :::
 
 ## Show DNODEs
 
-The below command can be executed in TDengine CLI `taos` to list all dnodes in the cluster, including ID, end point (fqdn:port), status (ready, offline), number of vnodes, number of free vnodes, etc. It's suggested to execute this command to check after adding or removing a dnode.
+The below command can be executed in TDengine CLI `taos` to list all dnodes in the cluster, including ID, end point (fqdn:port), status (ready, offline), number of vnodes, number of free vnodes and so on. We recommend executing this command after adding or removing a dnode.
 
 ```sql
 SHOW DNODES;
@@ -30,7 +30,7 @@ Query OK, 1 row(s) in set (0.008298s)
 
 ## Show VGROUPs
 
-To utilize system resources efficiently and provide scalability, data sharding is required. The data of each database is divided into multiple shards and stored in multiple vnodes. These vnodes may be located in different dnodes, scaling out can be achieved by adding more vnodes from more dnodes. Each vnode can only be used for a single DB, but one DB can have multiple vnodes. The allocation of vnode is scheduled automatically by mnode according to system resources of the dnodes.
+To utilize system resources efficiently and provide scalability, data sharding is required. The data of each database is divided into multiple shards and stored in multiple vnodes. These vnodes may be located on different dnodes. One way of scaling out is to add more vnodes on dnodes. Each vnode can only be used for a single DB, but one DB can have multiple vnodes. The allocation of vnode is scheduled automatically by mnode based on system resources of the dnodes.
 
 Launch TDengine CLI `taos` and execute below command:
 
@@ -87,7 +87,7 @@ taos> show dnodes;
 Query OK, 2 row(s) in set (0.001017s)
 ```
 
-It can be seen that the status of the new dnode is "offline", once the dnode is started and connects the firstEp of the cluster, execute the command again and get the example output below, from which it can be seen that two dnodes are both in "ready" status.
+It can be seen that the status of the new dnode is "offline". Once the dnode is started and connects to the firstEp of the cluster, you can execute the command again and get the example output below. As can be seen, both dnodes are in "ready" status.
 
 ```
 taos> show dnodes;
@@ -132,12 +132,12 @@ taos> show dnodes;
 Query OK, 1 row(s) in set (0.001137s)
 ```
 
-In the above example, when `show dnodes` is executed the first time, two dnodes are shown. Then `drop dnode 2` is executed, after that from the output of executing `show dnodes` again it can be seen that only the dnode with ID 1 is still in the cluster.
+In the above example, when `show dnodes` is executed the first time, two dnodes are shown. After `drop dnode 2` is executed, you can execute `show dnodes` again and it can be seen that only the dnode with ID 1 is still in the cluster.
 
 :::note
 
-- Once a dnode is dropped, it can't rejoin the cluster. To rejoin, the dnode needs to deployed again after cleaning up the data directory. Normally, before dropping a dnode, the data belonging to the dnode needs to be migrated to other place.
-- Please be noted that `drop dnode` is different from stopping `taosd` process. `drop dnode` just removes the dnode out of TDengine cluster. Only after a dnode is dropped, can the corresponding `taosd` process be stopped.
+- Once a dnode is dropped, it can't rejoin the cluster. To rejoin, the dnode needs to deployed again after cleaning up the data directory. Before dropping a dnode, the data belonging to the dnode MUST be migrated/backed up according to your data retention, data security or other SOPs.
+- Please note that `drop dnode` is different from stopping `taosd` process. `drop dnode` just removes the dnode out of TDengine cluster. Only after a dnode is dropped, can the corresponding `taosd` process be stopped.
 - Once a dnode is dropped, other dnodes in the cluster will be notified of the drop and will not accept the request from the dropped dnode.
 - dnodeID is allocated automatically and can't be manually modified. dnodeID is generated in ascending order without duplication.
 

docs-en/10-cluster/03-ha-and-lb.md

@@ -7,7 +7,7 @@ title: High Availability and Load Balancing
 
 High availability of vnode and mnode can be achieved through replicas in TDengine.
 
-The number of vnodes is associated with each DB, there can be multiple DBs in a TDengine cluster. A different number of replicas can be configured for each DB. When creating a database, the parameter `replica` is used to specify the number of replicas, the default value is 1. With single replica, the high availability of the system can't be guaranteed. Whenever one node is down, the data service will be unavailable. The number of dnodes in the cluster must NOT be lower than the number of replicas set for any DB, otherwise the `create table` operation would fail with error "more dnodes are needed". The SQL statement below is used to create a database named "demo" with 3 replicas.
+A TDengine cluster can have multiple databases. Each database has a number of vnodes associated with it. A different number of replicas can be configured for each DB. When creating a database, the parameter `replica` is used to specify the number of replicas. The default value for `replica` is 1. Naturally, a single replica cannot guarantee high availability since if one node is down, the data service is unavailable. Note that the number of dnodes in the cluster must NOT be lower than the number of replicas set for any DB, otherwise the `create table` operation will fail with error "more dnodes are needed". The SQL statement below is used to create a database named "demo" with 3 replicas.
 
 ```sql
 CREATE DATABASE demo replica 3;
@@ -15,19 +15,19 @@ CREATE DATABASE demo replica 3;
 
 The data in a DB is divided into multiple shards and stored in multiple vgroups. The number of vnodes in each vgroup is determined by the number of replicas set for the DB. The vnodes in each vgroup store exactly the same data. For the purpose of high availability, the vnodes in a vgroup must be located in different dnodes on different hosts. As long as over half of the vnodes in a vgroup are in an online state, the vgroup is able to provide data access. Otherwise the vgroup can't provide data access for reading or inserting data.
 
-There may be data for multiple DBs in a dnode. Once a dnode is down, multiple DBs may be affected. However, it's hard to say the cluster is guaranteed to work properly as long as over half of dnodes are online because vnodes are introduced and there may be complex mapping between vnodes and dnodes.
+There may be data for multiple DBs in a dnode. When a dnode is down, multiple DBs may be affected. While in theory, the cluster will provide data access for reading or inserting data if over half the vnodes in vgroups are online, because of the possibly complex mapping between vnodes and dnodes, it is difficult to guarantee that the cluster will work properly if over half of the dnodes are online.
 
 ## High Availability of Mnode
 
-Each TDengine cluster is managed by `mnode`, which is a module of `taosd`. For the high availability of mnode, multiple mnodes can be configured using system parameter `numOfMNodes`, the valid time range is [1,3]. To make sure the data consistency between mnodes, the data replication between mnodes is performed in a synchronous way.
+Each TDengine cluster is managed by `mnode`, which is a module of `taosd`. For the high availability of mnode, multiple mnodes can be configured using system parameter `numOfMNodes`. The valid range for `numOfMnodes` is [1,3]. To ensure data consistency between mnodes, data replication between mnodes is performed synchronously.
 
-There may be multiple dnodes in a cluster, but only one mnode can be started in each dnode. Which one or ones of the dnodes will be designated as mnodes is automatically determined by TDengine according to the cluster configuration and system resources. Command `show mnodes` can be executed in TDengine `taos` to show the mnodes in the cluster.
+There may be multiple dnodes in a cluster, but only one mnode can be started in each dnode. Which one or ones of the dnodes will be designated as mnodes is automatically determined by TDengine according to the cluster configuration and system resources. The command `show mnodes` can be executed in TDengine `taos` to show the mnodes in the cluster.
 
 ```sql
 SHOW MNODES;
 ```
 
-The end point and role/status (master, slave, unsynced, or offline) of all mnodes can be shown by the above command. When the first dnode is started in a cluster, there must be one mnode in this dnode, because there must be at least one mnode otherwise the cluster doesn't work. If `numOfMNodes` is configured to 2, another mnode will be started when the second dnode is launched.
+The end point and role/status (master, slave, unsynced, or offline) of all mnodes can be shown by the above command. When the first dnode is started in a cluster, there must be one mnode in this dnode. Without at least one mnode, the cluster cannot work. If `numOfMNodes` is configured to 2, another mnode will be started when the second dnode is launched.
 
 For the high availability of mnode, `numOfMnodes` needs to be configured to 2 or a higher value. Because the data consistency between mnodes must be guaranteed, the replica confirmation parameter `quorum` is set to 2 automatically if `numOfMNodes` is set to 2 or higher.
 
@@ -36,15 +36,16 @@ If high availability is important for your system, both vnode and mnode must be
 
 :::
 
-## Load Balance
+## Load Balancing
 
-Load balance will be triggered in 3 cases without manual intervention.
+Load balancing will be triggered in 3 cases without manual intervention.
 
-- When a new dnode is joined in the cluster, automatic load balancing may be triggered, some data from some dnodes may be transferred to the new dnode automatically.
+- When a new dnode joins the cluster, automatic load balancing may be triggered. Some data from other dnodes may be transferred to the new dnode automatically.
 - When a dnode is removed from the cluster, the data from this dnode will be transferred to other dnodes automatically.
 - When a dnode is too hot, i.e. too much data has been stored in it, automatic load balancing may be triggered to migrate some vnodes from this dnode to other dnodes.
+
 :::tip
-Automatic load balancing is controlled by parameter `balance`, 0 means disabled and 1 means enabled.
+Automatic load balancing is controlled by the parameter `balance`, 0 means disabled and 1 means enabled. This is set in the file [taos.cfg](https://docs.tdengine.com/reference/config/#balance).
 
 :::
 
@@ -52,22 +53,22 @@ Automatic load balancing is controlled by parameter `balance`, 0 means disabled
 
 When a dnode is offline, it can be detected by the TDengine cluster. There are two cases:
 
-- The dnode becomes online again before the threshold configured in `offlineThreshold` is reached, it is still in the cluster and data replication is started automatically. The dnode can work properly after the data syncup is finished.
+- The dnode comes online before the threshold configured in `offlineThreshold` is reached. The dnode is still in the cluster and data replication is started automatically. The dnode can work properly after the data sync is finished.
 
-- If the dnode has been offline over the threshold configured in `offlineThreshold` in `taos.cfg`, the dnode will be removed from the cluster automatically. A system alert will be generated and automatic load balancing will be triggered if `balance` is set to 1. When the removed dnode is restarted and becomes online, it will not join in the cluster automatically, it can only be joined manually by the system operator.
+- If the dnode has been offline over the threshold configured in `offlineThreshold` in `taos.cfg`, the dnode will be removed from the cluster automatically. A system alert will be generated and automatic load balancing will be triggered if `balance` is set to 1. When the removed dnode is restarted and becomes online, it will not join the cluster automatically. The system administrator has to manually join the dnode to the cluster.
 
 :::note
-If all the vnodes in a vgroup (or mnodes in mnode group) are in offline or unsynced status, the master node can only be voted after all the vnodes or mnodes in the group become online and can exchange status, then the vgroup (or mnode group) is able to provide service.
+If all the vnodes in a vgroup (or mnodes in mnode group) are in offline or unsynced status, the master node can only be voted on, after all the vnodes or mnodes in the group become online and can exchange status. Following this, the vgroup (or mnode group) is able to provide service.
 
 :::
 
 ## Arbitrator
 
-If the number of replicas is set to an even number like 2, when half of the vnodes in a vgroup don't work a master node can't be voted. A similar case is also applicable to mnode if the number of mnodes is set to an even number like 2.
+The "arbitrator" component is used to address the special case when the number of replicas is set to an even number like 2,4 etc. If half of the vnodes in a vgroup don't work, it is impossible to vote and select a master node. This situation also applies to mnodes if the number of mnodes is set to an even number like 2,4 etc.
 
-To resolve this problem, a new arbitrator component named `tarbitrator`, abbreviated for TDengine Arbitrator, was introduced. Arbitrator simulates a vnode or mnode but it's only responsible for network communication and doesn't handle any actual data access. As long as more than half of the vnode or mnode, including Arbitrator, are available the vnode group or mnode group can provide data insertion or query services normally.
+To resolve this problem, a new arbitrator component named `tarbitrator`, an abbreviation of TDengine Arbitrator, was introduced. The `tarbitrator` simulates a vnode or mnode but it's only responsible for network communication and doesn't handle any actual data access. As long as more than half of the vnode or mnode, including Arbitrator, are available the vnode group or mnode group can provide data insertion or query services normally.
 
-Normally, it's suggested to configure a replica number of each DB or system parameter `numOfMNodes` to an odd number. However, if a user is very sensitive to storage space, a replica number of 2 plus arbitrator component can be used to achieve both lower cost of storage space and high availability.
+Normally, it's prudent to configure the replica number for each DB or system parameter `numOfMNodes` to be an odd number. However, if a user is very sensitive to storage space, a replica number of 2 plus arbitrator component can be used to achieve both lower cost of storage space and high availability.
 
 Arbitrator component is installed with the server package. For details about how to install, please refer to [Install](/operation/pkg-install). The `-p` parameter of `tarbitrator` can be used to specify the port on which it provides service.
 

docs-en/12-taos-sql/01-data-type.md

 ---
 title: Data Types
-description: "The data types supported by TDengine include timestamp, float, JSON, etc"
+description: "TDengine supports a variety of data types including timestamp, float, JSON and many others."
 ---
 
-When using TDengine to store and query data, the most important part of the data is timestamp. Timestamp must be specified when creating and inserting data rows or querying data, timestamp must follow the rules below:
+When using TDengine to store and query data, the most important part of the data is timestamp. Timestamp must be specified when creating and inserting data rows. Timestamp must follow the rules below:
 
-- the format must be `YYYY-MM-DD HH:mm:ss.MS`, the default time precision is millisecond (ms), for example `2017-08-12 18:25:58.128`
-- internal function `now` can be used to get the current timestamp of the client side
-- the current timestamp of the client side is applied when `now` is used to insert data
+- The format must be `YYYY-MM-DD HH:mm:ss.MS`, the default time precision is millisecond (ms), for example `2017-08-12 18:25:58.128`
+- Internal function `now` can be used to get the current timestamp on the client side
+- The current timestamp of the client side is applied when `now` is used to insert data
 - Epoch Time：timestamp can also be a long integer number, which means the number of seconds, milliseconds or nanoseconds, depending on the time precision, from 1970-01-01 00:00:00.000 (UTC/GMT)
-- timestamp can be applied with add/subtract operation, for example `now-2h` means 2 hours back from the time at which query is executed，the unit can be b(nanosecond), u(microsecond), a(millisecond), s(second), m(minute), h(hour), d(day), or w(week). So `select * from t1 where ts > now-2w and ts <= now-1w` means the data between two weeks ago and one week ago. The time unit can also be n (calendar month) or y (calendar year) when specifying the time window for down sampling operation.
+- Add/subtract operations can be carried out on timestamps. For example `now-2h` means 2 hours prior to the time at which query is executed. The units of time in operations can be b(nanosecond), u(microsecond), a(millisecond), s(second), m(minute), h(hour), d(day), or w(week). So `select * from t1 where ts > now-2w and ts <= now-1w` means the data between two weeks ago and one week ago. The time unit can also be n (calendar month) or y (calendar year) when specifying the time window for down sampling operations.
 
-Time precision in TDengine can be set by the `PRECISION` parameter when executing `CREATE DATABASE`, like below, the default time precision is millisecond.
+Time precision in TDengine can be set by the `PRECISION` parameter when executing `CREATE DATABASE`. The default time precision is millisecond. In the statement below, the precision is set to nanonseconds.
 
 ```sql
 CREATE DATABASE db_name PRECISION 'ns';
@@ -30,8 +30,8 @@ In TDengine, the data types below can be used when specifying a column or tag.
 | 7   | SMALLINT  | 2         | Short integer, the value range is [-32767, 32767], while -32768 is treated as NULL  |
 | 8   |  TINYINT  | 1         | Single-byte integer, the value range is [-127, 127], while -128 is treated as NULL |
 | 9   |   BOOL    | 1         | Bool, the value range is {true, false}   |
-| 10  | NCHAR     | User Defined| Multiple-Byte string that can include like Chinese characters. Each character of NCHAR type consumes 4 bytes storage. The string value should be quoted with single quotes. Literal single quote inside the string must be preceded with backslash, like `\’`. The length must be specified when defining a column or tag of NCHAR type, for example nchar(10) means it can store at most 10 characters of nchar type and will consume fixed storage of 40 bytes. An error will be reported if the string value exceeds the length defined.   |
-| 11  |   JSON    |           | json type can only be used on tag, a tag of json type is excluded with any other tags of any other type |
+| 10  | NCHAR     | User Defined| Multi-Byte string that can include multi byte characters like Chinese characters. Each character of NCHAR type consumes 4 bytes storage. The string value should be quoted with single quotes. Literal single quote inside the string must be preceded with backslash, like `\’`. The length must be specified when defining a column or tag of NCHAR type, for example nchar(10) means it can store at most 10 characters of nchar type and will consume fixed storage of 40 bytes. An error will be reported if the string value exceeds the length defined.   |
+| 11  |   JSON    |           | JSON type can only be used on tags. A tag of json type is excluded with any other tags of any other type |
 
 :::tip
 TDengine is case insensitive and treats any characters in the sql command as lower case by default, case sensitive strings must be quoted with single quotes.
@@ -39,7 +39,7 @@ TDengine is case insensitive and treats any characters in the sql command as low
 :::
 
 :::note
-Only ASCII visible characters are suggested to be used in a column or tag of BINARY type. Multiple-byte characters must be stored in NCHAR type.
+Only ASCII visible characters are suggested to be used in a column or tag of BINARY type. Multi-byte characters must be stored in NCHAR type.
 
 :::
 

docs-en/12-taos-sql/02-database.md

@@ -4,7 +4,7 @@ title: Database
 description: "create and drop database, show or change database parameters"
 ---
 
-## Create Datable
+## Create Database
 
 ```
 CREATE DATABASE [IF NOT EXISTS] db_name [KEEP keep] [DAYS days] [UPDATE 1];
@@ -12,11 +12,11 @@ CREATE DATABASE [IF NOT EXISTS] db_name [KEEP keep] [DAYS days] [UPDATE 1];
 
 :::info
 
-1. KEEP specifies the number of days for which the data in the database to be created will be kept, the default value is 3650 days, i.e. 10 years. The data will be deleted automatically once its age exceeds this threshold.
+1. KEEP specifies the number of days for which the data in the database will be retained. The default value is 3650 days, i.e. 10 years. The data will be deleted automatically once its age exceeds this threshold.
 2. UPDATE specifies whether the data can be updated and how the data can be updated.
-   1. UPDATE set to 0 means update operation is not allowed, the data with an existing timestamp will be dropped silently.
-   2. UPDATE set to 1 means the whole row will be updated, the columns for which no value is specified will be set to NULL
-   3. UPDATE set to 2 means updating a part of columns for a row is allowed, the columns for which no value is specified will be kept as no change
+   1. UPDATE set to 0 means update operation is not allowed. The update for data with an existing timestamp will be discarded silently and the original record in the database will be preserved as is.
+   2. UPDATE set to 1 means the whole row will be updated. The columns for which no value is specified will be set to NULL.
+   3. UPDATE set to 2 means updating a subset of columns for a row is allowed. The columns for which no value is specified will be kept unchanged.
 3. The maximum length of database name is 33 bytes.
 4. The maximum length of a SQL statement is 65,480 bytes.
 5. Below are the parameters that can be used when creating a database
@@ -35,7 +35,7 @@ CREATE DATABASE [IF NOT EXISTS] db_name [KEEP keep] [DAYS days] [UPDATE 1];
    - maxVgroupsPerDb: [Description](/reference/config/#maxvgroupsperdb)
    - comp: [Description](/reference/config/#comp)
    - precision: [Description](/reference/config/#precision)
-6. Please note that all of the parameters mentioned in this section can be configured in configuration file `taosd.cfg` at server side and used by default, the default parameters can be overriden if they are specified in `create database` statement.
+6. Please note that all of the parameters mentioned in this section are configured in configuration file `taos.cfg` on the TDengine server. If not specified in the `create database` statement, the values from taos.cfg are used by default. To override default parameters, they must be specified in the `create database` statement.
    
 :::
 
@@ -52,7 +52,7 @@ USE db_name;
 ```
 
 :::note
-This way is not applicable when using a REST connection
+This way is not applicable when using a REST connection. In a REST connection the database name must be specified before a table or stable name. For e.g. to query the stable "meters" in database "test" the query would be "SELECT count(*) from test.meters"
 
 :::
 
@@ -63,13 +63,13 @@ DROP DATABASE [IF EXISTS] db_name;
 ```
 
 :::note
-All data in the database will be deleted too. This command must be used with caution.
+All data in the database will be deleted too. This command must be used with extreme caution. Please follow your organization's data integrity, data backup, data security or any other applicable SOPs before using this command.
 
 :::
 
 ## Change Database Configuration
 
-Some examples are shown below to demonstrate how to change the configuration of a database. Please note that some configuration parameters can be changed after the database is created, but some others can't, for details of the configuration parameters of database please refer to [Configuration Parameters](/reference/config/).
+Some examples are shown below to demonstrate how to change the configuration of a database. Please note that some configuration parameters can be changed after the database is created, but some cannot. For details of the configuration parameters of database please refer to [Configuration Parameters](/reference/config/).
 
 ```
 ALTER DATABASE db_name COMP 2;
@@ -81,7 +81,7 @@ COMP parameter specifies whether the data is compressed and how the data is comp
 ALTER DATABASE db_name REPLICA 2;
 ```
 
-REPLICA parameter specifies the number of replications of the database.
+REPLICA parameter specifies the number of replicas of the database.
 
 ```
 ALTER DATABASE db_name KEEP 365;
@@ -124,4 +124,4 @@ SHOW DATABASES;
 SHOW CREATE DATABASE db_name;
 ```
 
-This command is useful when migrating the data from one TDengine cluster to another one. This command can be used to get the CREATE statement, which can be used in another TDengine to create the exact same database.
+This command is useful when migrating the data from one TDengine cluster to another. This command can be used to get the CREATE statement, which can be used in another TDengine instance to create the exact same database.

docs-en/12-taos-sql/03-table.md

@@ -12,10 +12,10 @@ CREATE TABLE [IF NOT EXISTS] tb_name (timestamp_field_name TIMESTAMP, field1_nam
 
 :::info
 
-1. The first column of a table must be of TIMESTAMP type, and it will be set as the primary key automatically
+1. The first column of a table MUST be of type TIMESTAMP. It is automatically set as the primary key.
 2. The maximum length of the table name is 192 bytes.
-3. The maximum length of each row is 16k bytes, please note that the extra 2 bytes used by each BINARY/NCHAR column are also counted.
-4. The name of the subtable can only consist of English characters, digits and underscore, and can't start with a digit. Table names are case insensitive.
+3. The maximum length of each row is 48k bytes, please note that the extra 2 bytes used by each BINARY/NCHAR column are also counted.
+4. The name of the subtable can only consist of characters from the English alphabet, digits and underscore. Table names can't start with a digit. Table names are case insensitive.
 5. The maximum length in bytes must be specified when using BINARY or NCHAR types.
 6. Escape character "\`" can be used to avoid the conflict between table names and reserved keywords, above rules will be bypassed when using escape character on table names, but the upper limit for the name length is still valid. The table names specified using escape character are case sensitive. Only ASCII visible characters can be used with escape character.
    For example \`aBc\` and \`abc\` are different table names but `abc` and `aBc` are same table names because they are both converted to `abc` internally.
@@ -44,7 +44,7 @@ The tags for which no value is specified will be set to NULL.
 CREATE TABLE [IF NOT EXISTS] tb_name1 USING stb_name TAGS (tag_value1, ...) [IF NOT EXISTS] tb_name2 USING stb_name TAGS (tag_value2, ...) ...;
 ```
 
-This can be used to create a lot of tables in a single SQL statement to accelerate the speed of the creating tables.
+This can be used to create a lot of tables in a single SQL statement while making table creation much faster.
 
 :::info
 
@@ -111,7 +111,7 @@ If a table is created using a super table as template, the table definition can
 ALTER TABLE tb_name MODIFY COLUMN field_name data_type(length);
 ```
 
-The type of a column is variable length, like BINARY or NCHAR, this can be used to change (or increase) the length of the column.
+If the type of a column is variable length, like BINARY or NCHAR, this command can be used to change the length of the column.
 
 :::note
 If a table is created using a super table as template, the table definition can only be changed on the corresponding super table, and the change will be automatically applied to all the subtables created using this super table as template. For tables created in the normal way, the table definition can be changed directly on the table.

docs-en/12-taos-sql/04-stable.md

@@ -9,7 +9,7 @@ Keyword `STable`, abbreviated for super table, is supported since version 2.0.15
 
 :::
 
-## Crate STable
+## Create STable
 
 ```
 CREATE STable [IF NOT EXISTS] stb_name (timestamp_field_name TIMESTAMP, field1_name data_type1 [, field2_name data_type2 ...]) TAGS (tag1_name tag_type1, tag2_name tag_type2 [, tag3_name tag_type3]);
@@ -19,7 +19,7 @@ The SQL statement of creating a STable is similar to that of creating a table, b
 
 :::info
 
-1. The tag types specified in TAGS should NOT be timestamp. Since 2.1.3.0 timestamp type can be used in TAGS column, but its value must be fixed and arithmetic operation can't be applied on it.
+1. A tag can be of type timestamp, since version 2.1.3.0, but its value must be fixed and arithmetic operations cannot be performed on it. Prior to version 2.1.3.0, tag types specified in TAGS could not be of type timestamp.
 2. The tag names specified in TAGS should NOT be the same as other columns.
 3. The tag names specified in TAGS should NOT be the same as any reserved keywords.(Please refer to [keywords](/taos-sql/keywords/)
 4. The maximum number of tags specified in TAGS is 128, there must be at least one tag, and the total length of all tag columns should NOT exceed 16KB.
@@ -76,7 +76,7 @@ ALTER STable stb_name DROP COLUMN field_name;
 ALTER STable stb_name MODIFY COLUMN field_name data_type(length);
 ```
 
-This command can be used to change (or increase, more specifically) the length of a column of variable length types, like BINARY or NCHAR.
+This command can be used to change (or more specifically, increase) the length of a column of variable length types, like BINARY or NCHAR.
 
 ## Change Tags of A STable
 
@@ -94,7 +94,7 @@ This command is used to add a new tag for a STable and specify the tag type.
 ALTER STable stb_name DROP TAG tag_name;
 ```
 
-The tag will be removed automatically from all the subtables created using the super table as template once a tag is removed from a super table.
+The tag will be removed automatically from all the subtables, created using the super table as template, once a tag is removed from a super table.
 
 ### Change A Tag
 
@@ -102,7 +102,7 @@ The tag will be removed automatically from all the subtables created using the s
 ALTER STable stb_name CHANGE TAG old_tag_name new_tag_name;
 ```
 
-The tag name will be changed automatically for all the subtables created using the super table as template once a tag name is changed for a super table.
+The tag name will be changed automatically for all the subtables, created using the super table as template, once a tag name is changed for a super table.
 
 ### Change Tag Length
 
@@ -110,7 +110,7 @@ The tag name will be changed automatically for all the subtables created using t
 ALTER STable stb_name MODIFY TAG tag_name data_type(length);
 ```
 
-This command can be used to change (or increase, more specifically) the length of a tag of variable length types, like BINARY or NCHAR.
+This command can be used to change (or more specifically, increase) the length of a tag of variable length types, like BINARY or NCHAR.
 
 :::note
 Changing tag values can be applied to only subtables. All other tag operations, like add tag, remove tag, however, can be applied to only STable. If a new tag is added for a STable, the tag will be added with NULL value for all its subtables.

docs-en/12-taos-sql/06-select.md

@@ -21,7 +21,7 @@ SELECT select_expr [, select_expr ...]
 
 ## Wildcard
 
-Wilcard \* can be used to specify all columns. The result includes only data columns for normal tables.
+Wildcard \* can be used to specify all columns. The result includes only data columns for normal tables.
 
 ```
 taos> SELECT * FROM d1001;
@@ -51,14 +51,14 @@ taos> SELECT * FROM meters;
 Query OK, 9 row(s) in set (0.002022s)
 ```
 
-Wildcard can be used with table name as prefix, both below SQL statements have same effects and return all columns.
+Wildcard can be used with table name as prefix. Both SQL statements below have the same effect and return all columns.
 
 ```SQL
 SELECT * FROM d1001;
 SELECT d1001.* FROM d1001;
 ```
 
-In JOIN query, however, with or without table name prefix will return different results. \* without table prefix will return all the columns of both tables, but \* with table name as prefix will return only the columns of that table.
+In a JOIN query, however, the results are different with or without a table name prefix. \* without table prefix will return all the columns of both tables, but \* with table name as prefix will return only the columns of that table.
 
 ```
 taos> SELECT * FROM d1001, d1003 WHERE d1001.ts=d1003.ts;
@@ -76,7 +76,7 @@ taos> SELECT d1001.* FROM d1001,d1003 WHERE d1001.ts = d1003.ts;
 Query OK, 1 row(s) in set (0.020443s)
 ```
 
-Wilcard \* can be used with some functions, but the result may be different depending on the function being used. For example, `count(*)` returns only one column, i.e. the number of rows; `first`, `last` and `last_row` return all columns of the selected row.
+Wildcard \* can be used with some functions, but the result may be different depending on the function being used. For example, `count(*)` returns only one column, i.e. the number of rows; `first`, `last` and `last_row` return all columns of the selected row.
 
 ```
 taos> SELECT COUNT(*) FROM d1001;
@@ -96,7 +96,7 @@ Query OK, 1 row(s) in set (0.000849s)
 
 ## Tags
 
-Starting from version 2.0.14, tag columns can be selected together with data columns when querying sub tables. Please note that, however, wildcard \* doesn't represent any tag column, that means tag columns must be specified explicitly like the example below.
+Starting from version 2.0.14, tag columns can be selected together with data columns when querying sub tables. Please note however, that, wildcard \* cannot be used to represent any tag column. This means that tag columns must be specified explicitly like the example below.
 
 ```
 taos> SELECT location, groupid, current FROM d1001 LIMIT 2;
@@ -109,7 +109,7 @@ Query OK, 2 row(s) in set (0.003112s)
 
 ## Get distinct values
 
-`DISTINCT` keyword can be used to get all the unique values of tag columns from a super table, it can also be used to get all the unique values of data columns from a table or subtable.
+`DISTINCT` keyword can be used to get all the unique values of tag columns from a super table. It can also be used to get all the unique values of data columns from a table or subtable.
 
 ```sql
 SELECT DISTINCT tag_name [, tag_name ...] FROM stb_name;
@@ -118,15 +118,15 @@ SELECT DISTINCT col_name [, col_name ...] FROM tb_name;
 
 :::info
 
-1. Configuration parameter `maxNumOfDistinctRes` in `taos.cfg` is used to control the number of rows to output. The minimum configurable value is 100,000, the maximum configurable value is 100,000,000, the default value is 1000,000. If the actual number of rows exceeds the value of this parameter, only the number of rows specified by this parameter will be output.
-2. It can't be guaranteed that the results selected by using `DISTINCT` on columns of `FLOAT` or `DOUBLE` are exactly unique because of the precision nature of floating numbers.
+1. Configuration parameter `maxNumOfDistinctRes` in `taos.cfg` is used to control the number of rows to output. The minimum configurable value is 100,000, the maximum configurable value is 100,000,000, the default value is 1,000,000. If the actual number of rows exceeds the value of this parameter, only the number of rows specified by this parameter will be output.
+2. It can't be guaranteed that the results selected by using `DISTINCT` on columns of `FLOAT` or `DOUBLE` are exactly unique because of the precision errors in floating point numbers.
 3. `DISTINCT` can't be used in the sub-query of a nested query statement, and can't be used together with aggregate functions, `GROUP BY` or `JOIN` in the same SQL statement.
 
 :::
 
 ## Columns Names of Result Set
 
-When using `SELECT`, the column names in the result set will be same as that in the select clause if `AS` is not used. `AS` can be used to rename the column names in the result set. For example
+When using `SELECT`, the column names in the result set will be the same as that in the select clause if `AS` is not used. `AS` can be used to rename the column names in the result set. For example
 
 ```
 taos> SELECT ts, ts AS primary_key_ts FROM d1001;
@@ -161,7 +161,7 @@ SELECT * FROM d1001;
 
 ## Special Query
 
-Some special query functionalities can be performed without `FORM` sub-clause. For example, below statement can be used to get the current database in use.
+Some special query functions can be invoked without `FROM` sub-clause. For example, the statement below can be used to get the current database in use.
 
 ```
 taos> SELECT DATABASE();
@@ -181,7 +181,7 @@ taos> SELECT DATABASE();
 Query OK, 1 row(s) in set (0.000184s)
 ```
 
-Below statement can be used to get the version of client or server.
+The statement below can be used to get the version of client or server.
 
 ```
 taos> SELECT CLIENT_VERSION();
@@ -197,7 +197,7 @@ taos> SELECT SERVER_VERSION();
 Query OK, 1 row(s) in set (0.000077s)
 ```
 
-Below statement is used to check the server status. One integer, like `1`, is returned if the server status is OK, otherwise an error code is returned. This is compatible with the status check for TDengine from connection pool or 3rd party tools, and can avoid the problem of losing the connection from a connection pool when using the wrong heartbeat checking SQL statement.
+The statement below is used to check the server status. An integer, like `1`, is returned if the server status is OK, otherwise an error code is returned. This is compatible with the status check for TDengine from connection pool or 3rd party tools, and can avoid the problem of losing the connection from a connection pool when using the wrong heartbeat checking SQL statement.
 
 ```
 taos> SELECT SERVER_STATUS();
@@ -284,7 +284,7 @@ taos> SELECT COUNT(tbname) FROM meters WHERE groupId > 2;
 Query OK, 1 row(s) in set (0.001091s)
 ```
 
-- Wildcard \* can be used to get all columns, or specific column names can be specified. Arithmetic operation can be performed on columns of number types, columns can be renamed in the result set.
+- Wildcard \* can be used to get all columns, or specific column names can be specified. Arithmetic operation can be performed on columns of numerical types, columns can be renamed in the result set.
 - Arithmetic operation on columns can't be used in where clause. For example, `where a*2>6;` is not allowed but `where a>6/2;` can be used instead for the same purpose.
 - Arithmetic operation on columns can't be used as the objectives of select statement. For example, `select min(2*a) from t;` is not allowed but `select 2*min(a) from t;` can be used instead.
 - Logical operation can be used in `WHERE` clause to filter numeric values, wildcard can be used to filter string values.
@@ -318,13 +318,13 @@ Logical operations in below table can be used in the `where` clause to filter th
 - Operator `like` is used together with wildcards to match strings
   - '%' matches 0 or any number of characters, '\_' matches any single ASCII character.
   - `\_` is used to match the \_ in the string.
-  - The maximum length of wildcard string is 100 bytes from version 2.1.6.1 (before that the maximum length is 20 bytes). `maxWildCardsLength` in `taos.cfg` can be used to control this threshold. Too long wildcard string may slowdown the execution performance of `LIKE` operator.
+  - The maximum length of wildcard string is 100 bytes from version 2.1.6.1 (before that the maximum length is 20 bytes). `maxWildCardsLength` in `taos.cfg` can be used to control this threshold. A very long wildcard string may slowdown the execution performance of `LIKE` operator.
 - `AND` keyword can be used to filter multiple columns simultaneously. AND/OR operation can be performed on single or multiple columns from version 2.3.0.0. However, before 2.3.0.0 `OR` can't be used on multiple columns.
 - For timestamp column, only one condition can be used; for other columns or tags, `OR` keyword can be used to combine multiple logical operators. For example, `((value > 20 AND value < 30) OR (value < 12))`.
   - From version 2.3.0.0, multiple conditions can be used on timestamp column, but the result set can only contain single time range.
 - From version 2.0.17.0, operator `BETWEEN AND` can be used in where clause, for example `WHERE col2 BETWEEN 1.5 AND 3.25` means the filter condition is equal to "1.5 ≤ col2 ≤ 3.25".
-- From version 2.1.4.0, operator `IN` can be used in the where clause. For example, `WHERE city IN ('California.SanFrancisco', 'California.SanDiego')`. For bool type, both `{true, false}` and `{0, 1}` are allowed, but integers other than 0 or 1 are not allowed. FLOAT and DOUBLE types are impacted by floating precision, only values that match the condition within the tolerance will be selected. Non-primary key column of timestamp type can be used with `IN`.
-- From version 2.3.0.0, regular expression is supported in the where clause with keyword `match` or `nmatch`, the regular expression is case insensitive.
+- From version 2.1.4.0, operator `IN` can be used in the where clause. For example, `WHERE city IN ('California.SanFrancisco', 'California.SanDiego')`. For bool type, both `{true, false}` and `{0, 1}` are allowed, but integers other than 0 or 1 are not allowed. FLOAT and DOUBLE types are impacted by floating point precision errors. Only values that match the condition within the tolerance will be selected. Non-primary key column of timestamp type can be used with `IN`.
+- From version 2.3.0.0, regular expression is supported in the where clause with keyword `match` or `nmatch`. The regular expression is case insensitive.
 
 ## Regular Expression
 
@@ -364,7 +364,7 @@ FROM temp_STable t1, temp_STable t2
 WHERE t1.ts = t2.ts AND t1.deviceid = t2.deviceid AND t1.status=0;
 ```
 
-Similary, join operation can be performed on the result set of multiple sub queries.
+Similarly, join operations can be performed on the result set of multiple sub queries.
 
 :::note
 Restrictions on join operation:
@@ -380,7 +380,7 @@ Restrictions on join operation:
 
 ## Nested Query
 
-Nested query is also called sub query, that means in a single SQL statement the result of inner query can be used as the data source of the outer query.
+Nested query is also called sub query. This means that in a single SQL statement the result of inner query can be used as the data source of the outer query.
 
 From 2.2.0.0, unassociated sub query can be used in the `FROM` clause. Unassociated means the sub query doesn't use the parameters in the parent query. More specifically, in the `tb_name_list` of `SELECT` statement, an independent SELECT statement can be used. So a complete nested query looks like:
 
@@ -390,14 +390,14 @@ SELECT ... FROM (SELECT ... FROM ...) ...;
 
 :::info
 
-- Only one layer of nesting is allowed, that means no sub query is allowed in a sub query
-- The result set returned by the inner query will be used as a "virtual table" by the outer query, the "virtual table" can be renamed using `AS` keyword for easy reference in the outer query.
+- Only one layer of nesting is allowed, that means no sub query is allowed within a sub query
+- The result set returned by the inner query will be used as a "virtual table" by the outer query. The "virtual table" can be renamed using `AS` keyword for easy reference in the outer query.
 - Sub query is not allowed in continuous query.
 - JOIN operation is allowed between tables/STables inside both inner and outer queries. Join operation can be performed on the result set of the inner query.
 - UNION operation is not allowed in either inner query or outer query.
-- The functionalities that can be used in the inner query is same as non-nested query.
-  - `ORDER BY` inside the inner query doesn't make any sense but will slow down the query performance significantly, so please avoid such usage.
-- Compared to the non-nested query, the functionalities that can be used in the outer query have such restrictions as:
+- The functions that can be used in the inner query are the same as those that can be used in a non-nested query.
+  - `ORDER BY` inside the inner query is unnecessary and will slow down the query performance significantly. It is best to avoid the use of `ORDER BY` inside the inner query.
+- Compared to the non-nested query, the functionality that can be used in the outer query has the following restrictions:
   - Functions
     - If the result set returned by the inner query doesn't contain timestamp column, then functions relying on timestamp can't be used in the outer query, like `TOP`, `BOTTOM`, `FIRST`, `LAST`, `DIFF`.
     - Functions that need to scan the data twice can't be used in the outer query, like `STDDEV`, `PERCENTILE`.
@@ -442,8 +442,8 @@ The sum of col1 and col2 for rows later than 2018-06-01 08:00:00.000 and whose c
 SELECT (col1 + col2) AS 'complex' FROM tb1 WHERE ts > '2018-06-01 08:00:00.000' AND col2 > 1.2 LIMIT 10 OFFSET 5;
 ```
 
-The rows in the past 10 minutes and whose col2 is bigger than 3.14 are selected and output to the result file `/home/testoutpu.csv` with below SQL statement:
+The rows in the past 10 minutes and whose col2 is bigger than 3.14 are selected and output to the result file `/home/testoutput.csv` with below SQL statement:
 
 ```SQL
-SELECT COUNT(*) FROM tb1 WHERE ts >= NOW - 10m AND col2 > 3.14 >> /home/testoutpu.csv;
+SELECT COUNT(*) FROM tb1 WHERE ts >= NOW - 10m AND col2 > 3.14 >> /home/testoutput.csv;
 ```

docs-en/12-taos-sql/07-function.md

@@ -22,8 +22,8 @@ SELECT COUNT([*|field_name]) FROM tb_name [WHERE clause];
 
 **More explanation**:
 
-- Wildcard (\*) can be used to represent all columns, it's used to get the number of all rows
-- The number of non-NULL values will be returned if this function is used on a specific column
+- Wildcard (\*) is used to represent all columns. The `COUNT` function is used to get the total number of all rows.
+- The number of non-NULL values will be returned if this function is used on a specific column.
 
 **Examples**:
 
@@ -87,7 +87,7 @@ SELECT TWA(field_name) FROM tb_name WHERE clause;
 
 **More explanations**:
 
-- From version 2.1.3.0, function TWA can be used on stable with `GROUP BY`, i.e. timelines generated by `GROUP BY tbname` on a STable.
+- Since version 2.1.3.0, function TWA can be used on stable with `GROUP BY`, i.e. timelines generated by `GROUP BY tbname` on a STable.
 
 ### IRATE
 
@@ -105,7 +105,7 @@ SELECT IRATE(field_name) FROM tb_name WHERE clause;
 
 **More explanations**:
 
-- From version 2.1.3.0, function IRATE can be used on stble with `GROUP BY`, i.e. timelines generated by `GROUP BY tbname` on a STable.
+- Since version 2.1.3.0, function IRATE can be used on stble with `GROUP BY`, i.e. timelines generated by `GROUP BY tbname` on a STable.
 
 ### SUM
 
@@ -149,7 +149,7 @@ SELECT STDDEV(field_name) FROM tb_name [WHERE clause];
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
-**Applicable table types**: table, STable (starting from version 2.0.15.1)
+**Applicable table types**: table, STable (since version 2.0.15.1)
 
 **Examples**:
 
@@ -193,13 +193,13 @@ SELECT MODE(field_name) FROM tb_name [WHERE clause];
 
 **Description**:The value which has the highest frequency of occurrence. NULL is returned if there are multiple values which have highest frequency of occurrence. It can't be used on timestamp column or tags.
 
-**Return value type**:Same as the data type of the column being operated
+**Return value type**:Same as the data type of the column being operated upon
 
 **Applicable column types**:Data types except for timestamp
 
 **More explanations**:Considering the number of returned result set is unpredictable, it's suggested to limit the number of unique values to 100,000, otherwise error will be returned.
 
-**Applicable version**:From version 2.6.0.0
+**Applicable version**:Since version 2.6.0.0
 
 **Examples**:
 
@@ -234,7 +234,7 @@ SELECT HYPERLOGLOG(field_name) FROM { tb_name | stb_name } [WHERE clause];
 
 **More explanations**: The benefit of using hyperloglog algorithm is that the memory usage is under control when the data volume is huge. However, when the data volume is very small, the result may be not accurate, it's recommented to use `select count(data) from (select unique(col) as data from table)` in this case.
 
-**Applicable versions**:From version 2.6.0.0
+**Applicable versions**:Since version 2.6.0.0
 
 **Examples**:
 
@@ -271,7 +271,7 @@ SELECT MIN(field_name) FROM {tb_name | stb_name} [WHERE clause];
 
 **Description**: The minimum value of a specific column in a table or STable
 
-**Return value type**: Same as the data type of the column being operated
+**Return value type**: Same as the data type of the column being operated upon
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
@@ -301,7 +301,7 @@ SELECT MAX(field_name) FROM { tb_name | stb_name } [WHERE clause];
 
 **Description**: The maximum value of a specific column of a table or STable
 
-**Return value type**: Same as the data type of the column being operated
+**Return value type**: Same as the data type of the column being operated upon
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
@@ -331,7 +331,7 @@ SELECT FIRST(field_name) FROM { tb_name | stb_name } [WHERE clause];
 
 **Description**: The first non-null value of a specific column in a table or STable
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Any data type
 
@@ -341,7 +341,7 @@ SELECT FIRST(field_name) FROM { tb_name | stb_name } [WHERE clause];
 
 - FIRST(\*) can be used to get the first non-null value of all columns
 - NULL will be returned if all the values of the specified column are all NULL
-- No result will NOT be returned if all the columns in the result set are all NULL
+- A result will NOT be returned if all the columns in the result set are all NULL
 
 **Examples**:
 
@@ -367,7 +367,7 @@ SELECT LAST(field_name) FROM { tb_name | stb_name } [WHERE clause];
 
 **Description**: The last non-NULL value of a specific column in a table or STable
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Any data type
 
@@ -403,7 +403,7 @@ SELECT TOP(field_name, K) FROM { tb_name | stb_name } [WHERE clause];
 
 **Description**: The greatest _k_ values of a specific column in a table or STable. If a value has multiple occurrences in the column but counting all of them in will exceed the upper limit _k_, then a part of them will be returned randomly.
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
@@ -442,7 +442,7 @@ SELECT BOTTOM(field_name, K) FROM { tb_name | stb_name } [WHERE clause];
 
 **Description**: The least _k_ values of a specific column in a table or STable. If a value has multiple occurrences in the column but counting all of them in will exceed the upper limit _k_, then a part of them will be returned randomly.
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
@@ -549,7 +549,7 @@ SELECT LAST_ROW(field_name) FROM { tb_name | stb_name };
 
 **Description**: The last row of a table or STable
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Any data type
 
@@ -576,7 +576,7 @@ SELECT LAST_ROW(field_name) FROM { tb_name | stb_name };
  Query OK, 1 row(s) in set (0.001042s)
 ```
 
-### INTERP [From version 2.3.1]
+### INTERP [Since version 2.3.1]
 
 ```
 SELECT INTERP(field_name) FROM { tb_name | stb_name } [WHERE where_condition] [ RANGE(timestamp1,timestamp2) ] [EVERY(interval)] [FILL ({ VALUE | PREV | NULL | LINEAR | NEXT})];
@@ -584,7 +584,7 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } [WHERE where_condition] [
 
 **Description**: The value that matches the specified timestamp range is returned, if existing; or an interpolation value is returned.
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Numeric data types
 
@@ -593,7 +593,7 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } [WHERE where_condition] [
 **More explanations**
 
 - `INTERP` is used to get the value that matches the specified time slice from a column. If no such value exists an interpolation value will be returned based on `FILL` parameter.
-- The input data of `INTERP` is the value of the specified column, `where` can be used to filter the original data. If no `where` condition is specified then all original data is the input.
+- The input data of `INTERP` is the value of the specified column and a `where` clause can be used to filter the original data. If no `where` condition is specified then all original data is the input.
 - The output time range of `INTERP` is specified by `RANGE(timestamp1,timestamp2)` parameter, with timestamp1<=timestamp2. timestamp1 is the starting point of the output time range and must be specified. timestamp2 is the ending point of the output time range and must be specified. If `RANGE` is not specified, then the timestamp of the first row that matches the filter condition is treated as timestamp1, the timestamp of the last row that matches the filter condition is treated as timestamp2.
 - The number of rows in the result set of `INTERP` is determined by the parameter `EVERY`. Starting from timestamp1, one interpolation is performed for every time interval specified `EVERY` parameter. If `EVERY` parameter is not used, the time windows will be considered as no ending timestamp, i.e. there is only one time window from timestamp1.
 - Interpolation is performed based on `FILL` parameter. No interpolation is performed if `FILL` is not used, that means either the original data that matches is returned or nothing is returned.
@@ -632,7 +632,7 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } [WHERE where_condition] [
   taos> SELECT INTERP(current) FROM t1 where ts >= '2017-07-14 17:00:00' and ts <= '2017-07-14 20:00:00' RANGE('2017-7-14 18:00:00','2017-7-14 19:00:00') EVERY(5s) FILL(LINEAR);
 ```
 
-### INTERP [Prior to version 2.3.1]
+### INTERP [Since version 2.0.15.0]
 
 ```
 SELECT INTERP(field_name) FROM { tb_name | stb_name } WHERE ts='timestamp' [FILL ({ VALUE | PREV | NULL | LINEAR | NEXT})];
@@ -640,7 +640,7 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } WHERE ts='timestamp' [FILL
 
 **Description**: The value of a specific column that matches the specified time slice
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Numeric data type
 
@@ -648,7 +648,6 @@ SELECT INTERP(field_name) FROM { tb_name | stb_name } WHERE ts='timestamp' [FILL
 
 **More explanations**:
 
-- It can be used from version 2.0.15.0
 - Time slice must be specified. If there is no data matching the specified time slice, interpolation is performed based on `FILL` parameter. Conditions such as tags or `tbname` can be used `Where` clause can be used to filter data.
 - The timestamp specified must be within the time range of the data rows of the table or STable. If it is beyond the valid time range, nothing is returned even with `FILL` parameter.
 - `INTERP` can be used to query only single time point once. `INTERP` can be used with `EVERY` to get the interpolation value every time interval.
@@ -696,11 +695,11 @@ SELECT TAIL(field_name, k, offset_val) FROM {tb_name | stb_name} [WHERE clause];
 
 **Parameter value range**: k: [1,100] offset_val: [0,100]
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Any data type except form timestamp, i.e. the primary key
 
-**Applicable versions**: From version 2.6.0.0
+**Applicable versions**: Since version 2.6.0.0
 
 **Examples**:
 
@@ -732,11 +731,11 @@ SELECT UNIQUE(field_name) FROM {tb_name | stb_name} [WHERE clause];
 
 **Description**: The values that occur the first time in the specified column. The effect is similar to `distinct` keyword, but it can also be used to match tags or timestamp.
 
-**Return value type**: Same as the column or tag being operated
+**Return value type**: Same as the column or tag being operated upon
 
 **Applicable column types**: Any data types except for timestamp
 
-**Applicable versions**: From version 2.6.0.0
+**Applicable versions**: Since version 2.6.0.0
 
 **More explanations**:
 
@@ -780,7 +779,7 @@ SELECT {DIFF(field_name, ignore_negative) | DIFF(field_name)} FROM tb_name [WHER
 
 **Description**: The different of each row with its previous row for a specific column. `ignore_negative` can be specified as 0 or 1, the default value is 1 if it's not specified. `1` means negative values are ignored.
 
-**Return value type**: Same as the column being operated
+**Return value type**: Same as the column being operated upon
 
 **Applicable column types**: Data types except for timestamp, binary, nchar and bool
 
@@ -789,8 +788,8 @@ SELECT {DIFF(field_name, ignore_negative) | DIFF(field_name)} FROM tb_name [WHER
 **More explanations**:
 
 - The number of result rows is the number of rows subtracted by one, no output for the first row
-- From version 2.1.30, `DIFF` can be used on STable with `GROUP by tbname`
-- From version 2.6.0, `ignore_negative` parameter is supported
+- Since version 2.1.30, `DIFF` can be used on STable with `GROUP by tbname`
+- Since version 2.6.0, `ignore_negative` parameter is supported
 
 **Examples**:
 
@@ -874,7 +873,7 @@ Query OK, 1 row(s) in set (0.000836s)
 SELECT CEIL(field_name) FROM { tb_name | stb_name } [WHERE clause];
 ```
 
-**Description**: The round up value of a specific column
+**Description**: The rounded up value of a specific column
 
 **Return value type**: Same as the column being used
 
@@ -896,9 +895,9 @@ SELECT CEIL(field_name) FROM { tb_name | stb_name } [WHERE clause];
 SELECT FLOOR(field_name) FROM { tb_name | stb_name } [WHERE clause];
 ```
 
-**Description**: The round down value of a specific column
+**Description**: The rounded down value of a specific column
 
-**More explanations**: The restrictions are same as `CEIL` function.
+**More explanations**: The restrictions are same as those of the `CEIL` function.
 
 ### ROUND
 
@@ -906,7 +905,7 @@ SELECT FLOOR(field_name) FROM { tb_name | stb_name } [WHERE clause];
 SELECT ROUND(field_name) FROM { tb_name | stb_name } [WHERE clause];
 ```
 
-**Description**: The round value of a specific column.
+**Description**: The rounded value of a specific column.
 
 **More explanations**: The restrictions are same as `CEIL` function.
 
@@ -933,7 +932,7 @@ SELECT ROUND(field_name) FROM { tb_name | stb_name } [WHERE clause];
 - Can only be used with aggregate functions
 - `Group by tbname` must be used together on a STable to force the result on a single timeline
 
-**Applicable versions**: From 2.3.0.x
+**Applicable versions**: Since 2.3.0.x
 
 ### MAVG
 
@@ -958,7 +957,7 @@ SELECT ROUND(field_name) FROM { tb_name | stb_name } [WHERE clause];
 - Can't be used with aggregate functions.
 - Must be used with `GROUP BY tbname` when it's used on a STable to force the result on each single timeline.
 
-**Applicable versions**: From 2.3.0.x
+**Applicable versions**: Since 2.3.0.x
 
 ### SAMPLE
 
@@ -981,7 +980,7 @@ SELECT ROUND(field_name) FROM { tb_name | stb_name } [WHERE clause];
 - Arithmetic operation can't be operated on the result of `SAMPLE` function
 - Must be used with `Group by tbname` when it's used on a STable to force the result on each single timeline
 
-**Applicable versions**: From 2.3.0.x
+**Applicable versions**: Since 2.3.0.x
 
 ### ASIN
 
@@ -1460,8 +1459,8 @@ SELECT field_name [+|-|*|/|%][Value|field_name] FROM { tb_name | stb_name }  [WH
 
 **More explanations**:
 
-- Arithmetic operations can be performed on two or more columns, `()` can be used to control the precedence
-- NULL doesn't participate the operation, if one of the operands is NULL then result is NULL
+- Arithmetic operations can be performed on two or more columns, Parentheses `()` can be used to control the order of precedence.
+- NULL doesn't participate in the operation i.e. if one of the operands is NULL then result is NULL.
 
 **Examples**:
 
@@ -1586,7 +1585,7 @@ Query OK, 6 row(s) in set (0.002613s)
 
 ## Time Functions
 
-From version 2.6.0.0, below time related functions can be used in TDengine.
+Since version 2.6.0.0, below time related functions can be used in TDengine.
 
 ### NOW
 
@@ -1840,6 +1839,8 @@ SELECT TIMEDIFF(ts_val1 | datetime_string1 | ts_col1, ts_val2 | datetime_string2
   1u(microsecond),1a(millisecond),1s(second),1m(minute),1h(hour),1d(day).
 - The precision of the returned timestamp is same as the precision set for the current data base in use
 
+**Applicable versions**:Since version 2.6.0.0
+
 **Examples**:
 
 ```sql

docs-en/12-taos-sql/08-interval.md

@@ -3,36 +3,36 @@ sidebar_label: Interval
 title: Aggregate by Time Window
 ---
 
-Aggregate by time window is supported in TDengine. For example, each temperature sensor reports the temperature every second, the average temperature every 10 minutes can be retrieved by query with time window.
-Window related clauses are used to divide the data set to be queried into subsets and then aggregate. There are three kinds of windows, time window, status window, and session window. There are two kinds of time windows, sliding window and flip time window.
+Aggregation by time window is supported in TDengine. For example, in the case where temperature sensors report the temperature every seconds, the average temperature for every 10 minutes can be retrieved by performing a query with a time window.
+Window related clauses are used to divide the data set to be queried into subsets and then aggregation is performed across the subsets. There are three kinds of windows: time window, status window, and session window. There are two kinds of time windows: sliding window and flip time/tumbling window.
 
 ## Time Window
 
-`INTERVAL` clause is used to generate time windows of the same time interval, `SLIDING` is used to specify the time step for which the time window moves forward. The query is performed on one time window each time, and the time window moves forward with time. When defining continuous query both the size of time window and the step of forward sliding time need to be specified. As shown in the figure blow, [t0s, t0e] ，[t1s , t1e]， [t2s, t2e] are respectively the time ranges of three time windows on which continuous queries are executed. The time step for which time window moves forward is marked by `sliding time`. Query, filter and aggregate operations are executed on each time window respectively. When the time step specified by `SLIDING` is same as the time interval specified by `INTERVAL`, the sliding time window is actually a flip time window.
+The `INTERVAL` clause is used to generate time windows of the same time interval. The `SLIDING` parameter is used to specify the time step for which the time window moves forward. The query is performed on one time window each time, and the time window moves forward with time. When defining a continuous query, both the size of the time window and the step of forward sliding time need to be specified. As shown in the figure blow, [t0s, t0e] ，[t1s , t1e]， [t2s, t2e] are respectively the time ranges of three time windows on which continuous queries are executed. The time step for which time window moves forward is marked by `sliding time`. Query, filter and aggregate operations are executed on each time window respectively. When the time step specified by `SLIDING` is same as the time interval specified by `INTERVAL`, the sliding time window is actually a flip time/tumbling window.
 
-![Time Window](./timewindow-1.webp)
+![TDengine Database Time Window](./timewindow-1.webp)
 
-`INTERVAL` and `SLIDING` should be used with aggregate functions and select functions. Below SQL statement is illegal because no aggregate or selection function is used with `INTERVAL`.
+`INTERVAL` and `SLIDING` should be used with aggregate functions and select functions. The SQL statement below is illegal because no aggregate or selection function is used with `INTERVAL`.
 
 ```
 SELECT * FROM temp_tb_1 INTERVAL(1m);
 ```
 
-The time step specified by `SLIDING` can't exceed the time interval specified by `INTERVAL`. Below SQL statement is illegal because the time length specified by `SLIDING` exceeds that specified by `INTERVAL`.
+The time step specified by `SLIDING` cannot exceed the time interval specified by `INTERVAL`. The SQL statement below is illegal because the time length specified by `SLIDING` exceeds that specified by `INTERVAL`.
 
 ```
 SELECT COUNT(*) FROM temp_tb_1 INTERVAL(1m) SLIDING(2m);
 ```
 
-When the time length specified by `SLIDING` is the same as that specified by `INTERVAL`, the sliding window is actually a flip window. The minimum time range specified by `INTERVAL` is 10 milliseconds (10a) prior to version 2.1.5.0. From version 2.1.5.0, the minimum time range by `INTERVAL` can be 1 microsecond (1u). However, if the DB precision is millisecond, the minimum time range is 1 millisecond (1a). Please note that the `timezone` parameter should be configured to be the same value in the `taos.cfg` configuration file on client side and server side.
+When the time length specified by `SLIDING` is the same as that specified by `INTERVAL`, the sliding window is actually a flip/tumbling window. The minimum time range specified by `INTERVAL` is 10 milliseconds (10a) prior to version 2.1.5.0. Since version 2.1.5.0, the minimum time range by `INTERVAL` can be 1 microsecond (1u). However, if the DB precision is millisecond, the minimum time range is 1 millisecond (1a). Please note that the `timezone` parameter should be configured to be the same value in the `taos.cfg` configuration file on client side and server side.
 
 ## Status Window
 
-In case of using integer, bool, or string to represent the device status at a moment, the continuous rows with same status belong to same status window. Once the status changes, the status window closes. As shown in the following figure, there are two status windows according to status, [2019-04-28 14:22:07，2019-04-28 14:22:10] and [2019-04-28 14:22:11，2019-04-28 14:22:12]. Status window is not applicable to STable for now.
+In case of using integer, bool, or string to represent the status of a device at any given moment, continuous rows with the same status belong to a status window. Once the status changes, the status window closes. As shown in the following figure, there are two status windows according to status, [2019-04-28 14:22:07，2019-04-28 14:22:10] and [2019-04-28 14:22:11，2019-04-28 14:22:12]. Status window is not applicable to STable for now.
 
-![Status Window](./timewindow-3.webp)
+![TDengine Database Status Window](./timewindow-3.webp)
 
-`STATE_WINDOW` is used to specify the column based on which to define status window, for example：
+`STATE_WINDOW` is used to specify the column on which the status window will be based. For example：
 
 ```
 SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status);
@@ -44,9 +44,9 @@ SELECT COUNT(*), FIRST(ts), status FROM temp_tb_1 STATE_WINDOW(status);
 SELECT COUNT(*), FIRST(ts) FROM temp_tb_1 SESSION(ts, tol_val);
 ```
 
-The primary key, i.e. timestamp, is used to determine which session window the row belongs to. If the time interval between two adjacent rows is within the time range specified by `tol_val`, they belong to the same session window; otherwise they belong to two different time windows. As shown in the figure below, if the limit of time interval for the session window is specified as 12 seconds, then the 6 rows in the figure constitutes 2 time windows, [2019-04-28 14:22:10，2019-04-28 14:22:30] and [2019-04-28 14:23:10，2019-04-28 14:23:30], because the time difference between 2019-04-28 14:22:30 and 2019-04-28 14:23:10 is 40 seconds, which exceeds the time interval limit of 12 seconds.
+The primary key, i.e. timestamp, is used to determine which session window a row belongs to. If the time interval between two adjacent rows is within the time range specified by `tol_val`, they belong to the same session window; otherwise they belong to two different session windows. As shown in the figure below, if the limit of time interval for the session window is specified as 12 seconds, then the 6 rows in the figure constitutes 2 time windows, [2019-04-28 14:22:10，2019-04-28 14:22:30] and [2019-04-28 14:23:10，2019-04-28 14:23:30], because the time difference between 2019-04-28 14:22:30 and 2019-04-28 14:23:10 is 40 seconds, which exceeds the time interval limit of 12 seconds.
 
-![Session Window](./timewindow-2.webp)
+![TDengine Database Session Window](./timewindow-2.webp)
 
 If the time interval between two continuous rows are within the time interval specified by `tol_value` they belong to the same session window; otherwise a new session window is started automatically. Session window is not supported on STable for now.
 
@@ -73,7 +73,7 @@ SELECT function_list FROM stb_name
 
 ### Restrictions
 
-- Aggregate functions and select functions can be used in `function_list`, with each function having only one output, for example COUNT, AVG, SUM, STDDEV, LEASTSQUARES, PERCENTILE, MIN, MAX, FIRST, LAST. Functions having multiple output can't be used, for example DIFF or arithmetic operations.
+- Aggregate functions and select functions can be used in `function_list`, with each function having only one output. For example COUNT, AVG, SUM, STDDEV, LEASTSQUARES, PERCENTILE, MIN, MAX, FIRST, LAST. Functions having multiple outputs, such as DIFF or arithmetic operations can't be used.
 - `LAST_ROW` can't be used together with window aggregate.
 - Scalar functions, like CEIL/FLOOR, can't be used with window aggregate.
 - `WHERE` clause can be used to specify the starting and ending time and other filter conditions
@@ -87,8 +87,8 @@ SELECT function_list FROM stb_name
 
 :::info
 
-1. Huge volume of interpolation output may be returned using `FILL`, so it's recommended to specify the time range when using `FILL`. The maximum interpolation values that can be returned in single query is 10,000,000.
-2. The result set is in ascending order of timestamp in aggregate by time window aggregate.
+1. A huge volume of interpolation output may be returned using `FILL`, so it's recommended to specify the time range when using `FILL`. The maximum number of interpolation values that can be returned in a single query is 10,000,000.
+2. The result set is in ascending order of timestamp when you aggregate by time window.
 3. If aggregate by window is used on STable, the aggregate function is performed on all the rows matching the filter conditions. If `GROUP BY` is not used in the query, the result set will be returned in ascending order of timestamp; otherwise the result set is not exactly in the order of ascending timestamp in each group.
 
 :::
@@ -97,13 +97,13 @@ Aggregate by time window is also used in continuous query, please refer to [Cont
 
 ## Examples
 
-The table of intelligent meters can be created by the SQL statement below：
+A table of intelligent meters can be created by the SQL statement below：
 
 ```sql
 CREATE TABLE meters (ts TIMESTAMP, current FLOAT, voltage INT, phase FLOAT) TAGS (location BINARY(64), groupId INT);
 ```
 
-The average current, maximum current and median of current in every 10 minutes for the past 24 hours can be calculated using the below SQL statement, with missing values filled with the previous non-NULL values.
+The average current, maximum current and median of current in every 10 minutes for the past 24 hours can be calculated using the SQL statement below, with missing values filled with the previous non-NULL values.
 
 ```
 SELECT AVG(current), MAX(current), APERCENTILE(current, 50) FROM meters

docs-en/12-taos-sql/09-limit.md

@@ -4,8 +4,8 @@ title: Limits & Restrictions
 
 ## Naming Rules
 
-1. Only English characters, digits and underscore are allowed
-2. Can't start with a digit
+1. Only characters from the English alphabet, digits and underscore are allowed
+2. Names cannot start with a digit
 3. Case insensitive without escape character "\`"
 4. Identifier with escape character "\`"
    To support more flexible table or column names, a new escape character "\`" is introduced. For more details please refer to [escape](/taos-sql/escape).
@@ -16,38 +16,38 @@ The legal character set is `[a-zA-Z0-9!?$%^&*()_–+={[}]:;@~#|<,>.?/]`.
 
 ## General Limits
 
-- Maximum length of database name is 32 bytes
-- Maximum length of table name is 192 bytes, excluding the database name prefix and the separator
-- Maximum length of each data row is 48K bytes from version 2.1.7.0 , before which the limit is 16K bytes. Please note that the upper limit includes the extra 2 bytes consumed by each column of BINARY/NCHAR type.
-- Maximum of column name is 64.
+- Maximum length of database name is 32 bytes.
+- Maximum length of table name is 192 bytes, excluding the database name prefix and the separator.
+- Maximum length of each data row is 48K bytes since version 2.1.7.0 , before which the limit was 16K bytes. Please note that the upper limit includes the extra 2 bytes consumed by each column of BINARY/NCHAR type.
+- Maximum length of column name is 64.
 - Maximum number of columns is 4096. There must be at least 2 columns, and the first column must be timestamp.
 - Maximum length of tag name is 64.
 - Maximum number of tags is 128. There must be at least 1 tag. The total length of tag values should not exceed 16K bytes.
-- Maximum length of singe SQL statement is 1048576, i.e. 1 MB bytes. It can be configured in the parameter `maxSQLLength` in the client side, the applicable range is [65480, 1048576].
-- At most 4096 columns (or 1024 prior to 2.1.7.0) can be returned by `SELECT`, functions in the query statement may constitute columns. Error will be returned if the limit is exceeded.
-- Maximum numbers of databases, STables, tables are only depending on the system resources.
+- Maximum length of singe SQL statement is 1048576, i.e. 1 MB. It can be configured in the parameter `maxSQLLength` in the client side, the applicable range is [65480, 1048576].
+- At most 4096 columns (or 1024 prior to 2.1.7.0) can be returned by `SELECT`. Functions in the query statement constitute columns. An error is returned if the limit is exceeded.
+- Maximum numbers of databases, STables, tables are dependent only on the system resources.
 - Maximum of database name is 32 bytes, and it can't include "." or special characters.
-- Maximum replica number of database is 3
-- Maximum length of user name is 23 bytes
-- Maximum length of password is 15 bytes
-- Maximum number of rows depends on the storage space only.
-- Maximum number of tables depends on the number of nodes only.
-- Maximum number of databases depends on the number of nodes only.
-- Maximum number of vnodes for single database is 64.
+- Maximum number of replicas for a database is 3.
+- Maximum length of user name is 23 bytes.
+- Maximum length of password is 15 bytes.
+- Maximum number of rows depends only on the storage space.
+- Maximum number of tables depends only on the number of nodes.
+- Maximum number of databases depends only on the number of nodes.
+- Maximum number of vnodes for a single database is 64.
 
 ## Restrictions of `GROUP BY`
 
-`GROUP BY` can be performed on tags and `TBNAME`. It can be performed on data columns too, with one restriction that only one column and the number of unique values on that column is lower than 100,000. Please note that `GROUP BY` can't be performed on float or double types.
+`GROUP BY` can be performed on tags and `TBNAME`. It can be performed on data columns too, with the only restriction being it can only be performed on one data column and the number of unique values in that column is lower than 100,000. Please note that `GROUP BY` cannot be performed on float or double types.
 
 ## Restrictions of `IS NOT NULL`
 
-`IS NOT NULL` can be used on any data type of columns. The non-empty string evaluation expression, i.e. `<\>""` can only be used on non-numeric data types.
+`IS NOT NULL` can be used on any data type of columns. The non-empty string evaluation expression, i.e. `< > ""` can only be used on non-numeric data types.
 
 ## Restrictions of `ORDER BY`
 
 - Only one `order by` is allowed for normal table and subtable.
 - At most two `order by` are allowed for STable, and the second one must be `ts`.
-- `order by tag` must be used with `group by tag` on same tag, this rule is also applicable to `tbname`.
+- `order by tag` must be used with `group by tag` on same tag. This rule is also applicable to `tbname`.
 - `order by column` must be used with `group by column` or `top/bottom` on same column. This rule is applicable to table and STable.
 - `order by ts` is applicable to table and STable.
 - If `order by ts` is used with `group by`, the result set is sorted using `ts` in each group.
@@ -56,7 +56,7 @@ The legal character set is `[a-zA-Z0-9!?$%^&*()_–+={[}]:;@~#|<,>.?/]`.
 
 ### Name Restrictions of Table/Column
 
-The name of a table or column can only be composed of ASCII characters, digits and underscore, while it can't start with a digit. The maximum length is 192 bytes. Names are case insensitive. The name mentioned in this rule doesn't include the database name prefix and the separator.
+The name of a table or column can only be composed of ASCII characters, digits and underscore and it cannot start with a digit. The maximum length is 192 bytes. Names are case insensitive. The name mentioned in this rule doesn't include the database name prefix and the separator.
 
 ### Name Restrictions After Escaping
 

docs-en/12-taos-sql/10-json.md

@@ -4,7 +4,7 @@ title: JSON Type
 
 ## Syntax
 
-1. Tag of JSON type
+1. Tag of type JSON
 
    ```sql
    create STable s1 (ts timestamp, v1 int) tags (info json);
@@ -12,7 +12,7 @@ title: JSON Type
    create table s1_1 using s1 tags ('{"k1": "v1"}');
    ```
 
-2. -> Operator of JSON
+2. "->" Operator of JSON
 
    ```sql
    select * from s1 where info->'k1' = 'v1';
@@ -20,7 +20,7 @@ title: JSON Type
    select info->'k1' from s1;
    ```
 
-3. contains Operator of JSON
+3. "contains" Operator of JSON
 
    ```sql
    select * from s1 where info contains 'k2';
@@ -30,7 +30,7 @@ title: JSON Type
 
 ## Applicable Operations
 
-1. When JSON data type is used in `where`, `match/nmatch/between and/like/and/or/is null/is no null` can be used but `in` can't be used.
+1. When a JSON data type is used in `where`, `match/nmatch/between and/like/and/or/is null/is no null` can be used but `in` can't be used.
 
    ```sql
    select * from s1 where info->'k1' match 'v*';
@@ -42,9 +42,9 @@ title: JSON Type
    select * from s1 where info->'k1' is not null;
    ```
 
-2. Tag of JSON type can be used in `group by`, `order by`, `join`, `union all` and sub query, for example `group by json->'key'`
+2. A tag of JSON type can be used in `group by`, `order by`, `join`, `union all` and sub query; for example `group by json->'key'`
 
-3. `Distinct` can be used with tag of JSON type
+3. `Distinct` can be used with a tag of type JSON
 
    ```sql
    select distinct info->'k1' from s1;
@@ -52,9 +52,9 @@ title: JSON Type
 
 4. Tag Operations
 
-   The value of JSON tag can be altered. Please note that the full JSON will be overriden when doing this.
+   The value of a JSON tag can be altered. Please note that the full JSON will be overriden when doing this.
 
-   The name of JSON tag can be altered. A tag of JSON type can't be added or removed. The column length of a JSON tag can't be changed.
+   The name of a JSON tag can be altered. A tag of JSON type can't be added or removed. The column length of a JSON tag can't be changed.
 
 ## Other Restrictions
 
@@ -64,17 +64,17 @@ title: JSON Type
 
 - JSON format：
 
-  - The input string for JSON can be empty, i.e. "", "\t", or NULL, but can't be non-NULL string, bool or array.
-  - object can be {}, and the whole JSON is empty if so. Key can be "", and it's ignored if so.
-  - value can be int, double, string, boll or NULL, can't be array. Nesting is not allowed, that means value can't be another JSON.
+  - The input string for JSON can be empty, i.e. "", "\t", or NULL, but it can't be non-NULL string, bool or array.
+  - object can be {}, and the entire JSON is empty if so. Key can be "", and it's ignored if so.
+  - value can be int, double, string, bool or NULL, and it can't be an array. Nesting is not allowed which means that the value of a key can't be JSON.
   - If one key occurs twice in JSON, only the first one is valid.
   - Escape characters are not allowed in JSON.
 
-- NULL is returned if querying a key that doesn't exist in JSON.
+- NULL is returned when querying a key that doesn't exist in JSON.
 
 - If a tag of JSON is the result of inner query, it can't be parsed and queried in the outer query.
 
-For example, the below SQL statements are not supported.
+For example, the SQL statements below are not supported.
 
 ```sql;
 select jtag->'key' from (select jtag from STable);

docs-en/12-taos-sql/index.md

@@ -3,11 +3,9 @@ title: TDengine SQL
 description: "The syntax supported by TDengine SQL "
 ---
 
-This section explains the syntax to operating databases, tables, STables, inserting data, selecting data, functions and some tips that can be used in TDengine SQL. It would be easier to understand with some fundamental knowledge of SQL.
+This section explains the syntax of SQL to perform operations on databases, tables and STables, insert data, select data and use functions. We also provide some tips that can be used in TDengine SQL. If you have previous experience with SQL this section will be fairly easy to understand. If you do not have previous experience with SQL, you'll come to appreciate the simplicity and power of SQL.
 
-TDengine SQL is the major interface for users to write data into or query from TDengine. For users to easily use, syntax similar to standard SQL is provided. However, please note that TDengine SQL is not standard SQL. For instance, TDengine doesn't provide the functionality of deleting time series data, thus corresponding statements are not provided in TDengine SQL.
-
-TDengine SQL doesn't support abbreviation for keywords, for example `DESCRIBE` can't be abbreviated as `DESC`.
+TDengine SQL is the major interface for users to write data into or query from TDengine. For ease of use, the syntax is similar to that of standard SQL. However, please note that TDengine SQL is not standard SQL. For instance, TDengine doesn't provide a delete function for time series data and so corresponding statements are not provided in TDengine SQL.
 
 Syntax Specifications used in this chapter:
 
@@ -16,7 +14,7 @@ Syntax Specifications used in this chapter:
 - | means one of a few options, excluding | itself.
 - … means the item prior to it can be repeated multiple times.
 
-To better demonstrate the syntax, usage and rules of TAOS SQL, hereinafter it's assumed that there is a data set of meters. Assuming each meter collects 3 data measurements: current, voltage, phase. The data model is shown below:
+To better demonstrate the syntax, usage and rules of TAOS SQL, hereinafter it's assumed that there is a data set of data from electric meters. Each meter collects 3 data measurements: current, voltage, phase. The data model is shown below:
 
 ```sql
 taos> DESCRIBE meters;
@@ -30,4 +28,4 @@ taos> DESCRIBE meters;
  groupid                        | INT                |           4 | TAG        |
 ```
 
-The data set includes the data collected by 4 meters, the corresponding table name is d1001, d1002, d1003, d1004 respectively based on the data model of TDengine.
+The data set includes the data collected by 4 meters, the corresponding table name is d1001, d1002, d1003 and d1004 based on the data model of TDengine.

docs-en/13-operation/01-pkg-install.md

@@ -6,7 +6,7 @@ description: Install, Uninstall, Start, Stop and Upgrade
 import Tabs from "@theme/Tabs";
 import TabItem from "@theme/TabItem";
 
-TDengine community version provides dev and rpm packages for users to choose based on the system environment. deb supports Debian, Ubuntu and systems derived from them. rpm supports CentOS, RHEL, SUSE and systems derived from them. Furthermore, tar.gz package is provided for enterprise customers.
+TDengine community version provides deb and rpm packages for users to choose from, based on their system environment. The deb package supports Debian, Ubuntu and derivative systems. The rpm package supports CentOS, RHEL, SUSE and derivative systems. Furthermore, a tar.gz package is provided for TDengine Enterprise customers.
 
 ## Install
 
@@ -124,7 +124,7 @@ taoskeeper is installed, enable it by `systemctl enable taoskeeper`
 ```
 
 :::info
-Some configuration will be prompted for users to provide when install.sh is executing, the interactive mode can be disabled by executing `./install.sh -e no`. `./install -h` can show all parameters and detailed explanation.
+Users will be prompted to enter some configuration information when install.sh is executing. The interactive mode can be disabled by executing `./install.sh -e no`. `./install.sh -h` can show all parameters with detailed explanation.
 
 :::
 
@@ -132,7 +132,7 @@ Some configuration will be prompted for users to provide when install.sh is exec
 </Tabs>
 
 :::note
-When installing on the first node in the cluster, when "Enter FQDN:" is prompted, nothing needs to be provided. When installing on following nodes, when "Enter FQDN:" is prompted, the end point of the first dnode in the cluster can be input if it is already up; or just ignore it and configure later after installation is done.
+When installing on the first node in the cluster, at the "Enter FQDN:" prompt, nothing needs to be provided. When installing on subsequent nodes, at the "Enter FQDN:" prompt, you must enter the end point of the first dnode in the cluster if it is already up. You can also just ignore it and configure it later after installation is finished.
 
 :::
 
@@ -181,14 +181,14 @@ taosKeeper is removed successfully!
 
 :::note
 
-- It's strongly suggested not to use multiple kinds of installation packages on a single host TDengine
-- After deb package is installed, if the installation directory is removed manually so that uninstall or reinstall can't succeed, it can be resolved by cleaning up TDengine package information as in the command below and then reinstalling.
+- We strongly recommend not to use multiple kinds of installation packages on a single host TDengine. 
+- After deb package is installed, if the installation directory is removed manually, uninstall or reinstall will not work. This issue can be resolved by using the command below which cleans up TDengine package information. You can then reinstall if needed.
 
 ```bash
    $ sudo rm -f /var/lib/dpkg/info/tdengine*
 ```
 
-- After rpm package is installed, if the installation directory is removed manually so that uninstall or reinstall can't succeed, it can be resolved by cleaning up TDengine package information as in the command below and then reinstalling.
+- After rpm package is installed, if the installation directory is removed manually, uninstall or reinstall will not work. This issue can be resolved by using the command below which cleans up TDengine package information. You can then reinstall if needed.
 
 ```bash
    $ sudo rpm -e --noscripts tdengine
@@ -219,7 +219,7 @@ lrwxrwxrwx  1 root root   13 Feb 22 09:34 log -> /var/log/taos/
 During the installation process:
 
 - Configuration directory, data directory, and log directory are created automatically if they don't exist
-- The default configuration file is located at /etc/taos/taos.cfg, which is a copy of /usr/local/taos/cfg/taos.cfg if not existing
+- The default configuration file is located at /etc/taos/taos.cfg, which is a copy of /usr/local/taos/cfg/taos.cfg
 - The default data directory is /var/lib/taos, which is a soft link to /usr/local/taos/data
 - The default log directory is /var/log/taos, which is a soft link to /usr/local/taos/log
 - The executables at /usr/local/taos/bin are linked to /usr/bin
@@ -228,7 +228,7 @@ During the installation process:
 
 :::note
 
-- When TDengine is uninstalled, the configuration /etc/taos/taos.cfg, data directory /var/lib/taos, log directory /var/log/taos are kept. They can be deleted manually with caution because data can't be recovered
+- When TDengine is uninstalled, the configuration /etc/taos/taos.cfg, data directory /var/lib/taos, log directory /var/log/taos are kept. They can be deleted manually with caution, because data can't be recovered. Please follow data integrity, security, backup or relevant SOPs before deleting any data.
 - When reinstalling TDengine, if the default configuration file /etc/taos/taos.cfg exists, it will be kept and the configuration file in the installation package will be renamed to taos.cfg.orig and stored at /usr/local/taos/cfg to be used as configuration sample. Otherwise the configuration file in the installation package will be installed to /etc/taos/taos.cfg and used.
 
 ## Start and Stop
@@ -263,18 +263,19 @@ Active: inactive (dead)
 
 There are two aspects in upgrade operation: upgrade installation package and upgrade a running server.
 
-Upgrading package should follow the steps mentioned previously to first uninstall the old version then install the new version.
+To upgrade a package, follow the steps mentioned previously to first uninstall the old version then install the new version.
 
-Upgrading a running server is much more complex. First please check the version number of the old version and the new version. The version number of TDengine consists of 4 sections, only if the first 3 section match can the old version be upgraded to the new version. The steps of upgrading a running server are as below:
+Upgrading a running server is much more complex. First please check the version number of the old version and the new version. The version number of TDengine consists of 4 sections, only if the first 3 sections match can the old version be upgraded to the new version. The steps of upgrading a running server are as below:
 
 - Stop inserting data
-- Make sure all data are persisted into disk
+- Make sure all data is persisted to disk
+- Make some simple queries (Such as total rows in stables, tables and so on. Note down the values. Follow best practices and relevant SOPs.)
 - Stop the cluster of TDengine
 - Uninstall old version and install new version
 - Start the cluster of TDengine
-- Make some simple queries to make sure no data loss
-- Make some simple data insertion to make sure the cluster works well
-- Restore business data
+- Execute simple queries, such as the ones executed prior to installing the new package, to make sure there is no data loss
+- Run some simple data insertion statements to make sure the cluster works well
+- Restore business services
 
 :::warning
 

docs-en/13-operation/02-planning.mdx

@@ -2,17 +2,17 @@
 title: Resource Planning
 ---
 
-The computing and storage resources need to be planned if using TDengine to build an IoT platform. How to plan the CPU, memory and disk required will be described in this chapter.
+It is important to plan computing and storage resources if using TDengine to build an IoT, time-series or Big Data platform. How to plan the CPU, memory and disk resources required, will be described in this chapter.
 
 ## Memory Requirement of Server Side
 
-The number of vgroups created for each database is the same as the number of CPU cores by default and can be configured by parameter `maxVgroupsPerDb`, each vnode in a vgroup stores one replica. Each vnode consumes a fixed size of memory, i.e. `blocks` \* `cache`. Besides, some memory is required for tag values associated with each table. A fixed amount of memory is required for each cluster. So, the memory required for each DB can be calculated using the formula below:
+By default, the number of vgroups created for each database is the same as the number of CPU cores. This can be configured by the parameter `maxVgroupsPerDb`. Each vnode in a vgroup stores one replica. Each vnode consumes a fixed amount of memory, i.e. `blocks` \* `cache`. In addition, some memory is required for tag values associated with each table. A fixed amount of memory is required for each cluster. So, the memory required for each DB can be calculated using the formula below:
 
 ```
 Database Memory Size = maxVgroupsPerDb * replica * (blocks * cache + 10MB) + numOfTables * (tagSizePerTable + 0.5KB)
 ```
 
-For example, assuming the default value of `maxVgroupPerDB` is 64, the default value of `cache` 16M, the default value of `blocks` is 6, there are 100,000 tables in a DB, the replica number is 1, total length of tag values is 256 bytes, the total memory required for this DB is: 64 \* 1 \* (16 \* 6 + 10) + 100000 \* (0.25 + 0.5) / 1000 = 6792M.
+For example, assuming the default value of `maxVgroupPerDB` is 64, the default value of `cache` is 16M, the default value of `blocks` is 6, there are 100,000 tables in a DB, the replica number is 1, total length of tag values is 256 bytes, the total memory required for this DB is: 64 \* 1 \* (16 \* 6 + 10) + 100000 \* (0.25 + 0.5) / 1000 = 6792M.
 
 In the real operation of TDengine, we are more concerned about the memory used by each TDengine server process `taosd`.
 
@@ -22,10 +22,10 @@ In the real operation of TDengine, we are more concerned about the memory used b
 
 In the above formula:
 
-1. "vnode_memory" of a `taosd` process is the memory used by all vnodes hosted by this `taosd` process. It can be roughly calculated by firstly adding up the total memory of all DBs whose memory usage can be derived according to the formula mentioned previously then dividing by number of dnodes and multiplying the number of replicas.
+1. "vnode_memory" of a `taosd` process is the memory used by all vnodes hosted by this `taosd` process. It can be roughly calculated by firstly adding up the total memory of all DBs whose memory usage can be derived according to the formula for Database Memory Size, mentioned above, then dividing by number of dnodes and multiplying the number of replicas.
 
 ```
-    vnode_memory = sum(Database memory) / number_of_dnodes * replica
+    vnode_memory = (sum(Database Memory Size) / number_of_dnodes) * replica
 ```
 
 2. "mnode_memory" of a `taosd` process is the memory consumed by a mnode. If there is one (and only one) mnode hosted in a `taosd` process, the memory consumed by "mnode" is "0.2KB \* the total number of tables in the cluster".
@@ -56,8 +56,8 @@ So, at least 3GB needs to be reserved for such a client.
 
 The CPU resources required depend on two aspects:
 
-- **Data Insertion** Each dnode of TDengine can process at least 10,000 insertion requests in one second, while each insertion request can have multiple rows. The computing resource consumed between inserting 1 row one time and inserting 10 rows one time is very small. So, the more the rows to insert one time, the higher the efficiency. Inserting in bach also exposes requirements for the client side which needs to cache rows and insert in batch once the cached rows reaches a threshold.
-- **Data Query** High efficiency query is provided in TDengine, but it's hard to estimate the CPU resource required because the queries used in different use cases and the frequency of queries vary significantly. It can only be verified with the query statements, query frequency, data size to be queried, etc provided by user.
+- **Data Insertion** Each dnode of TDengine can process at least 10,000 insertion requests in one second, while each insertion request can have multiple rows. The difference in computing resource consumed, between inserting 1 row at a time, and inserting 10 rows at a time is very small. So, the more the number of rows that can be inserted one time, the higher the efficiency. Inserting in batch also imposes requirements on the client side which needs to cache rows to insert in batch once the number of cached rows reaches a threshold.
+- **Data Query** High efficiency query is provided in TDengine, but it's hard to estimate the CPU resource required because the queries used in different use cases and the frequency of queries vary significantly. It can only be verified with the query statements, query frequency, data size to be queried, and other requirements provided by users.
 
 In short, the CPU resource required for data insertion can be estimated but it's hard to do so for query use cases. In real operation, it's suggested to control CPU usage below 50%. If this threshold is exceeded, it's a reminder for system operator to add more nodes in the cluster to expand resources.
 
@@ -71,12 +71,12 @@ Raw DataSize = numOfTables * rowSizePerTable * rowsPerTable
 
 For example, there are 10,000,000 meters, while each meter collects data every 15 minutes and the data size of each collection is 128 bytes, so the raw data size of one year is: 10000000 \* 128 \* 24 \* 60 / 15 \* 365 = 44.8512(TB). Assuming compression ratio is 5, the actual disk size is: 44.851 / 5 = 8.97024(TB).
 
-Parameter `keep` can be used to set how long the data will be kept on disk. To further reduce storage cost, multiple storage levels can be enabled in TDengine, with the coldest data stored on the cheapest storage device, and this is transparent to application programs.
+Parameter `keep` can be used to set how long the data will be kept on disk. To further reduce storage cost, multiple storage levels can be enabled in TDengine, with the coldest data stored on the cheapest storage device. This is completely transparent to application programs.
 
-To increase the performance, multiple disks can be setup for parallel data reading or data inserting. Please note that an expensive disk array is not necessary because replications are used in TDengine to provide high availability.
+To increase performance, multiple disks can be setup for parallel data reading or data inserting. Please note that an expensive disk array is not necessary because replications are used in TDengine to provide high availability.
 
 ## Number of Hosts
 
-A host can be either physical or virtual. The total memory, total CPU, total disk required can be estimated according to the formulas mentioned previously. Then, according to the system resources that a single host can provide, assuming all hosts have the same resources, the number of hosts can be derived easily.
+A host can be either physical or virtual. The total memory, total CPU, total disk required can be estimated according to the formulae mentioned previously. Then, according to the system resources that a single host can provide, assuming all hosts have the same resources, the number of hosts can be derived easily.
 
 **Quick Estimation for CPU, Memory and Disk** Please refer to [Resource Estimate](https://www.taosdata.com/config/config.html).

docs-en/13-operation/03-tolerance.md

@@ -7,23 +7,26 @@ title: Fault Tolerance & Disaster Recovery
 
 TDengine uses **WAL**, i.e. Write Ahead Log, to achieve fault tolerance and high reliability.
 
-When a data block is received by TDengine, the original data block is firstly written into WAL. The log in WAL will be deleted only after the data has been written into data files in the database. Data can be recovered from WAL in case the server is stopped abnormally due to any reason and then restarted.
+When a data block is received by TDengine, the original data block is first written into WAL. The log in WAL will be deleted only after the data has been written into data files in the database. Data can be recovered from WAL in case the server is stopped abnormally for any reason and then restarted.
 
 There are 2 configuration parameters related to WAL:
 
-- walLevel：0：wal is disabled; 1：wal is enabled without fsync; 2：wal is enabled with fsync.
-- fsync：only valid when walLevel is set to 2, it specified the interval of invoking fsync. If set to 0, it means fsync is invoked immediately once WAL is written.
+- walLevel：
+  - 0：wal is disabled 
+  - 1：wal is enabled without fsync 
+  - 2：wal is enabled with fsync
+- fsync：This parameter is only valid when walLevel is set to 2. It specifies the interval, in milliseconds, of invoking fsync. If set to 0, it means fsync is invoked immediately once WAL is written.
 
-To achieve absolutely no data loss, walLevel needs to be set to 2 and fsync needs to be set to 1. The penalty is the performance of data ingestion downgrades. However, if the concurrent threads of data insertion on the client side can reach a big enough number, for example 50, the data ingestion performance would be still good enough, our verification shows that the drop is only 30% compared to fsync is set to 3,000 milliseconds.
+To achieve absolutely no data loss, walLevel should be set to 2 and fsync should be set to 1. There is a performance penalty to the data ingestion rate. However, if the concurrent data insertion threads on the client side can reach a big enough number, for example 50, the data ingestion performance will be still good enough. Our verification shows that the drop is only 30% when fsync is set to 3,000 milliseconds.
 
 ## Disaster Recovery
 
-TDengine uses replications to provide high availability and disaster recovery capability.
+TDengine uses replication to provide high availability and disaster recovery capability.
 
-TDengine cluster is managed by mnode. To make sure the high availability of mnode, multiple replicas can be configured by system parameter `numOfMnodes`. The data replication between mnode replicas is in synchronous way to guarantee the metadata consistency.
+A TDengine cluster is managed by mnode. To ensure the high availability of mnode, multiple replicas can be configured by the system parameter `numOfMnodes`. The data replication between mnode replicas is performed in a synchronous way to guarantee metadata consistency.
 
-The number of replicas for time series data in TDengine is associated with each database, there can be a lot of databases in a cluster while each database can be configured with a different number of replicas. When creating a database, parameter `replica` is used to configure the number of replications. To achieve high availability, `replica` needs to be higher than 1.
+The number of replicas for time series data in TDengine is associated with each database. There can be many databases in a cluster and each database can be configured with a different number of replicas. When creating a database, parameter `replica` is used to configure the number of replications. To achieve high availability, `replica` needs to be higher than 1.
 
-The number of dnodes in a TDengine cluster must NOT be lower than the number of replicas for any database, otherwise it would fail when trying to create table.
+The number of dnodes in a TDengine cluster must NOT be lower than the number of replicas for any database, otherwise it would fail when trying to create a table.
 
-As long as the dnodes of a TDengine cluster are deployed on different physical machines and replica number is set to bigger than 1, high availability can be achieved without any other assistance. If dnodes of TDengine cluster are deployed in geographically different data centers, disaster recovery can be achieved too.
+As long as the dnodes of a TDengine cluster are deployed on different physical machines and the replica number is higher than 1, high availability can be achieved without any other assistance. For disaster recovery, dnodes of a TDengine cluster should be deployed in geographically different data centers.

docs-en/13-operation/06-admin.md

@@ -2,7 +2,7 @@
 title: User Management
 ---
 
-System operator can use TDengine CLI `taos` to create or remove user or change password. The SQL command is as low:
+A system operator can use TDengine CLI `taos` to create or remove users or change passwords. The SQL commands are documented below:
 
 ## Create User
 
@@ -10,7 +10,7 @@ System operator can use TDengine CLI `taos` to create or remove user or change p
 CREATE USER <user_name> PASS <'password'>;
 ```
 
-When creating a user and specifying the user name and password, password needs to be quoted using single quotes.
+When creating a user and specifying the user name and password, the password needs to be quoted using single quotes.
 
 ## Drop User
 
@@ -18,7 +18,7 @@ When creating a user and specifying the user name and password, password needs t
 DROP USER <user_name>;
 ```
 
-Drop a user can only be performed by root.
+Dropping a user can only be performed by root.
 
 ## Change Password
 
@@ -26,7 +26,7 @@ Drop a user can only be performed by root.
 ALTER USER <user_name> PASS <'password'>;
 ```
 
-To keep the case of the password when changing password, password needs to be quoted using single quotes.
+To keep the case of the password when changing password, the password needs to be quoted using single quotes.
 
 ## Change Privilege
 
@@ -36,7 +36,7 @@ ALTER USER <user_name> PRIVILEGE <write|read>;
 
 The privileges that can be changed to are `read` or `write` without single quotes.
 
-Note：there is another privilege `super`, which not allowed to be authorized to any user.
+Note：there is another privilege `super`, which is not allowed to be authorized to any user.
 
 ## Show Users
 
@@ -45,6 +45,6 @@ SHOW USERS;
 ```
 
 :::note
-In SQL syntax, `< >` means the part that needs to be input by user, excluding the `< >` itself.
+In SQL syntax, `< >` means the part that needs to be input by the user, excluding the `< >` itself.
 
 :::

docs-en/13-operation/07-import.md

@@ -2,26 +2,26 @@
 title: Data Import
 ---
 
-There are multiple ways of importing data provided byTDengine: import with script, import from data file, import using `taosdump`.
+There are multiple ways of importing data provided by TDengine: import with script, import from data file, import using `taosdump`.
 
 ## Import Using Script
 
-TDengine CLI `taos` supports `source <filename>` command for executing the SQL statements in the file in batch. The SQL statements for creating databases, creating tables, and inserting rows can be written in single file with one statement on each line, then the file can be executed using `source` command in TDengine CLI `taos` to execute the SQL statements in order and in batch. In the script file, any line beginning with "#" is treated as comments and ignored silently.
+TDengine CLI `taos` supports `source <filename>` command for executing the SQL statements in the file in batch. The SQL statements for creating databases, creating tables, and inserting rows can be written in a single file with one statement on each line, then the file can be executed using the `source` command in TDengine CLI `taos` to execute the SQL statements in order and in batch. In the script file, any line beginning with "#" is treated as comments and ignored silently.
 
 ## Import from Data File
 
-In TDengine CLI, data can be imported from a CSV file into an existing table. The data in single CSV must belong to same table and must be consistent with the schema of that table. The SQL statement is as below:
+In TDengine CLI, data can be imported from a CSV file into an existing table. The data in a single CSV must belong to the same table and must be consistent with the schema of that table. The SQL statement is as below:
 
 ```sql
 insert into tb1 file 'path/data.csv';
 ```
 
 :::note
-If there is description in the first line of a CSV file, please remove it before importing. If there is no value for a column, please use `NULL` without quotes.
+If there is a description in the first line of the CSV file, please remove it before importing. If there is no value for a column, please use `NULL` without quotes.
 
 :::
 
-For example, there is a sub table d1001 whose schema is as below:
+For example, there is a subtable d1001 whose schema is as below:
 
 ```sql
 taos> DESCRIBE d1001
@@ -49,7 +49,7 @@ The format of the CSV file to be imported, data.csv, is as below:
 '2018-10-12 06:38:05.000',18.30000,219,0.31000
 ```
 
-Then, below SQL statement can be used to import data from file "data.csv", assuming the file is located under the home directory of current Linux user.
+Then, the below SQL statement can be used to import data from file "data.csv", assuming the file is located under the home directory of the current Linux user.
 
 ```sql
 taos> insert into d1001 file '~/data.csv';
@@ -58,4 +58,4 @@ Query OK, 9 row(s) affected (0.004763s)
 
 ## Import using taosdump
 
-A convenient tool for importing and exporting data is provided by TDengine, `taosdump`, which can used to export data from one TDengine cluster and import into another one. For the details of using `taosdump` please refer to [Tool for exporting and importing data: taosdump](/reference/taosdump).
+A convenient tool for importing and exporting data is provided by TDengine, `taosdump`, which can be used to export data from one TDengine cluster and import into another one. For the details of using `taosdump` please refer to [Tool for exporting and importing data: taosdump](/reference/taosdump).

docs-en/13-operation/08-export.md

@@ -2,11 +2,13 @@
 title: Data Export
 ---
 
-There are two ways of exporting data from a TDengine cluster, one is SQL statement in TDengine CLI, the other one is `taosdump`.
+There are two ways of exporting data from a TDengine cluster:
+- Using a SQL statement in TDengine CLI
+- Using the `taosdump` tool
 
 ## Export Using SQL
 
-If you want to export the data of a table or a STable, please execute below SQL statement in TDengine CLI.
+If you want to export the data of a table or a STable, please execute the SQL statement below, in the TDengine CLI.
 
 ```sql
 select * from <tb_name> >> data.csv;
@@ -16,4 +18,4 @@ The data of table or STable specified by `tb_name` will be exported into a file
 
 ## Export Using taosdump
 
-With `taosdump`, you can choose to export the data of all databases, a database, a table or a STable, you can also choose export the data within a time range, or even only export the schema definition of a table. For the details of using `taosdump` please refer to [Tool for exporting and importing data: taosdump](/reference/taosdump).
+With `taosdump`, you can choose to export the data of all databases, a database, a table or a STable, you can also choose to export the data within a time range, or even only export the schema definition of a table. For the details of using `taosdump` please refer to [Tool for exporting and importing data: taosdump](/reference/taosdump).

docs-en/13-operation/09-status.md

@@ -3,7 +3,7 @@ sidebar_label: Connections & Tasks
 title: Manage Connections and Query Tasks
 ---
 
-System operator can use TDengine CLI to show the connections, ongoing queries, stream computing, and can close connection or stop ongoing query task or stream computing.
+A system operator can use the TDengine CLI to show connections, ongoing queries, stream computing, and can close connections or stop ongoing query tasks or stream computing.
 
 ## Show Connections
 
@@ -13,7 +13,7 @@ SHOW CONNECTIONS;
 
 One column of the output of the above SQL command is "ip:port", which is the end point of the client.
 
-## Close Connections Forcedly
+## Force Close Connections
 
 ```sql
 KILL CONNECTION <connection-id>;
@@ -27,9 +27,9 @@ In the above SQL command, `connection-id` is from the first column of the output
 SHOW QUERIES;
 ```
 
-The first column of the output is query ID, which is composed of the corresponding connection ID and the sequence number of the current query task started on this connection, in format of "connection-id:query-no".
+The first column of the output is query ID, which is composed of the corresponding connection ID and the sequence number of the current query task started on this connection. The format is "connection-id:query-no".
 
-## Close Queries Forcedly
+## Force Close Queries
 
 ```sql
 KILL QUERY <query-id>;
@@ -43,12 +43,12 @@ In the above SQL command, `query-id` is from the first column of the output of `
 SHOW STREAMS;
 ```
 
-The first column of the output is stream ID, which is composed of the connection ID and the sequence number of the current stream started on this connection, in the format of "connection-id:stream-no".
+The first column of the output is stream ID, which is composed of the connection ID and the sequence number of the current stream started on this connection. The format is "connection-id:stream-no".
 
-## Close Continuous Query Forcedly
+## Force Close Continuous Query
 
 ```sql
 KILL STREAM <stream-id>;
 ```
 
-The the above SQL command, `stream-id` is from the first column of the output of `SHOW STREAMS`.
+The above SQL command, `stream-id` is from the first column of the output of `SHOW STREAMS`.

docs-en/13-operation/10-monitor.md

@@ -2,19 +2,19 @@
 title: TDengine Monitoring
 ---
 
-After TDengine is started, a database named `log` for monitoring is created automatically. The information about CPU, memory, disk, bandwidth, number of requests, disk I/O speed, slow query is written into `log` database on the basis of a predefined interval. Besides, some important system operations, like logon, create user, drop database, and alerts and warnings generated in TDengine are written into `log` database too. System operator can view the data in `log` database from TDengine CLI or from a web console.
+After TDengine is started, a database named `log` is created automatically to help with monitoring. Information that includes CPU, memory and disk usage, bandwidth, number of requests, disk I/O speed, slow queries, is written into the `log` database at a predefined interval. Additionally, some important system operations, like logon, create user, drop database, and alerts and warnings generated in TDengine are written into the `log` database too. A system operator can view the data in `log` database from TDengine CLI or from a web console.
 
-Collection of the monitoring information is enabled by default, but can be disabled by parameter `monitor` in configuration file. 
+The collection of the monitoring information is enabled by default, but can be disabled by parameter `monitor` in the configuration file. 
 
 ## TDinsight 
 
-TDinsight is a total solution which uses the monitor database `log` mentioned previously and Grafana to monitor a TDengine cluster.
+TDinsight is a complete solution which uses the monitoring database `log` mentioned previously, and Grafana, to monitor a TDengine cluster.
 
 From version 2.3.3.0, more monitoring data has been added in the `log` database. Please refer to [TDinsight Grafana Dashboard](https://grafana.com/grafana/dashboards/15167) to learn more details about using TDinsight to monitor TDengine.
 
-A script `TDinsight.sh` is provided to deploy TDinsight in automatic way.
+A script `TDinsight.sh` is provided to deploy TDinsight automatically.
 
-Download `TDinsight.sh` with below command:
+Download `TDinsight.sh` with the below command:
 
 ```bash
 wget https://github.com/taosdata/grafanaplugin/raw/master/dashboards/TDinsight.sh
@@ -38,7 +38,7 @@ There are two ways to setup Grafana alert notification.
      sudo ./TDinsight.sh -a http://localhost:6041 -u root -p taosdata -E <notifier uid>
      ```
 
-- The AliCloud SMS alert built in TDengine data source plugin can be enabled with parameter `-s`, the parameters of this way are as follows:
+- The AliCloud SMS alert built in TDengine data source plugin can be enabled with parameter `-s`, the parameters of enabling this plugin are listed below:
 
   - `-I`: AliCloud SMS Key ID
   - `-K`: AliCloud SMS Key Secret
@@ -47,7 +47,7 @@ There are two ways to setup Grafana alert notification.
   - `-T`: Input parameters in JSON format for the SMS notification template, for example`{"alarm_level":"%s","time":"%s","name":"%s","content":"%s"}`
   - `-B`: List of mobile numbers to be notified
 
-  Below is an example of the full command using this way.
+  Below is an example of the full command using the AliCloud SMS alert.
 
   ```bash
      sudo ./TDinsight.sh -a http://localhost:6041 -u root -p taosdata -s \
@@ -55,6 +55,6 @@ There are two ways to setup Grafana alert notification.
        -T '{"alarm_level":"%s","time":"%s","name":"%s","content":"%s"}'
   ```
 
-Launch `TDinsight.sh` as above command and restart Grafana, then open Dashboard `http://localhost:3000/d/tdinsight`.
+Launch `TDinsight.sh` with the command above and restart Grafana, then open Dashboard `http://localhost:3000/d/tdinsight`.
 
 For more use cases and restrictions please refer to [TDinsight](/reference/tdinsight/).

docs-en/13-operation/17-diagnose.md

@@ -4,19 +4,19 @@ title: Problem Diagnostics
 
 ## Network Connection Diagnostics
 
-When the client is unable to access the server, the network connection between the client side and the server side needs to be checked to find out the root cause and resolve problems.
+When a TDengine client is unable to access a TDengine server, the network connection between the client side and the server side must be checked to find the root cause and resolve problems.
 
-The diagnostic for network connection can be executed between Linux and Linux or between Linux and Windows.
+Diagnostics for network connections can be executed between Linux and Linux or between Linux and Windows.
 
 Diagnostic steps：
 
-1. If the port range to be diagnosed are being occupied by a `taosd` server process, please firstly stop `taosd.
-2. On the server side, execute command `taos -n server -P <port> -l <pktlen>` to monitor the port range starting from the port specified by `-P` parameter with the role of "server.
-3. On the client side, execute command `taos -n client -h <fqdn of server> -P <port> -l <pktlen>` to send testing package to the specified server and port.
+1. If the port range to be diagnosed is being occupied by a `taosd` server process, please first stop `taosd.
+2. On the server side, execute command `taos -n server -P <port> -l <pktlen>` to monitor the port range starting from the port specified by `-P` parameter with the role of "server".
+3. On the client side, execute command `taos -n client -h <fqdn of server> -P <port> -l <pktlen>` to send a testing package to the specified server and port.
  
--l <pktlen\>： The size of the testing package, in bytes. The value range is [11, 64,000] and default value is 1,000. Please be noted that the package length must be same in the above 2 commands executed on server side and client side respectively.
+-l <pktlen\>： The size of the testing package, in bytes. The value range is [11, 64,000] and default value is 1,000. Please note that the package length must be same in the above 2 commands executed on server side and client side respectively.
 
-Output of the server side is as below for example:
+Output of the server side for the example is below:
 
 ```bash
 # taos -n server -P 6000
@@ -47,7 +47,7 @@ Output of the server side is as below for example:
 12/21 14:50:22.721261 0x7f53427ec700 UTL UDP: send:1000 bytes to 172.27.0.8 at 6011
 ```
 
-Output of the client side is as below for example:
+Output of the client side for the example is below:
 
 ```bash
 # taos -n client -h 172.27.0.7 -P 6000
@@ -65,13 +65,13 @@ Output of the client side is as below for example:
 12/21 14:50:22.721274 0x7fc95d859200 UTL successed to test UDP port:6011
 ```
 
-The output needs to be checked carefully for the system operator to find out root cause and solve the problem.
+The output needs to be checked carefully for the system operator to find the root cause and resolve the problem.
 
 ## Startup Status and RPC Diagnostic
 
-`taos -n startup -h <fqdn of server>` can be used to check the startup status of a `taosd` process. This is a comman task for a system operator to do to determine whether `taosd` has been started successfully, especially in case of cluster.
+`taos -n startup -h <fqdn of server>` can be used to check the startup status of a `taosd` process. This is a common task which should be performed by a system operator, especially in the case of a cluster, to determine whether `taosd` has been started successfully.
 
-`taos -n rpc -h <fqdn of server>` can be used to check whether the port of a started `taosd` can be accessed or not. If `taosd` process doesn't respond or work abnormally, this command can be used to initiate a rpc communication with the specified fqdn to determine whether it's network problem or `taosd` is abnormal.
+`taos -n rpc -h <fqdn of server>` can be used to check whether the port of a started `taosd` can be accessed or not. If `taosd` process doesn't respond or is working abnormally, this command can be used to initiate a rpc communication with the specified fqdn to determine whether it's a network problem or whether `taosd` is abnormal.
 
 ## Sync and Arbitrator Diagnostic
 
@@ -80,43 +80,43 @@ taos -n sync -P 6040 -h <fqdn of server>
 taos -n sync -P 6042 -h <fqdn of server>
 ```
 
-The above commands can be executed on Linux Shell to check whether the port for sync works well and whether the sync module of the server side works well. Besides, `-P 6042` is used to check whether the arbitrator is configured properly and works well.
+The above commands can be executed in a Linux shell to check whether the port for sync is working well and whether the sync module on the server side is working well. Additionally, `-P 6042` is used to check whether the arbitrator is configured properly and is working well.
 
 ## Network Speed Diagnostic
 
 `taos -n speed -h <fqdn of server> -P 6030 -N 10 -l 10000000 -S TCP`
 
-From version 2.2.0.0, the above command can be executed on Linux Shell to test the network speed, it sends uncompressed package to a running `taosd` server process or a simulated server process started by `taos -n server` to test the network speed. Parameters can be used when testing network speed are as below:
+From version 2.2.0.0 onwards, the above command can be executed in a Linux shell to test network speed. The command sends uncompressed packages to a running `taosd` server process or a simulated server process started by `taos -n server` to test the network speed. Parameters can be used when testing network speed are as below:
 
--n：When set to "speed", it means testing network speed
--h：The FQDN or IP of the server process to be connected to; if not set, the FQDN configured in `taos.cfg` is used
--P：The port of the server process to connect to, the default value is 6030
--N：The number of packages that will be sent in the test, range is [1,10000], default value is 100
--l：The size of each package in bytes, range is [1024, 1024 \* 1024 \* 1024], default value is 1024
--S：The type of network packages to send, can be either TCP or UDP, default value is 
+-n：When set to "speed", it means testing network speed. 
+-h：The FQDN or IP of the server process to be connected to; if not set, the FQDN configured in `taos.cfg` is used. 
+-P：The port of the server process to connect to, the default value is 6030. 
+-N：The number of packages that will be sent in the test, range is [1,10000], default value is 100. 
+-l：The size of each package in bytes, range is [1024, 1024 \* 1024 \* 1024], default value is 1024. 
+-S：The type of network packages to send, can be either TCP or UDP, default value is TCP.  
 
 ## FQDN Resolution Diagnostic
 
 `taos -n fqdn -h <fqdn of server>`
 
-From version 2.2.0.0, the above command can be executed on Linux Shell to test the resolution speed of FQDN. It can be used to try to resolve a FQDN to an IP address and record the time spent in this process. The parameters that can be used for this purpose are as below:
+From version 2.2.0.0 onward, the above command can be executed in a Linux shell to test the resolution speed of FQDN. It can be used to try to resolve a FQDN to an IP address and record the time spent in this process. The parameters that can be used for this purpose are as below:
 
--n：When set to "fqdn", it means testing the speed of resolving FQDN
--h：The FQDN to be resolved. If not set, the `FQDN` parameter in `taos.cfg` is used by default.
+-n：When set to "fqdn", it means testing the speed of resolving FQDN. 
+-h：The FQDN to be resolved. If not set, the `FQDN` parameter in `taos.cfg` is used by default.  
 
 ## Server Log
 
-The parameter `debugFlag` is used to control the log level of `taosd` server process. The default value is 131, for debug purpose it needs to be escalated to 135 or 143. 
+The parameter `debugFlag` is used to control the log level of the `taosd` server process. The default value is 131. For debugging and tracing, it needs to be set to either 135 or 143 respectively. 
 
-Once this parameter is set to 135 or 143, the log file grows very quickly especially when there is huge volume of data insertion and data query requests. If all the logs are stored together, some important information may be missed very easily, so on server side important information is stored at different place from other logs.
+Once this parameter is set to 135 or 143, the log file grows very quickly especially when there is a huge volume of data insertion and data query requests. If all the logs are stored together, some important information may be missed very easily and so on the server side, important information is stored in a different place from other logs.
 
 - The log at level of INFO, WARNING and ERROR is stored in `taosinfo` so that it is easy to find important information 
 - The log at level of DEBUG (135) and TRACE (143) and other information not handled by `taosinfo` are stored in `taosdlog`
 
 ## Client Log
 
-An independent log file, named as "taoslog+<seq num\>" is generated for each client program, i.e. a client process. The default value of `debugFlag` is also 131 and only log at level of INFO/ERROR/WARNING is recorded, it and needs to be changed to 135 or 143 so that log at DEBUG or TRACE level can be recorded for debugging purpose.
+An independent log file, named as "taoslog+<seq num\>" is generated for each client program, i.e. a client process. The default value of `debugFlag` is also 131 and only logs at level of INFO/ERROR/WARNING are recorded. As stated above, for debugging and tracing, it needs to be changed to 135 or 143 respectively, so that logs at DEBUG or TRACE level can be recorded.
 
 The maximum length of a single log file is controlled by parameter `numOfLogLines` and only 2 log files are kept for each `taosd` server process.
 
-log file is written in async way to minimize the workload on disk, bu the penalty is that a few log lines may be lost in some extreme conditions. 
+Log files are written in an async way to minimize the workload on disk, but the trade off for performance is that a few log lines may be lost in some extreme conditions. 

docs-en/13-operation/index.md

@@ -2,7 +2,7 @@
 title: Administration
 ---
 
-This chapter is mainly written for system administrators, covering download, install/uninstall, data import/export, system monitoring, user management, connection management, etc. Capacity planning and system optimization are also covered.
+This chapter is mainly written for system administrators. It covers download, install/uninstall, data import/export, system monitoring, user management, connection management, capacity planning and system optimization.
 
 ```mdx-code-block
 import DocCardList from '@theme/DocCardList';

docs-en/14-reference/02-rest-api/02-rest-api.mdx

@@ -2,23 +2,23 @@
 title: REST API
 ---
 
-To support the development of various types of platforms, TDengine provides an API that conforms to the REST principle, namely REST API. To minimize the learning cost, different from the other database REST APIs, TDengine directly requests the SQL command contained in the request BODY through HTTP POST to operate the database and only requires a URL.
+To support the development of various types of applications and platforms, TDengine provides an API that conforms to REST principles; namely REST API. To minimize the learning cost, unlike REST APIs for other database engines, TDengine allows insertion of SQL commands in the BODY of an HTTP POST request, to operate the database.
 
 :::note 
-One difference from the native connector is that the REST interface is stateless, so the `USE db_name` command has no effect. All references to table names and super table names need to specify the database name prefix. (Since version 2.2.0.0, it is supported to specify db_name in RESTful URL. If the database name prefix is not specified in the SQL command, the `db_name` specified in the URL will be used. Since version 2.4.0.0, REST service is provided by taosAdapter by default. And it requires that the `db_name` must be specified in the URL.)
+One difference from the native connector is that the REST interface is stateless and so the `USE db_name` command has no effect. All references to table names and super table names need to specify the database name in the prefix. (Since version 2.2.0.0, TDengine supports specification of the db_name in RESTful URL. If the database name prefix is not specified in the SQL command, the `db_name` specified in the URL will be used. Since version 2.4.0.0, REST service is provided by taosAdapter by default and it requires that the `db_name` must be specified in the URL.)
 :::
 
 ## Installation
 
-The REST interface does not rely on any TDengine native library, so the client application does not need to install any TDengine libraries. The client application's development language supports the HTTP protocol is enough.
+The REST interface does not rely on any TDengine native library, so the client application does not need to install any TDengine libraries. The client application's development language only needs to support the HTTP protocol.
 
 ## Verification
 
 If the TDengine server is already installed, it can be verified as follows:
 
-The following is an Ubuntu environment using the `curl` tool (to confirm that it is installed) to verify that the REST interface is working.
+The following example is in an Ubuntu environment and uses the `curl` tool to verify that the REST interface is working. Note that the `curl` tool may need to be installed in your environment.
 
-The following example lists all databases, replacing `h1.taosdata.com` and `6041` (the default port) with the actual running TDengine service FQDN and port number.
+The following example lists all databases on the host h1.taosdata.com. To use it in your environment, replace `h1.taosdata.com` and `6041` (the default port) with the actual running TDengine service FQDN and port number.
 
 ```html
 curl -H 'Authorization: Basic cm9vdDp0YW9zZGF0YQ==' -d 'show databases;' h1.taosdata.com:6041/rest/sql
@@ -89,7 +89,7 @@ For example, `http://h1.taos.com:6041/rest/sql/test` is a URL to `h1.taos.com:60
 
 TDengine supports both Basic authentication and custom authentication mechanisms, and subsequent versions will provide a standard secure digital signature mechanism for authentication.
 
-- The custom authentication information is as follows (Let's introduce token later)
+- The custom authentication information is as follows. More details about "token" later.
 
   ```
   Authorization: Taosd <TOKEN>
@@ -136,7 +136,7 @@ The return result is in JSON format, as follows:
 
 Description:
 
-- status: tell if the operation result is success or failure.
+- status: tells you whethre the operation result is success or failure.
 - head: the definition of the table, or just one column "affected_rows" if no result set is returned. (As of version 2.0.17.0, it is recommended not to rely on the head return value to determine the data column type but rather use column_meta. In later versions, the head item may be removed from the return value.)
 - column_meta: this item is added to the return value to indicate the data type of each column in the data with version 2.0.17.0 and later versions. Each column is described by three values: column name, column type, and type length. For example, `["current",6,4]` means that the column name is "current", the column type is 6, which is the float type, and the type length is 4, which is the float type with 4 bytes. If the column type is binary or nchar, the type length indicates the maximum length of content stored in the column, not the length of the specific data in this return value. When the column type is nchar, the type length indicates the number of Unicode characters that can be saved, not bytes.
 - data: The exact data returned, presented row by row, or just [[affected_rows]] if no result set is returned. The order of the data columns in each row of data is the same as that of the data columns described in column_meta.

docs-en/14-reference/03-connector/03-connector.mdx

@@ -4,7 +4,7 @@ title: Connector
 
 TDengine provides a rich set of APIs (application development interface). To facilitate users to develop their applications quickly, TDengine supports connectors for multiple programming languages, including official connectors for C/C++, Java, Python, Go, Node.js, C#, and Rust. These connectors support connecting to TDengine clusters using both native interfaces (taosc) and REST interfaces (not supported in a few languages yet). Community developers have also contributed several unofficial connectors, such as the ADO.NET connector, the Lua connector, and the PHP connector.
 
-![image-connector](./connector.webp)
+![TDengine Database image-connector](./connector.webp)
 
 ## Supported platforms
 

docs-en/14-reference/03-connector/csharp.mdx

@@ -179,9 +179,9 @@ namespace TDengineExample
 
 1. "Unable to establish connection", "Unable to resolve FQDN"
 
-  Usually, it cause by the FQDN configuration is incorrect, you can refer to [How to understand TDengine's FQDN (Chinese)](https://www.taosdata.com/blog/2021/07/29/2741.html) to solve it. 2.
+  Usually, it cause by the FQDN configuration is incorrect, you can refer to [How to understand TDengine's FQDN (Chinese)](https://www.taosdata.com/blog/2021/07/29/2741.html) to solve it. 
 
-Unhandled exception. System.DllNotFoundException: Unable to load DLL 'taos' or one of its dependencies: The specified module cannot be found.
+2. Unhandled exception. System.DllNotFoundException: Unable to load DLL 'taos' or one of its dependencies: The specified module cannot be found.
 
   This is usually because the program did not find the dependent client driver. The solution is to copy `C:\TDengine\driver\taos.dll` to the `C:\Windows\System32\` directory on Windows, and create the following soft link on Linux `ln -s /usr/local/taos/driver/libtaos.so.x.x .x.x /usr/lib/libtaos.so` will work.
 

docs-en/14-reference/03-connector/go.mdx

@@ -15,9 +15,9 @@ import GoOpenTSDBTelnet from "../../07-develop/03-insert-data/_go_opts_telnet.md
 import GoOpenTSDBJson from "../../07-develop/03-insert-data/_go_opts_json.mdx"
 import GoQuery from "../../07-develop/04-query-data/_go.mdx"
 
-`driver-go` is the official Go language connector for TDengine, which implements the interface to the Go language [database/sql](https://golang.org/pkg/database/sql/) package. Go developers can use it to develop applications that access TDengine cluster data.
+`driver-go` is the official Go language connector for TDengine. It implements the [database/sql](https://golang.org/pkg/database/sql/) package, the generic Go language interface to SQL databases. Go developers can use it to develop applications that access TDengine cluster data.
 
-`driver-go` provides two ways to establish connections. One is **native connection**, which connects to TDengine instances natively through the TDengine client driver (taosc), supporting data writing, querying, subscriptions, schemaless writing, and bind interface. The other is the **REST connection**, which connects to TDengine instances via the REST interface provided by taosAdapter. The set of features implemented by the REST connection differs slightly from the native connection.
+`driver-go` provides two ways to establish connections. One is **native connection**, which connects to TDengine instances natively through the TDengine client driver (taosc), supporting data writing, querying, subscriptions, schemaless writing, and bind interface. The other is the **REST connection**, which connects to TDengine instances via the REST interface provided by taosAdapter. The set of features implemented by the REST connection differs slightly from those implemented by the native connection.
 
 This article describes how to install `driver-go` and connect to TDengine clusters and perform basic operations such as data query and data writing through `driver-go`.
 
@@ -213,7 +213,7 @@ func main() {
 
 Since the REST interface is stateless, the `use db` syntax will not work. You need to put the db name into the SQL command, e.g. `create table if not exists tb1 (ts timestamp, a int)` to `create table if not exists test.tb1 (ts timestamp, a int)` otherwise it will report the error `[0x217] Database not specified or available`.
 
-You can also put the db name in the DSN by changing `root:taosdata@http(localhost:6041)/` to `root:taosdata@http(localhost:6041)/test`. This method is supported by taosAdapter in TDengine 2.4.0.5. is supported since TDengine 2.4.0.5. Executing the `create database` statement when the specified db does not exist will not report an error while executing other queries or writing against that db will report an error.
+You can also put the db name in the DSN by changing `root:taosdata@http(localhost:6041)/` to `root:taosdata@http(localhost:6041)/test`. This method is supported by taosAdapter since TDengine 2.4.0.5. Executing the `create database` statement when the specified db does not exist will not report an error while executing other queries or writing against that db will report an error.
 
 The complete example is as follows.
 
@@ -289,7 +289,7 @@ func main() {
 
 6. `readBufferSize` parameter has no significant effect after being increased
 
-  If you increase `readBufferSize` will reduce the number of `syscall` calls when fetching results. If the query result is smaller, modifying this parameter will not improve significantly. If you increase the parameter value too much, the bottleneck will be parsing JSON data. If you need to optimize the query speed, you must adjust the value according to the actual situation to achieve the best query result.
+  Increasing `readBufferSize` will reduce the number of `syscall` calls when fetching results. If the query result is smaller, modifying this parameter will not improve performance significantly. If you increase the parameter value too much, the bottleneck will be parsing JSON data. If you need to optimize the query speed, you must adjust the value based on the actual situation to achieve the best query performance.
 
 7. `disableCompression` parameter is set to `false` when the query efficiency is reduced
 

docs-en/14-reference/03-connector/java.mdx

@@ -9,19 +9,19 @@ description: TDengine Java based on JDBC API and provide both native and REST co
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-'taos-jdbcdriver' is TDengine's official Java language connector, which allows Java developers to develop applications that access the TDengine database. 'taos-jdbcdriver' implements the interface of the JDBC driver standard and provides two forms of connectors. One is to connect to a TDengine instance natively through the TDengine client driver (taosc), which supports functions including data writing, querying, subscription, schemaless writing, and bind interface. And the other is to connect to a TDengine instance through the REST interface provided by taosAdapter (2.4.0.0 and later). REST connections implement has a slight differences to compare the set of features implemented and native connections.
+'taos-jdbcdriver' is TDengine's official Java language connector, which allows Java developers to develop applications that access the TDengine database. 'taos-jdbcdriver' implements the interface of the JDBC driver standard and provides two forms of connectors. One is to connect to a TDengine instance natively through the TDengine client driver (taosc), which supports functions including data writing, querying, subscription, schemaless writing, and bind interface. And the other is to connect to a TDengine instance through the REST interface provided by taosAdapter (2.4.0.0 and later). The implementation of the REST connection and those of the native connections have slight differences in features.
 
-![tdengine-connector](tdengine-jdbc-connector.webp)
+![TDengine Database tdengine-connector](tdengine-jdbc-connector.webp)
 
 The preceding diagram shows two ways for a Java app to access TDengine via connector:
 
 - JDBC native connection: Java applications use TSDBDriver on physical node 1 (pnode1) to call client-driven directly (`libtaos.so` or `taos.dll`) APIs to send writing and query requests to taosd instances located on physical node 2 (pnode2).
-- JDBC REST connection: The Java application encapsulates the SQL as a REST request via RestfulDriver, sends it to the REST server of physical node 2 (taosAdapter), requests TDengine server through the REST server, and returns the result.
+- JDBC REST connection: The Java application encapsulates the SQL as a REST request via RestfulDriver, sends it to the REST server (taosAdapter) on physical node 2. taosAdapter forwards the request to TDengine server and returns the result.
 
-Using REST connection, which does not rely on TDengine client drivers.It can be cross-platform more convenient and flexible but introduce about 30% lower performance than native connection.
+The REST connection, which does not rely on TDengine client drivers, is more convenient and flexible, in addition to being cross-platform. However the performance is about 30% lower than that of the native connection.
 
 :::info
-TDengine's JDBC driver implementation is as consistent as possible with the relational database driver. Still, there are differences in the use scenarios and technical characteristics of TDengine and relational object databases, so 'taos-jdbcdriver' also has some differences from traditional JDBC drivers. You need to pay attention to the following points when using:
+TDengine's JDBC driver implementation is as consistent as possible with the relational database driver. Still, there are differences in the use scenarios and technical characteristics of TDengine and relational object databases. So 'taos-jdbcdriver' also has some differences from traditional JDBC drivers. It is important to keep the following points in mind:
 
 - TDengine does not currently support delete operations for individual data records.
 - Transactional operations are not currently supported.
@@ -88,7 +88,7 @@ Add following dependency in the `pom.xml` file of your Maven project:
 </TabItem>
 <TabItem value="source" label="Build from source code">
 
-You can build Java connector from source code after clone TDengine project:
+You can build Java connector from source code after cloning the TDengine project:
 
 ```shell
 git clone https://github.com/taosdata/TDengine.git
@@ -96,7 +96,7 @@ cd TDengine/src/connector/jdbc
 mvn clean install -Dmaven.test.skip=true
 ```
 
-After compilation, a jar package of taos-jdbcdriver-2.0.XX-dist .jar is generated in the target directory, and the compiled jar file is automatically placed in the local Maven repository.
+After compilation, a jar package named taos-jdbcdriver-2.0.XX-dist.jar is generated in the target directory, and the compiled jar file is automatically placed in the local Maven repository.
 
 </TabItem>
 </Tabs>
@@ -186,7 +186,7 @@ Connection conn = DriverManager.getConnection(jdbcUrl);
 
 In the above example, a RestfulDriver with a JDBC REST connection is used to establish a connection to a database named `test` with hostname `taosdemo.com` on port `6041`. The URL specifies the user name as `root` and the password as `taosdata`.
 
-There is no dependency on the client driver when Using a JDBC REST connection. Compared to a JDBC native connection, only the following are required: 1.
+There is no dependency on the client driver when Using a JDBC REST connection. Compared to a JDBC native connection, only the following are required:
 
 1. driverClass specified as "com.taosdata.jdbc.rs.RestfulDriver".
 2. jdbcUrl starting with "jdbc:TAOS-RS://".
@@ -209,7 +209,7 @@ The configuration parameters in the URL are as follows.
 INSERT INTO test.t1 USING test.weather (ts, temperature) TAGS('California.SanFrancisco') VALUES(now, 24.6);
 ```
 
-- Starting from taos-jdbcdriver-2.0.36 and TDengine 2.2.0.0, if dbname is specified in the URL, JDBC REST connections will use `/rest/sql/dbname` as the URL for REST requests by default, and there is no need to specify dbname in SQL. For example, if the URL is `jdbc:TAOS-RS://127.0.0.1:6041/test`, then the SQL can be executed: insert into t1 using weather(ts, temperature) tags('California.SanFrancisco') values(now, 24.6);
+- Starting from taos-jdbcdriver-2.0.36 and TDengine 2.2.0.0, if dbname is specified in the URL, JDBC REST connections will use `/rest/sql/dbname` as the URL for REST requests by default, and there is no need to specify dbname in SQL. For example, if the URL is `jdbc:TAOS-RS://127.0.0.1:6041/test`, then the SQL can be executed: insert into test using weather(ts, temperature) tags('California.SanFrancisco') values(now, 24.6);
 
 :::
 
@@ -271,7 +271,7 @@ If the configuration parameters are duplicated in the URL, Properties, or client
 2. Properties connProps
 3. the configuration file taos.cfg of the TDengine client driver when using a native connection
 
-For example, if you specify the password as `taosdata` in the URL and specify the password as `taosdemo` in the Properties simultaneously. In this case, JDBC will use the password in the URL to establish the connection.
+For example, if you specify the password as `taosdata` in the URL and specify the password as `taosdemo` in the Properties simultaneously, JDBC will use the password in the URL to establish the connection.
 
 ## Usage examples
 
@@ -323,7 +323,7 @@ while(resultSet.next()){
 }
 ```
 
-> The query is consistent with operating a relational database. When using subscripts to get the contents of the returned fields, starting from 1, it is recommended to use the field names to get them.
+> The query is consistent with operating a relational database. When using subscripts to get the contents of the returned fields, you have to start from 1. However, we recommend using the field names to get the values of the fields in the result set.
 
 ### Handling exceptions
 
@@ -623,7 +623,7 @@ public void setNString(int columnIndex, ArrayList<String> list, int size) throws
 
 ### Schemaless Writing
 
-Starting with version 2.2.0.0, TDengine has added the ability to schemaless writing. It is compatible with InfluxDB's Line Protocol, OpenTSDB's telnet line protocol, and OpenTSDB's JSON format protocol. See [schemaless writing](/reference/schemaless/) for details.
+Starting with version 2.2.0.0, TDengine has added the ability to perform schemaless writing. It is compatible with InfluxDB's Line Protocol, OpenTSDB's telnet line protocol, and OpenTSDB's JSON format protocol. See [schemaless writing](/reference/schemaless/) for details.
 
 **Note**.
 
@@ -666,16 +666,16 @@ The TDengine Java Connector supports subscription functionality with the followi
 #### Create subscriptions
 
 ```java
-TSDBSubscribe sub = ((TSDBConnection)conn).subscribe("topic", "select * from meters", false);
+TSDBSubscribe sub = ((TSDBConnection)conn).subscribe("topicname", "select * from meters", false);
 ```
 
 The three parameters of the `subscribe()` method have the following meanings.
 
-- topic: the subscribed topic (i.e., name). This parameter is the unique identifier of the subscription
-- sql: the query statement of the subscription, this statement can only be `select` statement, only the original data should be queried, and you can query only the data in the positive time order
+- topicname: the name of the subscribed topic. This parameter is the unique identifier of the subscription.
+- sql: the query statement of the subscription. This statement can only be a `select` statement. Only original data can be queried, and you can query the data only temporal order.
 - restart: if the subscription already exists, whether to restart or continue the previous subscription
 
-The above example will use the SQL command `select * from meters` to create a subscription named `topic`. If the subscription exists, it will continue the progress of the previous query instead of consuming all the data from the beginning.
+The above example will use the SQL command `select * from meters` to create a subscription named `topicname`. If the subscription exists, it will continue the progress of the previous query instead of consuming all the data from the beginning.
 
 #### Subscribe to consume data
 

docs-en/14-reference/03-connector/node.mdx

@@ -14,7 +14,6 @@ import NodeInfluxLine from "../../07-develop/03-insert-data/_js_line.mdx";
 import NodeOpenTSDBTelnet from "../../07-develop/03-insert-data/_js_opts_telnet.mdx";
 import NodeOpenTSDBJson from "../../07-develop/03-insert-data/_js_opts_json.mdx";
 import NodeQuery from "../../07-develop/04-query-data/_js.mdx";
-import NodeAsyncQuery from "../../07-develop/04-query-data/_js_async.mdx";
 
 `td2.0-connector` and `td2.0-rest-connector` are the official Node.js language connectors for TDengine. Node.js developers can develop applications to access TDengine instance data.
 
@@ -189,14 +188,8 @@ let cursor = conn.cursor();
 
 ### Query data
 
-#### Synchronous queries
-
 <NodeQuery />
 
-#### asynchronous query
-
-<NodeAsyncQuery />
-
 ## More Sample Programs
 
 | Sample Programs | Sample Program Description |

docs-en/14-reference/03-connector/python.mdx

@@ -11,18 +11,18 @@ import TabItem from "@theme/TabItem";
 `taospy` is the official Python connector for TDengine. `taospy` provides a rich set of APIs that makes it easy for Python applications to access TDengine. `taospy` wraps both the [native interface](/reference/connector/cpp) and [REST interface](/reference/rest-api) of TDengine, which correspond to the `taos` and `taosrest` modules of the `taospy` package, respectively.
 In addition to wrapping the native and REST interfaces, `taospy` also provides a set of programming interfaces that conforms to the [Python Data Access Specification (PEP 249)](https://peps.python.org/pep-0249/). It is easy to integrate `taospy` with many third-party tools, such as [SQLAlchemy](https://www.sqlalchemy.org/) and [pandas](https://pandas.pydata.org/).
 
-The connection to the server directly using the native interface provided by the client driver is referred to hereinafter as a "native connection"; the connection to the server using the REST interface provided by taosAdapter is referred to hereinafter as a "REST connection".
+The direct connection to the server using the native interface provided by the client driver is referred to hereinafter as a "native connection"; the connection to the server using the REST interface provided by taosAdapter is referred to hereinafter as a "REST connection".
 
 The source code for the Python connector is hosted on [GitHub](https://github.com/taosdata/taos-connector-python).
 
 ## Supported Platforms
 
-- The native connection [supported platforms](/reference/connector/#supported-platforms) is the same as the one supported by the TDengine client.
+- The [supported platforms](/reference/connector/#supported-platforms) for the native connection are the same as the ones supported by the TDengine client.
 - REST connections are supported on all platforms that can run Python.
 
 ## Version selection
 
-We recommend using the latest version of `taospy`, regardless what the version of TDengine is.
+We recommend using the latest version of `taospy`, regardless of the version of TDengine.
 
 ## Supported features
 
@@ -53,7 +53,7 @@ Earlier TDengine client software includes the Python connector. If the Python co
 
 :::
 
-#### to install `taospy`
+#### To install `taospy`
 
 <Tabs>
 <TabItem label="Install from PyPI" value="pypi">
@@ -139,7 +139,7 @@ The FQDN above can be the FQDN of any dnode in the cluster, and the PORT is the
 </TabItem>
 <TabItem value="rest" label="REST connection" groupId="connect">
 
-For REST connections and making sure the cluster is up, make sure the taosAdapter component is up. This can be tested using the following `curl ` command.
+For REST connections, make sure the cluster and taosAdapter component, are running. This can be tested using the following `curl ` command.
 
 ```
 curl -u root:taosdata http://<FQDN>:<PORT>/rest/sql -d "select server_version()"
@@ -312,7 +312,7 @@ For a more detailed description of the `sql()` method, please refer to [RestClie
 
 ### Exception handling
 
-All database operations will be thrown directly if an exception occurs. The application is responsible for exception handling. For example:
+All errors from database operations are thrown directly as exceptions and the error message from the database is passed up the exception stack. The application is responsible for exception handling. For example:
 
 ```python
 {{#include docs-examples/python/handle_exception.py}}
@@ -320,7 +320,7 @@ All database operations will be thrown directly if an exception occurs. The appl
 
 ### About nanoseconds
 
-Due to the current imperfection of Python's nanosecond support (see link below), the current implementation returns integers at nanosecond precision instead of the `datetime` type produced by `ms and `us`, which application developers will need to handle on their own. And it is recommended to use pandas' to_datetime(). The Python Connector may modify the interface in the future if Python officially supports nanoseconds in full.
+Due to the current imperfection of Python's nanosecond support (see link below), the current implementation returns integers at nanosecond precision instead of the `datetime` type produced by `ms` and `us`, which application developers will need to handle on their own. And it is recommended to use pandas' to_datetime(). The Python Connector may modify the interface in the future if Python officially supports nanoseconds in full.
 
 1. https://stackoverflow.com/questions/10611328/parsing-datetime-strings-containing-nanoseconds
 2. https://www.python.org/dev/peps/pep-0564/
@@ -328,7 +328,7 @@ Due to the current imperfection of Python's nanosecond support (see link below),
 
 ## Frequently Asked Questions
 
-Welcome to [ask questions or report questions] (https://github.com/taosdata/taos-connector-python/issues).
+Welcome to [ask questions or report questions](https://github.com/taosdata/taos-connector-python/issues).
 
 ## Important Update
 

docs-en/14-reference/03-connector/rust.mdx

@@ -30,7 +30,7 @@ REST connections are supported on all platforms that can run Rust.
 
 Please refer to [version support list](/reference/connector#version-support).
 
-The Rust Connector is still under rapid development and is not guaranteed to be backward compatible before 1.0. Recommend to use TDengine version 2.4 or higher to avoid known issues.
+The Rust Connector is still under rapid development and is not guaranteed to be backward compatible before 1.0. We recommend using TDengine version 2.4 or higher to avoid known issues.
 
 ## Installation
 
@@ -206,7 +206,7 @@ let conn: Taos = cfg.connect();
 
 ### Connection pooling
 
-In complex applications, recommand to enable connection pool. Connection pool for [libtaos] is implemented using [r2d2].
+In complex applications, we recommend enabling connection pools. Connection pool for [libtaos] is implemented using [r2d2].
 
 As follows, a connection pool with default parameters can be generated.
 
@@ -269,7 +269,7 @@ The [Taos] structure is the connection manager in [libtaos] and provides two mai
 
 Note that Rust asynchronous functions and an asynchronous runtime are required.
 
-[Taos] provides partial Rust methodization of SQL to reduce the frequency of `format!` code blocks.
+[Taos] provides a few Rust methods that encapsulate SQL to reduce the frequency of `format!` code blocks.
 
 - `.describe(table: &str)`: Executes `DESCRIBE` and returns a Rust data structure.
 - `.create_database(database: &str)`: Executes the `CREATE DATABASE` statement.
@@ -279,7 +279,7 @@ In addition, this structure is also the entry point for [Parameter Binding](#Par
 
 ### Bind Interface
 
-Similar to the C interface, Rust provides the bind interface's wraping. First, create a bind object [Stmt] for a SQL command from the [Taos] object.
+Similar to the C interface, Rust provides the bind interface's wrapping. First, create a bind object [Stmt] for a SQL command from the [Taos] object.
 
 ```rust
 let mut stmt: Stmt = taos.stmt("insert into ? values(? ,?)") ? ;

docs-en/14-reference/04-taosadapter.md

@@ -24,21 +24,21 @@ taosAdapter provides the following features.
 
 ## taosAdapter architecture diagram
 
-![taosAdapter Architecture](taosAdapter-architecture.webp)
+![TDengine Database taosAdapter Architecture](taosAdapter-architecture.webp)
 
 ## taosAdapter Deployment Method
 
 ### Install taosAdapter
 
-taosAdapter has been part of TDengine server software since TDengine v2.4.0.0. If you use the TDengine server, you don't need additional steps to install taosAdapter. You can download taosAdapter from [TAOSData official website](https://taosdata.com/en/all-downloads/) to download the TDengine server installation package (taosAdapter is included in v2.4.0.0 and later version). If you need to deploy taosAdapter separately on another server other than the TDengine server, you should install the full TDengine on that server to install taosAdapter. If you need to build taosAdapter from source code, you can refer to the [Building taosAdapter]( https://github.com/taosdata/taosadapter/blob/develop/BUILD.md) documentation.
+taosAdapter has been part of TDengine server software since TDengine v2.4.0.0. If you use the TDengine server, you don't need additional steps to install taosAdapter. You can download taosAdapter from [TDengine official website](https://tdengine.com/all-downloads/) to download the TDengine server installation package (taosAdapter is included in v2.4.0.0 and later version). If you need to deploy taosAdapter separately on another server other than the TDengine server, you should install the full TDengine server package on that server to install taosAdapter. If you need to build taosAdapter from source code, you can refer to the [Building taosAdapter]( https://github.com/taosdata/taosadapter/blob/develop/BUILD.md) documentation.
 
-### start/stop taosAdapter
+### Start/Stop taosAdapter
 
 On Linux systems, the taosAdapter service is managed by `systemd` by default. You can use the command `systemctl start taosadapter` to start the taosAdapter service and use the command `systemctl stop taosadapter` to stop the taosAdapter service.
 
 ### Remove taosAdapter
 
-Use the command `rmtaos` to remove the TDengine server software if you use tar.gz package or use package management command like rpm or apt to remove the TDengine server, including taosAdapter.
+Use the command `rmtaos` to remove the TDengine server software if you use tar.gz package. If you installed using a .deb or .rpm package, use the corresponding command, for your package manager, like apt or rpm to remove the TDengine server, including taosAdapter.
 
 ### Upgrade taosAdapter
 
@@ -153,8 +153,7 @@ See [example/config/taosadapter.toml](https://github.com/taosdata/taosadapter/bl
 
 ## Feature List
 
-- Compatible with RESTful interfaces
-  [https://www.taosdata.com/cn/documentation/connector#restful](https://www.taosdata.com/cn/documentation/connector#restful)
+- Compatible with RESTful interfaces [REST API](/reference/rest-api/)
 - Compatible with InfluxDB v1 write interface
   [https://docs.influxdata.com/influxdb/v2.0/reference/api/influxdb-1x/write/](https://docs.influxdata.com/influxdb/v2.0/reference/api/influxdb-1x/write/)
 - Compatible with OpenTSDB JSON and telnet format writes
@@ -187,7 +186,7 @@ You can use any client that supports the http protocol to write data to or query
 
 ### InfluxDB
 
-You can use any client that supports the http protocol to access the Restful interface address `http://<fqdn>:6041/<APIEndPoint>` to write data in InfluxDB compatible format to TDengine. The EndPoint is as follows:
+You can use any client that supports the http protocol to access the RESTful interface address `http://<fqdn>:6041/<APIEndPoint>` to write data in InfluxDB compatible format to TDengine. The EndPoint is as follows:
 
 ```text
 /influxdb/v1/write
@@ -204,7 +203,7 @@ Note: InfluxDB token authorization is not supported at present. Only Basic autho
 
 ### OpenTSDB
 
-You can use any client that supports the http protocol to access the Restful interface address `http://<fqdn>:6041/<APIEndPoint>` to write data in OpenTSDB compatible format to TDengine.
+You can use any client that supports the http protocol to access the RESTful interface address `http://<fqdn>:6041/<APIEndPoint>` to write data in OpenTSDB compatible format to TDengine.
 
 ```text
 /opentsdb/v1/put/json/:db
@@ -241,7 +240,7 @@ node_export is an exporter of hardware and OS metrics exposed by the \*NIX kerne
 
 ## Memory usage optimization methods
 
-taosAdapter will monitor its memory usage during operation and adjust it with two thresholds. Valid values range from -1 to 100 integers in percent of the system's physical memory.
+taosAdapter will monitor its memory usage during operation and adjust it with two thresholds. Valid values are integers between 1 to 100, and represent a percentage of the system's physical memory.
 
 - pauseQueryMemoryThreshold
 - pauseAllMemoryThreshold
@@ -277,7 +276,7 @@ Corresponding configuration parameter
   monitor.pauseQueryMemoryThreshold memory threshold for no more queries Environment variable `TAOS_MONITOR_PAUSE_QUERY_MEMORY_THRESHOLD` (default 70)
 ```
 
-You can adjust it according to the specific application scenario and operation strategy, and it is recommended to use operation monitoring software to monitor system memory status timely. The load balancer can also check the taosAdapter running status through this interface.
+You should adjust this parameter based on your specific application scenario and operation strategy. We recommend using monitoring software to monitor system memory status. The load balancer can also check the taosAdapter running status through this interface.
 
 ## taosAdapter Monitoring Metrics
 
@@ -326,7 +325,7 @@ You can also adjust the level of the taosAdapter log output by setting the `--lo
 
 ## How to migrate from older TDengine versions to taosAdapter
 
-In TDengine server 2.2.x.x or earlier, the TDengine server process (taosd) contains an embedded HTTP service. As mentioned earlier, taosAdapter is a standalone software managed using `systemd` and has its process ID. And there are some configuration parameters and behaviors that are different between the two. See the following table for details.
+In TDengine server 2.2.x.x or earlier, the TDengine server process (taosd) contains an embedded HTTP service. As mentioned earlier, taosAdapter is a standalone software managed using `systemd` and has its own process ID. There are some configuration parameters and behaviors that are different between the two. See the following table for details.
 
 | **#** | **embedded httpd** | **taosAdapter** | **comment** |
 | ----- | ------------------- | ------------------------------------ | ------------------------------------------------------------------ ------------------------------------------------------------------------ |

docs-en/14-reference/06-taosdump.md

@@ -12,14 +12,13 @@ taosdump can back up a database, a super table, or a normal table as a logical d
 Suppose the specified location already has data files. In that case, taosdump will prompt the user and exit immediately to avoid data overwriting which means that the same path can only be used for one backup.
 Please be careful if you see a prompt for this.
 
-taosdump is a logical backup tool and should not be used to back up any raw data, environment settings,
 Users should not use taosdump to back up raw data, environment settings, hardware information, server configuration, or cluster topology. taosdump uses [Apache AVRO](https://avro.apache.org/) as the data file format to store backup data.
 
 ## Installation
 
 There are two ways to install taosdump:
 
-- Install the taosTools official installer. Please find taosTools from [All download links](https://www.taosdata.com/all-downloads) page and download and install it.
+- Install the taosTools official installer. Please find taosTools from [All download links](https://www.tdengine.com/all-downloads) page and download and install it.
 
 - Compile taos-tools separately and install it. Please refer to the [taos-tools](https://github.com/taosdata/taos-tools) repository for details.
 
@@ -28,14 +27,14 @@ There are two ways to install taosdump:
 ### taosdump backup data
 
 1. backing up all databases: specify `-A` or `-all-databases` parameter.
-2. backup multiple specified databases: use `-D db1,db2,... ` parameters; 3.
+2. backup multiple specified databases: use `-D db1,db2,... ` parameters;
 3. back up some super or normal tables in the specified database: use `-dbname stbname1 stbname2 tbname1 tbname2 ... ` parameters. Note that the first parameter of this input sequence is the database name, and only one database is supported. The second and subsequent parameters are the names of super or normal tables in that database, separated by spaces.
 4. back up the system log database: TDengine clusters usually contain a system database named `log`. The data in this database is the data that TDengine runs itself, and the taosdump will not back up the log database by default. If users need to back up the log database, users can use the `-a` or `-allow-sys` command-line parameter. 
 5. Loose mode backup: taosdump version 1.4.1 onwards provides `-n` and `-L` parameters for backing up data without using escape characters and "loose" mode, which can reduce the number of backups if table names, column names, tag names do not use This can reduce the backup data time and backup data footprint if table names, column names, and tag names do not use `escape character`. If you are unsure about using `-n` and `-L` conditions, please use the default parameters for "strict" mode backup. See the [official documentation](/taos-sql/escape) for a description of escaped characters.
 
 :::tip
 - taosdump versions after 1.4.1 provide the `-I` argument for parsing Avro file schema and data. If users specify `-s` then only taosdump will parse schema.
-- Backups after taosdump 1.4.2 use the batch count specified by the `-B` parameter. The default value is 16384. If, in some environments, low network speed or disk performance causes "Error actual dump ... batch ..." can be tried by challenging the `-B` parameter to a smaller value.
+- Backups after taosdump 1.4.2 use the batch count specified by the `-B` parameter. The default value is 16384. If, in some environments, low network speed or disk performance causes "Error actual dump ... batch ...", then try changing the `-B` parameter to a smaller value.
 
 :::
 
@@ -44,7 +43,7 @@ There are two ways to install taosdump:
 Restore the data file in the specified path: use the `-i` parameter plus the path to the data file. You should not use the same directory to backup different data sets, and you should not backup the same data set multiple times in the same path. Otherwise, the backup data will cause overwriting or multiple backups.
 
 :::tip
-taosdump internally uses TDengine stmt binding API for writing recovery data and currently uses 16384 as one write batch for better data recovery performance. If there are more columns in the backup data, it may cause a "WAL size exceeds limit" error. You can try to adjust to a smaller value by using the `-B` parameter.
+taosdump internally uses TDengine stmt binding API for writing recovery data with a default batch size of 16384 for better data recovery performance. If there are more columns in the backup data, it may cause a "WAL size exceeds limit" error. You can try to adjust the batch size to a smaller value by using the `-B` parameter.
 
 :::
 

docs-en/14-reference/07-tdinsight/index.md

@@ -61,7 +61,7 @@ sudo yum install \
 
 ## Automated deployment of TDinsight
 
-We provide an installation script [`TDinsight.sh`](https://github.com/taosdata/grafanaplugin/releases/latest/download/TDinsight.sh) script to allow users to configure the installation automatically and quickly.
+We provide an installation script [`TDinsight.sh`](https://github.com/taosdata/grafanaplugin/releases/latest/download/TDinsight.sh) to allow users to configure the installation automatically and quickly.
 
 You can download the script via `wget` or other tools:
 
@@ -233,33 +233,33 @@ The default username/password is `admin`. Grafana will require a password change
 
 Point to the **Configurations** -> **Data Sources** menu, and click the **Add data source** button.
 
-![Add data source button](./assets/howto-add-datasource-button.webp)
+![TDengine Database TDinsight Add data source button](./assets/howto-add-datasource-button.webp)
 
 Search for and select **TDengine**.
 
-![Add datasource](./assets/howto-add-datasource-tdengine.webp)
+![TDengine Database TDinsight Add datasource](./assets/howto-add-datasource-tdengine.webp)
 
 Configure the TDengine datasource.
 
-![Datasource Configuration](./assets/howto-add-datasource.webp)
+![TDengine Database TDinsight Datasource Configuration](./assets/howto-add-datasource.webp)
 
 Save and test. It will report 'TDengine Data source is working' under normal circumstances.
 
-![datasource test](./assets/howto-add-datasource-test.webp)
+![TDengine Database TDinsight datasource test](./assets/howto-add-datasource-test.webp)
 
 ### Importing dashboards
 
 Point to **+** / **Create** - **import** (or `/dashboard/import` url).
 
-![Import Dashboard and Configuration](./assets/import_dashboard.webp)
+![TDengine Database TDinsight Import Dashboard and Configuration](./assets/import_dashboard.webp)
 
 Type the dashboard ID `15167` in the **Import via grafana.com** location and **Load**.
 
-![Import via grafana.com](./assets/import-dashboard-15167.webp)
+![TDengine Database TDinsight Import via grafana.com](./assets/import-dashboard-15167.webp)
 
 Once the import is complete, the full page view of TDinsight is shown below.
 
-![show](./assets/TDinsight-full.webp)
+![TDengine Database TDinsight show](./assets/TDinsight-full.webp)
 
 ## TDinsight dashboard details
 
@@ -269,7 +269,7 @@ Details of the metrics are as follows.
 
 ### Cluster Status
 
-![tdinsight-mnodes-overview](./assets/TDinsight-1-cluster-status.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-1-cluster-status.webp)
 
 This section contains the current information and status of the cluster, the alert information is also here (from left to right, top to bottom).
 
@@ -289,7 +289,7 @@ This section contains the current information and status of the cluster, the ale
 
 ### DNodes Status
 
-![tdinsight-mnodes-overview](./assets/TDinsight-2-dnodes.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-2-dnodes.webp)
 
 - **DNodes Status**: simple table view of `show dnodes`.
 - **DNodes Lifetime**: the time elapsed since the dnode was created.
@@ -298,14 +298,14 @@ This section contains the current information and status of the cluster, the ale
 
 ### MNode Overview
 
-![tdinsight-mnodes-overview](./assets/TDinsight-3-mnodes.webp)
+![TDengine Database TDinsight mnodes overview](./assets/TDinsight-3-mnodes.webp)
 
-1. **MNodes Status**: a simple table view of `show mnodes`. 2.
+1. **MNodes Status**: a simple table view of `show mnodes`.
 2. **MNodes Number**: similar to `DNodes Number`, the number of MNodes changes.
 
 ### Request
 
-![tdinsight-requests](./assets/TDinsight-4-requests.webp)
+![TDengine Database TDinsight tdinsight requests](./assets/TDinsight-4-requests.webp)
 
 1. **Requests Rate(Inserts per Second)**: average number of inserts per second.
 2. **Requests (Selects)**: number of query requests and change rate (count of second).
@@ -313,46 +313,46 @@ This section contains the current information and status of the cluster, the ale
 
 ### Database
 
-![tdinsight-database](./assets/TDinsight-5-database.webp)
+![TDengine Database TDinsight database](./assets/TDinsight-5-database.webp)
 
 Database usage, repeated for each value of the variable `$database` i.e. multiple rows per database.
 
-1. **STables**: number of super tables. 2.
-2. **Total Tables**: number of all tables. 3.
-3. **Sub Tables**: the number of all super table sub-tables. 4.
+1. **STables**: number of super tables.
+2. **Total Tables**: number of all tables.
+3. **Sub Tables**: the number of all super table subtables.
 4. **Tables**: graph of all normal table numbers over time.
 5. **Tables Number Foreach VGroups**: The number of tables contained in each VGroups.
 
 ### DNode Resource Usage
 
-![dnode-usage](./assets/TDinsight-6-dnode-usage.webp)
+![TDengine Database TDinsight dnode usage](./assets/TDinsight-6-dnode-usage.webp)
 
 Data node resource usage display with repeated multiple rows for the variable `$fqdn` i.e., each data node. Includes.
 
 1. **Uptime**: the time elapsed since the dnode was created.
-2. **Has MNodes?**: whether the current dnode is a mnode. 3.
-3. **CPU Cores**: the number of CPU cores. 4.
-4. **VNodes Number**: the number of VNodes in the current dnode. 5.
-5. **VNodes Masters**: the number of vnodes in the master role. 6.
+2. **Has MNodes?**: whether the current dnode is a mnode.
+3. **CPU Cores**: the number of CPU cores.
+4. **VNodes Number**: the number of VNodes in the current dnode.
+5. **VNodes Masters**: the number of vnodes in the master role.
 6. **Current CPU Usage of taosd**: CPU usage rate of taosd processes.
 7. **Current Memory Usage of taosd**: memory usage of taosd processes.
 8. **Disk Used**: The total disk usage percentage of the taosd data directory.
-9. **CPU Usage**: Process and system CPU usage. 10.
+9. **CPU Usage**: Process and system CPU usage.
 10. **RAM Usage**: Time series view of RAM usage metrics.
 11. **Disk Used**: Disks used at each level of multi-level storage (default is level0).
 12. **Disk Increasing Rate per Minute**: Percentage increase or decrease in disk usage per minute.
-13. **Disk IO**: Disk IO rate. 14.
+13. **Disk IO**: Disk IO rate.
 14. **Net IO**: Network IO, the aggregate network IO rate in addition to the local network.
 
 ### Login History
 
-![Login History](./assets/TDinsight-7-login-history.webp)
+![TDengine Database TDinsight Login History](./assets/TDinsight-7-login-history.webp)
 
 Currently, only the number of logins per minute is reported.
 
 ### Monitoring taosAdapter
 
-![taosadapter](./assets/TDinsight-8-taosadapter.webp)
+![TDengine Database TDinsight monitor taosadapter](./assets/TDinsight-8-taosadapter.webp)
 
 Support monitoring taosAdapter request statistics and status details. Includes.
 
@@ -376,7 +376,7 @@ TDinsight installed via the `TDinsight.sh` script can be cleaned up using the co
 To completely uninstall TDinsight during a manual installation, you need to clean up the following.
 
 1. the TDinsight Dashboard in Grafana.
-2. the Data Source in Grafana. 3.
+2. the Data Source in Grafana.
 3. remove the `tdengine-datasource` plugin from the plugin installation directory.
 
 ## Integrated Docker Example

docs-en/14-reference/08-taos-shell.md

 ---
-title: TDengine Command Line (CLI)
-sidebar_label: TDengine CLI
+title: TDengine Command Line Interface (CLI)
+sidebar_label: Command Line Interface
 description: Instructions and tips for using the TDengine CLI
 ---
 
-The TDengine command-line application (hereafter referred to as `TDengine CLI`) is the most simplest way for users to manipulate and interact with TDengine instances.
+The TDengine command-line interface (hereafter referred to as `TDengine CLI`) is the simplest way for users to manipulate and interact with TDengine instances.
 
 ## Installation
 
-If executed on the TDengine server-side, there is no need for additional installation steps to install TDengine CLI as it is already included and installed automatically. To run TDengine CLI on the environment which no TDengine server running, the TDengine client installation package needs to be installed first. For details, please refer to [connector](/reference/connector/).
+If executed on the TDengine server-side, there is no need for additional installation steps to install TDengine CLI as it is already included and installed automatically. To run TDengine CLI in an environment where no TDengine server is running, the TDengine client installation package needs to be installed first. For details, please refer to [connector](/reference/connector/).
 
 ## Execution
 

docs-en/14-reference/11-docker/index.md

@@ -315,13 +315,13 @@ password:             taosdata
      taoslog-td2:
    ```
 
-  :::note
+:::note
 - The `VERSION` environment variable is used to set the tdengine image tag
     - `TAOS_FIRST_EP` must be set on the newly created instance so that it can join the TDengine cluster; if there is a high availability requirement, `TAOS_SECOND_EP` needs to be used at the same time
     - `TAOS_REPLICA` is used to set the default number of database replicas. Its value range is [1,3]
-      We recommend setting with `TAOS_ARBITRATOR` to use arbitrator in a two-nodes environment.
-  :::
-
+      We recommend setting it with `TAOS_ARBITRATOR` to use arbitrator in a two-nodes environment.
+ 
+ :::
 
 2. Start the cluster
 

docs-en/14-reference/12-config/index.md

@@ -65,7 +65,7 @@ taos --dump-config
 | ------------- | ------------------------------------------------------------------------ |
 | Applicable    | Server Only                                                              |
 | Meaning       | The FQDN of the host where `taosd` will be started. It can be IP address |
-| Default Value | The first hostname configured for the hos                                |
+| Default Value | The first hostname configured for the host                               |
 | Note          | It should be within 96 bytes                                             |
 
 ### serverPort
@@ -78,7 +78,7 @@ taos --dump-config
 | Note          | REST service is provided by `taosd` before 2.4.0.0 but by `taosAdapter` after 2.4.0.0, the default port of REST service is 6041 |
 
 :::note
-TDengine uses continuous 13 ports, both TCP and TCP, from the port specified by `serverPort`. These ports need to be kept as open if firewall is enabled. Below table describes the ports used by TDengine in details.
+TDengine uses continuous 13 ports, both TCP and UDP, from the port specified by `serverPort`. These ports need to be kept open if firewall is enabled. Below table describes the ports used by TDengine in details.
 
 :::
 
@@ -182,8 +182,8 @@ TDengine uses continuous 13 ports, both TCP and TCP, from the port specified by
 | ------------- | -------------------------------------------- |
 | Applicable    | Server Only                                  |
 | Meaning       | The maximum number of distinct rows returned |
-| Value Range   | [100,000 - 100, 000, 000]                    |
-| Default Value | 100, 000                                     |
+| Value Range   | [100,000 - 100,000,000]                      |
+| Default Value | 100,000                                      |
 | Note          | After version 2.3.0.0                        |
 
 ## Locale Parameters
@@ -240,7 +240,7 @@ To avoid the problems of using time strings, Unix timestamp can be used directly
 | Default Value | Locale configured in host |
 
 :::info
-A specific type "nchar" is provided in TDengine to store non-ASCII characters such as Chinese, Japanese, Korean. The characters to be stored in nchar type are firstly encoded in UCS4-LE before sending to server side. To store non-ASCII characters correctly, the encoding format of the client side needs to be set properly.
+A specific type "nchar" is provided in TDengine to store non-ASCII characters such as Chinese, Japanese, and Korean. The characters to be stored in nchar type are firstly encoded in UCS4-LE before sending to server side. To store non-ASCII characters correctly, the encoding format of the client side needs to be set properly.
 
 The characters input on the client side are encoded using the default system encoding, which is UTF-8 on Linux, or GB18030 or GBK on some systems in Chinese, POSIX in docker, CP936 on Windows in Chinese. The encoding of the operating system in use must be set correctly so that the characters in nchar type can be converted to UCS4-LE.
 
@@ -779,7 +779,7 @@ To prevent system resource from being exhausted by multiple concurrent streams,
 
 :::note
 HTTP server had been provided by `taosd` prior to version 2.4.0.0, now is provided by `taosAdapter` after version 2.4.0.0.
-The parameters described in this section are only application in versions prior to 2.4.0.0. If you are using any version from 2.4.0.0, please refer to [taosAdapter]](/reference/taosadapter/).
+The parameters described in this section are only application in versions prior to 2.4.0.0. If you are using any version from 2.4.0.0, please refer to [taosAdapter](/reference/taosadapter/).
 
 :::
 

docs-en/14-reference/12-directory.md

@@ -32,7 +32,7 @@ All executable files of TDengine are in the _/usr/local/taos/bin_ directory by d
 - _taosd-dump-cfg.gdb_: script to facilitate debugging of taosd's gdb execution.
 
 :::note
-taosdump after version 2.4.0.0 require taosTools as a standalone installation. A few version taosBenchmark is include in taosTools too.
+taosdump after version 2.4.0.0 require taosTools as a standalone installation. A new version of taosBenchmark is include in taosTools too.
 :::
 
 :::tip

docs-en/14-reference/13-schemaless/13-schemaless.md

@@ -3,17 +3,17 @@ title: Schemaless Writing
 description: "The Schemaless write method eliminates the need to create super tables/sub tables in advance and automatically creates the storage structure corresponding to the data as it is written to the interface."
 ---
 
-In IoT applications, many data items are often collected for intelligent control, business analysis, device monitoring, etc. Due to the version upgrade of the application logic, or the hardware adjustment of the device itself, the data collection items may change more frequently. To facilitate the data logging work in such cases, TDengine starting from version 2.2.0.0, it provides a series of interfaces to the schemaless writing method, which eliminates the need to create super tables/sub tables in advance and automatically creates the storage structure corresponding to the data as the data is written to the interface. And when necessary, Schemaless writing will automatically add the required columns to ensure that the data written by the user is stored correctly.
+In IoT applications, many data items are often collected for intelligent control, business analysis, device monitoring, etc. Due to the version upgrades of the application logic, or the hardware adjustment of the devices themselves, the data collection items may change frequently. To facilitate the data logging work in such cases, TDengine starting from version 2.2.0.0 provides a series of interfaces to the schemaless writing method, which eliminate the need to create super tables and subtables in advance by automatically creating the storage structure corresponding to the data as the data is written to the interface. And when necessary, schemaless writing will automatically add the required columns to ensure that the data written by the user is stored correctly.
 
-The schemaless writing method creates super tables and their corresponding sub-tables completely indistinguishable from the super tables and sub-tables created directly via SQL. You can write data directly to them via SQL statements. Note that the names of tables created by schemaless writing are based on fixed mapping rules for tag values, so they are not explicitly ideographic and lack readability.
+The schemaless writing method creates super tables and their corresponding subtables completely indistinguishable from the super tables and subtables created directly via SQL. You can write data directly to them via SQL statements. Note that the names of tables created by schemaless writing are based on fixed mapping rules for tag values, so they are not explicitly ideographic and lack readability.
 
 ## Schemaless Writing Line Protocol
 
-TDengine's schemaless writing line protocol supports to be compatible with InfluxDB's Line Protocol, OpenTSDB's telnet line protocol, and OpenTSDB's JSON format protocol. However, when using these three protocols, you need to specify in the API the standard of the parsing protocol to be used for the input content.
+TDengine's schemaless writing line protocol supports InfluxDB's Line Protocol, OpenTSDB's telnet line protocol, and OpenTSDB's JSON format protocol. However, when using these three protocols, you need to specify in the API the standard of the parsing protocol to be used for the input content.
 
 For the standard writing protocols of InfluxDB and OpenTSDB, please refer to the documentation of each protocol. The following is a description of TDengine's extended protocol, based on InfluxDB's line protocol first. They allow users to control the (super table) schema more granularly.
 
-With the following formatting conventions, Schemaless writing uses a single string to express a data row (multiple rows can be passed into the writing API at once to enable bulk writing).
+With the following formatting conventions, schemaless writing uses a single string to express a data row (multiple rows can be passed into the writing API at once to enable bulk writing).
 
 ```json
 measurement,tag_set field_set timestamp
@@ -23,7 +23,7 @@ where :
 
 - measurement will be used as the data table name. It will be separated from tag_set by a comma.
 - tag_set will be used as tag data in the format `<tag_key>=<tag_value>,<tag_key>=<tag_value>`, i.e. multiple tags' data can be separated by a comma. It is separated from field_set by space.
-- field_set will be used as normal column data in the format of `<field_key>=<field_value>,<field_key>=<field_value>`, again using a comma to separate multiple normal columns of data. It is separated from the timestamp by space.
+- field_set will be used as normal column data in the format of `<field_key>=<field_value>,<field_key>=<field_value>`, again using a comma to separate multiple normal columns of data. It is separated from the timestamp by a space.
 - The timestamp is the primary key corresponding to the data in this row.
 
 All data in tag_set is automatically converted to the NCHAR data type and does not require double quotes (").
@@ -32,7 +32,7 @@ In the schemaless writing data line protocol, each data item in the field_set ne
 
 - If there are English double quotes on both sides, it indicates the BINARY(32) type. For example, `"abc"`.
 - If there are double quotes on both sides and an L prefix, it means NCHAR(32) type. For example, `L"error message"`.
-- Spaces, equal signs (=), commas (,), and double quotes (") need to be escaped with a backslash (\) in front. (All refer to the ASCII character)
+- Spaces, equal signs (=), commas (,), and double quotes (") need to be escaped with a backslash (\\) in front. (All refer to the ASCII character)
 - Numeric types will be distinguished from data types by the suffix.
 
 | **Serial number** | **Postfix** | **Mapping type** | **Size (bytes)** |
@@ -58,26 +58,26 @@ Note that if the wrong case is used when describing the data type suffix, or if
 
 Schemaless writes process row data according to the following principles.
 
-1. You can use the following rules to generate the sub-table names: first, combine the measurement name and the key and value of the label  into the next string:
+1. You can use the following rules to generate the subtable names: first, combine the measurement name and the key and value of the label  into the next string:
 
 ```json
 "measurement,tag_key1=tag_value1,tag_key2=tag_value2"
 ```
 
 Note that tag_key1, tag_key2 are not the original order of the tags entered by the user but the result of using the tag names in ascending order of the strings. Therefore, tag_key1 is not the first tag entered in the line protocol.
-The string's MD5 hash value "md5_val" is calculated after the ranking is completed. The calculation result is then combined with the string to generate the table name: "t_md5_val". "t*" is a fixed prefix that every table generated by this mapping relationship has. 2.
+The string's MD5 hash value "md5_val" is calculated after the ranking is completed. The calculation result is then combined with the string to generate the table name: "t_md5_val". "t*" is a fixed prefix that every table generated by this mapping relationship has.
 
 2. If the super table obtained by parsing the line protocol does not exist, this super table is created.
-If the sub-table obtained by the parse line protocol does not exist, Schemaless creates the sub-table according to the sub-table name determined in steps 1 or 2. 4.
+If the subtable obtained by the parse line protocol does not exist, Schemaless creates the sub-table according to the subtable name determined in steps 1 or 2.
 4. If the specified tag or regular column in the data row does not exist, the corresponding tag or regular column is added to the super table (only incremental).
 5. If there are some tag columns or regular columns in the super table that are not specified to take values in a data row, then the values of these columns are set to NULL.
 6. For BINARY or NCHAR columns, if the length of the value provided in a data row exceeds the column type limit, the maximum length of characters allowed to be stored in the column is automatically increased (only incremented and not decremented) to ensure complete preservation of the data.
-7. If the specified data sub-table already exists, and the specified tag column takes a value different from the saved value this time, the value in the latest data row overwrites the old tag column take value.
+7. If the specified data subtable already exists, and the specified tag column takes a value different from the saved value this time, the value in the latest data row overwrites the old tag column take value.
 8. Errors encountered throughout the processing will interrupt the writing process and return an error code.
 
 :::tip
 All processing logic of schemaless will still follow TDengine's underlying restrictions on data structures, such as the total length of each row of data cannot exceed
-16k bytes. See [TAOS SQL Boundary Limits](/taos-sql/limit) for specific constraints in this area.
+48k bytes. See [TAOS SQL Boundary Limits](/taos-sql/limit) for specific constraints in this area.
 :::
 
 ## Time resolution recognition

docs-en/14-reference/_collectd.mdx

@@ -25,7 +25,7 @@ The default database name written by taosAdapter is `collectd`. You can also mod
 #collectd
 collectd uses a plugin mechanism to write the collected monitoring data to different data storage software in various forms. tdengine supports both direct collection plugins and write_tsdb plugins.
 
-#### is configured to receive data from the direct collection plugin
+#### Configure the direct collection plugin
 
 Modify the relevant configuration items in the collectd configuration file (default location /etc/collectd/collectd.conf).
 
@@ -62,7 +62,7 @@ LoadPlugin write_tsdb
 </Plugin>
 ```
 
-Where <taosAdapter's host\> fills in the server's domain name or IP address running taosAdapter. <port for collectd write_tsdb plugin\> Fill in the data that taosAdapter uses to receive the collectd write_tsdb plugin (default is 6047).
+Where <taosAdapter's host\> is the domain name or IP address of the server running taosAdapter. <port for collectd write_tsdb plugin\> Fill in the data that taosAdapter uses to receive the collectd write_tsdb plugin (default is 6047).
 
 ```text
 LoadPlugin write_tsdb

docs-en/14-reference/index.md

@@ -2,11 +2,11 @@
 title: Reference
 ---
 
-The reference guide is the detailed introduction to TDengine, various TDengine's connectors in different languages, and the tools that come with it.
+The reference guide is a detailed introduction to TDengine including various TDengine connectors in different languages, and the tools that come with TDengine.
 
 ```mdx-code-block
 import DocCardList from '@theme/DocCardList';
 import {useCurrentSidebarCategory} from '@docusaurus/theme-common';
 
 <DocCardList items={useCurrentSidebarCategory().items}/>
-```
\ No newline at end of file
+```

docs-en/20-third-party/01-grafana.mdx

@@ -23,7 +23,7 @@ You can download The Grafana plugin for TDengine from <https://github.com/taosda
 
 Recommend using the [``grafana-cli`` command-line tool](https://grafana.com/docs/grafana/latest/administration/cli/) for plugin installation.
 
-``bash
+```bash
 sudo -u grafana grafana-cli \
   --pluginUrl https://github.com/taosdata/grafanaplugin/releases/download/v3.1.4/tdengine-datasource-3.1.4.zip \
   plugins install tdengine-datasource
@@ -62,15 +62,15 @@ GF_PLUGINS_ALLOW_LOADING_UNSIGNED_PLUGINS=tdengine-datasource
 
 Users can log in to the Grafana server (username/password: admin/admin) directly through the URL `http://localhost:3000` and add a datasource through `Configuration -> Data Sources` on the left side, as shown in the following figure.
 
-![img](./grafana/add_datasource1.webp)
+![TDengine Database TDinsight plugin add datasource 1](./grafana/add_datasource1.webp)
 
 Click `Add data source` to enter the Add data source page, and enter TDengine in the query box to add it, as shown in the following figure.
 
-![img](./grafana/add_datasource2.webp)
+![TDengine Database TDinsight plugin add datasource 2](./grafana/add_datasource2.webp)
 
 Enter the datasource configuration page, and follow the default prompts to modify the corresponding configuration.
 
-![img](./grafana/add_datasource3.webp)
+![TDengine Database TDinsight plugin add database 3](./grafana/add_datasource3.webp)
 
 - Host: IP address of the server where the components of the TDengine cluster provide REST service (offered by taosd before 2.4 and by taosAdapter since 2.4) and the port number of the TDengine REST service (6041), by default use `http://localhost:6041`.
 - User: TDengine user name.
@@ -78,23 +78,23 @@ Enter the datasource configuration page, and follow the default prompts to modif
 
 Click `Save & Test` to test. Follows are a success.
 
-![img](./grafana/add_datasource4.webp)
+![TDengine Database TDinsight plugin add database 4](./grafana/add_datasource4.webp)
 
 ### Create Dashboard
 
 Go back to the main interface to create the Dashboard, click Add Query to enter the panel query page:
 
-![img](./grafana/create_dashboard1.webp)
+![TDengine Database TDinsight plugin create dashboard 1](./grafana/create_dashboard1.webp)
 
 As shown above, select the `TDengine` data source in the `Query` and enter the corresponding SQL in the query box below for query.
 
-- INPUT SQL: enter the statement to be queried (the result set of the SQL statement should be two columns and multiple rows), for example: `select avg(mem_system) from log.dn where ts >= $from and ts < $to interval($interval)`, where, from, to and interval are built-in variables of the TDengine plugin, indicating the range and time interval of queries fetched from the Grafana plugin panel. In addition to the built-in variables, ` custom template variables are also supported.
+- INPUT SQL: enter the statement to be queried (the result set of the SQL statement should be two columns and multiple rows), for example: `select avg(mem_system) from log.dn where ts >= $from and ts < $to interval($interval)`, where, from, to and interval are built-in variables of the TDengine plugin, indicating the range and time interval of queries fetched from the Grafana plugin panel. In addition to the built-in variables, custom template variables are also supported.
 - ALIAS BY: This allows you to set the current query alias.
 - GENERATE SQL: Clicking this button will automatically replace the corresponding variables and generate the final executed statement.
 
 Follow the default prompt to query the average system memory usage for the specified interval on the server where the current TDengine deployment is located as follows.
 
-![img](./grafana/create_dashboard2.webp)
+![TDengine Database TDinsight plugin create dashboard 2](./grafana/create_dashboard2.webp)
 
 > For more information on how to use Grafana to create the appropriate monitoring interface and for more details on using Grafana, refer to the official Grafana [documentation](https://grafana.com/docs/).
 

docs-en/20-third-party/05-collectd.md

@@ -6,7 +6,7 @@ title: collectd writing
 import CollectD from "../14-reference/_collectd.mdx"
 
 
-collectd is a daemon used to collect system performance metric data. collectd provides various storage mechanisms to store different values. It periodically counts system performance statistics number while the system is running and storing information. You can use this information to help identify current system performance bottlenecks and predict future system load.
+collectd is a daemon used to collect system performance metric data. collectd provides various storage mechanisms to store different values. It periodically counts system performance statistics while the system is running and storing information. You can use this information to help identify current system performance bottlenecks and predict future system load.
 
 You can write the data collected by collectd to TDengine by simply modifying the configuration of collectd to the domain name (or IP address) and corresponding port of the server running taosAdapter. It can take full advantage of TDengine's efficient storage query performance and clustering capability for time-series data.
 

docs-en/20-third-party/09-emq-broker.md

@@ -3,7 +3,7 @@ sidebar_label: EMQX Broker
 title: EMQX Broker writing
 ---
 
-MQTT is a popular IoT data transfer protocol, [EMQX](https://github.com/emqx/emqx) is an open-source MQTT Broker software, without any code, only need to use "rules" in EMQX Dashboard to do simple configuration. You can write MQTT data directly to TDengine. EMQX supports saving data to TDengine by sending it to web services and provides a native TDengine driver for direct saving in the Enterprise Edition. Please refer to the [EMQX official documentation](https://www.emqx.io/docs/en/v4.4/rule/rule-engine.html) for details on how to use it. tdengine).
+MQTT is a popular IoT data transfer protocol, [EMQX](https://github.com/emqx/emqx) is an open-source MQTT Broker software, you can write MQTT data directly to TDengine without any code, you only need to use "rules" in EMQX Dashboard to create a simple configuration. EMQX supports saving data to TDengine by sending it to web services and provides a native TDengine driver for direct saving in the Enterprise Edition. Please refer to the [EMQX official documentation](https://www.emqx.io/docs/en/v4.4/rule/rule-engine.html) for details on how to use it.).
 
 ## Prerequisites
 
@@ -44,25 +44,25 @@ Since the configuration interface of EMQX differs from version to version, here
 
 Use your browser to open the URL `http://IP:18083` and log in to EMQX Dashboard. The initial installation username is `admin` and the password is: `public`.
 
-![img](./emqx/login-dashboard.webp)
+![TDengine Database EMQX login dashboard](./emqx/login-dashboard.webp)
 
 ### Creating Rule
 
 Select "Rule" in the "Rule Engine" on the left and click the "Create" button: !
 
-![img](./emqx/rule-engine.webp)
+![TDengine Database EMQX rule engine](./emqx/rule-engine.webp)
 
 ### Edit SQL fields
 
-![img](./emqx/create-rule.webp)
+![TDengine Database EMQX create rule](./emqx/create-rule.webp)
 
 ### Add "action handler"
 
-![img](./emqx/add-action-handler.webp)
+![TDengine Database EMQX add action handler](./emqx/add-action-handler.webp)
 
 ### Add "Resource"
 
-![img](./emqx/create-resource.webp)
+![TDengine Database EMQX create resource](./emqx/create-resource.webp)
 
 Select "Data to Web Service" and click the "New Resource" button.
 
@@ -70,13 +70,13 @@ Select "Data to Web Service" and click the "New Resource" button.
 
 Select "Data to Web Service" and fill in the request URL as the address and port of the server running taosAdapter (default is 6041). Leave the other properties at their default values.
 
-![img](./emqx/edit-resource.webp)
+![TDengine Database EMQX edit resource](./emqx/edit-resource.webp)
 
 ### Edit "action"
 
 Edit the resource configuration to add the key/value pairing for Authorization. Please refer to the [ TDengine REST API documentation ](https://docs.taosdata.com/reference/rest-api/) for the authorization in details. Enter the rule engine replacement template in the message body.
 
-![img](./emqx/edit-action.webp)
+![TDengine Database EMQX edit action](./emqx/edit-action.webp)
 
 ## Compose program to mock data
 
@@ -163,7 +163,7 @@ Edit the resource configuration to add the key/value pairing for Authorization.
 
 Note: `CLIENT_NUM` in the code can be set to a smaller value at the beginning of the test to avoid hardware performance be not capable to handle a more significant number of concurrent clients.
 
-![img](./emqx/client-num.webp)
+![TDengine Database EMQX client num](./emqx/client-num.webp)
 
 ## Execute tests to simulate sending MQTT data
 
@@ -172,19 +172,19 @@ npm install mqtt mockjs --save ---registry=https://registry.npm.taobao.org
 node mock.js
 ```
 
-![img](./emqx/run-mock.webp)
+![TDengine Database EMQX run mock](./emqx/run-mock.webp)
 
 ## Verify that EMQX is receiving data
 
 Refresh the EMQX Dashboard rules engine interface to see how many records were received correctly:
 
-![img](./emqx/check-rule-matched.webp)
+![TDengine Database EMQX rule matched](./emqx/check-rule-matched.webp)
 
 ## Verify that data writing to TDengine
 
 Use the TDengine CLI program to log in and query the appropriate databases and tables to verify that the data is being written to TDengine correctly:
 
-![img](./emqx/check-result-in-taos.webp)
+![TDengine Database EMQX result in taos](./emqx/check-result-in-taos.webp)
 
 Please refer to the [TDengine official documentation](https://docs.taosdata.com/) for more details on how to use TDengine.
 EMQX Please refer to the [EMQX official documentation](https://www.emqx.io/docs/en/v4.4/rule/rule-engine.html) for details on how to use EMQX.

docs-en/20-third-party/11-kafka.md

@@ -9,11 +9,11 @@ TDengine Kafka Connector contains two plugins: TDengine Source Connector and TDe
 
 Kafka Connect is a component of Apache Kafka that enables other systems, such as databases, cloud services, file systems, etc., to connect to Kafka easily. Data can flow from other software to Kafka via Kafka Connect and Kafka to other systems via Kafka Connect. Plugins that read data from other software are called Source Connectors, and plugins that write data to other software are called Sink Connectors. Neither Source Connector nor Sink Connector will directly connect to Kafka Broker, and Source Connector transfers data to Kafka Connect. Sink Connector receives data from Kafka Connect.
 
-![](kafka/Kafka_Connect.webp)
+![TDengine Database Kafka Connector -- Kafka Connect](kafka/Kafka_Connect.webp)
 
 TDengine Source Connector is used to read data from TDengine in real-time and send it to Kafka Connect. Users can use The TDengine Sink Connector to receive data from Kafka Connect and write it to TDengine.
 
-![](kafka/streaming-integration-with-kafka-connect.webp)
+![TDengine Database Kafka Connector -- streaming integration with kafka connect](kafka/streaming-integration-with-kafka-connect.webp)
 
 ## What is Confluent?
 
@@ -26,7 +26,7 @@ Confluent adds many extensions to Kafka. include:
 5. GUI for managing and monitoring Kafka - Confluent Control Center
 
 Some of these extensions are available in the community version of Confluent. Some are only available in the enterprise version.
-![](kafka/confluentPlatform.webp)
+![TDengine Database Kafka Connector -- Confluent platform](kafka/confluentPlatform.webp)
 
 Confluent Enterprise Edition provides the `confluent` command-line tool to manage various components.
 
@@ -228,7 +228,7 @@ taos> select * from meters;
 Query OK, 4 row(s) in set (0.004208s)
 ```
 
-If you see the above data, the synchronization is successful. If not, check the logs of Kafka Connect. For detailed description of configuration parameters, see [Configuration Reference](#Configuration Reference).
+If you see the above data, the synchronization is successful. If not, check the logs of Kafka Connect. For detailed description of configuration parameters, see [Configuration Reference](#configuration-reference).
 
 ## The use of TDengine Source Connector
 

docs-en/21-tdinternal/01-arch.md

@@ -11,7 +11,7 @@ The design of TDengine is based on the assumption that any hardware or software
 
 Logical structure diagram of TDengine distributed architecture as following:
 
-![TDengine architecture diagram](structure.webp)
+![TDengine Database architecture diagram](structure.webp)
 <center> Figure 1: TDengine architecture diagram </center>
 
 A complete TDengine system runs on one or more physical nodes. Logically, it includes data node (dnode), TDengine client driver (TAOSC) and application (app). There are one or more data nodes in the system, which form a cluster. The application interacts with the TDengine cluster through TAOSC's API. The following is a brief introduction to each logical unit.
@@ -54,7 +54,7 @@ A complete TDengine system runs on one or more physical nodes. Logically, it inc
 
 To explain the relationship between vnode, mnode, TAOSC and application and their respective roles, the following is an analysis of a typical data writing process.
 
-![typical process of TDengine](message.webp)
+![typical process of TDengine Database](message.webp)
 <center> Figure 2: Typical process of TDengine </center>
 
 1. Application initiates a request to insert data through JDBC, ODBC, or other APIs.
@@ -123,7 +123,7 @@ If a database has N replicas, thus a virtual node group has N virtual nodes, but
 
 Master Vnode uses a writing process as follows:
 
-![TDengine Master Writing Process](write_master.webp)
+![TDengine Database Master Writing Process](write_master.webp)
 <center> Figure 3: TDengine Master writing process </center>
 
 1. Master vnode receives the application data insertion request, verifies, and moves to next step;
@@ -137,7 +137,7 @@ Master Vnode uses a writing process as follows:
 
 For a slave vnode, the write process as follows:
 
-![TDengine Slave Writing Process](write_slave.webp)
+![TDengine Database Slave Writing Process](write_slave.webp)
 <center> Figure 4: TDengine Slave Writing Process </center>
 
 1. Slave vnode receives a data insertion request forwarded by Master vnode;
@@ -267,7 +267,7 @@ For the data collected by device D1001, the number of records per hour is counte
 
 TDengine creates a separate table for each data collection point, but in practical applications, it is often necessary to aggregate data from different data collection points. In order to perform aggregation operations efficiently, TDengine introduces the concept of STable. STable is used to represent a specific type of data collection point. It is a table set containing multiple tables. The schema of each table in the set is the same, but each table has its own static tag. The tags can be multiple and be added, deleted and modified at any time. Applications can aggregate or statistically operate all or a subset of tables under a STABLE by specifying tag filters, thus greatly simplifying the development of applications. The process is shown in the following figure:
 
-![Diagram of multi-table aggregation query](multi_tables.webp)
+![TDengine Database Diagram of multi-table aggregation query](multi_tables.webp)
 <center> Figure 5: Diagram of multi-table aggregation query </center>
 
 1. Application sends a query condition to system;

docs-en/25-application/01-telegraf.md

@@ -16,7 +16,7 @@ Current mainstream IT DevOps system usually include a data collection module, a
 
 This article introduces how to quickly build a TDengine + Telegraf + Grafana based IT DevOps visualization system without writing even a single line of code and by simply modifying a few lines of configuration files. The architecture is as follows.
 
-![IT-DevOps-Solutions-Telegraf.webp](./IT-DevOps-Solutions-Telegraf.webp)
+![TDengine Database IT-DevOps-Solutions-Telegraf](./IT-DevOps-Solutions-Telegraf.webp)
 
 ## Installation steps
 
@@ -73,9 +73,9 @@ sudo systemctl start telegraf
 
 Log in to the Grafana interface using a web browser at `IP:3000`, with the system's initial username and password being `admin/admin`.
 Click on the gear icon on the left and select `Plugins`, you should find the TDengine data source plugin icon.
-Click on the plus icon on the left and select `Import` to get the data from `https://github.com/taosdata/grafanaplugin/blob/master/examples/telegraf/grafana/dashboards/telegraf-dashboard- v0.1.0.json`, download the dashboard JSON file and import it. You will then see the dashboard in the following screen.
+Click on the plus icon on the left and select `Import` to get the data from `https://github.com/taosdata/grafanaplugin/blob/master/examples/telegraf/grafana/dashboards/telegraf-dashboard-v0.1.0.json`, download the dashboard JSON file and import it. You will then see the dashboard in the following screen.
 
-![IT-DevOps-Solutions-telegraf-dashboard.webp](./IT-DevOps-Solutions-telegraf-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-telegraf-dashboard](./IT-DevOps-Solutions-telegraf-dashboard.webp)
 
 ## Wrap-up
 

docs-en/25-application/02-collectd.md

@@ -17,7 +17,7 @@ The new version of TDengine supports multiple data protocols and can accept data
 
 This article introduces how to quickly build an IT DevOps visualization system based on TDengine + collectd / StatsD + Grafana without writing even a single line of code but by simply modifying a few lines of configuration files. The architecture is shown in the following figure.
 
-![IT-DevOps-Solutions-Collectd-StatsD.webp](./IT-DevOps-Solutions-Collectd-StatsD.webp)
+![TDengine Database IT-DevOps-Solutions-Collectd-StatsD](./IT-DevOps-Solutions-Collectd-StatsD.webp)
 
 ## Installation Steps
 
@@ -83,19 +83,19 @@ Click on the gear icon on the left and select `Plugins`, you should find the TDe
 Download the dashboard json from `https://github.com/taosdata/grafanaplugin/blob/master/examples/collectd/grafana/dashboards/collect-metrics-with-tdengine-v0.1.0.json`, click the plus icon on the left and select Import, follow the instructions to import the JSON file. After that, you can see
 The dashboard can be seen in the following screen.
 
-![IT-DevOps-Solutions-collectd-dashboard.webp](./IT-DevOps-Solutions-collectd-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-collectd-dashboard](./IT-DevOps-Solutions-collectd-dashboard.webp)
 
 #### import collectd dashboard
 
 Download the dashboard json file from `https://github.com/taosdata/grafanaplugin/blob/master/examples/collectd/grafana/dashboards/collect-metrics-with-tdengine-v0.1.0.json`. Download the dashboard json file, click the plus icon on the left side and select `Import`, and follow the interface prompts to select the JSON file to import. After that, you can see
 dashboard with the following interface.
 
-![IT-DevOps-Solutions-collectd-dashboard.webp](./IT-DevOps-Solutions-collectd-dashboard.webp)
+![IT-DevOps-Solutions-collectd-dashboard](./IT-DevOps-Solutions-collectd-dashboard.webp)
 
 #### Importing the StatsD dashboard
 
 Download the dashboard json from `https://github.com/taosdata/grafanaplugin/blob/master/examples/statsd/dashboards/statsd-with-tdengine-v0.1.0.json`. Click on the plus icon on the left and select `Import`, and follow the interface prompts to import the JSON file. You will then see the dashboard in the following screen.
-![IT-DevOps-Solutions-statsd-dashboard.webp](./IT-DevOps-Solutions-statsd-dashboard.webp)
+![TDengine Database IT-DevOps-Solutions-statsd-dashboard](./IT-DevOps-Solutions-statsd-dashboard.webp)
 
 ## Wrap-up
 

docs-en/25-application/03-immigrate.md

@@ -32,7 +32,7 @@ We will explain how to migrate OpenTSDB applications to TDengine quickly, secure
 The following figure (Figure 1) shows the system's overall architecture for a typical DevOps application scenario.
 
 **Figure 1. Typical architecture in a DevOps scenario**
-![IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch.webp "Figure 1. Typical architecture in a DevOps scenario")
+![TDengine Database IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Arch.webp "Figure 1. Typical architecture in a DevOps scenario")
 
 In this application scenario, there are Agent tools deployed in the application environment to collect machine metrics, network metrics, and application metrics. Data collectors to aggregate information collected by agents, systems for persistent data storage and management, and tools for monitoring data visualization (e.g., Grafana, etc.).
 
@@ -75,7 +75,7 @@ After writing the data to TDengine properly, you can adapt Grafana to visualize
 TDengine provides two sets of Dashboard templates by default, and users only need to import the templates from the Grafana directory into Grafana to activate their use.
 
 **Importing Grafana Templates** Figure 2.
-![](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard.webp "Figure 2. Importing a Grafana Template")
+![TDengine Database IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard](./IT-DevOps-Solutions-Immigrate-OpenTSDB-Dashboard.webp "Figure 2. Importing a Grafana Template")
 
 After the above steps, you completed the migration to replace OpenTSDB with TDengine. You can see that the whole process is straightforward, there is no need to write any code, and only some configuration files need to be adjusted to meet the migration work.
 
@@ -88,7 +88,7 @@ In most DevOps scenarios, if you have a small OpenTSDB cluster (3 or fewer nodes
 Suppose your application is particularly complex, or the application domain is not a DevOps scenario. You can continue reading subsequent chapters for a more comprehensive and in-depth look at the advanced topics of migrating an OpenTSDB application to TDengine.
 
 **Figure 3. System architecture after migration**
-![IT-DevOps-Solutions-Immigrate-TDengine-Arch](./IT-DevOps-Solutions-Immigrate-TDengine-Arch.webp "Figure 3. System architecture after migration completion")
+![TDengine Database IT-DevOps-Solutions-Immigrate-TDengine-Arch](./IT-DevOps-Solutions-Immigrate-TDengine-Arch.webp "Figure 3. System architecture after migration completion")
 
 ## Migration evaluation and strategy for other scenarios
 

docs-en/27-train-faq/03-docker.md

@@ -118,7 +118,7 @@ Output is like below:
 {"status":"succ","head":["name","created_time","ntables","vgroups","replica","quorum","days","keep0,keep1,keep(D)","cache(MB)","blocks","minrows","maxrows","wallevel","fsync","comp","cachelast","precision","update","status"],"column_meta":[["name",8,32],["created_time",9,8],["ntables",4,4],["vgroups",4,4],["replica",3,2],["quorum",3,2],["days",3,2],["keep0,keep1,keep(D)",8,24],["cache(MB)",4,4],["blocks",4,4],["minrows",4,4],["maxrows",4,4],["wallevel",2,1],["fsync",4,4],["comp",2,1],["cachelast",2,1],["precision",8,3],["update",2,1],["status",8,10]],"data":[["test","2021-08-18 06:01:11.021",10000,4,1,1,10,"3650,3650,3650",16,6,100,4096,1,3000,2,0,"ms",0,"ready"],["log","2021-08-18 05:51:51.065",4,1,1,1,10,"30,30,30",1,3,100,4096,1,3000,2,0,"us",0,"ready"]],"rows":2}
 ```
 
-For details of REST API please refer to [REST API]](/reference/rest-api/).
+For details of REST API please refer to [REST API](/reference/rest-api/).
 
 ### Run TDengine server and taosAdapter inside container
 
@@ -265,7 +265,7 @@ Below is an example output:
    $ taos> select groupid, location from test.d0;
       groupid   |     location     |
    =================================
-              0 | California.SanDieo         |
+              0 | California.SanDiego         |
    Query OK, 1 row(s) in set (0.003490s)
    ```
 

docs-examples/c/async_query_example.c

@@ -182,14 +182,14 @@ int main() {
 // query callback ...
 // ts current voltage phase location groupid
 // numOfRow = 8
-// 1538548685000 10.300000 219 0.310000 beijing.chaoyang 2
-// 1538548695000 12.600000 218 0.330000 beijing.chaoyang 2
-// 1538548696800 12.300000 221 0.310000 beijing.chaoyang 2
-// 1538548696650 10.300000 218 0.250000 beijing.chaoyang 3
-// 1538548685500 11.800000 221 0.280000 beijing.haidian 2
-// 1538548696600 13.400000 223 0.290000 beijing.haidian 2
-// 1538548685000 10.800000 223 0.290000 beijing.haidian 3
-// 1538548686500 11.500000 221 0.350000 beijing.haidian 3
+// 1538548685500 11.800000 221 0.280000 california.losangeles 2
+// 1538548696600 13.400000 223 0.290000 california.losangeles 2
+// 1538548685000 10.800000 223 0.290000 california.losangeles 3
+// 1538548686500 11.500000 221 0.350000 california.losangeles 3
+// 1538548685000 10.300000 219 0.310000 california.sanfrancisco 2
+// 1538548695000 12.600000 218 0.330000 california.sanfrancisco 2
+// 1538548696800 12.300000 221 0.310000 california.sanfrancisco 2
+// 1538548696650 10.300000 218 0.250000 california.sanfrancisco 3
 // numOfRow = 0
 // no more data, close the connection.
 // ANCHOR_END: demo
\ No newline at end of file

docs-examples/c/insert_example.c

@@ -36,10 +36,10 @@ int main() {
   executeSQL(taos, "CREATE DATABASE power");
   executeSQL(taos, "USE power");
   executeSQL(taos, "CREATE STABLE meters (ts TIMESTAMP, current FLOAT, voltage INT, phase FLOAT) TAGS (location BINARY(64), groupId INT)");
-  executeSQL(taos, "INSERT INTO d1001 USING meters TAGS(Beijing.Chaoyang, 2) VALUES ('2018-10-03 14:38:05.000', 10.30000, 219, 0.31000) ('2018-10-03 14:38:15.000', 12.60000, 218, 0.33000) ('2018-10-03 14:38:16.800', 12.30000, 221, 0.31000)"
-                "d1002 USING meters TAGS(Beijing.Chaoyang, 3) VALUES ('2018-10-03 14:38:16.650', 10.30000, 218, 0.25000)"
-                "d1003 USING meters TAGS(Beijing.Haidian, 2) VALUES ('2018-10-03 14:38:05.500', 11.80000, 221, 0.28000) ('2018-10-03 14:38:16.600', 13.40000, 223, 0.29000)"
-                "d1004 USING meters TAGS(Beijing.Haidian, 3) VALUES ('2018-10-03 14:38:05.000', 10.80000, 223, 0.29000) ('2018-10-03 14:38:06.500', 11.50000, 221, 0.35000)");
+  executeSQL(taos, "INSERT INTO d1001 USING meters TAGS(California.SanFrancisco, 2) VALUES ('2018-10-03 14:38:05.000', 10.30000, 219, 0.31000) ('2018-10-03 14:38:15.000', 12.60000, 218, 0.33000) ('2018-10-03 14:38:16.800', 12.30000, 221, 0.31000)"
+                "d1002 USING meters TAGS(California.SanFrancisco, 3) VALUES ('2018-10-03 14:38:16.650', 10.30000, 218, 0.25000)"
+                "d1003 USING meters TAGS(California.LosAngeles, 2) VALUES ('2018-10-03 14:38:05.500', 11.80000, 221, 0.28000) ('2018-10-03 14:38:16.600', 13.40000, 223, 0.29000)"
+                "d1004 USING meters TAGS(California.LosAngeles, 3) VALUES ('2018-10-03 14:38:05.000', 10.80000, 223, 0.29000) ('2018-10-03 14:38:06.500', 11.50000, 221, 0.35000)");
   taos_close(taos);
   taos_cleanup();
 }

docs-examples/c/json_protocol_example.c

@@ -29,11 +29,11 @@ int main() {
   executeSQL(taos, "USE test");
   char *line =
       "[{\"metric\": \"meters.current\", \"timestamp\": 1648432611249, \"value\": 10.3, \"tags\": {\"location\": "
-      "\"Beijing.Chaoyang\", \"groupid\": 2}},{\"metric\": \"meters.voltage\", \"timestamp\": 1648432611249, "
-      "\"value\": 219, \"tags\": {\"location\": \"Beijing.Haidian\", \"groupid\": 1}},{\"metric\": \"meters.current\", "
-      "\"timestamp\": 1648432611250, \"value\": 12.6, \"tags\": {\"location\": \"Beijing.Chaoyang\", \"groupid\": "
+      "\"California.SanFrancisco\", \"groupid\": 2}},{\"metric\": \"meters.voltage\", \"timestamp\": 1648432611249, "
+      "\"value\": 219, \"tags\": {\"location\": \"California.LosAngeles\", \"groupid\": 1}},{\"metric\": \"meters.current\", "
+      "\"timestamp\": 1648432611250, \"value\": 12.6, \"tags\": {\"location\": \"California.SanFrancisco\", \"groupid\": "
       "2}},{\"metric\": \"meters.voltage\", \"timestamp\": 1648432611250, \"value\": 221, \"tags\": {\"location\": "
-      "\"Beijing.Haidian\", \"groupid\": 1}}]";
+      "\"California.LosAngeles\", \"groupid\": 1}}]";
 
   char     *lines[] = {line};
   TAOS_RES *res = taos_schemaless_insert(taos, lines, 1, TSDB_SML_JSON_PROTOCOL, TSDB_SML_TIMESTAMP_NOT_CONFIGURED);

docs-examples/c/line_example.c

@@ -27,10 +27,10 @@ int main() {
   executeSQL(taos, "DROP DATABASE IF EXISTS test");
   executeSQL(taos, "CREATE DATABASE test");
   executeSQL(taos, "USE test");
-  char     *lines[] = {"meters,location=Beijing.Haidian,groupid=2 current=11.8,voltage=221,phase=0.28 1648432611249",
-                   "meters,location=Beijing.Haidian,groupid=2 current=13.4,voltage=223,phase=0.29 1648432611250",
-                   "meters,location=Beijing.Haidian,groupid=3 current=10.8,voltage=223,phase=0.29 1648432611249",
-                   "meters,location=Beijing.Haidian,groupid=3 current=11.3,voltage=221,phase=0.35 1648432611250"};
+  char     *lines[] = {"meters,location=California.LosAngeles,groupid=2 current=11.8,voltage=221,phase=0.28 1648432611249",
+                   "meters,location=California.LosAngeles,groupid=2 current=13.4,voltage=223,phase=0.29 1648432611250",
+                   "meters,location=California.LosAngeles,groupid=3 current=10.8,voltage=223,phase=0.29 1648432611249",
+                   "meters,location=California.LosAngeles,groupid=3 current=11.3,voltage=221,phase=0.35 1648432611250"};
   TAOS_RES *res = taos_schemaless_insert(taos, lines, 4, TSDB_SML_LINE_PROTOCOL, TSDB_SML_TIMESTAMP_MILLI_SECONDS);
   if (taos_errno(res) != 0) {
     printf("failed to insert schema-less data, reason: %s\n", taos_errstr(res));

docs-examples/c/multi_bind_example.c

@@ -52,7 +52,7 @@ void insertData(TAOS *taos) {
   checkErrorCode(stmt, code, "failed to execute taos_stmt_prepare");
   // bind table name and tags
   TAOS_BIND tags[2];
-  char     *location = "Beijing.Chaoyang";
+  char     *location = "California.SanFrancisco";
   int       groupId = 2;
   tags[0].buffer_type = TSDB_DATA_TYPE_BINARY;
   tags[0].buffer_length = strlen(location);

docs-examples/c/query_example.c

@@ -139,5 +139,5 @@ int main() {
 
 // output:
 // ts current voltage phase location groupid 
-// 1648432611249 10.300000 219 0.310000 Beijing.Chaoyang 2
-// 1648432611749 12.600000 218 0.330000 Beijing.Chaoyang 2
\ No newline at end of file
+// 1648432611249 10.300000 219 0.310000 California.SanFrancisco 2
+// 1648432611749 12.600000 218 0.330000 California.SanFrancisco 2
\ No newline at end of file