Update translated documentation (#1290)

Author: github-actions[bot]

docs/.translation_cache.json

@@ -63,7 +63,7 @@
     "hash": "52dd12d566da2003602ee21c4a3d007f"
   },
   "en:kernel/ktest/index.rst": {
-    "hash": "5a4565952877c82b9a0ed3b67103c141"
+    "hash": "91a6018265b0505ee81ba83c0a7a172a"
   },
   "en:kernel/filesystem/vfs/api.md": {
     "hash": "1b0b3fe0cc2918cc2c53a5af392a96ff"
@@ -292,5 +292,8 @@
   },
   "en:kernel/ipc/ipc_namespace.md": {
     "hash": "52df04d6a276b42617f7b79bbbffa61e"
+  },
+  "en:kernel/ktest/gvisor_syscall_test.rst": {
+    "hash": "019ff2a7240a60e49be0633625da88f6"
   }
 }

docs/locales/en/kernel/ktest/gvisor_syscall_test.rst

@@ -0,0 +1,91 @@
+.. note:: AI Translation Notice
+
+   This document was automatically translated by `hunyuan-turbos-latest` model, for reference only.
+
+   - Source document: kernel/ktest/gvisor_syscall_test.rst
+
+   - Translation time: 2025-09-24 08:27:04
+
+   - Translation model: `hunyuan-turbos-latest`
+
+
+   Please report issues via `Community Channel <https://github.com/DragonOS-Community/DragonOS/issues>`_
+
+==============================
+gVisor System Call Testing
+==============================
+
+DragonOS integrates the gVisor system call test suite to verify the compatibility and correctness of the operating system's system call implementation.
+
+Overview
+========
+
+gVisor is a container runtime sandbox developed by Google, which includes a comprehensive set of system call compatibility tests. These tests are designed to validate whether an operating system's system call implementation complies with Linux standards.
+
+Key Features:
+
+- **Comprehensive Test Coverage**: Contains hundreds of system call test cases
+- **Whitelist Mechanism**: By default, only verified tests are executed, with support gradually expanding
+- **Blacklist Filtering**: Allows blocking specific test cases for each test program
+- **Automated Execution**: Provides Makefiles and scripts to simplify the testing process
+
+Quick Start
+==========
+
+1. Navigate to the test directory:
+
+   .. code-block:: bash
+
+      cd user/apps/tests/syscall/gvisor
+
+2. Run whitelist tests on Linux (automatically downloads the test suite):
+
+   .. code-block:: bash
+
+      make test
+
+3. If you need to run the tests, first modify the configuration file:
+
+   Edit `config/app-blocklist.toml`, and comment out the following content:
+
+   .. code-block:: toml
+
+      # Block gvisor system call tests
+      # [[blocked_apps]]
+      # name = "gvisor syscall tests"
+      # reason = "Blocked due to large file size. To enable system call tests, uncomment these lines"
+
+4. Run the tests within the DragonOS system:
+
+   Navigate to the installation directory and execute the test program:
+
+   .. code-block:: bash
+
+      cd /opt/tests/gvisor
+      ./gvisor-test-runner --help
+
+   Use `_translated_label__`./gvisor-test-runner`_en` to run specific test cases.
+
+5. View detailed documentation:
+
+   Refer to `user/apps/tests/syscall/gvisor/README.md` for complete usage instructions.
+
+Testing Mechanism
+==========
+
+Whitelist Mode
+-----------
+
+The test framework defaults to whitelist mode, executing only the test programs specified in `_translated_label__`whitelist.txt`_en`. This allows for gradual validation of DragonOS's system call implementation.
+
+Blacklist Filtering
+-----------
+
+For each test program, specific test cases can be blocked through files in the `_translated_label__`blocklists/`_en` directory. This is particularly useful for skipping tests that are not yet supported or are unstable.
+
+More Details
+==============
+
+For detailed usage instructions, configuration options, and development guides regarding gVisor system call testing, please consult the README.md document in the test directory:
+
+- Documentation Location: `user/apps/tests/syscall/gvisor/README.md`

docs/locales/en/kernel/ktest/index.rst

@@ -1,12 +1,12 @@
 .. note:: AI Translation Notice
 
-   This document was automatically translated by `Qwen/Qwen3-8B` model, for reference only.
+   This document was automatically translated by `hunyuan-turbos-latest` model, for reference only.
 
    - Source document: kernel/ktest/index.rst
 
-   - Translation time: 2025-05-19 01:41:16
+   - Translation time: 2025-09-24 08:26:52
 
-   - Translation model: `Qwen/Qwen3-8B`
+   - Translation model: `hunyuan-turbos-latest`
 
 
    Please report issues via `Community Channel <https://github.com/DragonOS-Community/DragonOS/issues>`_
@@ -15,12 +15,12 @@
 Kernel Testing
 ====================================
 
-   This chapter will introduce how to test the kernel, including manual testing and automated testing.
+This chapter introduces how to test the kernel, including both manual and automated testing.
 
-   We need to perform thorough testing on the kernel as much as possible, so that we can better ensure the stability of the kernel and reduce the difficulty of debugging other modules.
+We need to conduct as comprehensive testing of the kernel as possible to better ensure its stability and reduce the debugging difficulty of other modules.
 
-   Setting up comprehensive test cases can help us detect problems as much as possible, preventing us from being "stabbed" by hidden bugs in existing modules when writing new modules.
+Establishing well-designed test cases helps us detect issues as much as possible, preventing us from being "ambushed" by deeply hidden bugs in existing modules when developing new ones.
 
-   Since it is difficult to debug using tools like GDB, manual testing in the kernel is more challenging compared to testing applications.
+Since it is difficult to debug using tools like GDB, manual testing in the kernel is more challenging than application testing.
 
-   For some modules, we can write code for unit testing and output error messages. Unfortunately, not all modules can be unit tested. For example, common modules such as memory management and process management cannot be unit tested.
+For some modules, we can write code for unit testing and output exception information. Unfortunately, not all modules can be unit tested. For example, common modules like memory management and process management cannot be unit tested.