diff --git a/content/en/administration/data/bucket/creation.md b/content/en/administration/data/bucket/creation.md
index 46804ffcf..97caf8b40 100644
--- a/content/en/administration/data/bucket/creation.md
+++ b/content/en/administration/data/bucket/creation.md
@@ -1,5 +1,5 @@
 ---
-title: "RustFS Bucket Creation"
+title: "Create a Bucket"
 description: "Create buckets using the RustFS UI, rc, or the S3 API."
 ---
 
@@ -10,11 +10,11 @@ This guide explains how to create buckets using the RustFS UI, `rc`, or the S3 A
 - A running RustFS instance (see [Installation Guide](../../../installation/index.md)).
 - [`rc`](/operations/rc) installed and configured with an alias for the command-line workflow.
 
-## Using the RustFS UI
+## Use the RustFS Console
 
 1. Log in to the RustFS Console.
 2. On the Buckets page, in the top right corner, select **Create Bucket**.
-3. Enter the bucket name and click **Create** to complete bucket creation.
+3. Enter a bucket name and select **Create**.
 
 ![bucket creation](images/bucket-creation-by-ui.png)
 
@@ -49,4 +49,4 @@ aws s3api create-bucket \
   --endpoint-url http://localhost:9000
 ```
 
-Verify the bucket creation in the RustFS Console.
+Confirm that the bucket appears in the RustFS Console.
diff --git a/content/en/administration/data/bucket/deletion.md b/content/en/administration/data/bucket/deletion.md
index b2234a810..2bb4fdaf9 100644
--- a/content/en/administration/data/bucket/deletion.md
+++ b/content/en/administration/data/bucket/deletion.md
@@ -10,14 +10,18 @@ This guide explains how to delete buckets using the RustFS UI, `rc`, or the S3 A
 - Install and configure [`rc`](/operations/rc) before using the command-line workflow.
 - Empty the target bucket before deleting it, or use `--force` only after reviewing the objects that will be removed.
 
-**Warning**: Deleting a bucket is irreversible and may break applications relying on it. Ensure you have backed up any necessary data before proceeding.
+:::warning[Deletion is permanent]
+
+Deleting a bucket is irreversible and can break applications that depend on it. Back up any data you need before you continue.
+
+:::
 
 ## Using the RustFS UI
 
 1. Log in to the RustFS Console.
 2. On the homepage, select the bucket you want to delete.
 3. On the far right, select the **Delete** button.
-4. In the popup dialog, click **Confirm** to complete bucket deletion.
+4. In the confirmation dialog, select **Confirm**.
 
 ![bucket deletion](images/bucket-deletion-on-ui.png)
 
diff --git a/content/en/administration/data/object/creation.md b/content/en/administration/data/object/creation.md
index b0c5ca07b..546a1aacf 100644
--- a/content/en/administration/data/object/creation.md
+++ b/content/en/administration/data/object/creation.md
@@ -22,7 +22,7 @@ Objects are the fundamental storage units in RustFS, containing data, metadata,
 
 ![object creation from ui](images/upload_file_from_ui.png)
 
-Click on an object to view its details.
+Select an object to view its details.
 
 ![object details info](images/object_details_info.png)
 
@@ -63,7 +63,7 @@ Verify the upload in the RustFS Console.
 
 See [Object Deletion](./deletion.md).
 
-Use the following API for file deletion:
+To delete an object with the S3 API, use:
 
 ```http
 DELETE /{bucketName}/{objectName} HTTP/1.1
@@ -78,4 +78,4 @@ aws s3api delete-object \
   --endpoint-url http://localhost:9000
 ```
 
-You can confirm the file has been deleted on the RustFS UI.
+Confirm in the RustFS Console that the object no longer appears.
diff --git a/content/en/administration/data/object/deletion.md b/content/en/administration/data/object/deletion.md
index 5e3106239..fa53e3672 100644
--- a/content/en/administration/data/object/deletion.md
+++ b/content/en/administration/data/object/deletion.md
@@ -13,9 +13,9 @@ This guide covers object deletion.
 ## Using the RustFS UI
 
 1. Log in to the RustFS Console.
-2. Select the bucket containing the file to be deleted.
+2. Select the bucket that contains the object you want to delete.
 3. On the bucket page, select the file to be deleted.
-4. Click **Delete Selected Items** in the upper right corner, then click **Confirm** in the popup dialog.
+4. Select **Delete Selected Items** in the upper-right corner, and then select **Confirm**.
 
 ![object deletion from ui](images/delete_file_from_ui.png)
 
diff --git a/content/en/administration/data/object/multipart-upload.md b/content/en/administration/data/object/multipart-upload.md
index d4a6af66e..93877a8bd 100644
--- a/content/en/administration/data/object/multipart-upload.md
+++ b/content/en/administration/data/object/multipart-upload.md
@@ -27,7 +27,7 @@ RustFS accepts part numbers from `1` through `10000`. `ListParts` and `ListMulti
 
 ![Console upload dialog with a selected large file](./images/multipart-upload-console.png)
 
-The observed Console upload dialog supports up to 10,000 selected files and reports a 512 GB maximum for a single file. These are Console upload limits; S3 clients can have different local limits.
+The Console upload dialog supports up to 10,000 files and reports a 512 GB maximum for a single file. These are Console upload limits; S3 clients can have different local limits.
 
 After upload starts, **Task Management** groups tasks into Pending, Processing, Completed, Failed, and Canceled states. Each processing task shows progress and a **Cancel** action. Canceling an active multipart task aborts the current part request and marks the task as canceled.
 
@@ -42,7 +42,7 @@ rc object copy /path/to/hello.txt rustfs/my-bucket/hello.txt
 rc object stat rustfs/my-bucket/hello.txt --json
 ```
 
-:::note[rc 0.1.29 multipart boundary]
+:::note[Multipart limitations in rc 0.1.29]
 
 `rc 0.1.29` does not expose create, upload-part, complete, list-parts, or abort multipart commands. A validated 20 MiB `rc object copy` used a single `PutObject` request rather than multipart upload. Use the Console or an S3 SDK when explicit multipart behavior is required; use `rc object stat` to verify the completed object.
 
diff --git a/content/en/administration/data/object/object-lock.md b/content/en/administration/data/object/object-lock.md
index 5db3468a1..c769ae64f 100644
--- a/content/en/administration/data/object/object-lock.md
+++ b/content/en/administration/data/object/object-lock.md
@@ -29,7 +29,7 @@ COMPLIANCE retention cannot be bypassed or shortened before its retain-until dat
 2. Select **Create Bucket** and enter the bucket name.
 3. Enable **Object Lock**. The Console also enables **Version** because Object Lock requires versioning.
 4. To apply retention automatically to new object versions, enable **Retention**.
-5. Select **COMPLIANCE** or **GOVERNANCE**, enter the validity, and select **Day** or **Year**.
+5. Select **COMPLIANCE** or **GOVERNANCE**, enter the retention period, and select **Day** or **Year**.
 6. Select **Create**.
 
 ![Create Bucket dialog with versioning, Object Lock, and default retention enabled](./images/object-lock-create-bucket.png)
@@ -48,7 +48,7 @@ rc alias set rustfs http://localhost:9000 \
 	--region us-east-1 --bucket-lookup path
 ```
 
-:::note[rc 0.1.29 bucket creation boundary]
+:::note[Bucket creation limitation in rc 0.1.29]
 
 `rc bucket create --with-lock` and `--with-versioning` appear in the `rc 0.1.29` help output but return `not implemented` when executed. Create the Object Lock bucket in the Console. The upload headers shown below are supported and were validated against RustFS.
 
diff --git a/content/en/administration/data/object/scanner.md b/content/en/administration/data/object/scanner.md
index 6330c38f6..5bccea986 100644
--- a/content/en/administration/data/object/scanner.md
+++ b/content/en/administration/data/object/scanner.md
@@ -3,30 +3,30 @@ title: "Object Scanning"
 description: "Guide to the RustFS object scanner, including design, implementation, and monitoring."
 ---
 
-This guide covers the design and implementation of the RustFS object scanner, including its integration with Erasure Coding, Scrub & Repair mechanisms, scheduling strategies, monitoring metrics, and troubleshooting.
+This guide covers the design and implementation of the RustFS object scanner, including how it works with erasure coding, scrubbing and repair, scheduling, metrics, and troubleshooting.
 
 ## Overview
 
 The RustFS object scanner is built into the storage engine and is responsible for periodically checking object integrity and executing scheduled operations.
-Scanning tasks include disk usage statistics, lifecycle management rule evaluation, object replication execution, and triggering corrupted object self-healing.
+The scanner collects disk usage statistics, evaluates lifecycle rules, performs object replication, and triggers healing for corrupted objects.
 
 ## Architecture and Design Principles
 
 ### Scanner Architecture
 
 The RustFS scanner uses a hash sampling mechanism, selecting one out of every 1024 objects for inspection based on object name hashing to minimize performance impact.
-The scanner is deeply integrated with the Erasure Coding module, utilizing redundant shards for online reconstruction when detecting lost or corrupted shards, ensuring high data availability and consistency.
+The scanner works with the erasure coding layer: when it detects a missing or corrupted shard, it rebuilds the shard online from the remaining redundant shards.
 
 ## Data Verification and Recovery
 
-The RustFS data verification mechanism checks metadata consistency and performs bit-by-bit reading and verification to discover hidden bad blocks. The object scanner detects issues like bit rot and triggers repair processes when necessary.
+The RustFS data verification mechanism checks metadata consistency and reads and verifies data bit by bit to detect latent bad sectors. The object scanner detects issues like bit rot and triggers repair processes when necessary.
 
 ## Scanning Modes and Scheduling
 
-RustFS supports three scanning modes: online scanning during reads, background periodic scanning, and manual full scanning, balancing performance and reliability.
-Similar to the `osd_scrub_begin_hour` configuration in Ceph, administrators can set scanning start times and frequency. For example, light verification is set to once daily by default.
+RustFS supports three scanning modes that balance performance and reliability: inline checks during reads, periodic background scans, and manual full scans.
+Similar to the `osd_scrub_begin_hour` configuration in Ceph, administrators can set scanning start times and frequency. For example, a lightweight check runs once a day by default.
 
 ## Monitoring and Metrics
 
-Scanner statistics include total task count, failure count, and time distribution, exposing metrics through the Prometheus data model such as `rustfs_scanner_jobs_total`, `rustfs_scanner_failures_total`, and `rustfs_scanner_duration_seconds`.
-Combined with monitoring systems, alerts can be set based on scanning failure rates and duration to promptly discover and locate potential issues at the storage or network levels.
\ No newline at end of file
+The scanner reports the total number of tasks, the number of failures, and duration distribution as Prometheus metrics, such as `rustfs_scanner_jobs_total`, `rustfs_scanner_failures_total`, and `rustfs_scanner_duration_seconds`.
+Configure alerts on scan failure rate and duration so you can detect and diagnose storage or network problems early.
\ No newline at end of file
diff --git a/content/en/administration/data/object/versioning.md b/content/en/administration/data/object/versioning.md
index b891c7567..b6a5130ba 100644
--- a/content/en/administration/data/object/versioning.md
+++ b/content/en/administration/data/object/versioning.md
@@ -25,7 +25,7 @@ Suspending versioning stops normal creation of new version IDs but preserves exi
 3. Enable **Version**.
 4. Select **Create**.
 
-### Enable or suspend an existing bucket
+### Enable or suspend versioning on an existing bucket
 
 1. Open **Buckets**, locate the bucket, and select **Settings**.
 2. Under **Data Protection**, locate **Versioning**.
