fix:Renaming of userguide titles in V23

Signed-off-by: Dindihub <[email protected]>

Author: Dindihub

content/en/docs/23.0/user-guides/configuration-basic/add-delete-cell.md

@@ -1,9 +1,9 @@
 ---
-title: Add or Delete a Cell
+title: Adding or Deleting a Cell
 weight: 15
 ---
 
-## Add
+## Adding a Cell
 To add a cell after a cluster is up and running, you start off by creating one using the same steps previously performed to create the first cell:
 
 ```sh
@@ -31,7 +31,7 @@ If the `cells` option is not specified, the rebuild deploys to all cells.
 
 Once these steps are done, you can bring up the necessary MySQLs, vttablets and vtgates under that cell.
 
-## Delete
+## Deleting a Cell
 
 To delete a cell, bring down all servers in that cell, and then remove its entry from the global topo with:
 

content/en/docs/23.0/user-guides/configuration-basic/delete-keyspace.md

@@ -1,5 +1,5 @@
 ---
-title: Delete a Keyspace
+title: Deleting a Keyspace
 weight: 14
 ---
 

content/en/docs/23.0/user-guides/configuration-basic/exporting-data.md

@@ -21,7 +21,7 @@ to the database.  As a result, you will only be guaranteed to get a 100%
 consistent dump using these tools if you are sure that you are not writing
 to the database while running the dump.
 
-### mysqldump
+## mysqldump
 
 The default invocation of `mysqldump` attempts to execute statements which are [not supported by Vitess](../../../reference/compatibility/mysql-compatibility/), such as attempting to lock tables and dump GTID coordinates. The following options are required when using the `mysqldump` binary from MySQL 5.7 to export data from the `commerce` keyspace:
 

content/en/docs/23.0/user-guides/configuration-basic/global-topo.md

@@ -1,5 +1,5 @@
 ---
-title: Global TopoServer
+title: Configuring a Global TopoServer
 weight: 4
 aliases: ['/docs/user-guide/topology-service/']
 ---
@@ -36,15 +36,15 @@ Note that the topo implementation for etcd is `etcd2`. This is because Vitess us
 To be safe, you may want to bring up etcd with `--enable-v2=true`, even though it is the default value. Also, you will need to set the `ETCDCTL_API=2` environment variable before bringing up etcd.
 {{< /info >}}
 
-## Moving to a different TopoServer
+## Moving TopoServers
 
 It is generally not recommended that you migrate from one type of toposerver to another. However, if absolutely necessary, you can use the [topo2topo](../../../reference/features/topology-service/#migration-between-implementations) command line tool to perform this migration.
 
-## Backups
+## Backing up TopoServer Data
 
 It is important to periodically backup the data in the TopoServer. Although most of the information in the TopoServer can be manually reconstructed, it is still a painful task. This can be avoided if a recent backup was readily available.
 
-## Checklist
+## Checklist for TopoSever setup
 
 * Ensure toposerver is up, and that you can set and get values using their provided client tools.
 * Ensure you have the mechanism to include the correct topo flags for all the components: `--topo_implementation`, `--topo_global_server_address` and `--topo_global_root`.

content/en/docs/23.0/user-guides/configuration-basic/initialize-shard-primary.md

@@ -1,5 +1,5 @@
 ---
-title: Initialize Shard Primary
+title: Initializing Shard Primary
 weight: 9
 ---
 

content/en/docs/23.0/user-guides/configuration-basic/keyspaces-shards.md

@@ -1,5 +1,5 @@
 ---
-title: Keyspaces and Shards
+title: Creating Keyspaces and Shards
 weight: 7
 ---
 

content/en/docs/23.0/user-guides/configuration-basic/monitoring.md

@@ -1,12 +1,12 @@
 ---
-title: Monitoring
+title: Monitoring Vitess Components
 weight: 16
 aliases: ['/docs/launching/server-configuration/', '/docs/user-guides/server-configuration/', '/docs/user-guides/configuring-components/']
 ---
 
 This section describes how to monitor Vitess components. Additionally, we recommend that you also add the necessary monitoring and alerting for the TopoServers as well as the MySQL instances running with each vttablet.
 
-## Tools
+## Monitoring Tools
 
 Vitess provides integrations with a variety of popular monitoring tools: Prometheus, InfluxDB and Datadog. The core infrastructure uses go's `expvar` package to export real-time variables visible as a JSON object served by the `/debug/vars` URL. The exported variables are CamelCase names. These names are algorithmically converted to the appropriate naming standards for each monitoring tool. For example, Prometheus uses a [snake case conversion algorithm](https://github.com/vitessio/vitess/blob/e259a08f017d9f1b5984fcaac5c54e26d1c7c31d/go/stats/prometheusbackend/prometheusbackend.go#L95-L116). In this case, the Prometheus exporter would convert the `Queries.Histograms.Select.500000` variable to `vttablet_queries_bucket{plan_type="Select",le="0.0005"}`.
 

content/en/docs/23.0/user-guides/configuration-basic/planning.md

@@ -1,5 +1,5 @@
 ---
-title: Planning
+title: Setting up and Managing a Vitess Cluster
 weight: 3
 aliases: ['/docs/user-guides/configuration-basic/configuring-components/'] 
 ---

content/en/docs/23.0/user-guides/configuration-basic/ports.md

@@ -1,9 +1,8 @@
 ---
-title: Ports
+title: Ports and Network interactions in Vitess
 weight: 16
 aliases: ['/docs/launching/server-configuration/', '/docs/user-guides/server-configuration/', '/docs/user-guides/configuring-components/']
 ---
-# Ports and Network interactions in Vitess
 
 Many/most of these ports are fully configurable, but we are listing their
 defaults or the defaults we use in examples here. Your