doc: Add ai doc translate tool and add English doc. (#1168)

- add tools/doc_translator.py
- translated docs into English

Signed-off-by: longjin <longjin@DragonOS.org>

docs/locales/en/community/code_contribution/c-coding-style.md

@@ -0,0 +1,173 @@
+:::{note}
+**AI Translation Notice**
+
+This document was automatically translated by `Qwen/Qwen3-8B` model, for reference only.
+
+- Source document: community/code_contribution/c-coding-style.md
+
+- Translation time: 2025-05-19 01:42:01
+
+- Translation model: `Qwen/Qwen3-8B`
+
+Please report issues via [Community Channel](https://github.com/DragonOS-Community/DragonOS/issues)
+
+:::
+
+# C Language Code Style
+
+  This document will briefly introduce the C language code style used in DragonOS. It is completely normal for each person to have their own code style. However, for the maintainability of an open-source project, we hope to establish some code standards so that every developer, including you, can feel more comfortable when reading the code. A project filled with various code styles is difficult to maintain.
+
+  We propose some recommendations here, and we hope you will follow them as much as possible. These recommendations are similar to those of Linux, but with some differences. DragonOS uses Linux's style for variable naming; for indentation, DragonOS uses Microsoft's style.
+
+## 0. Code Formatter
+
+  Before we present the following recommendations, we recommend that you use the `C/C++ Extension Pack` plugin in Visual Studio Code as a code formatter during development. These plugins provide good auto-formatting functionality, ensuring that your code's basic format meets DragonOS's requirements.
+
+  Pressing `Ctrl+shift+I` or your set code formatting shortcut frequently while coding can help you maintain good code formatting consistently.
+
+## 1. Indentation
+
+  The width of a tab is equal to 4 spaces. Code indentation is based on the tab width (usually 4 characters in most editors).
+
+  This makes your code more readable and helps better identify the control structures in the code. This can avoid many unnecessary troubles!
+
+For example: In a switch statement, place the switch and case on the same indentation level. And indent each case's code by one tab to the right. This improves code readability.
+
+```c
+switch (cmd)
+{
+case AHCI_CMD_READ_DMA_EXT:
+    pack->blk_pak.end_handler = NULL;
+    pack->blk_pak.cmd = AHCI_CMD_READ_DMA_EXT;
+    break;
+case AHCI_CMD_WRITE_DMA_EXT:
+    pack->blk_pak.end_handler = NULL;
+    pack->blk_pak.cmd = AHCI_CMD_WRITE_DMA_EXT;
+    break;
+default:
+    pack->blk_pak.end_handler = NULL;
+    pack->blk_pak.cmd = cmd;
+    break;
+}
+```
+
+## 2. Line Breaks
+
+  We recommend that each line should not exceed 120 characters. If it does, unless there is a necessary reason, it should be split into two lines.
+
+  When breaking lines, we need to indent the second line by one level from the first line's starting part to indicate that it is a sub-line. Using the code formatting shortcut can quickly accomplish this.
+
+  For log strings, we do not recommend breaking them into multiple lines for easier retrieval.
+
+  For code line breaks, do not try to place several statements on the same line, as this provides no benefit to code readability:
+
+```c
+// 错误示范(1)
+if(a) return 1;
+
+// 错误示范(2)
+if(b)
+    do_a(),do_b();
+```
+
+## 3. Braces and Spaces
+
+### 3.1 Braces
+
+  The placement of braces is a matter of personal preference, mainly due to habit rather than technical reasons. We recommend placing the opening and closing braces on new lines, as shown below:
+
+```c
+while(i<10)
+{
+    ++i;
+}
+```
+
+&emsp;&emsp;This rule applies to all code blocks.
+
+&emsp;&emsp;The reason for this choice is that, in some editors, placing the braces in this way will result in **a semi-transparent vertical line appearing in the editor, with the line ends being the braces**. This helps developers better understand the hierarchical relationships of the code blocks.
+
+Let's demonstrate this with some examples:
+
+&emsp;&emsp;In the following code block, we need to note that the `else if` statement should be on a new line, not after the previous `}`. This is because we require `{` to be at the start of each line and maintain the indentation level.
+
+```c
+if (*fmt == '*')
+{
+    ++fmt;
+}
+else if (is_digit(*fmt))
+{
+    field_width = skip_and_atoi(&fmt);
+}
+```
+
+&emsp;&emsp;When there are multiple simple statements in a loop, braces should be used.
+
+```c
+while (condition) 
+{
+    if (test)
+        do_something();
+}
+```
+
+&emsp;&emsp;When there is only one simple statement, we do not need to use braces.
+
+```c
+if(a)
+    return 1;
+```
+
+### 3.2 Spaces
+
+&emsp;&emsp;For most keywords, we need to add a space after them to improve code readability.
+
+&emsp;&emsp;Please add a space after all of these keywords:
+
+```c
+if, switch, case, for, do, while
+```
+
+&emsp;&emsp;Keywords such as sizeof, typeof, alignof, and __attribute__ do not require a space after them, as they are used like functions.
+
+&emsp;&emsp;For pointer-type variables, the asterisk should be close to the variable name rather than the type name. As shown below:
+
+```c
+char *a;
+void *func(char* s, int **p);
+```
+
+&emsp;&emsp;Use a space on both sides of most binary and ternary operators, as shown below:
+
+```c
+=  +  -  <  >  *  /  %  |  &  ^  <=  >=  ==  !=  ?  :
+```
+
+&emsp;&emsp;There is no space after these unary operators:
+
+```c
+&  *  +  -  ~  !  sizeof  typeof  alignof  __attribute__  defined
+```
+
+&emsp;&emsp;Special cases: no space is needed before or after the following operators:
+
+```c
+++  -- . ->
+```
+
+## 4. Naming
+
+&emsp;&emsp;DragonOS does not use the camelCase naming convention for function names, but instead uses concise and clear names like `tmp`.
+
+&emsp;&emsp;Note that this refers to our entire project not using the camelCase naming convention. It does not mean that programmers can use obscure abbreviations for variable names.
+
+&emsp;&emsp;For global variables or globally visible functions and structures, we need to follow the following naming conventions:
+
+- The name should be easy to understand and not ambiguous. For example, for a function that calculates folder size, we recommend using `count_folder_size()` instead of `cntfs()`, which can confuse others.
+- For global, non-static names, unless there is a special need, the naming should follow the format: `模块名缩写前缀_函数/变量名`. This naming convention helps others distinguish which module the name belongs to and reduces the risk of naming conflicts.
+- Global names that do not need to be visible to other code files must be prefixed with the `static` modifier.
+
+&emsp;&emsp;For local variables within functions, the naming convention should be concise. Long names for local variables have little significance.
+
+[Document not completed, to be continued]

docs/locales/en/community/code_contribution/conventional-commit.md

@@ -0,0 +1,62 @@
+:::{note}
+**AI Translation Notice**
+
+This document was automatically translated by `Qwen/Qwen3-8B` model, for reference only.
+
+- Source document: community/code_contribution/conventional-commit.md
+
+- Translation time: 2025-05-19 01:41:57
+
+- Translation model: `Qwen/Qwen3-8B`
+
+Please report issues via [Community Channel](https://github.com/DragonOS-Community/DragonOS/issues)
+
+:::
+
+# Code Commit Guidelines
+
+  This document will briefly introduce the code commit guidelines for the DragonOS GitHub repository, mainly providing the naming conventions based on Conventional Commit, as well as a brief introduction to the DragonOS Bot.
+
+## Conventional Commit (Conventional Commit)
+
+  For detailed specifications on Conventional Commit, please refer to the website [Conventional Commit/Conventional Commit](https://www.conventionalcommits.org/zh-hans/v1.0.0/). At the end of this section, we will provide examples (taken from the [Conventional Commit/Conventional Commit](https://www.conventionalcommits.org/zh-hans/v1.0.0/) website), which are optional to read. We make the following special notes:
+1. Since the DragonOS kernel ensures external usability primarily through system call interfaces, and up to now (April 22, 2024), considering the software ecosystem, DragonOS has chosen to implement system calls consistent with Linux. Therefore, there is no special explanation for `破坏性变更(BREAKING CHANGES)`, or in the current development environment, there will not be any destructive changes that significantly affect users. Therefore, unless there is a special need, the DragonOS kernel should not use `feat!` to indicate destructive changes. (Outside the kernel, such as dadk, the guidelines still apply.)
+2. The DragonOS community strictly follows a squash-based workflow, so we do not require each individual commit in a PR to conform to [Conventional Commit/Conventional Commit](https://www.conventionalcommits.org/zh-hans/v1.0.0/). However, we still strongly recommend using it.
+3. Regarding scope: If not specified otherwise, the scope should be the name of the submodule/system/directory. For example, if the code change is adding a feature in `kernel/src/driver/net`, it should be named as `feat(driver/net):`; if it is in `kernel/src/mm/allocator`, it should be named as `feat(mm)`. In short, the scope should be as short as possible to indicate the module it belongs to. Most of the time, it should not use more than two levels of scope identifiers. For example, `fix(x86_64/driver/apic)` is incorrect and should be named as `fix(x86_64/apic)`.
+4. In the DragonOS kernel code repository, `issue checker` will perform a simple review of the title format. If it does not conform to the format, it will be marked as `ambiguous`. Contributors are advised to modify it as needed.
+5. Use lowercase.
+
+### Examples
+
+#### Commit message with a description and a footnote indicating a breaking change
+```
+feat: allow provided config object to extend other configs
+
+BREAKING CHANGE: `extends` key in config file is now used for extending other config files
+```
+#### Commit message with the ! character to alert about a breaking change
+```
+feat!: send an email to the customer when a product is shipped
+```
+#### Commit message with scope and a breaking change !
+```
+feat(api)!: send an email to the customer when a product is shipped
+```
+#### Commit message with ! and BREAKING CHANGE footnote
+```
+chore!: drop support for Node 6
+
+BREAKING CHANGE: use JavaScript features not available in Node 6.
+```
+#### Commit message without a body
+```
+docs: correct spelling of CHANGELOG
+```
+#### Commit message with scope
+```
+feat(lang): add polish language
+```
+
+## DragonOS Bot
+
+  DragonOS uses triagebot to implement automatic labeling and reviewer assignment. Contributors can also interact with triagebot through some commands. For more details, see [triagebot](https://forge.rust-lang.org/triagebot/index.html)

docs/locales/en/community/code_contribution/index.rst

@@ -0,0 +1,29 @@
+.. note:: AI Translation Notice
+
+   This document was automatically translated by `Qwen/Qwen3-8B` model, for reference only.
+
+   - Source document: community/code_contribution/index.rst
+
+   - Translation time: 2025-05-19 01:41:37
+
+   - Translation model: `Qwen/Qwen3-8B`
+
+
+   Please report issues via `Community Channel <https://github.com/DragonOS-Community/DragonOS/issues>`_
+
+====================================
+Contributing to Development
+====================================
+
+   DragonOS community warmly welcomes your participation! While learning technology is important, the following documents will help you understand what DragonOS community needs.
+
+   Reading these documents will help you get involved in development and make your code merge into the mainline more quickly.
+
+.. toctree::
+   :maxdepth: 1
+
+   how-to-contribute <https://community.dragonos.org/contributors/>
+
+   c-coding-style
+   rust-coding-style
+   conventional-commit

docs/locales/en/community/code_contribution/rust-coding-style.md

@@ -0,0 +1,107 @@
+:::{note}
+**AI Translation Notice**
+
+This document was automatically translated by `Qwen/Qwen3-8B` model, for reference only.
+
+- Source document: community/code_contribution/rust-coding-style.md
+
+- Translation time: 2025-05-19 01:41:39
+
+- Translation model: `Qwen/Qwen3-8B`
+
+Please report issues via [Community Channel](https://github.com/DragonOS-Community/DragonOS/issues)
+
+:::
+
+# Rust Language Code Style
+
+  This document will introduce the Rust language code style used in DragonOS. As development progresses, these styles may change, but we will strive to maintain consistency in the style.
+
+## 1. Naming
+
+  This section is based on the naming conventions from the Rust language bible, [Naming Guide](https://course.rs/practice/naming.html). For parts not mentioned in this document, please refer to the [Naming Guide](https://course.rs/practice/naming.html) in the Rust language bible.
+
+## 2. Formatting
+
+### 2.1 Indentation
+
+  Please use the `cargo fmt` command to format the code before submitting it.
+
+### 2.2 Function Return Values
+
+  Although Rust allows returning the value of the last line of a function, this approach can reduce code readability. Therefore, we recommend using the `return` statement as the last line of the function, rather than directly returning the value.
+
+```rust
+// 不推荐
+fn foo() -> i32 {
+    1 + 2
+}
+
+// 推荐
+fn foo() -> i32 {
+    return 1 + 2;
+}
+```
+### 2.3 Error Handling
+
+  DragonOS uses returning POSIX error codes as the **inter-module error handling** method. To ensure consistency in error handling code across modules, we recommend returning the `SystemError` type when an error occurs. This approach is especially beneficial when calling functions across modules, as it allows direct return of a generic error code, thereby reducing the coupling of error handling code.
+
+```rust
+// 函数跨越模块边界时（由其他模块调用当前函数），不推荐
+fn foo() -> Result<(), CustomErr> {
+    if 1 + 2 == 3 {
+        return Ok(());
+    } else {
+        return Err(CustomErr::error);
+    }
+}
+
+// 函数跨越模块边界时（由其他模块调用当前函数），推荐
+fn foo() -> Result<(), SystemError> {
+    if 1 + 2 == 3 {
+        return Ok(());
+    } else {
+        return Err(SystemError::EINVAL);
+    }
+}
+```
+
+&emsp;&emsp;Within **modules**, you can either use a custom error enum or return the `SystemError` type. However, we recommend using a custom error enum for error handling within modules, as it makes the error handling code clearer.
+
+&emsp;&emsp;**TODO**: Convert existing code that uses i32 as an error code to use `SystemError`.
+
+## 3. Comments
+
+&emsp;&emsp;The commenting style in DragonOS is consistent with the official Rust style. We also recommend adding as many meaningful comments as possible in your code to help others understand your code. Additionally, variable and function declarations should follow the naming conventions mentioned in Section 1, making them "self-documenting."
+
+### 3.1 Function Comments
+
+&emsp;&emsp;Function comments should include the following:
+
+- The function's purpose
+- The function's parameters
+- The function's return value
+- The function's error handling
+- Any side effects or other information that needs to be explained
+
+&emsp;&emsp;The format for function comments is as follows:
+
+```rust
+/// # 函数的功能
+/// 
+/// 函数的详细描述
+/// 
+/// ## 参数
+/// 
+/// - 参数1: 参数1的说明
+/// - 参数2: 参数2的说明
+/// - ...
+/// 
+/// ## 返回值
+/// - Ok(返回值类型): 返回值的说明
+/// - Err(错误值类型): 错误的说明
+/// 
+/// ## Safety
+/// 
+/// 函数的安全性说明
+```