Change ordinal numbers to numbers or spell-out format (pingcap#4474)

* spell out ordinal numbers and unify the date format * Apply suggestions from code review Co-authored-by: Lilian Lee <lilin@pingcap.com> * Update link format Co-authored-by: Lilian Lee <lilin@pingcap.com>
Frank945946 · Dec 24, 2020 · 1ad9ca1 · 1ad9ca1
1 parent c905a3a
commit 1ad9ca1
Show file tree

Hide file tree

Showing 7 changed files with 10 additions and 10 deletions.
diff --git a/alert-rules.md b/alert-rules.md
@@ -121,7 +121,7 @@ Warning-level alerts are a reminder for an issue or error.
 
 * Description:
 
-    The latency of handling a request in TiDB. If the 99th percentile latency exceeds 1 second, an alert is triggered.
+    The latency of handling a request in TiDB. If the ninety-ninth percentile latency exceeds 1 second, an alert is triggered.
 
 * Solution:
 

diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md
@@ -141,10 +141,10 @@ Restart MySQL client and execute the following SQL statement to create a databas
 create database sbtest;
 ```
 
-Adjust the order in which Sysbench scripts create indexes. Sysbench imports data in the order of "Build Table -> Insert Data -> Create Index", which takes more time for TiDB to import data. Users can adjust the order to speed up the import of data. Suppose that you use Sysbench version <https://github.com/akopytov/sysbench/tree/1.0.14>. You can adjust the order in the following two ways.
+Adjust the order in which Sysbench scripts create indexes. Sysbench imports data in the order of "Build Table -> Insert Data -> Create Index", which takes more time for TiDB to import data. Users can adjust the order to speed up the import of data. Suppose that you use the Sysbench version [1.0.14](https://github.com/akopytov/sysbench/tree/1.0.14). You can adjust the order in either of the following two ways:
 
-1. Download the TiDB-modified [oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua) file and overwrite the `/usr/share/sysbench/oltp_common.lua` file with it.
-2. Move the [235th](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L235) to [240th](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L240) lines of `/usr/share/sysbench/oltp_common.lua` to be right behind 198th lines.
+- Download the modified [oltp_common.lua](https://raw.githubusercontent.com/pingcap/tidb-bench/master/sysbench/sysbench-patch/oltp_common.lua) file for TiDB and overwrite the `/usr/share/sysbench/oltp_common.lua` file with it.
+- In `/usr/share/sysbench/oltp_common.lua`, move the lines [235](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L235)-[240](https://github.com/akopytov/sysbench/blob/1.0.14/src/lua/oltp_common.lua#L240) to be right behind the line 198.
 
 > **Note:**
 >

diff --git a/explain-walkthrough.md b/explain-walkthrough.md
@@ -7,7 +7,7 @@ summary: Learn how to use EXPLAIN by walking through an example statement
 
 Because SQL is a declarative language, you cannot automatically tell whether a query is executed efficiently. You must first use the [`EXPLAIN`](/sql-statements/sql-statement-explain.md) statement to learn the current execution plan.
 
-The following statement from the [bikeshare example database](/import-example-data.md) counts how many trips were taken on the 1st July 2017:
+The following statement from the [bikeshare example database](/import-example-data.md) counts how many trips were taken on the July 1, 2017:
 
 {{< copyable "sql" >}}
 

diff --git a/functions-and-operators/aggregate-group-by-functions.md b/functions-and-operators/aggregate-group-by-functions.md
@@ -38,7 +38,7 @@ In addition, TiDB also provides the following aggregate functions:
 
     This function only supports the [numeric type](/data-type-numeric.md) and the [date and time type](/data-type-date-and-time.md) as the returned type of `expr`. For other returned types, `APPROX_PERCENTILE` only returns `NULL`.
 
-    The following example shows how to calculate the 50th percentile of a `INT` column:
+    The following example shows how to calculate the fiftieth percentile of a `INT` column:
 
     {{< copyable "sql" >}}
 

diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
@@ -489,7 +489,7 @@ Check the specific cause for busy by viewing the monitor **Grafana** -> **TiKV**
     - Check the position information recorded in `relay.meta`.
 
         - `relay.meta` has recorded the empty GTID information. DM-worker saves the GTID information in memory to `relay.meta` when it exits or in every 30s. When DM-worker does not obtain the upstream GTID information, it saves the empty GTID information to `relay.meta`. See [case-772](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case772.md) in Chinese.
-    
+
         - The binlog event recorded in `relay.meta` triggers the incomplete recover process and records the wrong GTID information. This issue is fixed in v1.0.2, and might occur in earlier versions. <!--See [case-764](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case764.md).-->
 
 - 6.2.7 The DM replication process returns an error `Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`.
@@ -543,7 +543,7 @@ Check the specific cause for busy by viewing the monitor **Grafana** -> **TiKV**
 
 - 6.3.7 `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'`
 
-    - Cause: A timestamp type entry has a time value that does not exist. This is either because of DST changes or because the time value has exceeded the supported range (from Jan 1st 1970 to Jan 19th 2038).
+    - Cause: A timestamp type entry has a time value that does not exist. This is either because of DST changes or because the time value has exceeded the supported range (from Jan 1, 1970 to Jan 19, 2038).
 
     - Solution: See [Troubleshooting Solution](/troubleshoot-tidb-lightning.md#sql2kv-sql-encode-error--types1292invalid-time-format-1970-1-1-).
 

diff --git a/troubleshoot-tidb-lightning.md b/troubleshoot-tidb-lightning.md
@@ -116,7 +116,7 @@ See the [Checkpoints control](/tidb-lightning/tidb-lightning-checkpoints.md#chec
 
 ## [sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}'
 
-**Cause**: A table contains a column with the `timestamp` type, but the time value itself does not exist. This is either because of DST changes or the time value has exceeded the supported range (1970 Jan 1st to 2038 Jan 19th).
+**Cause**: A table contains a column with the `timestamp` type, but the time value itself does not exist. This is either because of DST changes or the time value has exceeded the supported range (Jan 1, 1970 to Jan 19, 2038).
 
 **Solutions**:
 

diff --git a/whats-new-in-tidb-4.0.md b/whats-new-in-tidb-4.0.md
@@ -6,7 +6,7 @@ aliases: ['/docs/dev/whats-new-in-tidb-4.0/']
 
 # What’s New in TiDB 4.0
 
-TiDB v4.0 was officially released on May 28th, 2020. In this release, we have made great improvements in stability, usability, performance, security, and features. This document briefly introduces the most notable improvements for you. You can decide whether to upgrade to v4.0 based on your needs. For the complete list of new features and bug fixes, you can check our [earlier v4.0 release notes](/releases/release-notes.md#40).
+TiDB v4.0 was officially released on May 28, 2020. In this release, we have made great improvements in stability, usability, performance, security, and features. This document briefly introduces the most notable improvements for you. You can decide whether to upgrade to v4.0 based on your needs. For the complete list of new features and bug fixes, you can check our [earlier v4.0 release notes](/releases/release-notes.md#40).
 
 ## Scheduling