[docs/zh] Update zh docs: synced to 6c879186 (#4117)

# Description

This PR updates the Chinese documentation to 6c879186 (the latest commit at present).

It also fixed a small typo in the original docs. Since the change is so minor, I didn't make a separate PR.

Last docs/zh update PR: #3884

## Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: `[ ]` -> `[x]`

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

- [x] I/we have read the [GoToSocial contribution guidelines](https://codeberg.org/superseriousbusiness/gotosocial/src/branch/main/CONTRIBUTING.md).

Reviewed-on: https://codeberg.org/superseriousbusiness/gotosocial/pulls/4117
Co-authored-by: cdn0x12 <git@cdn0x12.dev>
Co-committed-by: cdn0x12 <git@cdn0x12.dev>
This commit is contained in:
cdn0x12 2025-05-03 09:28:16 +00:00 committed by tobi
commit 4d6408015b
18 changed files with 817 additions and 115 deletions

View file

@ -9,9 +9,9 @@ GoToSocial 编译为二进制可执行文件。
以下是 `gotosocial --help` 的完整输出,不包括全局配置选项的大列表。
```text
GoToSocial - 一个联邦制社交媒体服务器
GoToSocial - 一个联合式社交媒体服务器
帮助文档参见https://docs.gotosocial.org。
帮助文档参见https://docs.gotosocial.org/zh-cn/
代码仓库https://codeberg.org/superseriousbusiness/gotosocial
@ -57,6 +57,9 @@ GoToSocial - 一个联邦制社交媒体服务器
此命令可用于在你的实例上创建新账户。
!!! Warning "警告"
执行此命令前,你必须至少运行过一次服务端,以初始化数据库中的必要条目,然后才能运行此命令。
`gotosocial admin account create --help`:
```text

View file

@ -37,7 +37,7 @@
例如,实例 `instance-a.example.org``instance-b.example.org``instance-c.example.org` 决定他们只想彼此联合。
他们可以使用像 GitHub 这样的版本管理平台托管一个纯文本格式的允许列表,比如在 `https://raw.githubusercontent.com/our-cluster/allowlist/refs/heads/main/allows.txt`。
他们可以使用像 Codeberg 这样的版本管理平台托管一个纯文本格式的允许列表,比如在 `https://codeberg.org/our-cluster/allowlist/raw/branch/main/allows.txt`。
纯文本格式的允许列表内容如下:
@ -47,7 +47,7 @@ instance-b.example.org
instance-c.example.org
```
每个实例管理员都将他们的联合模式设置为`白名单`,并创建一个类型为“允许”,订阅地址为 `https://raw.githubusercontent.com/our-cluster/allowlist/refs/heads/main/allows.txt` 的订阅,这会为他们自己的域名以及集群中的其他域名创建域名允许条目。
每个实例管理员都将他们的联合模式设置为`allowlist`,并创建一个类型为“允许”,订阅地址为 `https://codeberg.org/our-cluster/allowlist/raw/branch/main/allows.txt` 的订阅,这会为他们自己的域名以及集群中的其他域名创建域名允许条目。
在某个时候,来自 `instance-d.example.org` 的某人(在站外)申请被添加到集群中。现有的管理员同意,并更新他们的纯文本格式允许列表为:
@ -66,7 +66,7 @@ instance-d.example.org
例如,实例 `instance-e.example.org``instance-f.example.org``instance-g.example.org` 的管理员认定:他们厌倦了通过与坏人玩打地鼠游戏来重复工作。为了让生活更轻松,他们决定合作开发一个共享的阻止列表。
他们使用像 GitHub 这样的版本管理平台在类似 `https://raw.githubusercontent.com/baddies/blocklist/refs/heads/main/blocks.csv` 的地方托管一个阻止列表。
他们使用像 Codeberg 这样的版本管理平台在类似 `https://codeberg.org/our-cluster/allowlist/raw/branch/main/blocks.csv` 的地方托管一个阻止列表。
当有人发现另一个他们不喜欢的实例时,他们可以通过合并请求或类似方法添加这个有问题的实例到域名列表中。
@ -113,6 +113,27 @@ nothanks.com,suspend,false,false,,false
JSON列表使用内容类型 `application/json`
```json
[
{
"domain": "bumfaces.net",
"suspended_at": "2020-05-13T13:29:12.000Z",
"comment": "这个实例上有坏蛋"
},
{
"domain": "peepee.poopoo",
"suspended_at": "2020-05-13T13:29:12.000Z",
"comment": "骚扰"
},
{
"domain": "nothanks.com",
"suspended_at": "2020-05-13T13:29:12.000Z"
}
]
```
可以使用 `"comment"` 字段替代 `"public_comment"`:
```json
[
{

View file

@ -31,13 +31,18 @@ GoToSocial 当前提供“黑名单”和“白名单”联合模式,可以通
## 结合屏蔽与允许
可以同时屏蔽和允许同一个域,结合这两者的效果取决于你的实例当前使用的联合模式。
!!! danger "危险"
结合屏蔽和允许是一项棘手的工作!
在导入白名单和黑名单时,你应该始终手动审核列表,以确保不会无意中屏蔽你不想屏蔽的实例,因为这可能带来 **非常令人困扰的副作用** ,例如关注/粉丝关系的移除、贴文的删除等。
有疑问时,请始终首先显式添加白名单条目作为保险策略!
![一个流程图,显示两种不同联合模式如何处理传入的请求。](../public/diagrams/federation_modes.png)
同时屏蔽和允许同一个域名是合法的,而这两个操作结合之后的效果取决于你的实例目前正在使用哪种联合模式,具体如下所述,你可以在下面找到流程图。
### 在黑名单模式下
如图所示,在黑名单模式下(图的左侧),显式添加允许条目可以用来覆盖域名屏蔽。
图所示,在黑名单模式下(图的左侧),显式添加允许条目可以用来覆盖域名屏蔽。
这在你从其他人处导入黑名单,但导入的黑名单中包含了一些你实际上不想屏蔽的实例时很有用。为了避免屏蔽这些实例,你可以先为这些实例显式创建允许条目。然后,当你导入黑名单时,显式允许的域将不会被屏蔽,并且创建屏蔽所导致的副作用(删除贴文、媒体、关系等)将不会被处理。
@ -47,16 +52,11 @@ GoToSocial 当前提供“黑名单”和“白名单”联合模式,可以通
### 在白名单模式下
如图所示,在白名单模式下(图的右侧),显式域名屏蔽条目会优先于显式域名允许条目。在运行白名单模式时,必须满足以下两个条件才能允许一个实例通过:
图所示,在白名单模式下(图的右侧),显式域名屏蔽条目会优先于显式域名允许条目。在运行白名单模式时,必须满足以下两个条件才能允许一个实例通过:
1. 实例没有存在对应的显式域名屏蔽。
2. 实例存在对应的显式域名允许。
如果上述任何条件不满足,请求将被拒绝。
!!! danger "危险"
结合屏蔽和允许是一项棘手的工作!
在导入允许和黑名单时,你应该始终手动审核列表,以确保不会无意中屏蔽你不想屏蔽的实例,因为这可能会有**非常烦人的副作用**,例如移除关注/被关注、贴文等。
有疑问时,请始终首先添加显式允许作为保险策略!
![展示两种联合模式分别如何处理入站请求的流程图](../public/diagrams/federation_modes.png)

View file

@ -10,8 +10,6 @@ GoToSocial 在主域名上提供一个 `robots.txt` 文件。该文件包含试
AI 爬虫来自一个[社区维护的仓库][airobots]。目前是手动保持同步的。如果你知道有任何遗漏的爬虫,请给他们提交一个 PR
已知有许多 AI 爬虫即便明确匹配其 User-Agent也会忽略 `robots.txt` 中的条目。这意味着 `robots.txt` 文件并不是确保 AI 爬虫不抓取你的内容的万无一失的方法。
如果你想完全屏蔽这些爬虫,需要在反向代理中根据 User-Agent 头进行屏蔽,直到 GoToSocial 能够根据 User-Agent 头过滤请求。
众所周知,很多 AI 爬虫在 `robots.txt` 不允许其 User-Agent 的情况下,仍然会忽略对应规则并继续抓去内容。这意味着 `robots.txt` 文件并不是确保 AI 爬虫不抓取你的内容的万无一失的方法。除此以外,你可能还需要考虑通过[请求标头过滤](request_filtering_modes.md)来阻止对应 User-Agent以及启用基于工作证明的[爬虫防护](../advanced/scraper_deterrence.md)。
[airobots]: https://github.com/ai-robots-txt/ai.robots.txt/