AUTO: Sync ScalarDB docs in English to docs site repo

Author: josh-wong

versioned_docs/version-3.11/add-scalardb-to-your-build.mdx

@@ -9,7 +9,7 @@ The ScalarDB library is available on the [Maven Central Repository](https://mvnr
 
 Select your build tool, and follow the instructions to add the build dependency for ScalarDB to your application.
 
-<Tabs groupId="build_dependency" queryString>
+<Tabs groupId="build_tools" queryString>
   <TabItem value="Gradle" label="Gradle" default>
     To add the build dependency for ScalarDB by using Gradle, add the following to `build.gradle` in your application, replacing `<VERSION>` with the version of ScalarDB that you want to use:
 

versioned_docs/version-3.11/api-guide.mdx

@@ -60,18 +60,8 @@ In the creation operations, like creating a namespace and creating a table, you
 Select your database to see the options available:
 
 <Tabs groupId="databases" queryString>
-  <TabItem value="Cassandra" label="Cassandra" default>
-    | Name                 | Description                                                                            | Default          |
-    |----------------------|----------------------------------------------------------------------------------------|------------------|
-    | replication-strategy | Cassandra replication strategy. Must be `SimpleStrategy` or `NetworkTopologyStrategy`. | `SimpleStrategy` |
-    | compaction-strategy  | Cassandra compaction strategy, Must be `LCS`, `STCS` or `TWCS`.                        | `STCS`           |
-    | replication-factor   | Cassandra replication factor.                                                          | 1                |
-  </TabItem>
-  <TabItem value="Cosmos_DB_for_NoSQL" label="Cosmos DB for NoSQL">
-    | Name       | Description                                         | Default |
-    |------------|-----------------------------------------------------|---------|
-    | ru         | Base resource unit.                                 | 400     |
-    | no-scaling | Disable auto-scaling for Cosmos DB for NoSQL.       | false   |
+  <TabItem value="JDBC_databases" label="JDBC databases" default>
+    No options are available for JDBC databases.
   </TabItem>
   <TabItem value="DynamoDB" label="DynamoDB">
     | Name       | Description                             | Default |
@@ -80,8 +70,18 @@ Select your database to see the options available:
     | no-backup  | Disable continuous backup for DynamoDB. | false   |
     | ru         | Base resource unit.                     | 10      |
   </TabItem>
-  <TabItem value="JDBC_databases" label="JDBC_databases">
-    No options are available for JDBC databases.
+  <TabItem value="Cosmos_DB_for_NoSQL" label="Cosmos DB for NoSQL">
+    | Name       | Description                                         | Default |
+    |------------|-----------------------------------------------------|---------|
+    | ru         | Base resource unit.                                 | 400     |
+    | no-scaling | Disable auto-scaling for Cosmos DB for NoSQL.       | false   |
+  </TabItem>
+  <TabItem value="Cassandra" label="Cassandra">
+    | Name                 | Description                                                                            | Default          |
+    |----------------------|----------------------------------------------------------------------------------------|------------------|
+    | replication-strategy | Cassandra replication strategy. Must be `SimpleStrategy` or `NetworkTopologyStrategy`. | `SimpleStrategy` |
+    | compaction-strategy  | Cassandra compaction strategy, Must be `LCS`, `STCS` or `TWCS`.                        | `STCS`           |
+    | replication-factor   | Cassandra replication factor.                                                          | 1                |
   </TabItem>
 </Tabs>
 
@@ -298,6 +298,7 @@ admin.importTable("ns", "tbl", options);
 
 You should carefully plan to import a table to ScalarDB in production because it will add transaction metadata columns to your database tables and the ScalarDB metadata tables. In this case, there would also be several differences between your database and ScalarDB, as well as some limitations. For details, see [Importing Existing Tables to ScalarDB by Using ScalarDB Schema Loader](./schema-loader-import.mdx).
 
+
 :::
 
 ## Transactional API

versioned_docs/version-3.11/backup-restore.mdx

@@ -40,7 +40,7 @@ The backup methods by database listed below are just examples of some of the dat
 
 :::
 
-<Tabs groupId="database" queryString>
+<Tabs groupId="databases" queryString>
   <TabItem value="Amazon_RDS_or_Azure_Database_for_MySQL_or_PostgreSQL" label="Amazon RDS or Azure Database for MySQL or PostgreSQL" default>
     You can restore to any point within the backup retention period by using the automated backup feature.
   </TabItem>
@@ -85,22 +85,22 @@ The backup methods by database listed below are just examples of some of the dat
 :::
 
 <Tabs groupId="databases" queryString>
-  <TabItem value="Cassandra" label="Cassandra" default>
-    Cassandra has a built-in replication feature, so you do not always have to create a transactionally consistent backup. For example, if the replication factor is set to `3` and only the data of one of the nodes in a Cassandra cluster is lost, you won't need a transactionally consistent backup (snapshot) because the node can be recovered by using a normal, transactionally inconsistent backup (snapshot) and the repair feature.
-
-    However, if the quorum of cluster nodes loses their data, you will need a transactionally consistent backup (snapshot) to restore the cluster to a certain transactionally consistent point.
+  <TabItem value="DynamoDB" label="DynamoDB" default>
+    You must enable the PITR feature for DynamoDB tables. If you're using [ScalarDB Schema Loader](schema-loader.mdx) to create schemas, the tool enables the PITR feature for tables by default.
 
-    To create a transactionally consistent cluster-wide backup (snapshot), pause the application that is using ScalarDB or [ScalarDB Cluster (redirects to the Enterprise docs site)](https://scalardb.scalar-labs.com/docs/latest/scalardb-cluster/) and create backups (snapshots) of the nodes as described in [Back up with explicit pausing](#back-up-with-explicit-pausing) or stop the Cassandra cluster, take copies of all the data in the nodes, and start the cluster.
+    To specify a transactionally consistent restore point, pause your application that is using ScalarDB with DynamoDB as described in [Back up with explicit pausing](#back-up-with-explicit-pausing).
   </TabItem>
   <TabItem value="Cosmos_DB_for_NoSQL" label="Cosmos DB for NoSQL">
     You must create a Cosmos DB for NoSQL account with a continuous backup policy that has the PITR feature enabled. After enabling the feature, backups are created continuously.
 
     To specify a transactionally consistent restore point, pause your application that is using ScalarDB with Cosmos DB for NoSQL as described in [Back up with explicit pausing](#back-up-with-explicit-pausing).
   </TabItem>
-  <TabItem value="DynamoDB" label="DynamoDB">
-    You must enable the PITR feature for DynamoDB tables. If you're using [ScalarDB Schema Loader](schema-loader.mdx) to create schemas, the tool enables the PITR feature for tables by default.
+  <TabItem value="Cassandra" label="Cassandra">
+    Cassandra has a built-in replication feature, so you do not always have to create a transactionally consistent backup. For example, if the replication factor is set to `3` and only the data of one of the nodes in a Cassandra cluster is lost, you won't need a transactionally consistent backup (snapshot) because the node can be recovered by using a normal, transactionally inconsistent backup (snapshot) and the repair feature.
 
-    To specify a transactionally consistent restore point, pause your application that is using ScalarDB with DynamoDB as described in [Back up with explicit pausing](#back-up-with-explicit-pausing).
+    However, if the quorum of cluster nodes loses their data, you will need a transactionally consistent backup (snapshot) to restore the cluster to a certain transactionally consistent point.
+
+    To create a transactionally consistent cluster-wide backup (snapshot), pause the application that is using ScalarDB or [ScalarDB Cluster (redirects to the Enterprise docs site)](https://scalardb.scalar-labs.com/docs/latest/scalardb-cluster/) and create backups (snapshots) of the nodes as described in [Back up with explicit pausing](#back-up-with-explicit-pausing) or stop the Cassandra cluster, take copies of all the data in the nodes, and start the cluster.
   </TabItem>
 </Tabs>