@@ -94,7 +94,7 @@ rc bucket version suspend rustfs/my-bucket
 rc bucket version info rustfs/my-bucket
 ```
 
-:::warning[rc 0.1.29 version deletion boundary]
+:::warning[Version deletion limitation in rc 0.1.29]
 
 `rc object remove --versions` is listed in the `rc 0.1.29` help output but returns `not implemented`. Use the Console or an S3 SDK to permanently delete selected version IDs. Do not remove an entire version history unless you have verified retention, replication, and recovery requirements.
 
diff --git a/content/en/administration/data/s3-tables.md b/content/en/administration/data/s3-tables.md
index 47d1403f9..bcccb465d 100644
--- a/content/en/administration/data/s3-tables.md
+++ b/content/en/administration/data/s3-tables.md
@@ -3,7 +3,7 @@ title: "S3 Tables"
 description: "Enable a RustFS table bucket and connect Iceberg clients to the built-in REST catalog."
 ---
 
-RustFS S3 Tables manages **Apache Iceberg** tables through a built-in REST catalog. Table data, manifests, and Iceberg metadata remain S3 objects in RustFS. This guide enables a dedicated table bucket and explains client connections, permissions, and maintenance boundaries.
+RustFS S3 Tables manages **Apache Iceberg** tables through a built-in REST catalog. Table data, manifests, and Iceberg metadata remain S3 objects in RustFS. This guide shows how to enable a dedicated table bucket and explains client connections, permissions, and maintenance limits.
 
 :::note[Preview and version scope]
 
diff --git a/content/en/administration/index.md b/content/en/administration/index.md
index d2f55515c..51cc9aaf6 100644
--- a/content/en/administration/index.md
+++ b/content/en/administration/index.md
@@ -12,6 +12,6 @@ Use this section to manage RustFS through the Console, administer buckets and ob
 - [S3 Tables](/administration/data/s3-tables) covers table buckets and the built-in Iceberg REST catalog.
 - [Protocol Support](./protocols/s3.md) covers S3, WebDAV, FTPS, and SFTP access.
 - [CORS Configuration](./cors/index.md) covers cross-origin access to RustFS services.
-- [Virtual-Host Access](/integration/virtual) covers domain-based S3 addressing.
+- [Virtual-hosted–style requests](/integration/virtual) cover domain-based S3 addressing.
 
 For identity, encryption, transport security, and auditing, continue with [Security & Compliance](/security-compliance).
diff --git a/content/en/administration/protocols/s3.md b/content/en/administration/protocols/s3.md
index 0148cd28b..cb7d2f2b5 100644
--- a/content/en/administration/protocols/s3.md
+++ b/content/en/administration/protocols/s3.md
@@ -22,7 +22,7 @@ RustFS covers the common S3 data plane used by applications, backup tools, and S
 | Objects | Put, get, head, copy, delete, multi-delete, range reads, conditional requests, and user metadata |
 | Listing | `ListObjects`, `ListObjectsV2`, prefixes, delimiters, markers, and pagination |
 | Large objects | Create, upload, copy, list, complete, and abort multipart uploads |
-| Data management | Versioning, lifecycle rules, bucket and object tags, checksums, and object lock |
+| Data management | Versioning, lifecycle rules, bucket and object tags, checksums, and Object Lock |
 | Access control | IAM credentials and policies, bucket policies, public access block, and presigned GET/PUT URLs |
 | Integration | CORS, bucket notifications, replication configuration, and server-side encryption workflows |
 
diff --git a/content/en/developer/integration/others/index.md b/content/en/developer/integration/others/index.md
index 65a45a2de..02b8e1e08 100644
--- a/content/en/developer/integration/others/index.md
+++ b/content/en/developer/integration/others/index.md
@@ -8,7 +8,7 @@ Integration guides that do not fit the other categories.
 ## Guides
 
 - [capo (Python)](./capo.md) — connect the community-driven capo SDK to RustFS with synchronous or asynchronous clients.
-rclone](./rclone.md) — sync, mount, and serve RustFS buckets from the command line.
+- [rclone](./rclone.md) — sync, mount, and serve RustFS buckets from the command line.
 - [tusd](./tusd.md) — receive resumable uploads into a RustFS bucket over the tus protocol.
 - [JuiceFS](./juicefs.md) — mount a POSIX filesystem backed by a RustFS bucket.
 - [Nextcloud](./nextcloud.md) — use RustFS as S3 external storage for Nextcloud files.
diff --git a/content/en/developer/mcp.md b/content/en/developer/mcp.md
index fd997b019..12ac3b370 100644
--- a/content/en/developer/mcp.md
+++ b/content/en/developer/mcp.md
@@ -1,15 +1,15 @@
 ---
 title: "RustFS MCP"
-description: "RustFS MCP Usage Guide"
+description: "Connect AI assistants to RustFS object storage with the RustFS MCP server."
 ---
 
-**RustFS MCP Server** is a high-performance [Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) server that provides AI/LLM tools with seamless access to S3-compatible object storage operations. Built with Rust for performance and security, it enables AI assistants like Claude Desktop to interact with cloud storage through standardized protocols.
+**RustFS MCP Server** is a [Model Context Protocol (MCP)](https://www.anthropic.com/news/model-context-protocol) server that gives AI assistants, such as Claude Desktop, access to S3-compatible object storage.
 
 ### What is MCP?
 
 The Model Context Protocol is an open standard that enables AI applications to establish secure, controlled connections with external systems. This server acts as a bridge between AI tools and S3-compatible storage services, providing structured access to file operations while maintaining security and observability.
 
-## ✨ Features
+## Features
 
 ### Supported S3 Operations
 
@@ -128,7 +128,7 @@ rustfs-mcp --log-level debug --region us-west-2
 
 ### Using with Docker
 
-[RustFS MCP officially provides a Dockerfile](https://github.com/rustfs/rustfs/tree/main/crates/mcp) that can be used to build container images for using RustFS MCP.
+RustFS MCP provides an [official Dockerfile](https://github.com/rustfs/rustfs/tree/main/crates/mcp) that you can use to build a container image.
 
 ```bash
 # Clone RustFS repository code
