` 元素使用 `class` 属性。
-
-在进行配置更改后，请重新启动 Gitea 以使更改生效。
-
-### 示例：Office DOCX
-
-使用 [`pandoc`](https://pandoc.org/) 显示 Office DOCX 文件：
-
-```ini
-[markup.docx]
-ENABLED = true
-FILE_EXTENSIONS = .docx
-RENDER_COMMAND = "pandoc --from docx --to html --self-contained --template /path/to/basic.html"
-
-[markup.sanitizer.docx.img]
-ALLOW_DATA_URI_IMAGES = true
-```
-
-在此示例中，配置将允许显示 Office DOCX 文件，并使用 `pandoc` 命令将文件转换为 HTML 格式。同时，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
-
-模板文件的内容如下：
-
-```
-$body$
-```
-
-### 示例：Jupyter Notebook
-
-使用 [`nbconvert`](https://github.com/jupyter/nbconvert) 显示 Jupyter Notebook 文件：
-
-```ini
-[markup.jupyter]
-ENABLED = true
-FILE_EXTENSIONS = .ipynb
-RENDER_COMMAND = "jupyter-nbconvert --stdin --stdout --to html --template basic"
-
-[markup.sanitizer.jupyter.img]
-ALLOW_DATA_URI_IMAGES = true
-```
-
-在此示例中，配置将允许显示 Jupyter Notebook 文件，并使用 `nbconvert` 命令将文件转换为 HTML 格式。同样，清理规则中的 `ALLOW_DATA_URI_IMAGES` 设置为 `true`，允许使用 Data URI 格式的图片。
-
-在进行配置更改后，请重新启动 Gitea 以使更改生效。
-
-## 自定义 CSS
-
-在 `.ini` 文件中，可以使用 `[markup.XXXXX]` 的格式指定外部渲染器，并且由外部渲染器生成的 HTML 将被包装在一个带有 `markup` 和 `XXXXX` 类的 `` 中。`markup` 类提供了预定义的样式（如果 `XXXXX` 是 `markdown`，则使用 `markdown` 类）。否则，您可以使用这些类来针对渲染的 HTML 内容进行定制样式。
-
-因此，您可以编写一些 CSS 样式：
-
-```css
-.markup.XXXXX html {
- font-size: 100%;
- overflow-y: scroll;
- -webkit-text-size-adjust: 100%;
- -ms-text-size-adjust: 100%;
-}
-
-.markup.XXXXX body {
- color: #444;
- font-family: Georgia, Palatino, "Palatino Linotype", Times, "Times New Roman",
- serif;
- font-size: 12px;
- line-height: 1.7;
- padding: 1em;
- margin: auto;
- max-width: 42em;
- background: #fefefe;
-}
-
-.markup.XXXXX p {
- color: orangered;
-}
-```
-
-将您的样式表添加到自定义目录中，例如 `custom/public/css/my-style-XXXXX.css`，并使用自定义的头文件 `custom/templates/custom/header.tmpl` 进行导入：
-
-```html
-
-```
-
-通过以上步骤，您可以将自定义的 CSS 样式应用到特定的外部渲染器，使其具有所需的样式效果。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/fail2ban-setup.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/fail2ban-setup.md
deleted file mode 100644
index 70a737ea..00000000
--- a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/fail2ban-setup.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-date: "2022-08-01T00:00:00+00:00"
-slug: "fail2ban-setup"
-sidebar_position: 16
----
-
-# 设置 Fail2ban
-
-**Fail2ban 检查客户端登录日志，将多次登录失败的客户端识别为攻击者并在一段时间内阻止其访问服务。如果你的实例是公开的，这一点尤其重要。请管理员仔细设置 fail2ban，错误的配置将导致防火墙阻止你访问自己的服务器。**
-
-Gitea 会在日志文件 `log/gitea.log` 中记录登录失败的 CLI、SSH 或 HTTP 客户端 IP 地址，而你需要将 Gitea 的日志输出模式从默认的 `console` 更改为 `file`。这表示将日志输出到文件，使得 fail2ban 可以定期扫描日志内容。
-
-当用户的身份验证失败时，日志中会记录此类信息：
-
-```log
-2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
-```
-
-```log
-2020/10/15 16:08:44 [E] invalid credentials from xxx.xxx.xxx.xxx
-```
-
-## Fail2ban 规则
-
-添加日志过滤器规则到配置文件 `/etc/fail2ban/filter.d/gitea.conf`:
-
-```ini
-[Definition]
-failregex = .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from
-ignoreregex =
-```
-
-添加监狱规则到配置文件 `/etc/fail2ban/jail.d/gitea.conf`:
-
-```ini
-[gitea]
-enabled = true
-filter = gitea
-logpath = /var/lib/gitea/log/gitea.log
-maxretry = 10
-findtime = 3600
-bantime = 900
-action = iptables-allports
-```
-
-如果你的 Gitea 实例运行在 Docker 容器中，并且直接将容器端口暴露到外部网络，
-你还需要添加 `chain="FORWARD"` 到监狱规则配置文件 `/etc/fail2ban/jail.d/gitea-docker.conf`
-以适应 Docker 的网络转发规则。但如果你在容器的宿主机上使用 Nginx 反向代理连接到 Gitea 则无需这样配置。
-
-```ini
-[gitea-docker]
-enabled = true
-filter = gitea
-logpath = /var/lib/gitea/log/gitea.log
-maxretry = 10
-findtime = 3600
-bantime = 900
-action = iptables-allports[chain="FORWARD"]
-```
-
-最后，运行 `systemctl restart fail2ban` 即可应用更改。现在，你可以使用 `systemctl status fail2ban` 检查 fail2ban 运行状态。
-
-上述规则规定客户端在 1 小时内，如果登录失败的次数达到 10 次，则通过 iptables 锁定该客户端 IP 地址 15 分钟。
-
-## 设置反向代理
-
-如果你使用 Nginx 反向代理到 Gitea 实例，你还需要设置 Nginx 的 HTTP 头部值 `X-Real-IP` 将真实的客户端 IP 地址传递给 Gitea。否则 Gitea 程序会将客户端地址错误解析为反向代理服务器的地址，例如回环地址 `127.0.0.1`。
-
-```
-proxy_set_header X-Real-IP $remote_addr;
-```
-
-额外注意，在 Gitea 的配置文件 `app.ini` 中存在下列默认值：
-
-```
-REVERSE_PROXY_LIMIT = 1
-REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.0/8,::1/128
-```
-
-`REVERSE_PROXY_LIMIT` 限制反向代理服务器的层数，设置为 `0` 表示不使用这些标头。
-`REVERSE_PROXY_TRUSTED_PROXIES` 表示受信任的反向代理服务器网络地址，
-经过该网络地址转发来的流量会经过解析 `X-Real-IP` 头部得到真实客户端地址。
-（参考 [configuration cheat sheet](https://docs.gitea.io/en-us/config-cheat-sheet/#安全性)）
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/git-lfs-support.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/git-lfs-support.md
deleted file mode 100644
index b537fa0a..00000000
--- a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/git-lfs-support.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-date: "2023-05-23T09:00:00+08:00"
-slug: "git-lfs-setup"
-sidebar_position: 12
-aliases:
- - /zh-cn/git-lfs-setup
----
-
-# Git LFS 设置
-
-要使用 Gitea 内置的 LFS 支持，您需要更新 `app.ini` 文件：
-
-```ini
-[server]
-; 启用 git-lfs 支持。true 或 false，默认为 false。
-LFS_START_SERVER = true
-
-[lfs]
-; 存放 LFS 文件的路径，默认为 data/lfs。
-PATH = /home/gitea/data/lfs
-```
-
-**注意**：LFS 服务器支持需要服务器上安装 Git v2.1.2 以上版本。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/logging-documentation.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/logging-documentation.md
deleted file mode 100644
index 5ddde240..00000000
--- a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/logging-documentation.md
+++ /dev/null
@@ -1,259 +0,0 @@
----
-date: "2023-05-23T09:00:00+08:00"
-slug: "logging-config"
-sidebar_position: 40
-aliases:
- - /zh-cn/logging-configuration
----
-
-# 日志配置
-
-Gitea 的日志配置主要由以下三种类型的组件组成：
-
-- `[log]` 部分用于一般配置
-- `[log.]` 部分用于配置不同的日志输出方式，也称为 "writer mode"，模式名称同时也作为 "writer name"
-- `[log]` 部分还可以包含遵循 `logger..` 模式的子日志记录器的配置
-
-默认情况下，已经有一个完全功能的日志输出，因此不需要重新定义。
-
-## `[log]` 部分
-
-在 Gitea 中，日志设施的配置在 `[log]` 部分及其子部分。
-
-在顶层的 `[log]` 部分，可以放置以下配置项：
-
-- `ROOT_PATH`：（默认值：**%(GITEA_WORK_DIR)/log**）：日志文件的基本路径。
-- `MODE`：（默认值：**console**）：要用于默认日志记录器的日志输出列表。
-- `LEVEL`：（默认值：**Info**）：要持久化的最严重的日志事件，不区分大小写。可能的值为：`Trace`、`Debug`、`Info`、`Warn`、`Error`、`Fatal`。
-- `STACKTRACE_LEVEL`：（默认值：**None**）：对于此类及更严重的事件，将在记录时打印堆栈跟踪。
-
-它还可以包含以下子日志记录器：
-
-- `logger.router.MODE`：（默认值：**,**）：用于路由器日志记录器的日志输出列表。
-- `logger.access.MODE`：（默认值：**_empty_**）：用于访问日志记录器的日志输出列表。默认情况下，访问日志记录器被禁用。
-- `logger.xorm.MODE`：（默认值：**,**）：用于 XORM 日志记录器的日志输出列表。
-
-将子日志记录器的模式设置为逗号（`,`）表示使用默认的全局 `MODE`。
-
-## 快速示例
-
-### 默认（空）配置
-
-空配置等同于默认配置：
-
-```ini
-[log]
-ROOT_PATH = %(GITEA_WORK_DIR)/log
-MODE = console
-LEVEL = Info
-STACKTRACE_LEVEL = None
-logger.router.MODE = ,
-logger.xorm.MODE = ,
-logger.access.MODE =
-
-; 这是“控制台”模式的配置选项（由上面的 MODE=console 使用）
-[log.console]
-MODE = console
-FLAGS = stdflags
-PREFIX =
-COLORIZE = true
-```
-
-这等同于将所有日志发送到控制台，并将默认的 Golang 日志也发送到控制台日志中。
-
-这只是一个示例，默认情况下不需要将其写入配置文件中。
-
-### 禁用路由日志并将一些访问日志记录到文件中
-
-禁用路由日志，将访问日志（>=Warn）记录到 `access.log` 中：
-
-```ini
-[log]
-logger.router.MODE =
-logger.access.MODE = access-file
-
-[log.access-file]
-MODE = file
-LEVEL = Warn
-FILE_NAME = access.log
-```
-
-### 为不同的模式设置不同的日志级别
-
-将默认日志（>=Warn）记录到 `gitea.log` 中，将错误日志记录到 `file-error.log` 中：
-
-```ini
-[log]
-LEVEL = Warn
-MODE = file, file-error
-
-; 默认情况下，"file" 模式会将日志记录到 %(log.ROOT_PATH)/gitea.log，因此我们不需要设置它
-; [log.file]
-
-[log.file-error]
-LEVEL = Error
-FILE_NAME = file-error.log
-```
-
-## 日志输出（模式和写入器）
-
-Gitea 提供以下日志写入器：
-
-- `console` - 输出日志到 `stdout`（或 `stderr`，如果已在配置中设置）
-- `file` - 输出日志到文件
-- `conn` - 输出日志到套接字（网络或 Unix 套接字）
-
-### 公共配置
-
-某些配置适用于所有日志输出模式：
-
-- `MODE` 是日志输出写入器的模式。它将默认为 ini 部分的模式名称。因此，`[log.console]` 将默认为 `MODE = console`。
-- `LEVEL` 是此输出将记录的最低日志级别。
-- `STACKTRACE_LEVEL` 是此输出将打印堆栈跟踪的最低日志级别。
-- `COLORIZE` 对于 `console`，默认为 `true`，否则默认为 `false`。
-
-#### `EXPRESSION`
-
-`EXPRESSION` 表示日志事件必须匹配才能被输出写入器记录的正则表达式。
-日志消息（去除颜色）或 `longfilename:linenumber:functionname` 必须匹配其中之一。
-注意：整个消息或字符串不需要完全匹配。
-
-请注意，此表达式将在写入器的 goroutine 中运行，而不是在日志事件的 goroutine 中运行。
-
-#### `FLAGS`
-
-`FLAGS` 表示在每条消息之前打印的前置日志上下文信息。
-它是一个逗号分隔的字符串集。值的顺序无关紧要。
-
-默认值为 `stdflags`（= `date,time,medfile,shortfuncname,levelinitial`）。
-
-可能的值为：
-
-- `none` 或 `,` - 无标志。
-- `date` - 当地时区的日期：`2009/01/23`。
-- `time` - 当地时区的时间：`01:23:23`。
-- `microseconds` - 微秒精度：`01:23:23.123123`。假定有时间。
-- `longfile` - 完整的文件名和行号：`/a/b/c/d.go:23`。
-- `shortfile` - 文件名的最后一个部分和行号：`d.go:23`。
-- `funcname` - 调用者的函数名：`runtime.Caller()`。
-- `shortfuncname` - 函数名的最后一部分。覆盖 `funcname`。
-- `utc` - 如果设置了日期或时间，则使用 UTC 而不是本地时区。
-- `levelinitial` - 提供的级别的初始字符，放在方括号内，例如 `[I]` 表示 info。
-- `level` - 在方括号内的级别，例如 `[INFO]`。
-- `gopid` - 上下文的 Goroutine-PID。
-- `medfile` - 文件名的最后 20 个字符 - 相当于 `shortfile,longfile`。
-- `stdflags` - 相当于 `date,time,medfile,shortfuncname,levelinitial`。
-
-### Console 模式
-
-在此模式下，日志记录器将将日志消息转发到 Gitea 进程附加的 stdout 和 stderr 流。
-
-对于 console 模式的日志记录器，如果不在 Windows 上，或者 Windows 终端可以设置为 ANSI 模式，或者是 cygwin 或 Msys 管道，则 `COLORIZE` 默认为 `true`。
-
-设置：
-
-- `STDERR`：**false**：日志记录器是否应将日志打印到 `stderr` 而不是 `stdout`。
-
-### File 模式
-
-在此模式下，日志记录器将将日志消息保存到文件中。
-
-设置：
-
-- `FILE_NAME`：要将日志事件写入的文件，相对于 `ROOT_PATH`，默认为 `%(ROOT_PATH)/gitea.log`。异常情况：访问日志默认为 `%(ROOT_PATH)/access.log`。
-- `MAX_SIZE_SHIFT`：**28**：单个文件的最大大小位移。28 表示 256Mb。详细信息见下文。
-- `LOG_ROTATE` **true**：是否轮转日志文件。
-- `DAILY_ROTATE`：**true**：是否每天旋转日志。
-- `MAX_DAYS`：**7**：在此天数之后删除旋转的日志文件。
-- `COMPRESS`：**true**：默认情况下是否使用 gzip 压缩旧的日志文件。
-- `COMPRESSION_LEVEL`：**-1**：压缩级别。详细信息见下文。
-
-`MAX_SIZE_SHIFT` 通过将给定次数左移 1 (`1 << x`) 来定义文件的最大大小。
-在 v1.17.3 版本时的确切行为可以在[这里](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185)中查看。
-
-`COMPRESSION_LEVEL` 的有用值范围从 1 到（包括）9，其中较高的数字表示更好的压缩。
-请注意，更好的压缩可能会带来更高的资源使用。
-必须在前面加上 `-` 符号。
-
-### Conn 模式
-
-在此模式下，日志记录器将通过网络套接字发送日志消息。
-
-设置：
-
-- `ADDR`：**:7020**：设置要连接的地址。
-- `PROTOCOL`：**tcp**：设置协议，可以是 "tcp"、"unix" 或 "udp"。
-- `RECONNECT`：**false**：在连接丢失时尝试重新连接。
-- `RECONNECT_ON_MSG`：**false**：为每条消息重新连接主机。
-
-### "Router" 日志记录器
-
-当 Gitea 的路由处理程序工作时，Router 日志记录器记录以下消息类型：
-
-- `started` 消息将以 TRACE 级别记录
-- `polling`/`completed` 路由将以 INFO 级别记录。异常情况："/assets" 静态资源请求也会以 TRACE 级别记录。
-- `slow` 路由将以 WARN 级别记录
-- `failed` 路由将以 WARN 级别记录
-
-### "XORM" 日志记录器
-
-为了使 XORM 输出 SQL 日志，还应将 `[database]` 部分中的 `LOG_SQL` 设置为 `true`。
-
-### "Access" 日志记录器
-
-"Access" 日志记录器是自 Gitea 1.9 版本以来的新日志记录器。它提供了符合 NCSA Common Log 标准的日志格式。虽然它具有高度可配置性，但在更改其模板时应谨慎。此日志记录器的主要好处是，Gitea 现在可以使用标准日志格式记录访问日志，因此可以使用标准工具进行分析。
-
-您可以通过使用 `logger.access.MODE = ...` 来启用此日志记录器。
-
-如果需要，可以通过更改 `ACCESS_LOG_TEMPLATE` 的值来更改 "Access" 日志记录器的格式。
-
-请注意，访问日志记录器将以 `INFO` 级别记录，将此日志记录器的 `LEVEL` 设置为 `WARN` 或更高级别将导致不记录访问日志。
-
-#### ACCESS_LOG_TEMPLATE
-
-此值表示一个 Go 模板。其默认值为
-
-```tmpl
-{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`
-```
-
-模板接收以下选项：
-
-- `Ctx` 是 `context.Context`
-- `Identity` 是 `SignedUserName`，如果用户未登录，则为 "-"
-- `Start` 是请求的开始时间
-- `ResponseWriter` 是 `http.ResponseWriter`
-
-更改此模板时必须小心，因为它在标准的 panic 恢复陷阱之外运行。此模板应该尽可能简单，因为它会为每个请求运行一次。
-
-## 释放和重新打开、暂停和恢复日志记录
-
-如果您在 Unix 上运行，您可能希望释放和重新打开日志以使用 `logrotate` 或其他工具。
-可以通过向运行中的进程发送 `SIGUSR1` 信号或运行 `gitea manager logging release-and-reopen` 命令来强制 Gitea 释放并重新打开其日志文件和连接。
-
-或者，您可能希望暂停和恢复日志记录 - 可以通过使用 `gitea manager logging pause` 和 `gitea manager logging resume` 命令来实现。请注意，当日志记录暂停时，低于 INFO 级别的日志事件将不会存储，并且只会存储有限数量的事件。在暂停时，日志记录可能会阻塞，尽管是暂时性的，但会大大减慢 Gitea 的运行速度，因此建议仅暂停很短的时间。
-
-### 在 Gitea 运行时添加和删除日志记录
-
-可以使用 `gitea manager logging add` 和 `remove` 子命令在 Gitea 运行时添加和删除日志记录。
-此功能只能调整正在运行的日志系统，不能用于启动未初始化的访问或路由日志记录器。如果您希望启动这些系统，建议调整 app.ini 并（优雅地）重新启动 Gitea 服务。
-
-这些命令的主要目的是在运行中的系统上轻松添加临时日志记录器，以便调查问题，因为重新启动可能会导致问题消失。
-
-## 使用 `logrotate` 而不是内置的日志轮转
-
-Gitea 包含内置的日志轮转功能，对于大多数部署来说应该已经足够了。但是，如果您想使用 `logrotate` 工具：
-
-- 在 `app.ini` 中将 `LOG_ROTATE` 设置为 `false`，禁用内置的日志轮转。
-- 安装 `logrotate`。
-- 根据部署要求配置 `logrotate`，有关配置语法细节，请参阅 `man 8 logrotate`。
- 在 `postrotate/endscript` 块中通过 `kill -USR1` 或 `kill -10` 向 `gitea` 进程本身发送 `USR1` 信号，
- 或者运行 `gitea manager logging release-and-reopen`（使用适当的环境设置）。
- 确保配置适用于由 Gitea 日志记录器生成的所有文件，如上述部分所述。
-- 始终使用 `logrotate /etc/logrotate.conf --debug` 来测试您的配置。
-- 如果您正在使用 Docker 并从容器外部运行，您可以使用
- `docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'`
- 或 `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'`，或直接向 Gitea 进程本身发送 `USR1` 信号。
-
-下一个 `logrotate` 作业将包括您的配置，因此不需要重新启动。
-您还可以立即使用 `logrotate /etc/logrotate.conf --force` 重新加载 `logrotate`。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/mail-templates.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/mail-templates.md
deleted file mode 100644
index b5402c22..00000000
--- a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/mail-templates.md
+++ /dev/null
@@ -1,254 +0,0 @@
----
-date: "2023-05-23T09:00:00+08:00"
-slug: "mail-templates"
-sidebar_position: 45
-aliases:
- - /zh-cn/mail-templates
----
-
-# 邮件模板
-
-为了定制特定操作的电子邮件主题和内容，可以使用模板来自定义 Gitea。这些功能的模板位于 [`custom` 目录](https://docs.gitea.io/en-us/customizing-gitea/) 下。
-如果没有自定义的替代方案，Gitea 将使用内部模板作为默认模板。
-
-自定义模板在 Gitea 启动时加载。对它们的更改在 Gitea 重新启动之前不会被识别。
-
-## 支持模板的邮件通知
-
-目前，以下通知事件使用模板：
-
-| 操作名称 | 用途 |
-| ---------- | ---------------------------------------------------------------------- |
-| `new` | 创建了新的工单或合并请求。 |
-| `comment` | 在现有工单或合并请求中创建了新的评论。 |
-| `close` | 关闭了工单或合并请求。 |
-| `reopen` | 重新打开了工单或合并请求。 |
-| `review` | 在合并请求中进行审查的首要评论。 |
-| `approve` | 对合并请求进行批准的首要评论。 |
-| `reject` | 对合并请求提出更改请求的审查的首要评论。 |
-| `code` | 关于合并请求的代码的单个评论。 |
-| `assigned` | 用户被分配到工单或合并请求。 |
-| `default` | 未包括在上述类别中的任何操作，或者当对应类别的模板不存在时使用的模板。 |
-
-特定消息类型的模板路径为：
-
-```sh
-custom/templates/mail/{操作类型}/{操作名称}.tmpl
-```
-
-其中 `{操作类型}` 是 `issue` 或 `pull`（针对合并请求），`{操作名称}` 是上述列出的操作名称之一。
-
-例如，有关合并请求中的评论的电子邮件的特定模板是：
-
-```sh
-custom/templates/mail/pull/comment.tmpl
-```
-
-然而，并不需要为每个操作类型/名称组合创建模板。
-使用回退系统来选择适当的模板。在此列表中，将使用 _第一个存在的_ 模板：
-
-- 所需**操作类型**和**操作名称**的特定模板。
-- 操作类型为 `issue` 和所需**操作名称**的模板。
-- 所需**操作类型**和操作名称为 `default` 的模板。
-- 操作类型为` issue` 和操作名称为 `default` 的模板。
-
-唯一必需的模板是操作类型为 `issue` 操作名称为 `default` 的模板，除非用户在 `custom` 目录中覆盖了它。
-
-## 模板语法
-
-邮件模板是 UTF-8 编码的文本文件，需要遵循以下格式之一：
-
-```
-用于主题行的文本和宏
-------------
-用于邮件正文的文本和宏
-```
-
-或者
-
-```
-用于邮件正文的文本和宏
-```
-
-指定 _主题_ 部分是可选的（因此也是虚线分隔符）。在使用时，_主题_ 和 _邮件正文_ 模板之间的分隔符需要至少三个虚线；分隔符行中不允许使用其他字符。
-
-_主题_ 和 _邮件正文_ 由 [Golang 的模板引擎](https://golang.org/pkg/text/template/) 解析，并提供了为每个通知组装的 _元数据上下文_。上下文包含以下元素：
-
-| 名称 | 类型 | 可用性 | 用途 |
-| ------------------ | ---------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `.FallbackSubject` | string | 始终可用 | 默认主题行。参见下文。 |
-| `.Subject` | string | 仅在正文中可用 | 解析后的 _主题_。 |
-| `.Body` | string | 始终可用 | 工单、合并请求或评论的消息，从 Markdown 解析为 HTML 并进行了清理。请勿与 _邮件正文_ 混淆。 |
-| `.Link` | string | 始终可用 | 源工单、合并请求或评论的地址。 |
-| `.Issue` | models.Issue | 始终可用 | 产生通知的工单（或合并请求）。要获取特定于合并请求的数据（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但需要注意，如果工单 _不是_ 合并请求，则该字段将为 `nil`。 |
-| `.Comment` | models.Comment | 如果适用 | 如果通知是针对添加到工单或合并请求的评论，则其中包含有关评论的信息。 |
-| `.IsPull` | bool | 始终可用 | 如果邮件通知与合并请求关联（即 `.Issue.PullRequest` 不为 `nil` ），则为 `true`。 |
-| `.Repo` | string | 始终可用 | 仓库的名称，包括所有者名称（例如 `mike/stuff`） |
-| `.User` | models.User | 始终可用 | 事件来源仓库的所有者。要获取用户名（例如 `mike`），可以使用 `.User.Name`。 |
-| `.Doer` | models.User | 始终可用 | 执行触发通知事件的操作的用户。要获取用户名（例如 `rhonda`），可以使用 `.Doer.Name`。 |
-| `.IsMention` | bool | 始终可用 | 如果此通知仅是因为在评论中提到了用户而生成的，并且收件人未订阅源，则为 `true`。如果收件人已订阅工单或仓库，则为 `false`。 |
-| `.SubjectPrefix` | string | 始终可用 | 如果通知是关于除工单或合并请求创建之外的其他内容，则为 `Re：`；否则为空字符串。 |
-| `.ActionType` | string | 始终可用 | `"issue"` 或 `"pull"`。它将与实际的 _操作类型_ 对应，与选择的模板无关。 |
-| `.ActionName` | string | 始终可用 | 它将是上述操作类型之一（`new` ，`comment` 等），并与选择的模板对应。 |
-| `.ReviewComments` | []models.Comment | 始终可用 | 审查中的代码评论列表。评论文本将在 `.RenderedContent` 中，引用的代码将在 `.Patch` 中。 |
-
-所有名称区分大小写。
-
-### 模板中的主题部分
-
-用于邮件主题的模板引擎是 Golang 的 [`text/template`](https://golang.org/pkg/text/template/)。
-有关语法的详细信息，请参阅链接的文档。
-
-主题构建的步骤如下：
-
-- 根据通知类型和可用的模板选择一个模板。
-- 解析并解析模板（例如，将 `{{.Issue.Index}}` 转换为工单或合并请求的编号）。
-- 将所有空格字符（例如 `TAB`，`LF` 等）转换为普通空格。
-- 删除所有前导、尾随和多余的空格。
-- 将字符串截断为前 256 个字母（字符）。
-
-如果最终结果为空字符串，**或者**没有可用的主题模板（即所选模板不包含主题部分），将使用 Gitea 的**内部默认值**。
-
-内部默认（回退）主题相当于：
-
-```
-{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
-```
-
-例如：`Re: [mike/stuff] New color palette (#38)`
-
-即使存在有效的主题模板，Gitea 的默认主题也可以在模板的元数据中作为 `.FallbackSubject` 找到。
-
-### 模板中的邮件正文部分
-
-用于邮件正文的模板引擎是 Golang 的 [`html/template`](https://golang.org/pkg/html/template/)。
-有关语法的详细信息，请参阅链接的文档。
-
-邮件正文在邮件主题之后进行解析，因此还有一个额外的 _元数据_ 字段，即在考虑所有情况之后实际呈现的主题。
-
-期望的结果是 HTML（包括结构元素，如``，``等）。可以通过 `
`)。
-
-多个净化规则可以被同时定义，只要section名称最后一位不重复即可。如： `[markup.sanitizer.TeX-2]`。
-为了针对一种渲染类型进行一个特殊的净化策略，必须使用形如 `[markup.sanitizer.asciidoc.rule-1]` 的方式来命名 section。
-如果此规则没有匹配到任何渲染类型，它将会被应用到所有的渲染类型。
-
-## Time (`time`)
-
-- `FORMAT`: 显示在界面上的时间格式。比如： RFC1123 或者 2006-01-02 15:04:05
-- `DEFAULT_UI_LOCATION`: 默认显示在界面上的时区，默认为本地时区。比如： Asia/Shanghai
-
-## Task (`task`)
-
-- `QUEUE_TYPE`: **channel**: 任务队列类型，可以为 `channel` 或 `redis`。
-- `QUEUE_LENGTH`: **1000**: 任务队列长度，当 `QUEUE_TYPE` 为 `channel` 时有效。
-- `QUEUE_CONN_STR`: **addrs=127.0.0.1:6379 db=0**: 任务队列连接字符串，当 `QUEUE_TYPE` 为 `redis` 时有效。如果redis有密码，则可以 `addrs=127.0.0.1:6379 password=123 db=0`。
-
-## Migrations (`migrations`)
-
-- `MAX_ATTEMPTS`: **3**: 在迁移过程中的 http/https 请求重试次数。
-- `RETRY_BACKOFF`: **3**: 等待下一次重试的时间，单位秒。
-- `ALLOWED_DOMAINS`: **_empty_**: 迁移仓库的域名白名单，默认为空，表示允许从任意域名迁移仓库，多个域名用逗号分隔。
-- `BLOCKED_DOMAINS`: **_empty_**: 迁移仓库的域名黑名单，默认为空，多个域名用逗号分隔。如果 `ALLOWED_DOMAINS` 不为空，此选项有更高的优先级拒绝这里的域名。
-- `ALLOW_LOCALNETWORKS`: **false**: Allow private addresses defined by RFC 1918
-- `SKIP_TLS_VERIFY`: **false**: 允许忽略 TLS 认证
-
-## LFS (`lfs`)
-
-LFS 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/lfs`，`MINIO_BASE_PATH` 默认为 `lfs/`。
-
-- `STORAGE_TYPE`: **local**: LFS 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
-- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
-- `PATH`: 存放 lfs 命令上传的文件的地方，默认是 `data/lfs`。
-- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_BASE_PATH`: **lfs/**: Minio base path ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `LFS_STORAGE_TYPE` 为 `minio` 时有效。
-
-## Storage (`storage`)
-
-Attachments, lfs, avatars and etc 的默认存储配置。
-
-- `STORAGE_TYPE`: **local**: 附件存储类型，`local` 将存储到本地文件夹， `minio` 将存储到 s3 兼容的对象存储服务中。
-- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
-- `MINIO_ENDPOINT`: **localhost:9000**: Minio 终端，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID ，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-- `MINIO_BUCKET`: **gitea**: Minio bucket to store the attachments，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-- `MINIO_LOCATION`: **us-east-1**: Minio location to create bucket，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-- `MINIO_USE_SSL`: **false**: Minio enabled ssl，仅当 `STORAGE_TYPE` 是 `minio` 时有效。
-
-你也可以自定义一个存储的名字如下：
-
-```ini
-[storage.my_minio]
-STORAGE_TYPE = minio
-; Minio endpoint to connect only available when STORAGE_TYPE is `minio`
-MINIO_ENDPOINT = localhost:9000
-; Minio accessKeyID to connect only available when STORAGE_TYPE is `minio`
-MINIO_ACCESS_KEY_ID =
-; Minio secretAccessKey to connect only available when STORAGE_TYPE is `minio`
-MINIO_SECRET_ACCESS_KEY =
-; Minio bucket to store the attachments only available when STORAGE_TYPE is `minio`
-MINIO_BUCKET = gitea
-; Minio location to create bucket only available when STORAGE_TYPE is `minio`
-MINIO_LOCATION = us-east-1
-; Minio enabled ssl only available when STORAGE_TYPE is `minio`
-MINIO_USE_SSL = false
-; Minio skip SSL verification available when STORAGE_TYPE is `minio`
-MINIO_INSECURE_SKIP_VERIFY = false
-```
-
-然后你在 `[attachment]`, `[lfs]` 等中可以把这个名字用作 `STORAGE_TYPE` 的值。
-
-## Repository Archive Storage (`storage.repo-archive`)
-
-Repository archive 的存储配置。 如果 `STORAGE_TYPE` 为空，则此配置将从 `[storage]` 继承。如果不为 `local` 或者 `minio` 而为 `xxx`， 则从 `[storage.xxx]` 继承。当继承时， `PATH` 默认为 `data/repo-archive`，`MINIO_BASE_PATH` 默认为 `repo-archive/`。
-
-- `STORAGE_TYPE`: **local**: Repository archive 的存储类型，`local` 将存储到磁盘，`minio` 将存储到 s3 兼容的对象服务。
-- `SERVE_DIRECT`: **false**: 允许直接重定向到存储系统。当前，仅 Minio/S3 是支持的。
-- `PATH`: 存放 Repository archive 上传的文件的地方，默认是 `data/repo-archive`。
-- `MINIO_ENDPOINT`: **localhost:9000**: Minio 地址，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_ACCESS_KEY_ID`: Minio accessKeyID，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_SECRET_ACCESS_KEY`: Minio secretAccessKey，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_BUCKET`: **gitea**: Minio bucket，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_LOCATION`: **us-east-1**: Minio location ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_BASE_PATH`: **repo-archive/**: Minio base path ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-- `MINIO_USE_SSL`: **false**: Minio 是否启用 ssl ，仅当 `STORAGE_TYPE` 为 `minio` 时有效。
-
-## Proxy (`proxy`)
-
-- `PROXY_ENABLED`: **false**: 是否启用全局代理。如果为否，则不使用代理，环境变量中的代理也不使用
-- `PROXY_URL`: **_empty_**: 代理服务器地址，支持 http://, https//, socks://，为空则不启用代理而使用环境变量中的 http_proxy/https_proxy
-- `PROXY_HOSTS`: **_empty_**: 逗号分隔的多个需要代理的网址，支持 * 号匹配符号， ** 表示匹配所有网站
-
-i.e.
-
-```ini
-PROXY_ENABLED = true
-PROXY_URL = socks://127.0.0.1:1080
-PROXY_HOSTS = *.github.com
-```
-
-## Other (`other`)
-
-- `SHOW_FOOTER_BRANDING`: 为真则在页面底部显示Gitea的字样。
-- `SHOW_FOOTER_VERSION`: 为真则在页面底部显示Gitea的版本。
diff --git a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/customizing-gitea.md b/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/customizing-gitea.md
deleted file mode 100644
index e4a44c63..00000000
--- a/i18n/zh-cn/docusaurus-plugin-content-docs/version-1.19/administration/customizing-gitea.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-date: "2017-04-15T14:56:00+02:00"
-slug: "customizing-gitea"
-sidebar_position: 100
----
-
-# 自定义 Gitea 配置
-
-Gitea 引用 `custom` 目录中的自定义配置文件来覆盖配置、模板等默认配置。
-
-如果从二进制部署 Gitea ，则所有默认路径都将相对于该 gitea 二进制文件；如果从发行版安装，则可能会将这些路径修改为Linux文件系统标准。Gitea
-将会自动创建包括 `custom/` 在内的必要应用目录，应用本身的配置存放在
-`custom/conf/app.ini` 当中。在发行版中可能会以 `/etc/gitea/` 的形式为 `custom` 设置一个符号链接，查看配置详情请移步：
-
-- [快速备忘单](https://docs.gitea.io/en-us/config-cheat-sheet/)
-- [完整配置清单](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
-
-如果您在 binary 同目录下无法找到 `custom` 文件夹，请检查您的 `GITEA_CUSTOM`
-环境变量配置， 因为它可能被配置到了其他地方（可能被一些启动脚本设置指定了目录）。
-
-- [环境变量清单](https://docs.gitea.io/en-us/specific-variables/)
-
-**注：** 必须完全重启 Gitea 以使配置生效。
-
-## 使用自定义 /robots.txt
-
-将 [想要展示的内容](http://www.robotstxt.org/) 存放在 `custom` 目录中的
-`robots.txt` 文件来让 Gitea 使用自定义的`/robots.txt` （默认：空 404）。
-
-## 使用自定义的公共文件
-
-将自定义的公共文件（比如页面和图片）作为 webroot 放在 `custom/public/` 中来让 Gitea 提供这些自定义内容（符号链接将被追踪）。
-
-举例说明：`image.png` 存放在 `custom/public/`中，那么它可以通过链接 http://gitea.domain.tld/assets/image.png 访问。
-
-## 修改默认头像
-
-替换以下目录中的 png 图片： `custom/public/img/avatar\_default.png`
-
-## 自定义 Gitea 页面
-
-您可以改变 Gitea `custom/templates` 的每个单页面。您可以在 Gitea 源码的 `templates` 目录中找到用于覆盖的模板文件，应用将根据
-`custom/templates` 目录下的路径结构进行匹配和覆盖。
-
-包含在 `{{` 和 `}}` 中的任何语句都是 Gitea 的模板语法，如果您不完全理解这些组件，不建议您对它们进行修改。
-
-### 添加链接和页签
-
-如果您只是想添加额外的链接到顶部导航栏或额外的选项卡到存储库视图，您可以将它们放在您 `custom/templates/custom/` 目录下的 `extra_links.tmpl` 和 `extra_tabs.tmpl` 文件中。
-
-举例说明：假设您需要在网站放置一个静态的“关于”页面，您只需将该页面放在您的
-"custom/public/"目录下（比如 `custom/public/impressum.html`）并且将它与 `custom/templates/custom/extra_links.tmpl` 链接起来即可。
-
-这个链接应当使用一个名为“item”的 class 来匹配当前样式，您可以使用 `{{AppSubUrl}}` 来获取 base URL:
-`Impressum`
-
-同理，您可以将页签添加到 `extra_tabs.tmpl` 中，使用同样的方式来添加页签。它的具体样式需要与
-`templates/repo/header.tmpl` 中已有的其他选项卡的样式匹配
-([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl))
-
-### 页面的其他新增内容
-
-除了 `extra_links.tmpl` 和 `extra_tabs.tmpl`，您可以在您的 `custom/templates/custom/` 目录中存放一些其他有用的模板，例如：
-
-- `header.tmpl`，在 `` 标记结束之前的模板，例如添加自定义CSS文件
-- `body_outer_pre.tmpl`，在 `` 标记开始处的模板
-- `body_inner_pre.tmpl`，在顶部导航栏之前，但在主 container 内部的模板，例如添加一个 `