feat: refine English wording for docs files: 27-42 (#427)

Author: Copilot

docs/MenuPermissions.mdx

@@ -6,66 +6,66 @@ keywords: [Menu Permissions, example]
 authors: [amikecoXu]
 ---
 
-We begin by introducing a Spring Boot example featuring a menu system. This example leverages jCasbin to manage menu permissions. Ultimately, it aims to abstract a middleware, specifically for menu permissions, which could be extended to other languages supported by Casbin, such as Go and Python.
+This guide demonstrates a Spring Boot application that implements menu-based access control using jCasbin. The approach shown here serves as a foundation for building menu permission middleware that can be adapted to other Casbin-supported languages like Go and Python.
 
 ### 1. Configuration Files
 
-You need to set up role and permission management in the `policy.csv` file, along with the parent-child relationships between menu items. For more details, please refer to [this GitHub repo](https://github.com/jcasbin/jcasbin-menu-permission).
+Configure role permissions and menu hierarchies in the `policy.csv` file. For a complete working example, see the [jCasbin menu permission repository](https://github.com/jcasbin/jcasbin-menu-permission).
 
 #### 1.1 Overview
 
-Using `policy.csv`, you can flexibly configure role permissions and menu structures for fine-grained access control. This configuration file defines access permissions for different roles on various menu items, associations between users and roles, and the hierarchical relationships between menu items.
+The `policy.csv` file enables granular access control by defining role-based permissions for menu items, user-role assignments, and hierarchical menu structures. This configuration combines three elements: which roles can access which menu items, which users belong to which roles, and how menus relate to each other in the navigation hierarchy.
 
 #### 1.2 Permission Definitions (Policies)
 
-- **Policy Rules**: Policies are defined with a `p` prefix, specifying roles (`sub`) and their permissions (`act`) on menu items (`obj`), along with the rule's effect (`eft`), where `allow` indicates permission is granted, and `deny` indicates it is denied.
+- **Policy Rules**: Each policy line starts with `p` and defines whether a role (`sub`) has permission to perform an action (`act`) on a menu item (`obj`). The effect (`eft`) is either `allow` or `deny`.
 
 Examples:
 
-- `p, ROLE_ROOT, SystemMenu, read, allow` means the `ROLE_ROOT` role has read access to the `SystemMenu` menu item.
-- `p, ROLE_ROOT, UserMenu, read, deny` means the `ROLE_ROOT` role is denied read access to the `UserMenu` menu item.
+- `p, ROLE_ROOT, SystemMenu, read, allow` grants `ROLE_ROOT` read access to `SystemMenu`.
+- `p, ROLE_ROOT, UserMenu, read, deny` denies `ROLE_ROOT` read access to `UserMenu`.
 
 #### 1.3 Roles and User Associations
 
-- **Role Inheritance**: User-role relationships and role hierarchies are defined with a `g` prefix. This allows users to inherit permissions from one or multiple roles.
+- **Role Inheritance**: Lines starting with `g` define user-role assignments and role inheritance chains. Users automatically inherit permissions from all their assigned roles.
 
 Examples:
 
-- `g, user, ROLE_USER` means the user `user` is assigned the `ROLE_USER` role.
-- `g, ROLE_ADMIN, ROLE_USER` means `ROLE_ADMIN` inherits permissions from `ROLE_USER`.
+- `g, user, ROLE_USER` assigns the user named `user` to `ROLE_USER`.
+- `g, ROLE_ADMIN, ROLE_USER` makes `ROLE_ADMIN` inherit all permissions from `ROLE_USER`.
 
 #### 1.4 Menu Item Hierarchy
 
-- **Menu Relationships**: Parent-child relationships between menu items are defined with a `g2` prefix, aiding in the construction of a menu's structure.
+- **Menu Relationships**: Lines starting with `g2` define parent-child relationships between menu items, establishing the menu structure.
 
 Examples:
 
-- `g2, UserSubMenu_allow, UserMenu` indicates `UserSubMenu_allow` is a submenu of `UserMenu`.
-- `g2, (NULL), SystemMenu` indicates `SystemMenu` has no submenu item, meaning it is a top-level menu item.
+- `g2, UserSubMenu_allow, UserMenu` makes `UserSubMenu_allow` a child of `UserMenu`.
+- `g2, (NULL), SystemMenu` marks `SystemMenu` as a top-level menu with no parent.
 
 #### 1.5 Menu Permission Inheritance and Default Rules
 
-When managing menu permissions with jCasbin, the permission relationship between parent and child menus follows specific inheritance rules, with two important default rules:
+jCasbin applies specific inheritance rules when determining menu access based on parent-child relationships:
 
 **Inheritance of Parent Menu Permissions**:
 
-If a parent menu is explicitly granted `allow` permission, all its submenus also default to `allow` permission unless specifically marked as `deny`. This means once a parent menu is accessible, its submenus are also accessible by default.
+When a parent menu has explicit `allow` permission, all child menus inherit `allow` by default unless explicitly set to `deny`. Granting access to a parent menu automatically grants access to its children.
 
 **Handling Parent Menus Without Direct Permission Settings**:
 
-If a parent menu has no direct permission settings (neither explicitly allowed nor denied) but has at least one submenu explicitly granted `allow` permission, then the parent menu is implicitly considered to have `allow` permission. This ensures users can navigate to these submenus.
+When a parent menu has no explicit permission but contains at least one child menu with explicit `allow` permission, the parent menu is implicitly granted `allow` status. This ensures users can reach the accessible child menus.
 
 #### 1.6 Special Permission Inheritance Rules
 
-Regarding the inheritance of permissions between roles, especially in scenarios involving `deny` permissions, the following rules must be followed to ensure system security and precise control of permissions:
+Role inheritance interacts with `deny` permissions according to these rules:
 
 **Distinction Between Explicit and Default Denials**:
 
-If a role, such as `ROLE_ADMIN`, is explicitly denied access to a menu item, such as `AdminSubMenu_deny` (marked as `deny`), then even if this role is inherited by another role (e.g., `ROLE_ROOT`), the inheriting role is not permitted access to the denied menu item. This ensures explicit security policies are not bypassed due to role inheritance.
+Explicit `deny` permissions always take precedence. When a role like `ROLE_ADMIN` is explicitly denied access to `AdminSubMenu_deny`, no role that inherits from `ROLE_ADMIN` (such as `ROLE_ROOT`) can access that menu. Explicit denials cannot be overridden through role inheritance.
 
 **Inheritance of Default Denial Permissions**:
 
-Conversely, if a role's denial of access to a menu item (e.g., `UserSubMenu_deny`) is default (not explicitly marked as `deny`, but because it was not explicitly granted `allow`), then when this role is inherited by another role (e.g., `ROLE_ADMIN`), the inheriting role may override the default `deny` status, allowing access to these menu items.
+Default denials (menus that lack an explicit `allow`) work differently. When `UserSubMenu_deny` is implicitly denied to `ROLE_USER` simply because no `allow` rule exists, a role inheriting from `ROLE_USER` (like `ROLE_ADMIN`) can override this by adding its own explicit `allow` rule.
 
 #### 1.7 Example Description
 
@@ -106,4 +106,4 @@ g2, (NULL), SystemMenu
 
 ### 2. Menu Permission Control
 
-The list of all menu items accessible by a given username can be identified through the `findAccessibleMenus()` function available in the [MenuService](https://github.com/jcasbin/jcasbin-menu-permission/blob/master/src/main/java/org/casbin/service/MenuService.java). To check whether a specific user has the rights to access a designated menu item, the `checkMenuAccess()` method can be utilized. This approach ensures that menu permissions are effectively controlled, leveraging jCasbin's capabilities to manage access rights efficiently.
+Use `findAccessibleMenus()` from [MenuService](https://github.com/jcasbin/jcasbin-menu-permission/blob/master/src/main/java/org/casbin/service/MenuService.java) to retrieve all menu items a user can access. To verify access to a specific menu item, call the `checkMenuAccess()` method. These functions provide efficient menu permission enforcement through jCasbin's access control engine.

docs/ModelStorage.mdx

@@ -6,15 +6,15 @@ keywords: [model storage]
 authors: [hsluoyz]
 ---
 
-Unlike the policy, the model can only be loaded, it cannot be saved. We believe that the model is not a dynamic component and should not be modified at runtime, so we have not implemented an API to save the model into storage.
+Casbin models are designed to be loaded rather than saved. The model defines your access control logic and should remain static at runtime, so Casbin does not provide an API for persisting model changes to storage.
 
-However, there is good news. We provide three equivalent ways to load a model, either statically or dynamically:
+You can load a model using any of these three approaches:
 
 ## Load model from .CONF file
 
-This is the most common way to use Casbin. It is easy to understand for beginners and convenient for sharing when you need help from the Casbin team.
+Loading from a configuration file is the standard approach. This method makes models easy to understand and share when seeking help from the Casbin community.
 
-The content of the `.CONF` file [examples/rbac_model.conf](https://github.com/casbin/casbin/blob/master/examples/rbac_model.conf) is as follows:
+Here's an example model file [examples/rbac_model.conf](https://github.com/casbin/casbin/blob/master/examples/rbac_model.conf):
 
 ```ini
 [request_definition]
@@ -33,15 +33,15 @@ e = some(where (p.eft == allow))
 m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act
 ```
 
-Then you can load the model file as follows:
+Load this model file:
 
 ```go
 e := casbin.NewEnforcer("examples/rbac_model.conf", "examples/rbac_policy.csv")
 ```
 
 ## Load model from code
 
-The model can be initialized dynamically from code instead of using a `.CONF` file. Here's an example for the RBAC model:
+Build the model programmatically instead of reading from a file. This example constructs an RBAC model:
 
 ```go
 import (
@@ -68,7 +68,7 @@ e := casbin.NewEnforcer(m, a)
 
 ## Load model from string
 
-Alternatively, you can load the entire model text from a multi-line string. The advantage of this approach is that you do not need to maintain a model file.
+Load the model directly from a multi-line string. This eliminates the need to maintain a separate model file.
 
 ```go
 import (

docs/MultiThreading.mdx

@@ -6,6 +6,6 @@ keywords: [multi-threading]
 authors: [hsluoyz]
 ---
 
-When using Casbin in a multi-threading environment, you can employ the synchronized wrapper of the Casbin enforcer: [https://github.com/casbin/casbin/blob/master/enforcer_synced.go](https://github.com/casbin/casbin/blob/master/enforcer_synced.go) (GoLang) and [https://github.com/casbin/casbin-cpp/blob/master/casbin/enforcer_synced.cpp](https://github.com/casbin/casbin-cpp/blob/master/casbin/enforcer_synced.cpp) (C++).
+For multi-threaded environments, use the synchronized wrapper provided by Casbin: [enforcer_synced.go](https://github.com/casbin/casbin/blob/master/enforcer_synced.go) (GoLang) and [enforcer_synced.cpp](https://github.com/casbin/casbin-cpp/blob/master/casbin/enforcer_synced.cpp) (C++).
 
-Furthermore, it also provides support for the "AutoLoad" feature, allowing the Casbin enforcer to automatically load the latest policy rules from the database if any changes occur. To initiate the automatic loading of policies periodically, call the "StartAutoLoadPolicy()" function. Likewise, to stop this automatic loading, call the "StopAutoLoadPolicy()" function.
+The synchronized enforcer also supports automatic policy reloading. This feature monitors the policy source for changes and reloads policies automatically when updates are detected. Call `StartAutoLoadPolicy()` to enable periodic policy reloading, and call `StopAutoLoadPolicy()` to disable it.

docs/OnlineEditor.mdx

@@ -6,54 +6,54 @@ keywords: [online editor, Casbin editor]
 authors: [hsluoyz]
 ---
 
-You can also use the [online editor](/editor) to write your Casbin model and policy in your web browser. It provides functionality such as "syntax highlighting" and "code completion", just like an IDE for a programming language.
+Write and test your Casbin models and policies directly in your browser using the [online editor](/editor). The editor provides syntax highlighting and code completion similar to a programming IDE.
 
 ## Editor Features
 
-The online editor provides several powerful features to enhance your Casbin development experience:
+The online editor includes these capabilities to streamline Casbin development:
 
 ### AI-Powered Assistance
 
-The editor includes AI assistance to help you write better Casbin models and policies.
+Get AI help while writing Casbin models and policies.
 
 ![editor-ai](/img/editor-ai.png)
 
 ### Engine Selection
 
-Choose from multiple Casbin engines including Go, Java, Node.js, Python, Rust, and .NET implementations.
+Test your models using Go, Java, Node.js, Python, Rust, or .NET Casbin implementations.
 
 ![editor-engine](/img/editor-engine.png)
 
 ### Multiple Engine Support
 
-Switch between different Casbin implementations to test your models across various platforms.
+Switch between Casbin implementations to validate your models across different platforms.
 
 ![editor-multi-engine](/img/editor-multi-engine.png)
 
 ### Endpoint Configuration
 
-Configure custom endpoints for testing your Casbin models against different environments.
+Point the editor to custom endpoints for testing models in different environments.
 
 ![editor-endpoint](/img/editor-endpoint.png)
 
 ### File Upload
 
-Upload existing model and policy files to quickly get started with the editor.
+Import existing model and policy files to start working immediately.
 
 ![editor-upload](/img/editor-upload.png)
 
 ### Use Custom Functions
 
-If you need to use a customized matching function (e.g. "RBAC with Patterns"), you can add it by clicking the "Add Role Matching" button at the bottom left corner of the editor.
+Add custom matching functions (for example, "RBAC with Patterns") by clicking the "Add Role Matching" button in the bottom left corner.
 
 ![editor-tips](/img/editor-tips.png).
 
-If you want to write the equivalent code, you need to specify the pattern matching function through the relevant API. Refer to [RBAC with Pattern](/docs/rbac-with-pattern) for more information.
+To implement custom matching functions in your code, configure them through the Casbin API. See [RBAC with Pattern](/docs/rbac-with-pattern) for details.
 
 :::note
 
-The editor supports multiple Casbin implementations, including [Node-Casbin (Node.js)](https://github.com/casbin/node-casbin), [JCasbin (Java)](https://github.com/casbin/jcasbin), [Casbin (Go)](https://github.com/casbin/casbin), [Casbin-rs (Rust)](https://github.com/casbin/casbin-rs), [PyCasbin (Python)](https://github.com/casbin/pycasbin), and [Casbin.NET (C#)](https://github.com/casbin/Casbin.NET). You can switch between different implementations in the upper right corner to test your model and policy.
+The editor supports [Node-Casbin (Node.js)](https://github.com/casbin/node-casbin), [JCasbin (Java)](https://github.com/casbin/jcasbin), [Casbin (Go)](https://github.com/casbin/casbin), [Casbin-rs (Rust)](https://github.com/casbin/casbin-rs), [PyCasbin (Python)](https://github.com/casbin/pycasbin), and [Casbin.NET (C#)](https://github.com/casbin/Casbin.NET). Switch between implementations in the upper right corner to test your configuration.
 
-Although the editor validates through a remote CLI, due to environment differences, the validation results may differ slightly from the results you get in your local environment. If you encounter any issues, please submit them to the corresponding Casbin implementation repository.
+The editor validates models through a remote CLI. Results may vary slightly from your local environment due to implementation differences. Report any issues to the appropriate Casbin implementation repository.
 
 :::