@@ -138,11 +138,11 @@ git clone https://github.com/rustfs/rustfs.git
 docker build -f crates/mcp/Dockerfile -t rustfs/rustfs-mcp .
 ```
 
-After successful build, you can configure it in the MCP configuration of AI IDEs.
+After the build succeeds, add the server to your IDE's MCP configuration.
 
 #### Configuring MCP in AI IDEs
 
-Currently, mainstream AI IDEs such as Cursor, Windsurf, Trae, etc. all support MCP. For example, in Trae, add the following content to the MCP configuration (**MCP --> Add**):
+Many AI IDEs, such as Cursor, Windsurf, and Trae, support MCP. For example, in Trae, add the following content to the MCP configuration (**MCP --> Add**):
 
 ```json
 {
@@ -174,23 +174,23 @@ Currently, mainstream AI IDEs such as Cursor, Windsurf, Trae, etc. all support M
 }
 ```
 
-> `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are RustFS access keys. You can refer to the [Access Key Management chapter](../security-compliance/iam/access-token.md) for creation.
+> `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are RustFS access keys. To create them, see [Access Key Management](../security-compliance/iam/access-token.md).
 
-If added successfully, you can list the [available tools](#️-available-tools) on the MCP configuration page.
+If the server is added successfully, the MCP configuration page lists its [available tools](#️-available-tools).
 
-![add rustfs mcp in trae mcp configuration successfully](images/add-rustfs-mcp-succ.png)
+![RustFS MCP server added to the MCP configuration in Trae](images/add-rustfs-mcp-succ.png)
 
-In Trae, you can use the corresponding tools by entering the corresponding prompts. For example, in Trae's chat dialog, enter:
+To invoke an MCP tool in Trae, enter a prompt in the chat. For example:
 
 ```text
 Please help me list the buckets in the current rustfs instance, thank you!
 ```
 
-Returns the following response:
+Trae returns the following response:
 
 ![list rustfs bucket with rustfs mcp](images/list-rustfs-bucket-with-mcp.png)
 
-Trae uses **Builder with MCP** mode, calling the `list_buckets` tool to list all buckets in the configured RustFS instance. The same applies to calls to other tools.
+Trae uses **Builder with MCP** mode, calling the `list_buckets` tool to list all buckets in the configured RustFS instance. Other tools work the same way.
 
 ## 🛠️ Available Tools
 
diff --git a/content/en/developer/sdk/go.md b/content/en/developer/sdk/go.md
index b40cab279..1652d6ccd 100644
--- a/content/en/developer/sdk/go.md
+++ b/content/en/developer/sdk/go.md
@@ -1,9 +1,9 @@
 ---
-title: "Golang SDK Guide"
+title: "Go SDK Guide"
 description: "Use the AWS SDK for Go v2 to operate on RustFS instances, including creating and deleting buckets and objects."
 ---
 
-RustFS ships no first-party Go SDK — it is fully S3-compatible, so you use the official AWS SDK for Go v2 configured to point at your RustFS server. Through the SDK, you can operate on RustFS, including creating and deleting buckets/objects, uploading and downloading files, etc.
+RustFS ships no first-party Go SDK — it is fully S3-compatible, so you use the official AWS SDK for Go v2 configured to point at your RustFS server. With the SDK, you can create and delete buckets, and upload and download objects.
 
 ## Prerequisites
 
@@ -104,7 +104,7 @@ Buckets:
 
 You can now perform bucket and object operations. The snippets below run inside the `main` function above, reusing `client` and `ctx`.
 
-## Create Bucket
+## Create a bucket
 
 ```go
 _, err = client.CreateBucket(ctx, &s3.CreateBucketInput{
diff --git a/content/en/developer/sdk/index.md b/content/en/developer/sdk/index.md
index f57b4164b..c67e66723 100644
--- a/content/en/developer/sdk/index.md
+++ b/content/en/developer/sdk/index.md
@@ -1,43 +1,41 @@
 ---
-title: "RustFS SDK Overview"
+title: "SDKs"
 description: "Overview of supported S3 SDKs for RustFS."
 ---
 
-RustFS is a distributed object storage system fully compatible with the S3 protocol. Users can:
+RustFS is a distributed object storage system fully compatible with the S3 protocol. You can:
 
-- Manage RustFS through the Console management interface.
+- Manage RustFS in the Console.
 - Manage RustFS through S3 clients.
-- Implement object storage operations and management on the business side through SDKs.
+- Use an S3 SDK to manage buckets and objects from your application.
 
-Currently, the SDKs provided by RustFS include:
+The following guides explain how to use S3 SDKs with RustFS:
 
 - [Java SDK](./java.md)
 - [JavaScript SDK](./javascript.md)
 - [Python SDK](./python.md)
 - [Rust SDK](./rust.md)
 - [TypeScript SDK](./typescript.md)
-- [Golang SDK](./go.md)
+- [Go SDK](./go.md)
 
 ## Terminology
 
-Amazon S3 (Simple Storage Service) was the first widely adopted object storage service. Its API has become the de facto standard for object storage. In this documentation, "S3" refers to the protocol.
+Amazon Simple Storage Service (Amazon S3) was the first widely adopted object storage service. Its API has become the de facto standard for object storage. In this documentation, "S3" refers to the protocol.
 
 ## SDK Recommendations
 
 We recommend using the official AWS S3 SDKs. These SDKs are mature, well-maintained, and highly optimized.
 
-If you have a familiar and trusted SDK from a vendor, you can use it.
+You can also use a vendor SDK you know and trust, provided it supports the S3 operations you need.
 
 Some third-party SDKs may have non-standard implementations. We recommend avoiding SDKs that are not strictly S3-compliant.
 
 ## Compatibility with MinIO SDKs
 
-Yes, RustFS is fully compatible with MinIO SDKs.
+RustFS is fully compatible with the MinIO SDKs.
 
-If you are using MinIO SDKs, you can modify the Endpoint, AK, and SK to be directly compatible with RustFS.
+To connect a MinIO SDK to RustFS, set the endpoint, access key, and secret key to your RustFS values.
 
 ## Handling Incompatible SDKs
 
-If you encounter an SDK that does not support standard S3, MinIO, or RustFS:
-
-We recommend switching to a standard AWS S3 SDK.
+If an SDK does not work with standard S3, MinIO, or RustFS, we recommend switching to a standard AWS S3 SDK.
diff --git a/content/en/developer/sdk/java.md b/content/en/developer/sdk/java.md
index 938a7f166..982873e0f 100644
--- a/content/en/developer/sdk/java.md
+++ b/content/en/developer/sdk/java.md
@@ -46,7 +46,7 @@ Add AWS SDK dependencies in `pom.xml`:
 </dependencies>
 ```
 
-> Recommend using AWS SDK v2, which has more complete features and supports async, reactive, and other patterns.
+We recommend AWS SDK for Java v2, which is more complete and supports asynchronous and reactive programming.
 
 ---
 
@@ -133,14 +133,14 @@ Deleted hello.txt
 
 ---
 
-## 3. Common Issues and Troubleshooting
+## 3. Troubleshooting
 
 | Issue | Cause | Solution |
 | -------------------------------------- | ------------------------------------ | ----------------------------------------- |
 | `S3Exception: 301 Moved Permanently` | Path-style not enabled or region error | Set `.forcePathStyle(true)` and use region `us-east-1` |
 | `ConnectException: Connection refused` | RustFS not started or incorrect port | Check RustFS status and port |
-| `403 Forbidden` | AccessKey / SecretKey error | Check authentication configuration |
-| Upload fails with no response | SDK defaults to HTTPS, RustFS only supports HTTP (or needs certificates) | Use `http://` address and configure `endpointOverride` |
+| `403 Forbidden` | Incorrect access key or secret key | Check your credentials |
+| Upload fails with no response | The SDK defaults to HTTPS, and RustFS only supports HTTP (or needs certificates) | Use an `http://` address and set `endpointOverride` |
 
 ---
 
@@ -148,38 +148,38 @@ Deleted hello.txt
 
 ### 4.1 Maven Package and Run
 
-Package project:
+Package the project:
 
 ```bash
 mvn clean package
 ```
 
-Execute:
+Run it:
 
 ```bash
 java -cp target/rustfs-java-s3-demo-1.0-SNAPSHOT.jar com.example.RustfsS3Example
 ```
 
-### 4.2 RustFS Configuration Recommendations
+### 4.2 Recommended RustFS settings
 
-* Ensure SSL validation is disabled when service uses HTTP protocol.
+* If RustFS is serving plain HTTP, disable TLS certificate validation in the SDK.
 * Enable CORS support (if used for web frontend).
-* Recommend setting limits like `max_object_size` and `max_part_size` to prevent large file transfer failures.
+* We recommend setting limits such as `max_object_size` and `max_part_size` to prevent large-file transfer failures.
 
 ---
 
 The following advanced examples cover:
 
 * Presigned URL generation and usage
-* Multipart Upload complete process
+* The complete multipart upload workflow
 
 ---
 
-## 5. Java Advanced Features Examples
+## 5. Advanced examples
 
 ### 5.1 Generate and Use Presigned URLs
 
-> Presigned URLs allow clients to temporarily access private objects without exposing credentials, widely used for browser direct upload or download file scenarios.
+Presigned URLs give clients temporary access to private objects without exposing credentials. They are commonly used for direct uploads and downloads from a browser.
 
 #### 5.1.1 Generate Download Link (GET)
 
@@ -229,11 +229,11 @@ System.out.println("Presigned URL: " + presignedRequest.url());
 Presigned URL: http://localhost:9000/my-bucket/hello.txt?X-Amz-Algorithm=AWS4-HMAC-SHA256&...
 ```
 
-> 🔗 Open the link in browser to access the object.
+Open the URL in a browser to access the object.
 
 #### 5.1.2 Upload Presigned URL (PUT)
 
-Similarly, you can also generate upload URLs:
+You can also generate upload URLs:
 
 ```java
 import software.amazon.awssdk.services.s3.model.PutObjectRequest;
@@ -259,7 +259,7 @@ System.out.println("Upload URL: " + presignedPut.url());
 
 ### 5.2 Implement Multipart Upload
 
-> Multipart Upload is the recommended way for large file uploads, enabling resume from breakpoint during network fluctuations.
+Multipart upload is the recommended way to upload large files. If the network is interrupted, you can retry failed parts instead of restarting the whole upload.
 
 The examples below reuse the `s3` client from section 2 and need these additional imports:
 
diff --git a/content/en/developer/sdk/javascript.md b/content/en/developer/sdk/javascript.md
index f010b46fa..108d5de15 100644
--- a/content/en/developer/sdk/javascript.md
+++ b/content/en/developer/sdk/javascript.md
@@ -3,11 +3,11 @@ title: "JavaScript SDK Guide"
 description: "Use the official AWS SDK for JavaScript v3 with RustFS."
 ---
 
-## I. Overview
+## Overview
 
 RustFS ships no first-party JavaScript SDK — it is S3-compatible, so you use the official AWS SDK for JavaScript (v3) configured to point at your RustFS server. This guide shows how to connect to RustFS and perform common object storage operations.
 
-## II. Prerequisites
+## Prerequisites
 
 * Node.js 18 or later
 * A running RustFS instance (see the [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001`
@@ -19,9 +19,9 @@ If you did not set credentials at install time, the server defaults to `rustfsad
 
 :::
 
-### 2.1 SDK Installation
+### Install the SDK
 
-Install the required AWS SDK v3 modules with NPM:
+Install the required AWS SDK v3 modules with npm:
 
 ```bash
 npm install @aws-sdk/client-s3 @aws-sdk/s3-request-presigner
@@ -31,7 +31,7 @@ The examples below use ES modules (`import`). Set `"type": "module"` in your `pa
 
 ---
 
-## III. Initializing the Client
+## Initialize the client
 
 The following is a complete, runnable script. Replace `localhost` with your server's IP address if RustFS runs on another machine, and fill in your own access keys:
 
@@ -67,7 +67,7 @@ All snippets below reuse this `s3` client.
 
 ---
 
-## IV. Basic Operations
+## Basic operations
 
 ### 4.1 Create Bucket
 
@@ -167,11 +167,11 @@ File deleted
 
 ---
 
-## V. Advanced Features
+## Advanced features
 
 ### 5.1 Generate Presigned URLs
 
-> Allows frontend or third parties to use temporary links for uploading/downloading files
+Presigned URLs let browser clients or third parties upload or download objects through temporary links.
 
 #### Download (GET)
 
@@ -275,11 +275,11 @@ Multipart upload completed
 
 ---
 
-## VI. Common Issues and Notes
+## Troubleshooting
 
 | Problem | Cause | Solution |
 | --------------------------- | -------------------- | --------------------------------------- |
-| SignatureDoesNotMatch | Wrong signature version | JS SDK v3 uses v4 by default, ensure RustFS supports v4 |
+| SignatureDoesNotMatch | Signature version mismatch | AWS SDK for JavaScript v3 uses Signature Version 4 by default. Confirm that RustFS accepts SigV4. |
 | EndpointConnectionError | Endpoint address misconfigured or not started | Check if RustFS address is accessible |
 | NoSuchKey | File does not exist | Check if `Key` is spelled correctly |
 | InvalidAccessKeyId / Secret | Credentials misconfigured | Check `accessKeyId` / `secretAccessKey` configuration |
@@ -287,9 +287,9 @@ Multipart upload completed
 
 ---
 
-## VII. Appendix: Frontend Upload Adaptation
+## Appendix: Browser uploads
 
-Using presigned URLs allows browsers to upload files directly without passing AccessKey.
+With presigned URLs, browsers can upload objects directly without access to your credentials.
 
 Frontend (HTML+JS) upload example:
 
diff --git a/content/en/developer/sdk/other.md b/content/en/developer/sdk/other.md
index 4b4380965..9d1152761 100644
--- a/content/en/developer/sdk/other.md
+++ b/content/en/developer/sdk/other.md
@@ -1,43 +1,43 @@
 ---
 title: "Other SDKs"
-description: "This article mainly explains the usage of various other language SDKs in RustFS."
+description: "Learn how to connect to RustFS from languages without an official AWS SDK."
 ---
 
-If AWS S3 doesn't officially support your language, you can adopt the following strategies to integrate with RustFS:
+If AWS does not provide an official SDK for your language, you can use one of the following approaches to integrate with RustFS:
 
-## 1. Use HTTP Interface Direct Requests (Based on S3 API Protocol)
+## 1. Send HTTP requests directly to the S3 API
 
-The S3 protocol is a standard RESTful API. You can encapsulate access logic yourself using any language that supports HTTP requests (such as C, Rust, Lua, Erlang).
+The S3 protocol is a standard RESTful API. You can implement the client logic yourself in any language that can send HTTP requests (such as C, Rust, Lua, or Erlang).
 
-### Key points include:
+### Key steps
 
-* **Signature Algorithm**: Implement AWS Signature Version 4 signature (more complex)
-* **Construct correct Headers and Canonical Request**
-* **Use HTTPS/HTTP client to send requests**
+* **Request signing**: Implement AWS Signature Version 4 (the most complex part).
+* **Headers and canonical request**: Build the canonical request and the required headers.
+* **HTTP client**: Send the signed request with an HTTP or HTTPS client.
 
-👉 Recommended to reference open-source project signature implementations, for example:
+We recommend consulting existing open-source implementations of request signing, such as:
 
 * [https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html](https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html)
 
 ---
 
-## 2. Call CLI Tools or Middleware Services of Existing SDKs
+## 2. Use the AWS CLI or a service built on an existing SDK
 
 If you don't want to implement signatures yourself, you can:
 
-### 2.1. Use AWS CLI tools with existing language support:
+### 2.1. Call the AWS CLI
 
-For example, call through Shell:
+For example, run the following command from your application using a shell:
 
 ```bash
 aws s3 cp local.txt s3://mybucket/myfile.txt --endpoint-url http://rustfs.local:9000
 ```
 
-Or write a simple relay service using Node.js/Python SDK, and your language uploads/downloads by calling this service.
+Alternatively, build a small relay service with an SDK for Node.js or Python, then call it from your application to upload or download objects.
 
-### 2.2. Set up a Proxy (such as Flask, FastAPI, Express)
+### 2.2. Run a proxy service (for example, Flask, FastAPI, or Express)
 
-Let clients that don't support S3 call your encapsulated HTTP API:
+Expose an HTTP API that clients without S3 support can call:
 
 ```http
 POST /upload -> Service internally calls SDK to upload objects to RustFS
@@ -48,31 +48,31 @@ GET /presigned-url -> Generate presigned URL for frontend/client use
 
 ## 3. Find Third-Party Community SDKs
 
-Although AWS doesn't have official SDKs, some language communities have developed unofficial S3 clients. For example:
+For languages without an official AWS SDK, look for community-maintained S3 clients. For example:
 
 * Haskell: `amazonka-s3`
 * Rust: `rusoto` (deprecated) or `aws-sdk-rust`
-* OCaml: May implement through `cohttp` yourself
-* Delphi: Has commercial libraries supporting S3 protocol
+* OCaml: Build your own client on top of `cohttp`
+* Delphi: Commercial libraries with S3 support are available
 
 Community SDKs vary greatly in stability, so you should evaluate activity, documentation, and compatibility before use.
 
 ---
 
-## 4. Delegate Core Upload Logic to Platform Hosting
+## 4. Upload directly from clients with presigned URLs
 
 For example:
 
-* Delegate frontend (Web/Mobile) upload tasks to browser or App side execution (using presigned URLs)
-* Backend uses Node.js/Python/Go and other proxies to implement upload logic
+* Use presigned URLs to upload directly from a browser or mobile app.
+* Implement the upload logic in a backend service (for example, Node.js, Python, or Go)
 
 ---
 
-## Summary Recommendations
+## Choose an approach
 
-| Scenario | Recommended Solution |
+| Situation | Recommended approach |
 | ------------- | ---------------------------------- |
-| Need complete control/embedded environment | Implement Signature V4 self-signing |
-| Weak language support but has Shell | Call upload through AWS CLI |
-| Can deploy relay service | Use Python/Node to build S3 API gateway |
+| You need full control, or you target an embedded environment | Implement SigV4 signing yourself |
+| Limited SDK support, but a shell is available | Upload with the AWS CLI |
+| You can deploy a relay service | Build a small S3 gateway with Python or Node.js |
 | Frontend upload | Use presigned URLs |
diff --git a/content/en/developer/sdk/python.md b/content/en/developer/sdk/python.md
index 672504524..f239d1d1d 100644
--- a/content/en/developer/sdk/python.md
+++ b/content/en/developer/sdk/python.md
@@ -204,7 +204,7 @@ curl -X PUT --upload-file /path/to/hello.txt "http://localhost:9000/my-bucket/up
 
 ### 5.2 Multipart Upload
 
-Suitable for files larger than 10 MB, allows manual control of each part.
+Use multipart upload for files larger than 10 MB when you need control over each part.
 
 ```python
 file_path = 'largefile.bin'
@@ -260,13 +260,13 @@ Multipart upload complete.
 
 ---
 
-## 6. Common Issue Troubleshooting
+## 6. Troubleshooting
 
 | Issue | Cause | Solution |
 | ------------------------- | ----------------- | -------------------------------------------------------------- |
 | `SignatureDoesNotMatch` | Not using v4 signature | Set `signature_version='s3v4'` |
 | `EndpointConnectionError` | Wrong RustFS address or service not started | Check endpoint and RustFS service status |
-| `AccessDenied` | Wrong credentials or insufficient permissions | Check AccessKey/SecretKey or bucket policies |
+| `AccessDenied` | Wrong credentials or insufficient permissions | Check the access key, secret key, and bucket policies |
 | `PermanentRedirect` / wrong bucket URL | Path-style not enabled | Set `s3={'addressing_style': 'path'}` in the `Config` |
 
 ---
diff --git a/content/en/developer/sdk/rust.md b/content/en/developer/sdk/rust.md
index 9d8181348..47b1f3056 100644
--- a/content/en/developer/sdk/rust.md
+++ b/content/en/developer/sdk/rust.md
@@ -1,9 +1,9 @@
 ---
 title: "Rust SDK Guide"
-description: "Operate RustFS instances through the AWS SDK for Rust, including creation and deletion of buckets and objects."
+description: "Use the AWS SDK for Rust to create and delete buckets and objects in RustFS."
 ---
 
-RustFS ships no first-party Rust client crate — it is fully S3-compatible, so you use the official AWS SDK for Rust (`aws-sdk-s3`) configured to point at your RustFS server. Through the SDK, you can operate RustFS, including creation and deletion of buckets/objects, file upload and download, etc.
+RustFS ships no first-party Rust client crate — it is fully S3-compatible, so you use the official AWS SDK for Rust (`aws-sdk-s3`) configured to point at your RustFS server. With the SDK, you can create and delete buckets and upload, download, and delete objects.
 
 ## Prerequisites
 
diff --git a/content/en/developer/sdk/typescript.md b/content/en/developer/sdk/typescript.md
index d26b7a938..bf78c7cd4 100644
--- a/content/en/developer/sdk/typescript.md
+++ b/content/en/developer/sdk/typescript.md
@@ -1,14 +1,14 @@
 ---
-title: "RustFS TypeScript SDK Usage Guide"
+title: "TypeScript SDK Guide"
 description: "Operate RustFS from TypeScript with the AWS SDK for JavaScript v3, including creation and deletion of buckets and objects."
 ---
 
-RustFS ships no first-party TypeScript SDK — it is fully S3-compatible, so you use the official AWS SDK for JavaScript v3 (which ships its own TypeScript type definitions) configured to point at your RustFS server. Through the SDK, you can operate RustFS, including creation and deletion of buckets/objects, file upload and download, etc.
+RustFS ships no first-party TypeScript SDK — it is fully S3-compatible, so you use the official AWS SDK for JavaScript v3 (which includes TypeScript type definitions) configured to point at your RustFS server. With the SDK, you can create and delete buckets, and upload and download objects.
 
 ## Prerequisites
 
 - Node.js 18 or later (the examples use ES modules — set `"type": "module"` in your `package.json`)
-- An available RustFS instance (refer to [Installation Guide](../../installation/index.md) for installation) — the S3 API listens on port `9000`, the Console on port `9001`
+- A running RustFS instance (see the [Installation Guide](../../installation/index.md)) — the S3 API listens on port `9000`, the Console on port `9001`
 - Access keys, set at install time via the `RUSTFS_ACCESS_KEY` / `RUSTFS_SECRET_KEY` environment variables (refer to [Access Key Management](../../security-compliance/iam/access-token.md) for creation)
 
 :::tip[Local test]
diff --git a/content/en/index.mdx b/content/en/index.mdx
index da087cfc6..aa0e7f4ec 100644
--- a/content/en/index.mdx
+++ b/content/en/index.mdx
@@ -6,8 +6,8 @@ description: "Install RustFS on Linux, containers, Kubernetes, macOS, or Windows
 <div className="rustfs-install-home">
   <div className="rustfs-install-intro">
     <div className="rustfs-install-lede">
-      RustFS is a distributed object storage system written in Rust and built
-      for S3-compatible workloads. This documentation covers installation,
+      RustFS is a distributed, S3-compatible object storage system written in Rust.
+      This documentation covers installation,
       administration, security, and operations for RustFS clusters.
     </div>
     <a className="rustfs-install-overview" href="/en/installation">
diff --git a/content/en/installation/cloud-native/index.md b/content/en/installation/cloud-native/index.md
index ef338b581..3d7b9dc04 100644
--- a/content/en/installation/cloud-native/index.md
+++ b/content/en/installation/cloud-native/index.md
@@ -106,7 +106,7 @@ The chart templates HTTP probes on the S3 port (9000) out of the box, matching t
 - **Liveness**: `GET /health` (`livenessProbe.httpGet.path`), initial delay 30s, period 5s
 - **Readiness**: `GET /health/ready` (`readinessProbe.httpGet.path`), initial delay 10s, period 5s
 
-A pod is only added to the Service endpoints once `/health/ready` returns `200`, which in distributed mode requires the storage quorum to be met. Thresholds and timings are tunable via the `livenessProbe.*` and `readinessProbe.*` values.
+A Pod is added to the Service endpoints only after `/health/ready` returns `200`, which in distributed mode requires the storage quorum to be met. Thresholds and timings are tunable via the `livenessProbe.*` and `readinessProbe.*` values.
 
 ## 5. Production hardening
 
@@ -147,7 +147,7 @@ Log in to the Console with the access key and secret key you set at install time
 
 ## 7. Scaling out with server pools
 
-In distributed mode the chart can run multiple **server pools** — independent StatefulSets whose drives together form one cluster. This is the chart-level equivalent of adding a Server Pool as described in [Pool Expansion](../../operations/scaling/storage-pool-expansion.md).
+In distributed mode the chart can run multiple **server pools** — independent StatefulSets whose drives together form one cluster. This is the chart-level equivalent of adding a server pool as described in [Pool Expansion](../../operations/scaling/storage-pool-expansion.md).
 
 To expand an existing deployment, enable pools and describe the current layout as pool 0 plus your new capacity:
 
@@ -172,7 +172,7 @@ The list index determines the StatefulSet name — never remove or reorder entri
 
 What to expect during the rollout, per the chart's documentation:
 
-- **Crash/restart cycles are normal.** Pods restart until every pod of every pool is resolvable — the server refuses to start with unresolvable peers, so expect a few crash loops before the cluster converges. This is harmless.
+- **Expect restarts.** Pods restart until every Pod in every pool is resolvable — the server refuses to start with unresolvable peers, so expect a few crash loops before the cluster converges. This is harmless.
 - **Rebalance afterwards.** After the cluster converges, run `rc admin rebalance start <alias>` to spread existing objects across the new pool.
 - The PodDisruptionBudget spans all pools: with the default `pdb.maxUnavailable: 1`, at most one pod of the whole cluster may be evicted at a time.
 
diff --git a/content/en/installation/container/docker.md b/content/en/installation/container/docker.md
index c88d61007..e139b39d9 100644
--- a/content/en/installation/container/docker.md
+++ b/content/en/installation/container/docker.md
@@ -7,8 +7,8 @@ This page covers running the official RustFS image with Docker: a single-node in
 
 ## 1. Prerequisites
 
-* Docker Engine (≥ 20.10) installed and able to pull images and run containers normally
-* Host ports 9000 (S3 API) and 9001 (Console) available, or consistent with your custom ports
+* Docker Engine (≥ 20.10) installed, with the ability to pull images and run containers
+* Host ports 9000 (S3 API) and 9001 (Console) available, or the custom ports you plan to use
 * If you bind-mount a host directory, the directory owner must match the container user — see [Bind-mount a host directory](#bind-mount-a-host-directory)
 
 ## 2. Pull the image
@@ -186,7 +186,7 @@ If [using TLS](../../integration/tls-configured.md), mount the certificate direc
 
 ## Before production
 
-Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. Use a multi-node deployment architecture, [enable TLS encrypted communication](../../integration/tls-configured.md), configure a log rotation strategy, and set up a regular backup strategy.
+Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. Use a multi-node deployment, [enable TLS](../../integration/tls-configured.md), configure log rotation, and schedule regular backups.
 
 ## Next steps
 
diff --git a/content/en/installation/container/index.md b/content/en/installation/container/index.md
index 4ee47b47d..2f076e392 100644
--- a/content/en/installation/container/index.md
+++ b/content/en/installation/container/index.md
@@ -3,7 +3,7 @@ title: "Container"
 description: "Run the official RustFS container image with Docker or Podman."
 ---
 
-RustFS is a high-performance, S3-compatible open-source distributed object storage system. In single-node single-disk (SNSD) deployment mode, the backend uses zero erasure coding without additional data redundancy, which makes it suitable for local testing and small-scale scenarios. The official RustFS image packages the RustFS binary and its runtime environment into a container, so you can start a service with a single command and persistent storage.
+RustFS is an open-source, S3-compatible distributed object storage system. In single-node single-disk (SNSD) mode, RustFS does not use erasure coding and stores no redundant data, so this mode is suitable only for local testing and small workloads. The official RustFS image packages the RustFS binary and its runtime environment into a container, so you can start RustFS with persistent storage by running a single command.
 
 The container runs as non-root user `rustfs` with id `10001`, so a bind-mounted host directory must be owned by `10001` to avoid permission denied errors.
 
diff --git a/content/en/installation/index.md b/content/en/installation/index.md
index 4d8361f57..b97593ecc 100644
--- a/content/en/installation/index.md
+++ b/content/en/installation/index.md
@@ -14,24 +14,24 @@ After installation, set unique values for `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET
 
 :::
 
-## Choose Your Path
+## Choose your path
 
 | Your goal | Recommended path | Guide |
 | - | - | - |
 | Try RustFS on a local machine | One-command install script, or a container | [Linux Quick Start](./linux/quick-start.md) · [Container](./container/index.md) |
 | Single-server production | SNSD (one disk) or SNMD (multiple disks) | [Installing RustFS on Linux](./linux/index.md) |
 | Multi-server production cluster | MNMD, after completing the production checklists | [Multiple Node Multiple Disk](./linux/multiple-node-multiple-disk.md) · [Checklists](./requirement/checklists/index.md) |
-| Kubernetes / cloud-native | Container orchestration deployment | [Cloud Native](./cloud-native/index.md) |
+| Kubernetes / cloud-native | Deploy with the Helm chart or the Operator | [Cloud Native](./cloud-native/index.md) |
 | Windows or macOS host | Native installation | [Windows](./windows/index.md) · [macOS](./macos/index.md) |
 
 ## Deployment Mode Comparison
 
 | Mode | Nodes | Disks | Fault Tolerance | Typical Use |
 | - | - | - | - | - |
-| [SNSD](./linux/single-node-single-disk.md) | 1 | 1 | None — rely on backups | Development, testing, low-density non-critical business |
-| [SNMD](./linux/single-node-multiple-disk.md) | 1 | Multiple | Up to M parity disks within the node | Medium, non-critical business on a single server |
+| [SNSD](./linux/single-node-single-disk.md) | 1 | 1 | None — rely on backups | Development, testing, and small non-critical workloads |
+| [SNMD](./linux/single-node-multiple-disk.md) | 1 | Multiple | Up to M parity disks within the node | Mid-sized, non-critical workloads on a single server |
 | [MNMD](./linux/multiple-node-multiple-disk.md) | 4+ | Multiple per node | Disk- and node-level via erasure coding across servers | Production workloads |
 
 ## Checklist
 
-Before any production deployment, work through the [Pre-Installation Checklists](./requirement/checklists/index.md) — hardware, network, software, and security — to make sure your environment meets production guidance.
+Before any production deployment, work through the [Pre-Installation Checklists](./requirement/checklists/index.md) — hardware, network, software, and security — to make sure your environment meets production requirements.
diff --git a/content/en/installation/linux/index.md b/content/en/installation/linux/index.md
index 8f9f4f1be..174723344 100644
--- a/content/en/installation/linux/index.md
+++ b/content/en/installation/linux/index.md
@@ -13,13 +13,13 @@ After installation, set unique `RUSTFS_ACCESS_KEY` and `RUSTFS_SECRET_KEY` value
 
 ## Single Node Single Disk (SNSD)
 
-One server, one data disk. The simplest mode, with no redundancy — a disk failure means data loss, so rely on backups. Suitable for development, testing, and low-density non-critical business.
+One server, one data disk. The simplest mode, with no redundancy — a disk failure means data loss, so rely on backups. Suitable for development, testing, and small non-critical workloads.
 
 → [Single Node Single Disk installation](./single-node-single-disk.md)
 
 ## Single Node Multiple Disk (SNMD)
 
-One server, multiple data disks. Erasure coding shards data across the disks, so the node tolerates a limited number of disk failures, but a whole-server failure still means data loss. Suitable for medium, non-critical business on a single machine.
+One server, multiple data disks. Erasure coding shards data across the disks, so the node tolerates a limited number of disk failures, but a whole-server failure still means data loss. Suitable for mid-sized, non-critical workloads on a single machine.
 
 → [Single Node Multiple Disk installation](./single-node-multiple-disk.md)
 
@@ -31,4 +31,4 @@ Four or more servers, each with one or more disks. Erasure coding spans servers,
 
 ## Before Production
 
-Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. If you don't need production standards, you can skip them.
+Work through the [Pre-Installation Checklists](../requirement/checklists/index.md) — hardware, network, software, and security — before deploying to production. You can skip them for non-production deployments.
diff --git a/content/en/installation/linux/multiple-node-multiple-disk.md b/content/en/installation/linux/multiple-node-multiple-disk.md
index 797c9cd9e..df0e26341 100644
--- a/content/en/installation/linux/multiple-node-multiple-disk.md
+++ b/content/en/installation/linux/multiple-node-multiple-disk.md
@@ -1,16 +1,16 @@
 ---
 title: "RustFS Multiple Node Multiple Disk Installation"
-description: "Install RustFS on multiple servers with multiple disks, data will be stored on multiple disks across multiple servers."
+description: "Install a distributed RustFS cluster across multiple servers, each with multiple disks."
 ---
 
-Multiple Node Multiple Disk (MNMD) mode is the deployment mode for production workloads, providing enterprise-grade performance, security, and scalability. A minimum of **4 servers** is required, each with at least 1 disk, to safely start a distributed object storage cluster.
+Multiple Node Multiple Disk (MNMD) mode is the production deployment for clusters that span multiple servers. A minimum of **4 servers** is required, each with at least 1 disk, to safely start a distributed object storage cluster.
 
 ## Topology and Planning
 
 In the following architecture, requests are distributed to the servers through load balancing. With the default 12 + 4 erasure coding layout, each object is split into 12 data shards and 4 parity shards stored on different disks across different servers:
 
-- Any single server failure or maintenance does not affect data security.
-- Corruption of up to 4 disks does not affect data security.
+- The cluster stays available and loses no data if any single server fails or is taken down for maintenance.
+- The cluster can tolerate the loss of up to 4 disks without data loss.
 
 ```mermaid
 flowchart TD
@@ -29,19 +29,19 @@ flowchart TD
     class N1D1,N1D2,N1D3,N1D4,N2D1,N2D2,N2D3,N2D4,N3D1,N3D2,N3D3,N3D4,N4D1,N4D2,N4D3,N4D4 disk
 ```
 
-Before installation, review the [Pre-Installation Checklists](../requirement/checklists/index.md) and ensure all items meet production guidance.
+Before installation, review the [Pre-Installation Checklists](../requirement/checklists/index.md) and make sure that every item meets production requirements.
 
 ## Hostnames
 
-Creating a RustFS cluster requires **identical, sequential** hostnames. There are two ways to achieve sequential hostnames:
+A RustFS cluster requires hostnames that follow a consistent, sequentially numbered pattern (for example, `node1` through `node4`). There are two ways to achieve sequential hostnames:
 
 **1. DNS Configuration:**
 
-Configure your DNS resolution server to ensure name continuity.
+Create DNS records so that each sequential hostname resolves to the correct node.
 
-**2. HOSTS Configuration:**
+**2. `/etc/hosts` configuration:**
 
-Modify the local alias settings in `/etc/hosts` as follows:
+Add the following entries to `/etc/hosts` on every node:
 
 ```bash title="/etc/hosts"
 vim /etc/hosts
@@ -86,7 +86,7 @@ sudo mkdir -p /data/rustfs{0..3} /var/log/rustfs /opt/tls
 sudo chmod -R 750 /data/rustfs* /var/log/rustfs
 ```
 
-## Start Service and Verification
+## Start and verify the service
 
 1. Start the service on every node and enable auto-start on boot:
 
diff --git a/content/en/installation/linux/prerequisites-and-service.md b/content/en/installation/linux/prerequisites-and-service.md
index 184bd2259..3e27d8fed 100644
--- a/content/en/installation/linux/prerequisites-and-service.md
+++ b/content/en/installation/linux/prerequisites-and-service.md
@@ -5,13 +5,13 @@ description: "Common prerequisites, disk preparation, binary installation, and s
 
 This page contains the prerequisites and service setup steps shared by all three Linux deployment modes — [SNSD](./single-node-single-disk.md), [SNMD](./single-node-multiple-disk.md), and [MNMD](./multiple-node-multiple-disk.md). Complete these steps first, then return to your mode page to configure the environment file and start the service.
 
-## Operating System Version
+## Operating system version
 
 We recommend Linux kernel version 4.x or later; versions 5.x/6.x achieve better I/O throughput and network performance. Ubuntu 22.04 and RHEL 8.x are both suitable for installing RustFS.
 
 ## Firewall
 
-Linux systems have firewalls enabled by default. Check the firewall status with:
+Many Linux distributions enable a firewall by default. Check the firewall status with:
 
 ```bash
 systemctl status firewalld
@@ -196,36 +196,36 @@ The difference between any two nodes should be negligible (under 1 millisecond i
 When planning object storage capacity, we recommend considering:
 
 - Initial data volume: How much data do you plan to migrate or store at once? (e.g., 500 TB)
-- Data growth volume: Daily/weekly/monthly data growth capacity
-- Planning cycle: How long should this hardware planning last? (recommended: 3 years)
-- Your company's hardware iteration and update cycles.
+- Data growth rate: expected daily, weekly, or monthly growth
+- Planning horizon: How long should this hardware last? (We recommend 3 years.)
+- Your organization's hardware refresh cycle.
 
 Review [EC Configuration](../requirement/ec-configuration.md) to calculate usable capacity, understand the automatic parity defaults, and validate any explicit parity or erasure-set width before deployment.
 
 ## Disk Planning
 
-Because NFS generates phantom writes and lock issues under high I/O, **NFS is prohibited** as the underlying storage medium for RustFS. We strongly recommend **JBOD (Just a Bunch of Disks)** mode: expose physical disks directly and independently to the operating system, and let the RustFS software layer handle data redundancy and protection.
+**Do not use NFS** as the underlying storage for RustFS: under heavy I/O, NFS can cause phantom writes and locking problems. We strongly recommend **JBOD (Just a Bunch of Disks)** mode: expose physical disks directly and independently to the operating system, and let the RustFS software layer handle data redundancy and protection.
 
-The reasons are as follows:
+This approach has several advantages:
 
-- **Better Performance:** RustFS's Erasure Coding engine is highly optimized and reads/writes multiple disks concurrently, achieving higher throughput than hardware RAID controllers. Hardware RAID becomes a performance bottleneck.
+- **Better Performance:** The RustFS erasure coding engine is highly optimized and reads/writes multiple disks concurrently, achieving higher throughput than hardware RAID controllers. Hardware RAID becomes a performance bottleneck.
 - **Lower Cost:** No expensive RAID cards needed, reducing hardware procurement costs.
-- **Simpler Management:** RustFS manages disks uniformly, simplifying storage layer operations and maintenance.
+- **Simpler Management:** RustFS manages disks uniformly, simplifying storage operations.
 - **Faster Fault Recovery:** The RustFS healing process is faster than a traditional RAID rebuild and has less impact on cluster performance.
 
 We recommend NVMe SSDs as the storage medium for higher performance and throughput.
 
 ## File System Selection
 
-RustFS strongly recommends formatting all storage disks with the XFS file system. RustFS development and testing are based on XFS, ensuring optimal performance and stability. Avoid other file systems such as ext4, BTRFS, or ZFS, as they may cause performance degradation or unpredictable issues.
+We strongly recommend formatting all data disks with XFS. RustFS is developed and tested on XFS. Avoid other file systems such as ext4, Btrfs, or ZFS, as they may cause performance degradation or unpredictable issues.
 
 XFS suits RustFS's workload for three reasons:
 
 - **High-concurrency I/O:** XFS was designed for high performance and scalability. Its internal journaling and data structures (such as B+ trees) efficiently handle large numbers of parallel read/write requests, matching how RustFS shards large objects and reads/writes multiple disks in an erasure set in parallel.
-- **Massive files and large file sizes:** XFS is a 64-bit file system supporting extremely large files (up to 8 EB). Its metadata management stays efficient even with millions of files in a single directory — important because RustFS stores each object (or object version) as an independent file.
+- **Many files and very large files:** XFS is a 64-bit file system supporting extremely large files (up to 8 EB). Its metadata management stays efficient even with millions of files in a single directory — important because RustFS stores each object (or object version) as an independent file.
 - **Space reservation:** XFS provides an efficient `fallocate` API. RustFS uses it to reserve contiguous disk space before writing objects, avoiding the overhead of dynamic expansion and metadata updates during writes and minimizing file fragmentation.
 
-For better disk discovery, we recommend using **Label** tags when formatting XFS file systems.
+To make disks easier to identify and mount, we recommend assigning a file system label (`-L`) when you format each disk.
 
 First, check the disk layout:
 
@@ -250,7 +250,7 @@ sudo mkfs.xfs  -i size=512 -n ftype=1 -L RUSTFS0 /dev/sdb
 Formatting options:
 
 - `-L <label>`: Set a label for the file system for easier identification and mounting.
-- `-i size=512`: We recommend an inode size of 512 bytes, which benefits scenarios storing large numbers of small objects (metadata).
+- `-i size=512`: We recommend an inode size of 512 bytes, which helps workloads that store many small objects.
 - `-n ftype=1`: Enable ftype so the file system records file types in directory structures, improving operations such as readdir and unlink.
 
 Mounting:
@@ -266,9 +266,9 @@ LABEL=RUSTFS0 /data/rustfs0   xfs   defaults,noatime,nodiratime   0   0
 sudo mount -a
 ```
 
-## Configure Service User
+## Configure the service user
 
-We recommend running RustFS as a dedicated user without login permissions.
+We recommend running RustFS as a dedicated user with no login shell.
 
 1. **Keep the default account:** The default user and group in the service unit are `root` and `root`; no changes are needed if you use them.
 2. **Use a dedicated account:** Create a user and group, then update the service unit accordingly.
diff --git a/content/en/installation/linux/quick-start.md b/content/en/installation/linux/quick-start.md
index b3afc15eb..f4b8462da 100644
--- a/content/en/installation/linux/quick-start.md
+++ b/content/en/installation/linux/quick-start.md
@@ -1,6 +1,6 @@
 ---
 title: "Quick Start"
-description: "Install RustFS with the one-click script, log in to the Console, and store your first object — in about ten minutes."
+description: "Install RustFS with the installation script, log in to the Console, and store your first object — in about ten minutes."
 ---
 
 This guide takes you from an empty Linux server to a working RustFS instance: install, log in to the Console, create a bucket, and upload your first object. Production planning (multi-node layout, hardware sizing) is deliberately left for [the next step](#next-steps).
@@ -60,7 +60,7 @@ Open `http://<server-ip>:9001` in your browser and sign in with the access key a
 
 ## 4. Create a bucket and upload a file
 
-1. In the Console home page, select **Create Bucket**, name it (for example `my-bucket`), and confirm.
+1. On the Console home page, select **Create Bucket**, name it (for example `my-bucket`), and confirm.
 2. Open the bucket and use the upload action to add any local file.
 3. Click the uploaded object to view its details — you have a working object store.
 
diff --git a/content/en/installation/linux/single-node-multiple-disk.md b/content/en/installation/linux/single-node-multiple-disk.md
index 4f4c26906..500a4b852 100644
--- a/content/en/installation/linux/single-node-multiple-disk.md
+++ b/content/en/installation/linux/single-node-multiple-disk.md
@@ -1,13 +1,13 @@
 ---
 title: "RustFS Single Node Multiple Disk Installation"
-description: "Install RustFS on a single server with multiple disks, data will be stored on multiple disks."
+description: "Install RustFS on a single server and distribute data across multiple disks."
 ---
 
-In Single Node Multiple Disk (SNMD) mode, one server stores data in sharded form across multiple data disks. Each object is split into K data shards and M parity shards (erasure coding), so the loss of up to M disks does not cause data loss.
+In Single Node Multiple Disk (SNMD) mode, one server shards data across multiple data disks. Each object is split into K data shards and M parity shards (erasure coding), so the loss of up to M disks does not cause data loss.
 
 :::warning
 
-SNMD is suitable for medium, non-critical business. Damage to at most M disks does not pose a data risk, but if the entire server fails or more than M disks are damaged, data will be lost. Keep backups of important data. For node-level fault tolerance, use [MNMD](./multiple-node-multiple-disk.md).
+SNMD is suitable for mid-sized, non-critical workloads. The deployment can lose up to M disks without losing data, but if the entire server fails or more than M disks are damaged, data will be lost. Keep backups of important data. For node-level fault tolerance, use [MNMD](./multiple-node-multiple-disk.md).
 
 :::
 
@@ -55,9 +55,9 @@ sudo mkdir -p /data/rustfs{0..3} /var/log/rustfs /opt/tls
 sudo chmod -R 750 /data/rustfs* /var/log/rustfs
 ```
 
-## Start Service and Verification
+## Start and verify the service
 
-1. Start the service and enable auto-start on boot:
+1. Start the service and enable it to start at boot:
 
 ```bash
 sudo systemctl enable --now rustfs
diff --git a/content/en/installation/linux/single-node-single-disk.md b/content/en/installation/linux/single-node-single-disk.md
index b6c96e62f..77ca8a59b 100644
--- a/content/en/installation/linux/single-node-single-disk.md
+++ b/content/en/installation/linux/single-node-single-disk.md
@@ -1,13 +1,13 @@
 ---
 title: RustFS Single Node Single Disk Installation
-description: Install RustFS on a single disk of a single server, data will be stored on this one disk.
+description: Install RustFS on a single server that stores all data on one disk.
 ---
 
 In Single Node Single Disk (SNSD) mode, one server stores all data on a single data disk. It is the simplest deployment mode and the same topology that the [Linux Quick Start](./quick-start.md) script sets up.
 
 :::warning
 
-A single disk offers no redundancy: if the disk fails, data is lost. SNSD is suitable for development, testing, and low-density non-critical business. For production use, maintain regular data backups or choose [SNMD](./single-node-multiple-disk.md) / [MNMD](./multiple-node-multiple-disk.md).
+A single disk offers no redundancy: if the disk fails, data is lost. SNSD is suitable for development, testing, and small non-critical workloads. For production use, maintain regular data backups or choose [SNMD](./single-node-multiple-disk.md) / [MNMD](./multiple-node-multiple-disk.md).
 
 :::
 
@@ -54,9 +54,9 @@ sudo mkdir -p /data/rustfs0 /var/log/rustfs /opt/tls
 sudo chmod -R 750 /data/rustfs* /var/log/rustfs
 ```
 
-## Start Service and Verification
+## Start and verify the service
 
-1. Start the service and enable auto-start on boot:
+1. Start the service and enable it to start at boot:
 
 ```bash
 sudo systemctl enable --now rustfs
@@ -80,7 +80,7 @@ netstat -ntpl
 tail -f /var/log/rustfs/rustfs*.log
 ```
 
-5. Access the console: enter the server's IP address and the console port (default 9001) in a browser. You should see:
+5. Open the Console: in a browser, go to `http://<server-ip>:9001`. You should see:
 
 ![Console](./images/console.jpg)
 
diff --git a/content/en/installation/macos/index.md b/content/en/installation/macos/index.md
index 2cb290a79..ad87aee2e 100644
--- a/content/en/installation/macos/index.md
+++ b/content/en/installation/macos/index.md
@@ -13,7 +13,7 @@ These procedures run RustFS as a desktop process, not as a macOS background serv
 
 ## 1. Check your Mac architecture
 
-RustFS distinguishes between Apple Silicon (`arm64`) and Intel (`x86_64`) Macs. Open Terminal and run:
+RustFS provides different builds for Apple silicon (`arm64`) and Intel (`x86_64`) Macs. Open Terminal and run:
 
 ```bash
 uname -m
diff --git a/content/en/installation/requirement/checklists/hardware-checklists.md b/content/en/installation/requirement/checklists/hardware-checklists.md
index 8250d5512..f4d5de2a7 100644
--- a/content/en/installation/requirement/checklists/hardware-checklists.md
+++ b/content/en/installation/requirement/checklists/hardware-checklists.md
@@ -1,34 +1,34 @@
 ---
-title: "Production Environment Hardware Configuration Guide"
-description: "RustFS is a high-performance distributed object storage system developed in Rust, suitable for massive unstructured data storage scenarios. This document provides comprehensive hardware selection and configuration guidance for production environment deployment."
+title: "Production Hardware Guide"
+description: "This page provides hardware sizing and configuration guidance for production RustFS deployments."
 ---
 
-## Deployment Planning Factor Analysis
+## Planning considerations
 
-Before formally deploying RustFS, it's recommended to conduct 2-3 weeks of business research, focusing on evaluating the following dimensions:
+Before deploying RustFS in production, assess your workload and capacity requirements over a two- to three-week period. Focus on the following factors:
 
-1. **Data Scale Analysis**
+1. **Data volume**
 
-- **Initial Data Volume**: Accurately calculate effective data volume at production startup (recommended in TiB units), considering hot/cold data ratios
-- **Growth Trend Prediction**: Estimate data increments for the next 24 months based on business development plans (recommended quarterly growth rate model)
-- **Object Scale**: Calculate total object count based on average object size (recommended 128 KB-1 MB range), note special optimization needed when exceeding 100 million objects
+   - **Initial data volume**: Estimate the usable data volume at go-live (in TiB), including the ratio of hot to cold data.
+   - **Growth forecast**: Estimate data growth for the next 24 months based on business plans. We recommend modeling growth quarterly.
+   - **Object count**: Estimate the total number of objects from the average object size (ideally 128 KB to 1 MB). Deployments with more than 100 million objects need additional tuning.
 
-2. **Business Characteristic Assessment**
+2. **Workload characteristics**
 
-- **Access Patterns**: Distinguish read-intensive (such as content distribution) from write-intensive (such as log collection) scenarios
-- **Compliance Requirements**: Data retention cycles must comply with industry regulatory requirements (e.g., financial industry must retain for at least 5 years)
-- **Multi-site Deployment**: Cross-regional deployment requires network latency assessment (recommended controlled within 50ms) and bandwidth cost evaluation
+   - **Access patterns**: Distinguish read-intensive workloads (such as content distribution) from write-intensive workloads (such as log collection).
+   - **Compliance requirements**: Retention periods must meet industry regulations (for example, some financial regulations require at least five years of retention).
+   - **Multi-site deployment**: For cross-region deployments, assess network latency (ideally under 50 ms) and bandwidth costs.
 
-3. **Storage Architecture Design**
+3. **Storage architecture**
 
-- **Bucket Planning**: Divide storage buckets by business units, single cluster recommended not exceeding 500 active buckets
-- **Disaster Recovery Strategy**: Choose dual-active architecture (recommended) or asynchronous replication based on data importance
+   - **Bucket planning**: Organize buckets by business unit. We recommend no more than 500 active buckets per cluster.
+   - **Disaster recovery**: Choose active-active replication (recommended) or asynchronous replication based on how critical the data is.
 
 ## Hardware Configuration Matrix
 
-Baseline configuration solutions based on stress test results:
+Baseline configurations based on load-test results:
 
-| Component | Basic Environment | Production Standard Configuration | High-Performance Configuration |
+| Component | Entry level | Standard production | High performance |
 |--------------|---------------------------|--------------------------|--------------------------|
 | Node Count | 4 nodes | 8 nodes | 16+ nodes |
 | Storage Media | 4× NVMe SSD | 8×NVMe SSD | 12×NVMe SSD |
@@ -37,57 +37,57 @@ Baseline configuration solutions based on stress test results:
 | Memory | 64 GB DDR4-3200 ECC | 256 GB DDR5-4800 ECC | 512 GB DDR5-5600 ECC |
 | Storage Controller | HBA 9500-8i | HBA 9600-16i | Dual controller redundant architecture |
 
-**Important Deployment Principles:**
+**Deployment guidelines:**
 
-1. Adopt "server farm" mode, ensuring all nodes use identical hardware batches and firmware versions
-2. Network architecture must meet: leaf-spine topology + physically isolated storage network + dual uplink paths
-3. Recommend using 2U server models, single node recommended configuration of 12+ disk bays (based on actual hard disk count)
+1. Use homogeneous nodes: every node should have identical hardware from the same batch and the same firmware versions.
+2. The network must use a leaf-spine topology, a physically isolated storage network, and dual uplinks.
+3. We recommend 2U servers with at least 12 drive bays per node, depending on the number of drives required.
 
-## Performance Critical Path Optimization
+## Performance tuning
 
 ### Network Topology Optimization (Highest Priority)
 
-- **Bandwidth Calculation**: Reserve 0.5 Gbps bandwidth per TB of effective data (e.g., 100 TB data needs 50 Gbps dedicated bandwidth)
+- **Bandwidth sizing**: Provision 0.5 Gbps of bandwidth per TB of usable data (for example, 100 TB of data needs 50 Gbps of dedicated bandwidth).
 - **Latency Requirements**:
-- Inter-node P99 latency ≤ 2ms
-- Cross-rack latency ≤ 5ms
+  - Inter-node P99 latency ≤ 2ms
+  - Cross-rack latency ≤ 5ms
 
 ### Storage Subsystem Tuning
 
 - **Controller Configuration**:
-- Enable read-ahead cache (recommended 256 MB+)
-- Disable all RAID functions, use pass-through mode
-- Regularly check BBU battery health status
+  - Enable read-ahead cache (recommended 256 MB+)
+  - Disable all RAID features and use pass-through (HBA/JBOD) mode.
+  - Check BBU health regularly.
 - **SSD Parameters**:
-- Reserve 20% OP space to improve durability
-- Enable atomic write features (requires hardware support)
+  - Reserve 20% over-provisioning (OP) space to improve endurance.
+  - Enable atomic writes (requires hardware support).
 
-### Memory Management Strategy
+### Memory allocation
 
 - **Allocation Ratios**:
-- Metadata cache: 60% of total memory
-- Read/write buffers: 30%
-- System reserve: 10%
+  - Metadata cache: 60% of total memory
+  - Read/write buffers: 30%
+  - System reserve: 10%
 
 ## Network Design Reference Model
 
-### Bandwidth and Disk Ratio Relationship
+### Network bandwidth vs. disk count
 
-| Network Type | Theoretical Throughput | Suitable Disk Types | Maximum Disk Support |
+| Network | Theoretical throughput | Disk type | Max disks per node |
 |------------|------------|---------------------|----------------|
 | 10GbE | 1.25 GB/s | 7.2K HDD (180 MB/s) | 8 disks |
 | 25GbE | 3.125 GB/s | SATA SSD (550 MB/s) | 6 disks |
-| 100GbE | 12.5 GB/s | NVMe Gen4 (7 GB/s) | 2 disks full-speed read/write |
+| 100GbE | 12.5 GB/s | NVMe Gen4 (7 GB/s) | 2 (at full read/write speed) |
 
-**Best Practice Case**: A video platform uses 16-node cluster, each node configured with:
+**Example**: A video platform runs a 16-node cluster. Each node has:
 
 - 8×7.68 TB NVMe SSD
-- Dual 100GbE CX5 network cards
+- Dual 100GbE NVIDIA ConnectX-5 NICs
 - Achieves aggregate throughput of 38 GB/s
 
-## Memory Configuration Calculator
+## Memory sizing
 
-Dynamic algorithm based on disk capacity and business characteristics:
+Use the following formula to size memory based on disk capacity and workload type:
 
 ```python
 # Memory calculation formula (unit: GB)
@@ -101,23 +101,23 @@ def calc_memory(data_tb, access_pattern):
  return base + data_tb * 1.0
 ```
 
-**Reference Configuration Table**:
+**Reference sizes**:
 
-| Data Scale | Read-Intensive | Write-Intensive | Mixed |
+| Data size | Read-heavy | Write-heavy | Mixed |
 |-----------|----------|----------|---------|
 | 10 TB | 40 GB | 44 GB | 42 GB |
 | 100 TB | 112 GB | 152 GB | 132 GB |
 | 500 TB | 432 GB | 632 GB | 532 GB |
 
-## Storage Deployment Standards
+## Storage guidelines
 
-### Media Selection Criteria
+### Choosing storage media
 
-| Metric | HDD Suitable Scenarios | SSD Suitable Scenarios | NVMe Mandatory Scenarios |
+| Metric | HDD | SATA SSD | NVMe (required) |
 |-------------|------------------|---------------------|----------------------|
 | Latency Requirements | >50ms | 1 to 10ms | < 1ms |
 | Throughput Requirements | < 500 MB/s | 500 MB-3 GB/s | > 3 GB/s |
-| Typical Use Cases | Archive storage | Hot data cache | Real-time analysis |
+| Typical use cases | Archival storage | Hot-data cache | Real-time analytics |
 
 ### File System Configuration
 
@@ -129,30 +129,34 @@ mkfs.xfs -f -L rustfs_disk1 -d su=256k,sw=10 /dev/sdb
 UUID=xxxx /mnt/disk1 xfs defaults,noatime,nodiratime,logbsize=256k 0 0
 ```
 
-## High Availability Assurance Measures
+## High availability
 
 1. **Power Supply**:
 
-- Adopt dual power supply architecture
-- Each PDU connects to different substations
-- Equip UPS (at least 30 minutes runtime)
+   - Use dual (redundant) power supplies.
+   - Connect each PDU to a separate power feed.
+   - Provide a UPS with at least 30 minutes of runtime.
 
 2. **Cooling Requirements**:
 
-- Cabinet power density ≤ 15kW/cabinet
-- Inlet/outlet temperature difference controlled within 8℃
+   - Rack power density ≤ 15 kW per rack.
+   - Keep the inlet-to-outlet temperature difference (ΔT) within 8 °C.
 
 3. **Firmware Management**:
 
-- Establish hardware compatibility matrix
-- Use unified firmware versions
+   - Maintain a hardware compatibility matrix.
+   - Standardize on the same firmware versions across nodes.
 
-> **Implementation Recommendations**: Recommend conducting 72-hour stress testing before formal deployment, simulating the following scenarios:
->
-> 1. Node failover testing
-> 2. Network partition drills
-> 3. Burst write pressure testing (recommended reaching 120% of theoretical value)
+:::tip[Before go-live]
+
+We recommend running a 72-hour stress test before production go-live that covers the following scenarios:
+
+1. Node failover testing
+2. Network partition tests
+3. Burst write load tests (we recommend testing at 120% of the theoretical maximum)
+
+:::
 
 ---
 
-This guide is based on the latest RustFS development version. For actual deployment, please combine with specific hardware vendor white papers for parameter fine-tuning. Or contact RustFS official recommendations for quarterly hardware health assessments to ensure continuous stable operation of storage clusters.
+This guide is based on the latest RustFS development version. For production deployments, fine-tune these settings using your hardware vendor's documentation. For quarterly hardware health assessments, contact RustFS.
diff --git a/content/en/installation/requirement/checklists/hardware-selection.md b/content/en/installation/requirement/checklists/hardware-selection.md
index e81d490bf..0dd99906b 100644
--- a/content/en/installation/requirement/checklists/hardware-selection.md
+++ b/content/en/installation/requirement/checklists/hardware-selection.md
@@ -1,13 +1,13 @@
 ---
 title: Hardware Selection
-description: Hardware requirements for RustFS.
+description: This page lists minimum and recommended hardware for RustFS test and production environments.
 ---
 
 > RustFS is designed for efficiency with a low memory footprint.
 
 ## Test Environment
 
-> Minimal requirements for testing:
+Minimum requirements for testing:
 
 | Component | Requirement |
 | - | - |
@@ -16,7 +16,7 @@ description: Hardware requirements for RustFS.
 | Memory | 1 GB+ |
 | Storage | HDD or SSD |
 | Docker | Supported |
-| Network | Local or Offline |
+| Network | Local or offline |
 | OS | Windows, Linux, macOS |
 | Load Balancing | None |
 | Nodes | 1 |
@@ -34,6 +34,6 @@ description: Hardware requirements for RustFS.
 | Load Balancing | Recommended |
 | Nodes | 4+ |
 
-## Expert Services
+## Professional services
 
 For complex deployments, contact support at hello@rustfs.com.
diff --git a/content/en/installation/requirement/checklists/index.md b/content/en/installation/requirement/checklists/index.md
index 7b1f73a8b..1b36bb1fc 100644
--- a/content/en/installation/requirement/checklists/index.md
+++ b/content/en/installation/requirement/checklists/index.md
@@ -1,5 +1,5 @@
 ---
-title: "Checklist"
+title: "Pre-Installation Checklists"
 description: "Pre-installation checklists."
 ---
 
@@ -13,7 +13,7 @@ These are general guidelines. Adjust them based on your specific architecture an
 
 For professional support, contact us at hello@rustfs.com.
 
-For community support, submit an issue on GitHub.
+For community support, open an issue on GitHub.
 
 ## Checklist
 
diff --git a/content/en/installation/requirement/checklists/network-checklists.md b/content/en/installation/requirement/checklists/network-checklists.md
index 8f77cd5ad..9a48892f0 100644
--- a/content/en/installation/requirement/checklists/network-checklists.md
+++ b/content/en/installation/requirement/checklists/network-checklists.md
@@ -12,12 +12,12 @@ description: "Network checklist for enterprise deployments."
 - **Redundancy**
  Ensure at least two independent physical links between nodes.
 - **Bandwidth**
- Calculate estimated traffic: object storage read/write bandwidth × node count × replica count + 20% redundancy.
+ Estimate traffic as: read/write bandwidth × node count × replica count, plus 20% headroom.
 
 ### IP Allocation
 
 - [ ] Separate management network from data network.
-- [ ] Allocate continuous IP segments for storage nodes (recommend /24 subnet).
+- [ ] Allocate a contiguous IP address range for storage nodes. We recommend a /24 subnet.
 - [ ] Reserve at least 15% of IP addresses for expansion.
 
 ---
@@ -26,17 +26,17 @@ description: "Network checklist for enterprise deployments."
 
 ### Switches
 
-| Check Item | Requirements |
+| Item | Requirement |
 |--------|---------|
-| Backplane Bandwidth | ≥ Full port line rate forwarding capability × 1.2 |
+| Backplane bandwidth | ≥ 1.2 × aggregate line rate of all ports |
 | Port Type | 10G/25G/100G SFP+/QSFP+ fiber ports |
 | Flow Table Capacity | ≥ Node count × 5 |
-| Spanning Tree | Enable RSTP/MSTP fast convergence |
+| Spanning Tree | Enable RSTP or MSTP for fast convergence |
 
 ### Cabling
 
 - [ ] Fiber attenuation test (single mode ≤0.35dB/km).
-- [ ] Port misalignment check (Node A eth0 ↔ Node B eth0).
+- [ ] Verify port mapping (Node A eth0 ↔ Node B eth0).
 - [ ] Cable labeling (including source/destination IP + port number).
 
 ---
@@ -74,8 +74,8 @@ net.ipv4.tcp_slow_start_after_idle = 0
 
 ### Access Control
 
-- Switch port security MAC restrictions.
-- IPSec tunnel encryption between storage nodes.
+- Enable port security (MAC address limits) on switches.
+- Encrypt traffic between storage nodes with IPsec.
 - Enable TLS 1.3 for management interfaces.
 
 ---
@@ -92,7 +92,7 @@ net.ipv4.tcp_slow_start_after_idle = 0
 
 | Metric | Requirements |
 |------|------|
-| Node Latency | ≤1ms (same room) / ≤5ms (cross AZ) |
+| Node latency | ≤ 1 ms (same data center) / ≤ 5 ms (cross-AZ) |
 | Bandwidth Utilization | Peak ≤70% of design capacity |
 | Failover | < 500ms BPDU convergence |
 
@@ -103,12 +103,12 @@ net.ipv4.tcp_slow_start_after_idle = 0
 1. Network topology diagram (including physical connections and logical IPs)
 2. Switch configuration backup files (with timestamps)
 3. Baseline test reports (including raw data)
-4. Change record table (including maintenance window information)
+4. Change log (including maintenance windows)
 
 :::tip
 
-Recommend conducting 72-hour stress testing before formal deployment, simulating 110% peak traffic load scenarios
+We recommend running a 72-hour stress test at 110% of the expected peak traffic before deploying to production.
 
 :::
 
-This checklist covers key checkpoints for enterprise storage system network deployment, specifically optimized parameter requirements for distributed object storage characteristics. You can contact RustFS for official technical support.
+This checklist covers the key network requirements for deploying distributed object storage in an enterprise environment. For technical support, contact RustFS.
diff --git a/content/en/installation/requirement/checklists/security-checklists.md b/content/en/installation/requirement/checklists/security-checklists.md
index 5024450ed..3fbb917b8 100644
--- a/content/en/installation/requirement/checklists/security-checklists.md
+++ b/content/en/installation/requirement/checklists/security-checklists.md
@@ -8,7 +8,7 @@ description: "Security checklist for enterprise deployments."
 ## Authentication & Access Control
 
 - **Use S3-Compatible Key Authentication**
- RustFS uses AWS Signature V4. Ensure all requests are authenticated with valid Access Keys and Secret Keys.
+ RustFS uses AWS Signature V4. Make sure that all requests are signed with a valid access key and secret key.
 
 - **Policy-Based Access Control**
  Define access policies based on the principle of least privilege. Explicitly define allowed operations; deny all others by default.
@@ -16,13 +16,13 @@ description: "Security checklist for enterprise deployments."
 ## Encryption (TLS/SSL)
 
 - **Enable TLS/SSL**
- Configure valid SSL certificates. We recommend using different certificates for external and internal access, and enforcing TLS 1.2+.
+ Configure valid TLS certificates. We recommend using different certificates for external and internal access, and enforcing TLS 1.2+.
 
 - **Certificate Management**
  Use certificates from trusted CAs. Protect private keys with strict file permissions.
 
 - **Multi-Domain and Cipher Suites**
- Configure independent certificates for multiple domains. Use strong encryption algorithms (e.g., 2048-bit RSA or 256-bit ECC).
+ Use separate certificates for each domain. Use strong key algorithms (for example, RSA 2048-bit or ECDSA P-256).
 
 ## Credential Protection
 
@@ -38,13 +38,13 @@ description: "Security checklist for enterprise deployments."
  Export audit logs to external systems (HTTP Webhook, Kafka, ELK, Splunk).
 
 - **Log Collection**
- Collect logs using standard tools (systemd, Docker, K8s) and analyze with ELK or Grafana Loki.
+ Collect logs with standard tools (journald, Docker, Kubernetes) and analyze them with ELK or Grafana Loki.
 
 - **Monitoring and Alerts**
  Set alerts for abnormal behavior (login failures, unusual access patterns, mass deletions).
 
 - **Observability**
- Monitor function execution times to optimize performance.
+ Monitor request latency to identify performance issues.
 
 ## API Security
 
@@ -59,7 +59,7 @@ description: "Security checklist for enterprise deployments."
 
 ## WORM Compliance
 
-- **Version Control and Object Locking**
+- **Versioning and Object Lock**
  Enable versioning and object locking to meet regulatory requirements.
 
 ## Updates
diff --git a/content/en/installation/requirement/checklists/software-checklists.md b/content/en/installation/requirement/checklists/software-checklists.md
index d2ed35b81..a3416d7a7 100644
--- a/content/en/installation/requirement/checklists/software-checklists.md
+++ b/content/en/installation/requirement/checklists/software-checklists.md
@@ -25,7 +25,7 @@ Ensure the following requirements are met before deployment.
 ## File System & Disks
 
 - **Dedicated Data Disks**: Use dedicated disks for RustFS data. Do not share with the OS.
-- **File System**: Use XFS or Ext4 with performance options (e.g., `noatime`).
+- **File system**: Use XFS or ext4 with performance mount options such as `noatime`.
 - **Disk Configuration**: Use JBOD (independent volumes). Do not use hardware RAID.
 - **Permissions**: Ensure the RustFS user has read/write access to data directories.
 
@@ -42,7 +42,7 @@ Ensure the following requirements are met before deployment.
 - **Dedicated User**: Run RustFS as a dedicated user (e.g., `rustfs-user`).
 - **File Permissions**: Restrict access to binaries and configuration files.
 - **SELinux/AppArmor**: Configure policies to allow RustFS operations, or disable if appropriate.
-- **Systemd**: Configure the systemd service file correctly (`User=`, `ExecStart=`, environment variables).
+- **systemd**: Configure the systemd service file correctly (`User=`, `ExecStart=`, environment variables).
 
 ## Other
 
diff --git a/content/en/integration/tls-configured.md b/content/en/integration/tls-configured.md
index 862913e1d..c0df20e2e 100644
--- a/content/en/integration/tls-configured.md
+++ b/content/en/integration/tls-configured.md
@@ -1,6 +1,6 @@
 ---
 title: "TLS Configuration"
-description: "Configure TLS for secure access."
+description: "Enable TLS for the RustFS S3 API and Console on Linux and Docker."
 ---
 
 Configure TLS for secure access. Set the `RUSTFS_TLS_PATH` environment variable.
@@ -10,7 +10,7 @@ Configure TLS for secure access. Set the `RUSTFS_TLS_PATH` environment variable.
 ### Prerequisites
 
 - A running RustFS instance (see [Installation Guide](../installation/index.md)).
-- Certificate pair (cert and key).
+- A TLS certificate and its matching private key.
 
 **Note**: Certificates must be named `rustfs_cert.pem` and `rustfs_key.pem` and placed in the specified path.
 
@@ -54,4 +54,4 @@ TLS now applies to both listeners: the S3 API at `https://rustfs.example.com:900
 
 2. Restart the RustFS instance container, then access the S3 API at `https://rustfs.example.com:9000` and the Console at `https://rustfs.example.com:9001`.
 
-**Note**: Since the RustFS instance container runs as `rustfs` user by default, you need to ensure that the certificate files (`rustfs_key.pem` and `rustfs_cert.pem`) belong to the `rustfs` user, otherwise the RustFS instance will fail to read the certificate files due to permission issues, causing TLS configuration to fail.
+**Note**: The RustFS container runs as the `rustfs` user (UID `10001`). Make sure that `rustfs` owns `rustfs_key.pem` and `rustfs_cert.pem`; otherwise, RustFS cannot read the certificates and TLS fails to start.
diff --git a/content/en/integration/virtual.md b/content/en/integration/virtual.md
index 02a9ac4d5..ec2440d3c 100644
--- a/content/en/integration/virtual.md
+++ b/content/en/integration/virtual.md
@@ -1,18 +1,18 @@
 ---
-title: "Virtual Host Style"
+title: "Virtual-Hosted–Style Requests"
 description: "RustFS S3 Virtual Host Style and Path Style configuration."
 ---
 
-RustFS complies with S3 protocols. S3 supports two request modes:
+RustFS supports both S3 URL addressing styles:
 
 1. Virtual Host Style
 2. Path Style
 
-The difference lies in the bucket name placement.
+The two styles differ in where the bucket name appears in the URL.
 
 ## Path Style
 
-Path Style is the default. In Path Style, the bucket name follows the endpoint.
+Path-style addressing is the default. In a path-style URL, the bucket name follows the endpoint.
 
 Example (Bucket: `test`, Host: `rustfs.yourdomain.com`):
 
@@ -34,7 +34,7 @@ http://test.rustfs.yourdomain.com/
 
 ### Configuration
 
-1. **DNS**: Configure wildcard DNS resolution (e.g., `*.rustfs.yourdomain.com` -> Server IP).
+1. **DNS**: Create a wildcard DNS record (for example, `*.rustfs.yourdomain.com` → your server's IP address).
 2. **Configuration**: Modify the configuration file (Linux: `/etc/default/rustfs`, Docker/K8s: env vars).
 3. **Set Domain**: Set `RUSTFS_SERVER_DOMAINS = "rustfs.yourdomain.com"`.
 4. **Restart**: Restart the service (`systemctl restart rustfs`).
@@ -55,7 +55,11 @@ This ensures that requests like:
 http://my-bucket.rustfs.yourdomain.com:8000/
 ```
 
-can be correctly resolved in Virtual Host Style mode.
+are routed correctly with virtual-hosted–style addressing.
 
-> ⚠️ Note: The value of `RUSTFS_SERVER_DOMAINS` must exactly match the **Host header** (including the port, if present) used by the client request
+:::warning[Match the Host header]
+
+The value of `RUSTFS_SERVER_DOMAINS` must exactly match the `Host` header (including the port, if present) that clients send.
+
+:::
 
diff --git a/content/en/operations/cluster-lifecycle.md b/content/en/operations/cluster-lifecycle.md
index 33a8535c6..574c2be69 100644
--- a/content/en/operations/cluster-lifecycle.md
+++ b/content/en/operations/cluster-lifecycle.md
@@ -7,7 +7,7 @@ This runbook is the operator entry point for erasure-coded RustFS deployments: l
 
 Related task pages: [Storage Pool Expansion](./scaling/storage-pool-expansion.md), [Data Rebalancing](./scaling/data-rebalancing.md), [Storage Pool Decommission](./scaling/storage-pool-decommission.md), and [Node Healing](./high-availability/node-healing.md).
 
-## Layout boundaries
+## Layout constraints
 
 A pool's endpoint count, set count, drives per set, and position in the pool list are persisted layout. On startup RustFS compares the stored format with the configured drive count and set width and fails permanently with `PoolTopologyMismatch` (or `UnsupportedSnsdExpansion` for a single-drive deployment) instead of migrating. Restore the original endpoints and set width; do not delete `format.json` to get past the error.
 
@@ -50,7 +50,7 @@ A storage-class error stops startup before any disk is touched. Startup then ini
 
 ## Startup configuration
 
-| Variable | Effect | Boundary |
+| Variable | Effect | Constraints |
 |---|---|---|
 | `RUSTFS_ERASURE_SET_DRIVE_COUNT` | Pin the set width | Must be a valid symmetric divisor of the pool, at most 16; cannot change an initialized pool |
 | `RUSTFS_STORAGE_CLASS_STANDARD` | STANDARD parity as `EC:<n>` | Validated per pool; affects new writes only |
@@ -95,7 +95,7 @@ Writes resolve the layout per pool, encode with Reed-Solomon in 1 MiB blocks, wr
 
 `EC:0` is accepted for STANDARD, for RRS, or for both, on any set width. It gives raw capacity and no redundancy.
 
-:::danger[EC:0 means one drive loss equals set loss]
+:::danger[With EC:0, losing one drive loses data across the set]
 
 A replaced or wiped drive permanently loses every zero-parity object that had a shard on it, unless a copy exists outside the set. Healing cannot rebuild zero-parity objects: heal reports `no-parity object is unrecoverable` for them. Production deployments should use `EC:1` or higher; `EC:2` or more per set is the usual floor once a set spans more than one node. Use `EC:0` only where an external layer (RAID, replication, backup, or a re-creatable source) owns durability and availability, and only with explicit sign-off.
 
diff --git a/content/en/operations/credentials.md b/content/en/operations/credentials.md
index 91c4500e7..bda39a016 100644
--- a/content/en/operations/credentials.md
+++ b/content/en/operations/credentials.md
@@ -1,6 +1,6 @@
 ---
 title: "Credential Management"
-description: "This article covers configuring RustFS root credentials via environment variables and secret files, rotating them safely, the internode RPC secret, and the MinIO-compatible environment aliases."
+description: "Configure and rotate RustFS root credentials, set the internode RPC secret, and use MinIO-compatible environment aliases."
 ---
 
 ## Root Credentials
diff --git a/content/en/operations/observability.md b/content/en/operations/observability.md
index b0531ca3a..3acc695cb 100644
--- a/content/en/operations/observability.md
+++ b/content/en/operations/observability.md
@@ -1,6 +1,6 @@
 ---
 title: "Observability"
-description: "This article explains RustFS telemetry exports, monitoring integrations, metric names and labels, recommended alerts, and log collection."
+description: "Export RustFS metrics, traces, and logs over OTLP, integrate with monitoring tools, and configure recommended alerts."
 ---
 
 ## How RustFS Exposes Telemetry
diff --git a/content/en/operations/scaling/storage-pool-decommission.md b/content/en/operations/scaling/storage-pool-decommission.md
index 4b881793f..00ee052ff 100644
--- a/content/en/operations/scaling/storage-pool-decommission.md
+++ b/content/en/operations/scaling/storage-pool-decommission.md
@@ -81,7 +81,7 @@ To cancel a running operation, use:
 rc admin decommission cancel rustfs 0 --by-id
 ```
 
-If a decommission is failed or canceled, clear its metadata before retrying:
+If a decommission failed or was canceled, clear its metadata before you retry:
 
 ```bash
 rc admin decommission clear rustfs 0 --by-id
diff --git a/content/en/operations/status-check.md b/content/en/operations/status-check.md
index 9627a3b5e..16ec93e69 100644
--- a/content/en/operations/status-check.md
+++ b/content/en/operations/status-check.md
@@ -30,7 +30,7 @@ firewall-cmd --reload
 
 :::warning[Restrict console access]
 
-Expose port 9001 only to trusted networks. If you do not need the console, set `RUSTFS_CONSOLE_ENABLE=false` and leave the port closed.
+Expose port 9001 only to trusted networks. If you do not need the Console, set `RUSTFS_CONSOLE_ENABLE=false` and leave the port closed.
 
 :::
 
diff --git a/content/en/security-compliance/encryption/kms.md b/content/en/security-compliance/encryption/kms.md
index a1db65686..90f3b40c7 100644
--- a/content/en/security-compliance/encryption/kms.md
+++ b/content/en/security-compliance/encryption/kms.md
@@ -115,9 +115,9 @@ For Vault Transit, you can alternatively create the named Transit key directly i
 vault write -f transit/keys/rustfs-default-key
 ```
 
-:::note[rc version boundary]
+:::note[rc version requirements]
 
-The tested `rc 0.1.29` on the validation host does not expose `rc admin kms`; it supports only the bucket and object encryption commands used below. Run `rc admin --help` before following the key lifecycle commands. If the KMS command family is absent, use a newer `rc` release that includes it or provision the key through the native RustFS KMS Admin API.
+`rc 0.1.29` does not include `rc admin kms`; it supports only the bucket and object encryption commands used below. Run `rc admin --help` before following the key lifecycle commands. If the KMS command family is absent, use a newer `rc` release that includes it or provision the key through the native RustFS KMS Admin API.
 
 :::
 
diff --git a/content/en/security-compliance/encryption/sse-s.md b/content/en/security-compliance/encryption/sse-s.md
index 7a4a9929b..e4889e059 100644
--- a/content/en/security-compliance/encryption/sse-s.md
+++ b/content/en/security-compliance/encryption/sse-s.md
@@ -62,7 +62,7 @@ rc bucket encryption info rustfs/my-bucket
 
 Clearing or changing the bucket default affects only later writes. It does not decrypt or rewrite existing objects.
 
-## Request contract
+## Request headers
 
 S3 clients request SSE-S3 with:
 
diff --git a/content/en/security-compliance/iam/access-token.md b/content/en/security-compliance/iam/access-token.md
index f3442e3b1..cdd5bf791 100644
--- a/content/en/security-compliance/iam/access-token.md
+++ b/content/en/security-compliance/iam/access-token.md
@@ -1,29 +1,29 @@
 ---
-title: "RustFS Access Key Management"
-description: "Creation, usage, and deletion of RustFS access keys."
+title: "Access Keys"
+description: "Create and delete RustFS access keys in the Console."
 ---
 
-RustFS access keys are the core credentials of the RustFS system, used for identity authentication and operation authorization, and are very useful in API and SDK scenarios. This chapter introduces the creation and deletion of RustFS access keys.
+Access keys are the credentials that applications and tools use to authenticate to RustFS and to authorize their requests. This page shows how to create and delete access keys in the Console.
 
-Prerequisites:
+## Prerequisites
 
-- An available RustFS instance. You can refer to the [Installation Guide](../../installation/index.md) for installation.
+- A running RustFS instance. See the [Installation Guide](../../installation/index.md).
 
 ## Creating Access Keys
 
-1. Log in to the RustFS UI console.
+1. Sign in to the RustFS Console.
 2. In the left navigation bar, select **Access Keys**.
 3. On the access keys page, in the upper right corner, click **Add Access Key**.
-4. Enter the key's **expiration time, name, and description**, then click **Submit**.
-5. (Optional but recommended). On the access key page that appears, select **Copy** or **Export** to save the access key for future use.
+4. Enter an **Expiration**, **Name**, and **Description** for the key, and then select **Submit**.
+5. (Recommended) On the page that appears, select **Copy** or **Export** to save the key.
 
 ![access key list page](images/access_token_creation.png)
 
 ## Deleting Access Keys
 
-1. Log in to the RustFS UI console.
+1. Sign in to the RustFS Console.
 2. In the left navigation bar, select **Access Keys**.
 3. On the access keys page, select the access key you want to delete.
-4. Select the **Delete** button on the right side of the access key or **Delete Selected Items** in the upper right corner to delete the access key.
+4. Select **Delete** next to the access key, or select **Delete Selected Items** in the upper-right corner.
 
 ![access key deletion](images/access_token_deletion.png)
\ No newline at end of file
diff --git a/content/en/security-compliance/iam/index.md b/content/en/security-compliance/iam/index.md
index 2d23161d0..6ddb84a96 100644
--- a/content/en/security-compliance/iam/index.md
+++ b/content/en/security-compliance/iam/index.md
@@ -1,5 +1,5 @@
 ---
-title: "RustFS IAM Management"
+title: "Identity and Access Management"
 description: "Overview of RustFS Identity and Access Management (IAM): identity types, policy attachment, and policy evaluation semantics."
 ---
 
diff --git a/content/en/troubleshooting/driver.md b/content/en/troubleshooting/driver.md
index f0d48390f..632340d2f 100644
--- a/content/en/troubleshooting/driver.md
+++ b/content/en/troubleshooting/driver.md
@@ -1,24 +1,15 @@
 ---
-title: "Hard Drive Failures"
-description: "RustFS ensures read/write access can still be provided when some disks fail through mechanisms similar to erasure coding, and automatically heals data after replacing disks."
+title: "Drive Failures"
+description: "Replace a failed drive in a RustFS deployment and let RustFS heal the data automatically."
 ---
 
-RustFS ensures read/write access can still be provided when some disks fail through mechanisms similar to erasure coding, and automatically heals data after replacing disks.
-
-## Table of Contents
-
-1. [Unmount Failed Disk](#unmount-failed-disk)
-2. [Replace Failed Disk](#replace-failed-disk)
-3. [Update `/etc/fstab` or RustFS Configuration](#update-etcfstab-or-rustfs-configuration)
-4. [Remount New Disk](#remount-new-disk)
-5. [Trigger and Monitor Data Healing](#trigger-and-monitor-data-healing)
-6. [Follow-up Checks and Notes](#follow-up-checks-and-notes)
+RustFS uses erasure coding to keep data readable and writable when some drives fail. After you replace a failed drive, RustFS heals the missing data onto it automatically.
 
 <a id="unmount-failed-disk"></a>
 
-### Unmount Failed Disk
+### Unmount the failed disk
 
-Before replacing the physical hard drive, you need to safely unmount the failed disk from the operating system level to avoid I/O errors in the file system or RustFS during the replacement process.
+Before replacing the physical hard drive, unmount the failed disk at the operating system level to prevent I/O errors in the file system or RustFS during replacement.
 
 ```bash
 # Assume the failed disk is /dev/sdb
@@ -27,8 +18,8 @@ umount /dev/sdb
 
 :::note[Notes]
 
-* If there are multiple mount points, execute `umount` separately.
-* If encountering "device is busy", you can first stop the RustFS service:
+* If the disk has multiple mount points, run `umount` on each one.
+* If you see a "device is busy" error, stop the RustFS service first:
 
 ```bash
 systemctl stop rustfs
@@ -38,7 +29,7 @@ systemctl stop rustfs
 
 <a id="replace-failed-disk"></a>
 
-### Replace Failed Disk
+### Replace the failed disk
 
 After physically replacing the failed disk, you need to partition and format the new disk, and apply the same label as the original disk.
 
@@ -47,17 +38,19 @@ After physically replacing the failed disk, you need to partition and format the
 mkfs.xfs -L DISK1 /dev/sdb
 ```
 
-> **Requirements**
->
-> * New disk capacity ≥ original disk capacity;
-> * File system type consistent with other disks (XFS, per the [installation guide](../installation/linux/index.md));
-> * Recommend using labels (LABEL) or UUID for mounting to ensure disk order is not affected by system restarts.
+:::note[Requirements]
+
+* The new disk is at least as large as the original disk.
+* Use the same file system as the other disks (XFS; see the [installation guide](../installation/linux/index.md)).
+* We recommend mounting file systems by label (LABEL) or UUID so that mounts remain correct if device names change after a restart.
+
+:::
 
 <a id="update-etcfstab-or-rustfs-configuration"></a>
 
-### Update `/etc/fstab` or RustFS Configuration
+### Update `/etc/fstab` or the RustFS configuration
 
-Confirm that the mount item labels or UUIDs in `/etc/fstab` point to the new disk. The mount point must stay identical to the one listed in `RUSTFS_VOLUMES` (in `/etc/default/rustfs`), so the healed disk rejoins the cluster at the same path.
+Confirm that the labels or UUIDs in the `/etc/fstab` entries point to the new disk. The mount point must stay identical to the one listed in `RUSTFS_VOLUMES` (in `/etc/default/rustfs`), so the healed disk rejoins the cluster at the same path.
 
 ```bash
 # View current fstab
@@ -76,7 +69,7 @@ blkid /dev/sdb
 # Get the new partition's UUID, then replace the corresponding field in fstab
 ```
 
-* After modifying fstab, be sure to validate syntax:
+* After you edit `/etc/fstab`, validate the syntax:
 
 ```bash
 mount -a # If no errors, configuration is correct
@@ -86,30 +79,30 @@ mount -a # If no errors, configuration is correct
 
 <a id="remount-new-disk"></a>
 
-### Remount New Disk
+### Remount the new disk
 
-Execute the following commands to batch mount all disks and start the RustFS service:
+Run the following commands to mount all configured file systems and start RustFS:
 
 ```bash
 mount -a
 systemctl start rustfs
 ```
 
-Confirm all disks are mounted normally:
+Verify that all expected file systems are mounted:
 
 ```bash
 df -h | grep /data/rustfs
 ```
 
-:::note
+:::note[Mount failures]
 
-If some mounts fail, please check if fstab entries are consistent with disk labels/UUIDs.
+If a mount fails, check that the labels or UUIDs in `/etc/fstab` match those on the target file system.
 
 :::
 
 <a id="trigger-and-monitor-data-healing"></a>
 
-### Trigger and Monitor Data Healing
+### Trigger and monitor data healing
 
 Once RustFS detects a freshly formatted disk at a known mount point, its background scanner heals the missing data onto it automatically — no manual command is required. Confirm that recovery has started and track its progress through the service logs:
 
@@ -125,24 +118,24 @@ You can also open the RustFS Console and check the disk status of the affected n
 
 :::note[Notes]
 
-* The healing process will complete in the background, usually with minimal impact on online access;
-* After healing is complete, the tool will report success or list failed objects.
+* Healing runs in the background and usually has little impact on client requests.
+* When healing finishes, the logs report success or list objects that failed to heal.
 
 :::
 
 <a id="follow-up-checks-and-notes"></a>
 
-### Follow-up Checks and Notes
+### Follow-up checks and notes
 
 1. **Performance Monitoring**
 
- * I/O may fluctuate slightly during healing, recommend monitoring disk and network load.
+ * I/O load may fluctuate during healing. We recommend monitoring disk and network utilization.
 2. **Batch Failures**
 
- * If multiple failures occur in the same batch of disks, consider more frequent hardware inspections.
-3. **Regular Drills**
+ * If several disks from the same manufacturing batch fail, inspect the remaining disks from that batch more often.
+3. **Regular failure tests**
 
- * Regularly simulate disk failure drills to ensure team familiarity with recovery processes.
+ * Run regular disk failure drills so your team can practice the recovery procedure.
 4. **Maintenance Windows**
 
- * When failure rates are high, arrange dedicated maintenance windows to speed up replacement and healing.
+ * When failure rates are high, schedule dedicated maintenance windows to speed up replacement and healing.
diff --git a/content/en/troubleshooting/index.md b/content/en/troubleshooting/index.md
index 2d67143db..56ba12d31 100644
--- a/content/en/troubleshooting/index.md
+++ b/content/en/troubleshooting/index.md
@@ -3,9 +3,9 @@ title: "Troubleshooting"
 description: "Diagnose and resolve RustFS issues."
 ---
 
-Contents:
+This section covers:
 
 - [Node Failures](./node.md)
-- [Driver Failures](./driver.md)
+- [Drive Failures](./driver.md)
 - [Node Healing](../operations/high-availability/node-healing.md)
 
diff --git a/content/en/troubleshooting/node.md b/content/en/troubleshooting/node.md
index 34f8fe953..ac9f3bc6a 100644
--- a/content/en/troubleshooting/node.md
+++ b/content/en/troubleshooting/node.md
@@ -1,48 +1,48 @@
 ---
 title: "Node Failures"
-description: "Complete steps for handling node failures in RustFS clusters. Mainly includes: replacement node hardware preparation, configuration updates, service deployment, rejoining the cluster, data healing, and subsequent checks and best practices."
+description: "Prepare a replacement node, update its configuration, restore cluster membership, and verify data healing."
 ---
 
-In distributed RustFS clusters, erasure coding mechanisms are adopted to ensure read/write access can still be provided when some nodes fail, and automatic data healing occurs after nodes rejoin. This document will guide you through the following process:
+A distributed RustFS cluster uses erasure coding to stay readable and writable when some nodes fail, and it heals data automatically when a node rejoins. This guide walks you through the following steps:
 
-1. Start replacement node and synchronize environment
-2. Update DNS/hostname to point old node identifiers to new nodes
-3. Download and deploy RustFS services consistent with the cluster
-4. Rejoin new nodes to the cluster and trigger data healing
-5. Monitor healing progress and perform subsequent checks and optimization
+1. Start the replacement node and match its software environment to the cluster.
+2. Update DNS or `/etc/hosts` so that the old hostname resolves to the new node.
+3. Install the same RustFS version as the other nodes.
+4. Start the replacement nodes so they rejoin the cluster and begin data healing.
+5. Monitor healing progress, then run follow-up checks.
 
-## 1) Start Replacement Node
+## 1. Prepare the replacement node
 
 * **Hardware and System Preparation**
-  Ensure the replacement node server hardware is roughly consistent with the failed node, including CPU, memory, network configuration, and disk type; even using higher configurations won't affect cluster performance.
-  Software environment needs to maintain version consistency with other nodes (operating system, kernel, dependency libraries, etc.) to avoid cluster abnormal behavior caused by environment differences.
+  Make sure that the replacement node's hardware (CPU, memory, network, and disk type) roughly matches the failed node. Using higher-spec hardware does not affect cluster performance.
+  Use software versions that match the other nodes, including the operating system, kernel, and dependencies, to avoid problems caused by inconsistent environments.
 
-* **Drive Exclusive Access**
-  As with physical drive operations, RustFS requires exclusive access to storage volumes, prohibiting any other processes or scripts from directly modifying data within storage volumes, otherwise data corruption or redundancy loss can easily occur.
+* **Exclusive access to drives**
+  As with physical drive operations, RustFS requires exclusive access to its storage volumes. Do not let other processes or scripts modify data on these volumes directly, as this can corrupt data or reduce redundancy.
 
-## 2) Update Hostname and Network Resolution
+## 2. Update hostname and network resolution
 
 * **DNS/Hosts Configuration**
-  If the replacement node's IP address differs from the failed node, you need to re-resolve the old node's hostname (such as `rustfs-node-2.example.net`) to the new node to ensure nodes within the cluster discover each other through the same address.
+  If the replacement node's IP address differs from the failed node, point the old node's hostname (for example, `rustfs-node-2.example.net`) to the new node's IP address so that cluster nodes can still reach each other by the same name.
 
  ```bash
  # Example: Add or modify line in /etc/hosts
  192.168.1.12 rustfs-node-2.example.net
  ```
 
-  After correct resolution, you can verify the hostname points to the new node through `ping` or `nslookup`.
+  Use `ping` or `nslookup` to verify that the hostname resolves to the new node.
 
-## 3) Deploy and Configure RustFS Services
+## 3. Deploy and configure RustFS services
 
 * **Download and Installation**
-  Follow the same version deployment process as RustFS official, download binaries or installation packages consistent with existing nodes, and extract to a unified directory. Ensure startup scripts, environment variables, and configuration files (such as `/etc/default/rustfs`) are completely consistent with other nodes in the cluster.
+  Install the same RustFS version as the existing nodes, using the same installation method and directory. Make sure that startup scripts, environment variables, and configuration files (such as `/etc/default/rustfs`) are identical to those on the other nodes.
 
 * **Configuration Verification**
 
  * Check that `RUSTFS_VOLUMES` in `/etc/default/rustfs` is byte-for-byte identical to the other nodes, and that it covers the replacement node's hostname and port.
- * Ensure all nodes have the same access keys and permission configurations to avoid new nodes being unable to join due to authentication failures.
+ * Make sure that all nodes use the same access keys and permission settings; otherwise, the new node fails to authenticate and cannot join the cluster.
 
-## 4) Rejoin Cluster and Trigger Data Healing
+## 4. Rejoin the cluster and trigger data healing
 
 * **Start Service**
 
@@ -50,7 +50,7 @@ In distributed RustFS clusters, erasure coding mechanisms are adopted to ensure
  systemctl start rustfs
  ```
 
-  Or use your custom startup script to start RustFS services, and view startup logs through `journalctl -u rustfs -f` to confirm the new node has detected other online nodes and started the data healing process.
+  Alternatively, start RustFS with your own startup script. Then run `journalctl -u rustfs -f` to confirm that the new node has detected the other nodes and started healing.
 
 * **Monitor Healing Status**
   Healing runs in the background once the node rejoins; no manual command is required. Watch its progress through the service logs on the replacement node, and check node and disk status in the RustFS Console:
@@ -59,25 +59,25 @@ In distributed RustFS clusters, erasure coding mechanisms are adopted to ensure
  journalctl -u rustfs -f
  ```
 
-* **Community Experience Reference**
-  Community testing shows that when nodes go offline and rejoin, RustFS will only perform healing operations on new nodes, not fully rebalance the cluster, thus avoiding unnecessary network and I/O peaks.
+* **Community observations**
+  When a node goes offline and rejoins, RustFS heals only that node instead of rebalancing the entire cluster, which avoids unnecessary network and I/O spikes.
 
-## 5) Subsequent Checks and Best Practices
+## 5. Follow-up checks and best practices
 
 * **Monitoring and Alerts**
 
- * During healing, monitor disk and network load to ensure the cluster meets read/write and network bandwidth requirements.
+ * During healing, monitor disk and network load to make sure the cluster still meets its read, write, and bandwidth requirements.
  * Set up alerts to notify operations teams when node healing fails or progress stalls beyond thresholds.
 
-* **Repeated Failure Drills**
-  Regularly simulate node failures and drill the entire recovery process to ensure team familiarity with operation commands and emergency procedures.
+* **Regular failure testing**
+  Run regular node failure drills and practice the full recovery procedure so your team is familiar with the commands and incident response process.
 
 * **Root Cause Analysis**
-  Conduct in-depth hardware health diagnostics (SMART, BIOS logs, etc.) on frequently failing nodes or disks, and implement preventive maintenance plans.
+  Run detailed hardware diagnostics (for example, SMART data and BIOS logs) on nodes or disks that fail repeatedly, and put a preventive maintenance plan in place.
 
 * **Professional Support**
-  If deeper-level fault location and recovery guidance is needed, contact the RustFS development team or community for help.
+  For help diagnosing the cause of a failure or recovering the cluster, contact the RustFS development team or community.
 
 ---
 
-**Summary**: Through the above process, RustFS can quickly and safely replace nodes and complete data healing after node hardware completely fails, minimizing cluster availability interruptions. Be sure to cross-reference with your own environment and specific command-line tools to ensure configuration consistency and correct operation sequence.
+These steps replace a failed node and heal its data. Adapt the commands to your environment, and keep the configuration identical across nodes.