Minorfixes

docs/content/preview/drivers-orms/go/pg.md

@@ -84,7 +84,7 @@ db := pg.Connect(opt)
 
 #### Use SSL
 
-For a YugabyteDB Aeon cluster, or a YugabyteDB cluster with SSL/TLS enabled, set the following SSL-related environment variables at the client side. SSL/TLS is enabled by default for client-side authentication. Refer to [Configure SSL/TLS](yb-pgx-reference/#configure-ssl-tls) for the default and supported modes.
+For a YugabyteDB Aeon cluster, or a YugabyteDB cluster with SSL/TLS enabled, set the following SSL-related environment variables at the client side. SSL/TLS is enabled by default for client-side authentication. Refer to [Configure SSL/TLS](../yb-pgx-reference/#configure-ssl-tls) for the default and supported modes.
 
 ```sh
 $ export PGSSLMODE=verify-ca

docs/content/preview/drivers-orms/orms/rust/ysql-diesel.md

@@ -45,7 +45,7 @@ Build the REST API server (written using Diesel and Rocket) as follows:
 $ cargo build --release
 ```
 
-If you encounter a build failure, install [libpq](../../ysql-client-drivers/#libpq) and try again.
+If you encounter a build failure, install [libpq](../../../ysql-client-drivers/#libpq) and try again.
 
 ## Set up the database connection
 

docs/content/preview/faq/general.md

@@ -97,19 +97,19 @@ Ensuring [ACID](../../architecture/key-concepts/#acid) transactions and full com
 
 - **Consistency vs. Latency**: YugabyteDB uses the [Raft](../../architecture/docdb-replication/raft) consensus algorithm for strong consistency in distributed systems. While this guarantees data integrity, it can result in higher write latency compared to eventually consistent databases like Cassandra.
 
-- **Increased Query Latency**: Transactions and JOINs that span multiple nodes experience inter-node latency, making queries slower than in single-node databases like PostgreSQL.
+- **Data Distribution vs Query Latency**: Transactions and JOINs that span multiple nodes experience inter-node latency, making queries slower than in single-node databases like PostgreSQL.
 
   {{<note>}}
   [Many projects](https://github.com/yugabyte/yugabyte-db?tab=readme-ov-file#current-roadmap) are currently in progress to match the performance of a single-node database.
   {{</note>}}
 
-- **Cross-Region Latency**: In multi-region or globally distributed setups, YugabyteDB replicates data across regions to ensure availability and resilience. However, this can lead to higher write latency due to cross-region coordination.
+- **Multi-Region vs Latency**: In multi-region or globally distributed setups, YugabyteDB replicates data across regions to ensure availability and resilience. However, this can lead to higher write latency due to cross-region coordination.
 
-- **Resource Requirements**: Being a distributed database, YugabyteDB demands more hardware and networking resources to maintain high availability and fault tolerance compared to traditional monolithic databases that run on a single machine.
+- **Availability vs Resource Requirements**: Being a distributed database, YugabyteDB demands more hardware and networking resources to maintain high availability and fault tolerance compared to traditional monolithic databases that run on a single machine.
 
 - **PostgreSQL Feature Support**: Every new PostgreSQL feature must be optimized for distributed environments, which is not a simple task. Be sure to verify that the PostgreSQL features your application relies on are supported in the current version of YugabyteDB.
 
-{{<link dest="/preview/explore/ysql-language-features/postgresql-compatibility/#unsupported-postgresql-features" text="PostgreSQL compatibility" icon-before="true">}}
+    {{<link dest="/preview/explore/ysql-language-features/postgresql-compatibility/#unsupported-postgresql-features" text="PostgreSQL compatibility" icon-before="true">}}
 
 ### What is a YugabyteDB universe
 

docs/content/preview/manage/data-migration/migrate-from-postgres.md

@@ -225,7 +225,7 @@ Regardless of how much data you decide to migrate, you can choose from the follo
 For more details, see [Offline migration](/preview/yugabyte-voyager/migrate/migrate-steps/).
 {{</lead>}}
 
-**Live migration**: Live migration aims to minimize downtime by keeping the application running during the migration process. Data is copied from the source database to the target database while the application is still live, and a final switchover is made after the migration is complete.
+**Live migration**: Live migration aims to minimize downtime by keeping the application running during the migration process. Data is copied from the source database to the new YugabyteDB cluster while the application is still live, and a final switchover is made after the migration is complete.
 
 {{<lead link="/preview/yugabyte-voyager/migrate/live-migrate/">}}
 For more details, see [Live migration](/preview/yugabyte-voyager/migrate/live-migrate/).
@@ -237,7 +237,7 @@ For more details, see [Live migration](/preview/yugabyte-voyager/migrate/live-mi
 For more details, see [Live migration with fall-forward](/preview/yugabyte-voyager/migrate/live-fall-forward/).
 {{</lead>}}
 
-**Live migration with fall-back**: Live migration with fall-back provides a safety net by allowing a return to the original database if issues are encountered after the cutover to the new database. This strategy involves maintaining bidirectional synchronization between the source and target databases for a period after the migration.
+**Live migration with fall-back**: Live migration with fall-back provides a safety net by allowing a return to the original database if issues are encountered after the cutover to the new database. This strategy involves maintaining bidirectional synchronization between the source database and the new YugabyteDB cluster for a period after the migration.
 
 {{<lead link="">}}
 For more details, see [Live migration with fall-back](/preview/yugabyte-voyager/migrate/live-fall-back/).
@@ -294,7 +294,7 @@ For more information, see [Verify migration](../verify-migration-ysql/).
 
 ### Monitoring
 
-Regularly monitor the target database to ensure it is performing efficiently. This includes tracking metrics such as query execution times, CPU usage, memory consumption, and disk I/O. Pay close attention to any errors or warnings that arise, as they can indicate potential issues with the database configuration, queries, or underlying infrastructure.
+Regularly monitor the new YugabyteDB cluster to ensure it is performing efficiently. This includes tracking metrics such as query execution times, CPU usage, memory consumption, and disk I/O. Pay close attention to any errors or warnings that arise, as they can indicate potential issues with the database configuration, queries, or underlying infrastructure.
 
 {{<lead link="../../../launch-and-manage/monitor-and-alert/metrics/">}}
 To learn more about the various useful metrics that can be monitored, see [Metrics](../../../launch-and-manage/monitor-and-alert/metrics/).
@@ -327,7 +327,7 @@ To understand the various schemes of backup, see [Backup and restore](../../back
 
 ### Decommissioning
 
-Before proceeding with decommissioning, thoroughly verify the stability and reliability of the target database. Ensure that it is functioning as expected, with no critical errors, performance issues, or compatibility problems. Once confident in the stability of the target database and after securing necessary backups, proceed with decommissioning the source database. This involves shutting down the source system and ensuring that it is no longer accessible to users or applications.
+Before proceeding with decommissioning, thoroughly verify the stability and reliability of the new YugabyteDB cluster. Ensure that it is functioning as expected, with no critical errors, performance issues, or compatibility problems. Once confident in the stability of the new YugabyteDB cluster and after securing necessary backups, proceed with decommissioning the source database. This involves shutting down the source system and ensuring that it is no longer accessible to users or applications.
 
 ## Learn more
 

docs/content/preview/quick-start-yugabytedb-managed/quick-start-buildapps-include.md

@@ -605,7 +605,7 @@ You have successfully executed a basic Ruby application that works with Yugabyte
 
   {{% tab header="Rust" lang="rust" %}}
 
-The [Rust application](https://github.com/yugabyte/yugabyte-simple-rust-app) connects to a YugabyteDB cluster using the [Rust-Postgres driver](/preview/drivers-orms/yb-rust-postgres/) and performs basic SQL operations. Use the application as a template to get started with YugabyteDB in Rust.
+The [Rust application](https://github.com/yugabyte/yugabyte-simple-rust-app) connects to a YugabyteDB cluster using the [Rust-Postgres driver](/preview/drivers-orms/rust/yb-rust-postgres/) and performs basic SQL operations. Use the application as a template to get started with YugabyteDB in Rust.
 
 The application requires the following:
 

docs/content/preview/yugabyte-platform/prepare/server-nodes-software/_index.md

@@ -22,7 +22,7 @@ Depending on the [provider type](../../yba-overview/#provider-configurations) an
 {{< warning title="Using disk encryption software with YugabyteDB" >}}
 If you are using third party disk encryption software, such as Vormetric or CipherTrust, the disk encryption service must be up and running on the node before starting any YugabyteDB services. If YugabyteDB processes start _before_ the encryption service, restarting an already encrypted node can result in data corruption.
 
-To avoid problems, [pause the universe](../../../manage-deployments/delete-universe/#pause-a-universe) _before_ enabling or disabling the disk encryption service on universe nodes.
+To avoid problems, [pause the universe](../../manage-deployments/delete-universe/#pause-a-universe) _before_ enabling or disabling the disk encryption service on universe nodes.
 {{< /warning >}}
 
 ##### Linux OS