gitea/gitea-docs
1
0
Fork 0
mirror of https://gitea.com/gitea/docs.git synced 2026-06-26 22:26:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update zh-tw (#197)

Browse Source 
Signed-off-by: appleboy <appleboy.tw@gmail.com>
Reviewed-on: https://gitea.com/gitea/docs/pulls/197
Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
This commit is contained in:
Bo-Yi Wu (吳柏毅)
2025-04-05 01:51:55 +00:00
parent abc5be48cc
commit 802aeb1e0c
2 changed files with 198 additions and 306 deletions
Download Patch File Download Diff File Expand all files Collapse all files

141
i18n/zh-tw/docusaurus-plugin-content-docs/version-1.23/contributing/guidelines-backend.md
View File

@@ -10,89 +10,55 @@ aliases:
## 背景
Gitea 使用 Golang 作為後端編程語言。它使用了許多第三方包，也自己編寫了一些包。
例如，Gitea 使用 [Chi](https://github.com/go-chi/chi) 作為基本的 Web 框架。[Xorm](https://xorm.io) 是一個 ORM 框架，用於與數據庫交互。
因此，管理這些包非常重要。在開始編寫後端代碼之前，請遵循以下指南。
Gitea 使用 Golang 作為後端程式語言。它使用了許多第三方套件，也自己寫了一些。
例如，Gitea 使用 [Chi](https://github.com/go-chi/chi) 作為基本的網頁框架。[Xorm](https://xorm.io) 是一個 ORM 框架，用來與資料庫互動。
因此，管理這些套件非常重要。在開始寫後端程式碼之前，請遵循以下指南。
## 包設計指南
## 套件設計指南
### 包列表
### 套件列表
為了保持代碼的可理解性並避免循環依賴，擁有良好的代碼結構非常重要。Gitea 後端分為以下幾個部分：
為了保持程式碼的可理解性並避免循環依賴，擁有良好的程式碼結構非常重要。Gitea 的後端分為以下幾個部分：
- `build`: 幫助構建 Gitea 的腳本。
- `cmd`: 所有 Gitea 的實際子命令，包括 web、doctor、serv、hooks、admin 等等。`web` 將啟動 Web 服務。`serv` 和 `hooks` 將由 Git 或 OpenSSH 調用。其他子命令可以幫助維護 Gitea。
- `cmd`: 所有 Gitea 的實際子命令，包括 web、doctor、serv、hooks、admin 等等。`web` 會啟動網頁服務。`serv` 和 `hooks` 會被 Git 或 OpenSSH 調用。其他子命令可以幫助維護 Gitea。
- `tests`: 常見的測試工具函數
- `tests/integration`: 集成測試，用於測試後端回歸
- `tests/e2e`: 端到端測試，用於測試前端和後端的兼容性和視覺回歸。
- `models`: 包含由 xorm 用於構建數據庫表的數據結構。它還包含查詢和更新數據庫的函數。應避免依賴其他 Gitea 代碼。可以在某些情況下例外，例如日誌記錄。
- `models/db`: 基本的數據庫操作。所有其他 `models/xxx` 包應依賴於此包。`GetEngine` 函數應僅從 `models/` 調用。
- `models/fixtures`: 單元測試和集成測試中使用的示
- `tests/integration`: 整合測試，用來測試後端的回歸
- `tests/e2e`: 端到端測試，用來測試前端和後端的相容性和視覺回歸。
- `models`: 包含由 xorm 用來構建資料庫表格的資料結構。它也包含查詢和更新資料庫的函數。應避免依賴其他 Gitea 程式碼。可以在某些情況下例外，例如記錄。
- `models/db`: 基本的資料庫操作。所有其他 `models/xxx` 套件應依賴此套件。`GetEngine` 函數應僅從 `models/` 調用。
- `models/fixtures`: 單元測試和整合測試中使用的樣本資料。一個 `yml` 文件代表一個表格，測試開始時會將其載入資料庫。
- `models/migrations`: 存儲版本之間的資料庫遷移。更改資料庫結構的 PR **必須** 也有遷移步驟。
- `modules`: 處理 Gitea 中特定功能的不同模組。進行中：其中一些應移動到 `services`，特別是那些依賴於 models 的，因為它們依賴於資料庫。
- `modules/setting`: 存儲從 ini 文件讀取的所有系統配置，並已被各處引用。但應盡可能作為函數參數使用。
- `modules/git`: 與 `Git` 命令行或 Gogit 套件互動的套件。
- `public`: 編譯後的前端文件（javascript、圖片、css 等）。
- `routers`: 處理伺服器請求。由於它使用其他 Gitea 套件來處理請求，其他套件（models、modules 或 services）不得依賴 routers。
- `routers/api` 包含處理 RESTful API 請求的 `/api/v1` 路由。
- `routers/install` 僅在系統處於安裝模式（INSTALL_LOCK=false）時響應。
- `routers/private` 只會被內部子命令調用，特別是 `serv` 和 `hooks`。
- `routers/web` 會處理來自網頁瀏覽器或 Git SMART HTTP 協議的 HTTP 請求。
- `services`: 支持常見路由操作或命令執行的函數。使用 `models` 和 `modules` 來處理請求。
- `templates`: 用於生成 html 輸出的 Golang 模板。
---
### 套件依賴
date: "2021-11-01T23:41:00+08:00"
slug: "guidelines-backend"
sidebar_position: 20
aliases:
- /zh-tw/guidelines-backend
---
# Guidelines for Backend Development
## Background
Gitea uses Golang as the backend programming language. It uses many third-party packages and also write some itself.
For example, Gitea uses [Chi](https://github.com/go-chi/chi) as basic web framework. [Xorm](https://xorm.io) is an ORM framework that is used to interact with the database.
So it's very important to manage these packages. Please take the below guidelines before you start to write backend code.
## Package Design Guideline
### Packages List
To maintain understandable code and avoid circular dependencies it is important to have a good code structure. The Gitea backend is divided into the following parts:
- `build`: Scripts to help build Gitea.
- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other sub commands could help to maintain Gitea.
- `tests`: Common test utility functions
- `tests/integration`: Integration tests, to test back-end regressions
- `tests/e2e`: E2e tests, to test front-end and back-end compatibility and visual regressions.
- `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided. You can make exceptions in cases such as logging.
- `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`.
- `models/fixtures`: Sample data used in unit tests and integration tests. One `yml` file means one table which will be loaded into database when beginning the tests.
- `models/migrations`: Stores database migrations between versions. PRs that change a database structure **MUST** also have a migration step.
- `modules`: Different modules to handle specific functionality in Gitea. Work in Progress: Some of them should be moved to `services`, in particular those that depend on models because they rely on the database.
- `modules/setting`: Store all system configurations read from ini files and has been referenced by everywhere. But they should be used as function parameters when possible.
- `modules/git`: Package to interactive with `Git` command line or Gogit package.
- `public`: Compiled frontend files (javascript, images, css, etc.)
- `routers`: Handling of server requests. As it uses other Gitea packages to serve the request, other packages (models, modules or services) must not depend on routers.
- `routers/api` Contains routers for `/api/v1` aims to handle RESTful API requests.
- `routers/install` Could only respond when system is in INSTALL mode (INSTALL_LOCK=false).
- `routers/private` will only be invoked by internal sub commands, especially `serv` and `hooks`.
- `routers/web` will handle HTTP requests from web browsers or Git SMART HTTP protocols.
- `services`: Support functions for common routing operations or command executions. Uses `models` and `modules` to handle the requests.
- `templates`: Golang templates for generating the html output.
### Package Dependencies
Since Golang doesn't support import cycles, we have to decide the package dependencies carefully. There are some levels between those packages. Below is the ideal package dependencies direction.
由於 Golang 不支持導入循環，我們必須仔細決定套件依賴關係。這些套件之間有一些層次。以下是理想的套件依賴方向。
`cmd` -> `routers` -> `services` -> `models` -> `modules`
From left to right, left packages could depend on right packages, but right packages MUST not depend on left packages. The sub packages on the same level could depend on according this level's rules.
從左到右，左邊的套件可以依賴右邊的套件，但右邊的套件不得依賴左邊的套件。同一層次的子套件可以根據該層次的規則依賴。
:::warning
Why do we need database transactions outside of `models`? And how?
Some actions should allow for rollback when database record insertion/update/deletion failed.
So services must be allowed to create a database transaction. Here is some example,
為什麼我們需要在 `models` 之外的資料庫交易？以及如何實現？
某些操作應允許在資料庫記錄插入/更新/刪除失敗時回滾。
因此，services 必須允許創建資料庫交易。這裡有一些例子，
```go
// services/repository/repository.go
func CreateXXXX() error {
return db.WithTx(func(ctx context.Context) error {
// do something, if err is returned, it will rollback automatically
// 做一些事情，如果返回錯誤，它會自動回滾
if err := issues.UpdateIssue(ctx, repoID); err != nil {
// ...
return err
@@ -103,8 +69,8 @@ func CreateXXXX() error {
}
```
You should **not** use `db.GetEngine(ctx)` in `services` directly, but just write a function under `models/`.
If the function will be used in the transaction, just let `context.Context` as the function's first parameter.
你不應該在 `services` 中直接使用 `db.GetEngine(ctx)`，而是應該在 `models/` 下寫一個函數。
如果該函數將在交易中使用，只需將 `context.Context` 作為該函數的第一個參數。
```go
// models/issues/issue.go
@@ -117,34 +83,35 @@ func UpdateIssue(ctx context.Context, repoID int64) error {
:::
### Package Name
### 套件名稱
For the top level package, use a plural as package name, i.e. `services`, `models`, for sub packages, use singular,
i.e. `services/user`, `models/repository`.
對於頂層套件，使用複數作為套件名稱，即 `services`、`models`，對於子套件，使用單數，
即 `services/user`、`models/repository`。
### Import Alias
### 導入別名
Since there are some packages which use the same package name, it is possible that you find packages like `modules/user`, `models/user`, and `services/user`. When these packages are imported in one Go file, it's difficult to know which package we are using and if it's a variable name or an import name. So, we always recommend to use import aliases. To differ from package variables which are commonly in camelCase, just use **snake_case** for import aliases.
i.e. `import user_service "code.gitea.io/gitea/services/user"`
由於有些套件使用相同的套件名稱，可能會發現像 `modules/user`、`models/user` 和 `services/user` 這樣的套件。
當這些套件在一個 Go 文件中導入時，很難知道我們使用的是哪個套件，以及它是變量名還是導入名。因此，我們總是建議使用導入別名。為了區分常見的駝峰式變量名，只需使用 **snake_case** 作為導入別名。
即 `import user_service "code.gitea.io/gitea/services/user"`
### Implementing `io.Closer`
### 實現 `io.Closer`
If a type implements `io.Closer`, calling `Close` multiple times must not fail or `panic` but return an error or `nil`.
如果一種類型實現了 `io.Closer`，多次調用 `Close` 不應失敗或 `panic`，而是返回錯誤或 `nil`。
### Important Gotchas
### 重要注意事項
- Never write `x.Update(exemplar)` without an explicit `WHERE` clause:
- This will cause all rows in the table to be updated with the non-zero values of the exemplar - including IDs.
- You should usually write `x.ID(id).Update(exemplar)`.
- If during a migration you are inserting into a table using `x.Insert(exemplar)` where the ID is preset:
- You will need to `` SET IDENTITY_INSERT `table` ON `` for the MSSQL variant (the migration will fail otherwise)
- However, you will also need to update the id sequence for postgres - the migration will silently pass here but later insertions will fail:
- 永遠不要在沒有明確 `WHERE` 子句的情況下寫 `x.Update(exemplar)`：
- 這會導致表中的所有行都被更新為 exemplar 的非零值 - 包括 ID。
- 你通常應該寫 `x.ID(id).Update(exemplar)`。
- 如果在遷移期間你正在插入一個預設 ID 的表格，使用 `x.Insert(exemplar)`：
- 對於 MSSQL 變體，你需要 `` SET IDENTITY_INSERT `table` ON ``（否則遷移會失敗）
- 但是，你還需要更新 postgres 的 id 序列 - 遷移會在這裡默默通過，但後來的插入會失敗：
`` SELECT setval('table_name_id_seq', COALESCE((SELECT MAX(id)+1 FROM `table_name`), 1), false) ``
### Future Tasks
### 未來任務
Currently, we are creating some refactors to do the following things:
目前，我們正在進行一些重構，以完成以下事情：
- Correct that codes which doesn't follow the rules.
- There are too many files in `models`, so we are moving some of them into a sub package `models/xxx`.
- Some `modules` sub packages should be moved to `services` because they depend on `models`.
- 修正不符合規則的代碼。
- `models` 中的文件太多了，所以我們正在將其中一些移動到子套件 `models/xxx`。
- 一些 `modules` 子套件應移動到 `services`，因為它們依賴於 `models`。

363
i18n/zh-tw/docusaurus-plugin-content-docs/version-1.23/help/faq.md
View File

@@ -28,252 +28,205 @@ aliases:
## 如何找到配置文件 "app.ini"
這取決於您如何安裝 Gitea。如果您沒有手動設置自定義路徑或配置文件的路徑，
那麼配置文件 (app
這取決於您如何安裝 Gitea。如果您沒有手動設置自定義路徑或配置文件的路徑，那麼配置文件 (app.ini) 應該存在於 Gitea 工作路徑的 "custom/conf" 目錄中。一些軟件包供應商可能會使用 "/etc/gitea" 來存儲配置文件，而其他供應商則不會。
---
您可以通過檢查 Gitea 的啟動日誌或閱讀 Gitea 網站管理員 -> 配置摘要來手動查找配置文件 (app.ini)。
date: "2019-04-05T16:00:00+02:00"
slug: "faq"
sidebar_position: 5
aliases:
如果您使用的是一些隔離環境（如容器 docker），您看到的路徑通常不是主機文件系統中的實際路徑。在這種情況下，您需要檢查容器的文件系統卷映射並找出主機上配置文件的實際路徑。
- /zh-tw/faq
---
# FAQ
This page contains some common questions and answers.
For more help resources, check all [Support Options](help/support.md).
## Difference between 1.x and 1.x.x downloads, how can I get latest stable release with bug fixes?
Version 1.20.x will be used for this example.
On our [downloads page](https://dl.gitea.com/gitea/) you will see a 1.20 directory, as well as directories for 1.20.0, 1.20.1.
The 1.20 directory is the nightly build, which is built on each merged commit to the [`release/v1.20`](https://github.com/go-gitea/gitea/tree/release/v1.20) branch.
The 1.20.0 directory is a release build that was created when the [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) tag was created.
The nightly builds (1.x) downloads will change as commits are merged to their respective branch, they contain the latest changes/fixes before a tag release is built.
If a bug fix is targeted on 1.20.1 but 1.20.1 is not released yet, you can get the "1.20-nightly" build to get the bug fix.
## How to find the config file "app.ini"
It depends on how you installed Gitea. If you didn't set a path for custom path or config file manually,
then the config file (app.ini) should exists in the "custom/conf" directory of your Gitea's working path.
Some package vendors might use "/etc/gitea" to store the config file, while some others don't.
You could manually find the config file (app.ini) by checking Gitea's startup logs
or reading the Gitea Web's Site Administrator -> Confugiraton Summary.
If you are using some isolated enviroments like container (docker),
the path you see usually is not what it is in the host's filesystem.
In this case you need to check the container's filesystem volume mapping
and figure out the real path of the config file on the host.
## Where does Gitea store what file
## Gitea 存儲文件的位置
- _`AppWorkPath`_
- The `WORK_PATH` option in `app.ini`
- Else the `--work-path` flag
- Else Environment variable `GITEA_WORK_DIR`
- Else a built-in value set at build time
- Else the directory that contains the Gitea binary
- `AppDataPath` (default for database, indexers, etc.)
- `APP_DATA_PATH` from `app.ini`
- Else _`AppWorkPath`_`/data`
- _`CustomPath`_ (custom templates)
- The `--custom-path` flag
- Else Environment variable `GITEA_CUSTOM`
- Else a built-in value set at build time
- Else _`AppWorkPath`_`/custom`
- `app.ini` 中的 `WORK_PATH` 選項
- 否則 `--work-path` 標誌
- 否則環境變量 `GITEA_WORK_DIR`
- 否則在構建時設置的內置值
- 否則包含 Gitea 二進制文件的目錄
- `AppDataPath`（默認為數據庫、索引器等）
- `app.ini` 中的 `APP_DATA_PATH`
- 否則 _`AppWorkPath`_`/data`
- _`CustomPath`_（自定義模板）
- `--custom-path` 標誌
- 否則環境變量 `GITEA_CUSTOM`
- 否則在構建時設置的內置值
- 否則 _`AppWorkPath`_`/custom`
- HomeDir
- Unix: Environment variable `HOME`
- Windows: Environment variable `USERPROFILE`, else environment variables `HOMEDRIVE`+`HOMEPATH`
- Unix：環境變量 `HOME`
- Windows：環境變量 `USERPROFILE`，否則環境變量 `HOMEDRIVE`+`HOMEPATH`
- RepoRootPath
- `ROOT` in the \[repository] section of `app.ini` if absolute
- Else _`AppWorkPath`_`/ROOT` if `ROOT` in the \[repository] section of `app.ini` if relative
- Default `%(APP_DATA_PATH)/gitea-repositories`
- INI (config file)
- `--config` flag
- A possible built-in value set a build time
- Else _`CustomPath`_`/conf/app.ini`
- SQLite Database
- `PATH` in `database` section of `app.ini`
- Else `%(APP_DATA_PATH)/gitea.db`
- `app.ini` 中 \[repository] 部分的 `ROOT`（如果是絕對路徑）
- 否則 _`AppWorkPath`_`/ROOT`（如果 `app.ini` 中 \[repository] 部分的 `ROOT` 是相對路徑）
- 默認 `%(APP_DATA_PATH)/gitea-repositories`
- INI（配置文件）
- `--config` 標誌
- 構建時設置的可能內置值
- 否則 _`CustomPath`_`/conf/app.ini`
- SQLite 數據庫
- `app.ini` 中 `database` 部分的 `PATH`
- 否則 `%(APP_DATA_PATH)/gitea.db`
## Not seeing a clone URL or the clone URL being incorrect
## 看不到克隆 URL 或克隆 URL 不正確
There are a few places that could make this show incorrectly.
有幾個地方可能會導致顯示不正確。
1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide](../administration/reverse-proxies.md)
2. Make sure you have correctly set `ROOT_URL` in the `server` section of your `app.ini`
1. 如果使用反向代理，請確保您已按照[反向代理指南](../administration/reverse-proxies.md)中的正確指示進行操作
2. 確保您已正確設置 `app.ini` 中 `server` 部分的 `ROOT_URL`
If certain clone options aren't showing up (HTTP/S or SSH), the following options can be checked in your `app.ini`
如果某些克隆選項未顯示（HTTP/S 或 SSH），可以在 `app.ini` 中檢查以下選項
- `DISABLE_HTTP_GIT`: if set to true, there will be no HTTP/HTTPS link
- `DISABLE_SSH`: if set to true, there will be no SSH link
- `SSH_EXPOSE_ANONYMOUS`: if set to false, SSH links will be hidden for anonymous users
- `DISABLE_HTTP_GIT`：如果設置為 true，則不會有 HTTP/HTTPS 連接
- `DISABLE_SSH`：如果設置為 true，則不會有 SSH 連接
- `SSH_EXPOSE_ANONYMOUS`：如果設置為 false，則匿名用戶將隱藏 SSH 連接
## File upload fails with: 413 Request Entity Too Large
## 文件上傳失敗：413 Request Entity Too Large
This error occurs when the reverse proxy limits the file upload size.
當反向代理限制文件上傳大小時，會出現此錯誤。
See the [reverse proxy guide](../administration/reverse-proxies.md) for a solution with nginx.
請參閱[反向代理指南](../administration/reverse-proxies.md)以獲取 nginx 的解決方案。
## Custom Templates not loading or working incorrectly
## 自定義模板未加載或工作不正確
Gitea's custom templates must be added to the correct location or Gitea will not find and use them.
Gitea 的自定義模板必須添加到正確的位置，否則 Gitea 將無法找到並使用它們。
The correct path for the template(s) will be relative to the `CustomPath`
模板的正確路徑將相對於 `CustomPath`
1. To find `CustomPath`, look for Custom File Root Path in Site Administration -> Configuration
2. If you are still unable to find a path, the default can be [calculated above](#where-does-gitea-store-what-file)
3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea](../administration/customizing-gitea.md) page to add your template to the correct location.
1. 要查找 `CustomPath`，請在網站管理 -> 配置中查找自定義文件根路徑
2. 如果您仍然無法找到路徑，可以[在上面計算](#where-does-gitea-store-what-file)默認值
3. 一旦您找到了正確的自定義路徑，您可以參考[自定義 Gitea](../administration/customizing-gitea.md)頁面將模板添加到正確的位置。
## Does Gitea have a "GitHub/GitLab pages" feature?
## Gitea 是否有 "GitHub/GitLab pages" 功能？
Gitea doesn't provide a built-in Pages server. You need a dedicated domain to serve static pages to avoid CSRF security risks.
Gitea 沒有內置的 Pages 服務器。您需要一個專用域來提供靜態頁面以避免 CSRF 安全風險。
For simple usage, you can use a reverse proxy to rewrite & serve static contents from Gitea's raw file URLs.
對於簡單的使用，您可以使用反向代理來重寫並從 Gitea 的原始文件 URL 提供靜態內容。
And there are already available third-party services, like a standalone [pages server](https://codeberg.org/Codeberg/pages-server) or a [caddy plugin](https://github.com/42wim/caddy-gitea), that can provide the required functionality.
已經有可用的第三方服務，如獨立的[pages 服務器](https://codeberg.org/Codeberg/pages-server)或[caddy 插件](https://github.com/42wim/caddy-gitea)，可以提供所需的功能。
## Active user vs login prohibited user
## 活躍用戶與禁止登錄用戶
In Gitea, an "active" user refers to a user that has activated their account via email.
在 Gitea 中，“活躍”用戶是指通過電子郵件激活其帳戶的用戶。
A "login prohibited" user is a user that is not allowed to log in to Gitea anymore
“禁止登錄”用戶是指不再允許登錄 Gitea 的用戶
## What is Swagger?
## 什麼是 Swagger？
[Swagger](https://swagger.io/) is what Gitea uses for its API documentation.
[Swagger](https://swagger.io/) 是 Gitea 用於其 API 文檔的工具。
All Gitea instances have the built-in API and there is no way to disable it completely.
You can, however, disable showing its documentation by setting `ENABLE_SWAGGER` to `false` in the `api` section of your `app.ini`.
For more information, refer to Gitea's [API docs](development/api-usage.md).
所有 Gitea 實例都有內置的 API，無法完全禁用它。
但是，您可以通過在 `app.ini` 的 `api` 部分中設置 `ENABLE_SWAGGER` 為 `false` 來禁用顯示其文檔。
有關更多信息，請參閱 Gitea 的 [API 文檔](development/api-usage.md)。
You can see the latest API (for example) on https://gitea.com/api/swagger
您可以在 https://gitea.com/api/swagger 上查看最新的 API（例如）
You can also see an example of the `swagger.json` file at https://gitea.com/swagger.v1.json
您還可以在 https://gitea.com/swagger.v1.json 上查看 `swagger.json` 文件的示例
## Adjusting your server for public/private use
## 調整您的服務器以供公用/私用
### Preventing spammers
### 防止垃圾郵件
There are multiple things you can combine to prevent spammers.
有多種方法可以結合使用來防止垃圾郵件。
1. By whitelisting or blocklisting certain email domains
2. By only whitelisting certain domains with OpenID (see below)
3. Setting `ENABLE_CAPTCHA` to `true` in your `app.ini` and properly configuring `RECAPTCHA_SECRET` and `RECAPTCHA_SITEKEY`
4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI](../administration/command-line.md), [API](development/api-usage.md), or Gitea's Admin UI
1. 通過白名單或黑名單某些電子郵件域
2. 通過僅白名單某些域與 OpenID（見下文）
3. 在 `app.ini` 中設置 `ENABLE_CAPTCHA` 為 `true` 並正確配置 `RECAPTCHA_SECRET` 和 `RECAPTCHA_SITEKEY`
4. 設置 `DISABLE_REGISTRATION` 為 `true` 並通過 [CLI](../administration/command-line.md)、[API](development/api-usage.md) 或 Gitea 的管理 UI 創建新用戶
### Only allow/block certain email domains
### 只允許/阻止某些電子郵件域
You can configure `EMAIL_DOMAIN_WHITELIST` or `EMAIL_DOMAIN_BLOCKLIST` in your app.ini under `[service]`
您可以在 `app.ini` 的 `[service]` 部分中配置 `EMAIL_DOMAIN_WHITELIST` 或 `EMAIL_DOMAIN_BLOCKLIST`
### Only allow/block certain OpenID providers
### 只允許/阻止某些 OpenID 提供商
You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in your `app.ini`
您可以在 `app.ini` 的 `[openid]` 部分中配置 `WHITELISTED_URIS` 或 `BLACKLISTED_URIS`
:::note
Whitelisted takes precedence, so if it is non-blank then blacklisted is ignored.
白名單優先，如果它不是空白的，則忽略黑名單。
:::
### Issue only users
### 僅限問題用戶
The current way to achieve this is to create/modify a user with a max repo creation limit of 0.
目前的實現方式是創建/修改用戶，將其最大倉庫創建限制設置為 0。
### Restricted users
### 受限用戶
Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.\_\_
受限用戶僅限於根據其組織/團隊成員資格和協作關係訪問部分內容，忽略組織/倉庫等的公共標誌。
Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browsable by all co-workers).
示例用例：一家公司運行一個需要登錄的 Gitea 實例。大多數倉庫是公共的（所有同事都可以訪問/瀏覽）。
At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private.
某個時候，客戶或第三方需要訪問特定倉庫並且僅限於該倉庫。將此類客戶帳戶設置為受限並使用團隊成員資格和/或協作關係授予所需的訪問權限是一種簡單的方法，無需將所有內容設置為私有。
### Enable Fail2ban
### 啟用 Fail2ban
Use [Fail2Ban](../administration/fail2ban-setup.md) to monitor and stop automated login attempts or other malicious behavior based on log patterns
使用 [Fail2Ban](../administration/fail2ban-setup.md) 監控並阻止基於日誌模式的自動登錄嘗試或其他惡意行為
## SSHD vs built-in SSH
## SSHD 與內置 SSH
SSHD is the built-in SSH server on most Unix systems.
SSHD 是大多數 Unix 系統上的內置 SSH 服務器。
Gitea also provides its own SSH server, for usage when SSHD is not available.
Gitea 也提供了自己的 SSH 服務器，用於 SSHD 不可用時使用。
## Translation is incorrect/how to add more translations
## 翻譯不正確/如何添加更多翻譯
Our translations are currently crowd-sourced on our [Crowdin project](https://crowdin.com/project/gitea)
我們的翻譯目前在我們的 [Crowdin 項目](https://crowdin.com/project/gitea) 上進行群眾外包
Whether you want to change a translation or add a new one, it will need to be there as all translations are overwritten in our CI via the Crowdin integration.
無論您是想更改翻譯還是添加新翻譯，都需要在那裡進行，因為所有翻譯都會在我們的 CI 中通過 Crowdin 集成進行覆蓋。
## Push Hook / Webhook / Actions aren't running
## 推送 Hook / Webhook / Actions 未運行
If you can push but can't see push activities on the home dashboard, or the push doesn't trigger webhook and Actions workflows, it's likely that the git hooks are not working.
如果您可以推送但在主頁面板上看不到推送活動，或者推送未觸發 webhook 和 Actions 工作流，這可能是 git hooks 未正常工作。
There are a few possibilities:
有幾種可能性：
1. The git hooks are out of sync: run "Resynchronize pre-receive, update and post-receive hooks of all repositories" on the site admin panel
2. The git repositories (and hooks) are stored on some filesystems (ex: mounted by NAS) which don't support script execution, make sure the filesystem supports `chmod a+x any-script`
3. If you are using docker, make sure Docker Server (not the client) >= 20.10.6
1. git hooks 不同步：在網站管理面板上運行“重新同步所有倉庫的 pre-receive、update 和 post-receive hooks”
2. git 倉庫（和 hooks）存儲在某些文件系統上（例如由 NAS 掛載）不支持腳本執行，確保文件系統支持 `chmod a+x any-script`
3. 如果您使用 docker，確保 Docker 服務器（不是客戶端）>= 20.10.6
## SSH issues
## SSH 問題
If you cannot reach repositories over `ssh`, but `https` works fine, consider looking into the following.
如果您無法通過 `ssh` 訪問倉庫，但 `https` 正常工作，請考慮查看以下內容。
First, make sure you can access Gitea via SSH.
首先，確保您可以通過 SSH 訪問 Gitea。
`ssh git@myremote.example`
If the connection is successful, you should receive an error message like the following:
如果連接成功，您應該會收到如下錯誤消息：
```
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.
```
If you do not get the above message but still connect, it means your SSH key is **not** being managed by Gitea. This means hooks won't run, among other potential problems.
如果您沒有收到上述消息但仍然連接，這意味著您的 SSH 密鑰**未**由 Gitea 管理。這意味著 hooks 不會運行，還有其他潛在問題。
If you cannot connect at all, your SSH key may not be configured correctly locally.
This is specific to SSH and not Gitea, so will not be covered here.
如果您無法連接，您的 SSH 密鑰可能在本地配置不正確。
這是特定於 SSH 而不是 Gitea 的問題，因此不在此處涵蓋。
### SSH Common Errors
### SSH 常見錯誤
```
Permission denied (publickey).
fatal: Could not read from remote repository.
```
This error signifies that the server rejected a log in attempt, check the
following things:
此錯誤表示服務器拒絕了登錄嘗試，請檢查以下內容：
- On the client:
- Ensure the public and private ssh keys are added to the correct Gitea user.
- Make sure there are no issues in the remote url. In particular, ensure the name of the
Git user (before the `@`) is spelled correctly.
- Ensure public and private ssh keys are correct on client machine.
- On the server:
- 在客戶端：
- 確保公鑰和私鑰已添加到正確的 Gitea 用戶。
- 確保遠程 URL 中沒有問題。特別是，確保 Git 用戶名（在 `@` 之前）拼寫正確。
- 確保客戶端機器上的公鑰和私鑰正確。
- 在服務器上：
- Make sure the repository exists and is correctly named.
- Check the permissions of the `.ssh` directory in the system user's home directory.
- Verify that the correct public keys are added to `.ssh/authorized_keys`.
- 確保倉庫存在並且名稱正確。
- 檢查系統用戶主目錄中 `.ssh` 目錄的權限。
- 驗證正確的公鑰已添加到 `.ssh/authorized_keys`。
Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
Gitea admin panel.
嘗試在 Gitea 管理面板上運行“重寫 '.ssh/authorized_keys' 文件（用於 Gitea SSH 密鑰）”。
- Read Gitea logs.
- Read /var/log/auth (or similar).
- Check permissions of repositories.
- 閱讀 Gitea 日誌。
- 閱讀 /var/log/auth（或類似）。
- 檢查倉庫的權限。
The following is an example of a missing public SSH key where authentication
succeeded, but some other setting is preventing SSH from reaching the correct
repository.
以下是缺少公鑰的示例，其中身份驗證成功，但某些其他設置阻止 SSH 訪問正確的倉庫。
```
fatal: Could not read from remote repository.
@@ -282,108 +235,80 @@ Please make sure you have the correct access rights
and the repository exists.
```
In this case, look into the following settings:
在這種情況下，請查看以下設置：
- On the server:
- Make sure that the `git` system user has a usable shell set
- Verify this with `getent passwd git | cut -d: -f7`
- `usermod` or `chsh` can be used to modify this.
- Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the
correct configuration file.
- 在服務器上：
- 確保 `git` 系統用戶設置了可用的 shell
- 使用 `getent passwd git | cut -d: -f7` 驗證
- 可以使用 `usermod` 或 `chsh` 進行修改。
- 確保 `.ssh/authorized_keys` 中的 `gitea serv` 命令使用正確的配置文件。
## Missing releases after migrating repository with tags
## 遷移帶有標籤的倉庫後缺少發布
To migrate an repository _with_ all tags, you need to do two things:
要遷移帶有所有標籤的倉庫，您需要做兩件事：
- Push tags to the repository:
- 將標籤推送到倉庫：
```
git push --tags
```
- (Re-)sync tags of all repositories within Gitea:
- 在 Gitea 中（重新）同步所有倉庫的標籤：
```
gitea admin repo-sync-releases
```
## How can I create users before starting Gitea
## 如何在啟動 Gitea 之前創建用戶
Gitea provides a sub-command `gitea migrate` to initialize the database, after which you can use the [admin CLI commands](../administration/command-line.md#admin) to add users like normal.
Gitea 提供了一個子命令 `gitea migrate` 來初始化數據庫，之後您可以使用 [admin CLI 命令](../administration/command-line.md#admin) 像正常一樣添加用戶。
## How can I enable password reset
## 如何啟用密碼重置
There is no setting for password resets. It is enabled when a [mail service](../administration/email-setup.md) is configured, and disabled otherwise.
沒有密碼重置的設置。當配置了[郵件服務](../administration/email-setup.md)時，它會啟用，否則禁用。
## How can a user's password be changed
## 如何更改用戶的密碼
- As an **admin**, you can change any user's password (and optionally force them to change it on next login)...
- 作為**管理員**，您可以更改任何用戶的密碼（並可選擇強制他們在下次登錄時更改）...
- By navigating to your `Site Administration -> User Accounts` page and editing a user.
- By using the [admin CLI commands](../administration/command-line.md#admin).
- 通過導航到您的 `網站管理 -> 用戶帳戶` 頁面並編輯用戶。
- 通過使用 [admin CLI 命令](../administration/command-line.md#admin)。
Keep in mind most commands will also need a [global flag](../administration/command-line.md#global-options) to point the CLI at the correct configuration.
請記住，大多數命令還需要一個[全局標誌](../administration/command-line.md#global-options)來指向正確的配置。
- As a **user** you can change it...
- 作為**用戶**，您可以更改它...
- In your account `Settings -> Account` page (this method **requires** you to know your current password).
- By using the `Forgot Password` link.
- 在您的帳戶 `設置 -> 帳戶` 頁面（此方法**需要**您知道當前密碼）。
- 通過使用 `忘記密碼` 連結。
If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service](../administration/email-setup.md).
如果 `忘記密碼/帳戶恢復` 頁面被禁用，請聯繫您的管理員配置[郵件服務](../administration/email-setup.md)。
## Warnings about struct defaults during database startup
## 數據庫啟動期間有關結構默認值的警告
Sometimes when there are migrations the old columns and default values may be left
unchanged in the database schema. This may lead to warning such as:
有時在進行遷移時，舊列和默認值可能會保留在數據庫模式中。這可能會導致如下警告：
```
2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync() [W] Table user Column keep_activity_private db default is , struct default is 0
```
These can safely be ignored, but you are able to stop these warnings by getting Gitea to recreate these tables using:
這些警告可以安全地忽略，但您可以通過讓 Gitea 重新創建這些表來停止這些警告：
```
gitea doctor recreate-table user
```
This will cause Gitea to recreate the user table and copy the old data into the new table
with the defaults set appropriately.
這將使 Gitea 重新創建用戶表並將舊數據複製到新表中，並適當設置默認值。
You can ask Gitea to recreate multiple tables using:
您可以讓 Gitea 重新創建多個表：
```
gitea doctor recreate-table table1 table2 ...
```
And if you would like Gitea to recreate all tables simply call:
如果您希望 Gitea 重新創建所有表，只需調用：
```
gitea doctor recreate-table
```
It is highly recommended to back-up your database before running these commands.
## How to adopt repositories from disk
- Add your (bare) repositories to the correct spot for your configuration (`repository.ROOT`), ensuring they are in the correct layout `<REPO_ROOT>/[user]/[repo].git`.
- **Note:** the directory names must be lowercase.
- You can also check `<ROOT_URL>/admin/config` for the repository root path.
- Ensure that the user/org exists that you want to adopt repositories for.
- As an admin, go to `<ROOT_URL>/admin/repos/unadopted` and search.
- Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](../administration/config-cheat-sheet.md#repository-repository).
- If the above steps are done correctly, you should be able to select repositories to adopt.
- If no repositories are found, enable [debug logging](../administration/config-cheat-sheet.md#repository-repository) to check for any specific errors.
## Gitea can't start on NFS
In most cases, it's caused by broken NFS lock system. You can try to stop Gitea process and
run `flock -n /data-nfs/gitea/queues/LOCK echo 'lock acquired'` to see whether the lock can be acquired immediately.
If the lock can't be acquired, NFS might report some errors like `lockd: cannot monitor node-3, statd: server rpc.statd not responding, timed out` in its server logs.
Then the NFS lock could be reset by:
```bash
# /etc/init.d/nfs stop
# rm -rf /var/lib/nfs/sm/*
# /etc/init.d/nfs start
```
強烈建議在運行這些命令之前備份您的