13太保玩转github-第3太保-李存勖-全面中文化

能翻译的是契约，翻不了的是入口。text[读者] 维护中文开源仓库的工程师[痛点] README 是中文，Issue 表单、标签、Release 却全是英文，贡献者卡在第一步[现在读] GitHub 没有官方简中 UI，你需要一套只翻“能翻的部分”的落地方法[读完] 会用 gh 与 .github/ 约定文件把仓库资产统一成中文体系，并知道哪一层绝对不要动``````text[旧方案] 只把 README 翻译成中文 | v[新需求] Issue / PR / Project / Discussion / Release 全链路中文 | v[冲突] 平台 UI、YAML 字段、Topics 由 GitHub 定义，翻译即破坏机器可读性 | v[后果] 中文表单提交失败、标签重复、自动化脚本读不到字段我是老李，springaialibabapractice这个仓库从第一太保写到现在，Actions 跑通了，Projects 建好了，Discussions 也开了分类。上周一位读者在 Issue 里问：我把模板填了，为什么提交按钮是灰的？我点开一看，他填的是中文表单，但表单里有一栏提示是英文的，他没看懂，直接留空了。第二个信号更直接：仓库里同时存在bug、缺陷、Bug修复三个标签，语义重叠，筛选视图全乱。一个人名下的仓库还好，等有第二位维护者时，谁都说不清该用哪个。GitHub.com 与官方 Desktop 都没有完整的官方简中界面，这是前提。于是这一章的任务定下来：不是把 GitHub 界面换成中文，而是把仓库里属于我们自己的那部分资产，统一成一套可维护、可验证的中文体系。那我们还翻什么？翻哪些层，哪些层碰都不能碰？如果翻错了层，代价是什么？# 01、故事后唐庄宗李存勖的厉害之处，不在于他自己能打，而在于他能把散在各地的力量收进同一面旗号、统一号令，最后灭后梁、建后唐。仓库中文化是一模一样的事：不是把界面涂成中文，而是立一面旗。springaialibabapractice里散着七类资产：README、Issue、PR、Projects、Discussions、Releases、Pages。它们各自说各自的话。读者看到 README 是中文，点进 Issue 却是英文表单；看到 Release 标题是中文，正文却混着英文模板段。我先做了一件最笨也最有用的准备工作——写一份词汇表。把 Issue Form 译作“Issue 表单”，把 Label 译作“标签”，把 Milestone 译作“里程碑”，并规定技术名词首次出现时写成“英文原名（中文说明）”。这份词汇表后来成了整章的验收基准，也是判断一处文案该不该改的那把尺子。具体到操作，我把它拆成两条线：Web SaaS 上点得出来的入口，和 CLI 里能复现的命令。两条线必须给出同一套名词，否则文档本身就自相矛盾。任务是：让这七类资产对同一个中文贡献者呈现同一套语言和同一套名词。> 立旗先立号> 号一令乃行> 译字先译界> 界明不乱翻# 02、问题旧的方案是“谁看到谁翻一句”。README 翻了，Issue 表单还是英文默认模板；标签是英文加几个随手建的中文标签；Release Notes 用--generate-notes出来全是英文 PR 标题。业务影响很具体：一位中文读者读完 README 想提需求，点开 New issue 看到英文表单，填到一半关掉。这不是“体验差一点”，而是贡献漏斗在第一步就断了。技术表现有四类：1. 同一语义存在多个标签，bug、缺陷、Bug修复并存。2. 表单与标签脱钩，Issue Form 里写的 label 名与仓库里实际存在的标签不一致。3. 官方入口被覆盖，good first issue、help wanted被改成中文后，仓库首页的官方筛选入口失联。4. 内容风格不一，README 中文、CONTRIBUTING 半英半中、Release Notes 英文。可验证的完成标准（这一章按此验收）：-gh label list输出的标签名全部符合前缀:名称格式，且good first issue、help wanted原样存在。- 打开 New issue，能看到全中文表单，必填校验生效，提交后自动带上正确的标签。-.github/下社区健康文件、PR 模板、至少两个 Issue Form 均为中文正文。-docs/github-ops/里留有可复现的命令与输出，其他维护者照着能重跑。> 说到做不到> 不算立了旗> 说到能验证> 才算真收编# 03、原理GitHub 仓库资产分三层，这是整章的判断依据。内容层：README、CONTRIBUTING、Release Notes 正文、Discussion 帖子。纯文本，想怎么写怎么写，全中文没问题。约定层：Issue Form 的字段值、PR 模板正文、标签名称。这一层是“半翻译”——name、description、label、placeholder这些 YAML 字段名不能动，字段值要写成中文；但其中作为机器键的部分（标签名、模板文件名）一旦翻译，就会与 GitHub 的识别逻辑脱钩。平台层：Topics、Actions YAML 关键字、API 字段名、仓库 slug。这层不可翻译。Topics 的格式规则是官方硬约束，只允许小写字母、数字与连字符，中文 Topic 会被直接拒绝。反直觉判断：中文化的收益不在“人看得懂”，而在“机器筛得准”。一个仓库有四十个标签、其中十个是同义英文词，人看得懂，但筛选视图里你永远不知道点哪个。第二个反直觉判断：最应该保留英文的，恰恰是最像“入口”的那些词。good first issue和help wanted不是普通标签，它们是 GitHub 为新仓库自动创建的默认标签，并参与仓库首页与搜索的官方呈现。把它们翻成中文，等于把官方入口关掉。Issue Form 的本質是 YAML 渲染成表单，提交时把字段值组装成 Issue 正文，再把labels里的名字去匹配仓库已有标签。所以中文 Issue Form 的正确写法是：字段值中文，字段名英文，标签名与仓库逐字符一致。> 名字不是名字> 名字是接口> 接口一旦改> 调用全失效# 04、架构text[输入] 一次中文化改动 | v[模块] 词汇表 + 标签清单 + 同步脚本 + .github/ 约定文件 | v[数据/状态] docs/github-ops/glossary.md、labels.txt、仓库内实际标签 | v[处理] gh label create --force 幂等同步；Issue Form labels 字段匹配标签名 | v[输出] 中文 README / Issue / PR / Project / Discussion / Release，全部可复现围绕“一次改动如何同时被人读到、被机器认到、被后来者复现”，架构分四块：1. 词汇表docs/github-ops/glossary.md：中英词对照与“首现写法”规则，是全仓库唯一的语言裁判。2. 标签清单docs/github-ops/labels.txt：名称|颜色|描述三列，脚本与 Issue Form 都从这里取名字。3. 同步脚本scripts/gh-labels.sh：读清单，用gh label create --force幂等写入。4..github/约定文件：Issue Forms、PR 模板、社区健康文件。边界：不碰 UI，浏览器装汉化插件不属于仓库行为，不进文档、不进脚本；不碰 Topics，保持小写英文连字符；不碰 Actions YAML 关键字与 API 字段名。收益：新增一个中文标签或一个中文表单，改一处清单即可，不用在五个文件里翻找。代价：多一层间接，清单文件与表单文件仍需人工保证一致，脚本无法校验 YAML 内部的标签名。适用条件：仓库已有外部贡献者、标签数量超过十五个、有多位维护者时收益明显；一个人自娱自乐的仓库直接手建标签更省事。> 一处立规矩> 处处照着抄> 抄错一处时> 有据可回查# 05、实战一次环境与版本：GitHub.com（SaaS）、ghCLI、Git 2.x、macOS 或 Linux。目标仓库lifuchun522/springaialibabapractice。以下命令未在当前环境实测，输出为预期结果并以“示例输出”标注，具体行为需按当前官方文档核验。分支：bashgit switch -c githubops/03-chinese-localizationmkdir -p .github/ISSUE_TEMPLATE docs/github-ops scripts词汇表docs/github-ops/glossary.md（节选）：markdown| 英文原名 | 中文写法 | 首现规则 || --- | --- | --- || Issue | Issue | 首现写 Issue（问题），此后用 Issue || Pull Request | Pull Request | 首现写 Pull Request（拉取请求），此后用 PR || Label | 标签 | 首现写 Label（标签） || Milestone | 里程碑 | 直接中文 || Discussion | Discussion | 保留英文 || Release | Release | 保留英文 || Topics | Topics | 不可翻译，保持小写英文连字符 |标签清单docs/github-ops/labels.txt：类型:缺陷|d73a4a|可复现的功能或文档错误类型:功能|a2eeef|新增能力请求类型:文档|0075ca|文档补充或修正优先级:高|b60205|阻断主流程优先级:中|fbca04|影响体验不阻断优先级:低|c5def5|可以排期状态:待确认|d4c5f9|等待维护者确认状态:进行中|0e8a16|已有人认领状态:已阻塞|b60205|依赖外部条件模块:文档|1d76db|README/CONTRIBUTING 等模块:脚本|5319e7|本地 CLI 脚本模块:CI|0e8a16|GitHub Actions 配置难度:入门|7057ff|适合首次贡献难度:进阶|8a2be2|需要熟悉项目结构注意：good first issue、help wanted不写进清单，保持原样，不做重命名，不做翻译。同步脚本scripts/gh-labels.sh：bash#!/usr/bin/env bashset -euo pipefailREPO="${REPO:-lifuchun522/springaialibabapractice}"MANIFEST="docs/github-ops/labels.txt"while IFS='|' read -r name color desc; do [ -z "${name}" ] && continue case "${name}" in \#*) continue ;; esac echo "==> ${name}" gh label create "${name}" --repo "${REPO}" --color "${color}" --description "${desc}" --forcedone < "${MANIFEST}"echo '保留官方默认标签：'gh label list --repo "${REPO}" --limit 100 --json name --jq '.[].name' | grep -E '^(good first issue|help wanted)$' || echo '警告：官方默认标签缺失'Issue Form.github/ISSUE_TEMPLATE/01-bug.yml（文件名保持 GitHub 规范，用户看到的中文名来自name字段）：yamlname: 缺陷报告description: 报告一个可复现的问题title: '[缺陷] 'labels: ['类型:缺陷']body: - type: markdown attributes: value: | 感谢反馈。请逐项填写，缺少复现步骤的问题会被标记为「状态:待确认」。 - type: textarea id: what-happened attributes: label: 发生了什么 description: 描述你观察到的现象，不要只写「报错了」 validations: required: true - type: textarea id: reproduce attributes: label: 复现步骤 description: 从干净环境开始，逐步写清命令 placeholder: | 1. git clone ... 2. gh label list 3. 观察到 ... validations: required: true - type: input id: version attributes: label: 版本或提交号 description: 填 Release 版本，或 git rev-parse --short HEAD 的输出 validations: required: true - type: dropdown id: module attributes: label: 受影响模块 options: - 文档 - CLI 脚本 - CI 配置 validations: required: true - type: checkboxes id: preflight attributes: label: 提交前确认 options: - label: 我已搜索过已有 Issue required: true - label: 我已阅读 CONTRIBUTING.md required: truePR 模板.github/pull_request_template.md：markdown## 这个 PR 做了什么## 关联 IssueCloses ### 自检清单- [ ] 我读过 CONTRIBUTING.md- [ ] 涉及命令的改动，我贴出了实际输出- [ ] 新增文案符合 docs/github-ops/glossary.md 的写法- [ ] 我没有修改 Topics、Actions 关键字或 API 字段名贡献指南CONTRIBUTING.md：markdown# 贡献指南## 你可以怎么贡献- 报告缺陷：使用「缺陷报告」表单，附最小复现步骤- 提交文档修正：直接开 Pull Request，标题用 [文档] 前缀- 认领入门任务：筛选标签 good first issue## 提交前1. 阅读 docs/github-ops/glossary.md，确认用词2. 本地跑一次 scripts/gh-labels.sh，确认标签同步不报错3. 在 PR 自检清单里逐项打勾## 语言约定正文用中文；技术名词首次出现写成「英文原名（中文说明）」，例如 Label（标签）。安全政策SECURITY.md：markdown# 安全政策## 支持的版本只维护最新一个 Release。## 报告漏洞请勿在公开 Issue 中披露细节，改用 GitHub 的私密漏洞报告入口（Security → Advisories → Report a vulnerability）。## 范围本仓库仅包含示例代码与文档，不处理生产数据。````CODE_OF_CONDUCT.md` 与 `SUPPORT.md` 同样改写成中文：前者首段说明适用范围与举报渠道，后者列出提问前先查 README、再搜 Issue、最后开 Discussion 的三步顺序。这两个文件名保持官方形式不变。启动：写标签。bashchmod +x scripts/gh-labels.shREPO=lifuchun522/springaialibabapractice ./scripts/gh-labels.sh示例输出：bash==> 类型:缺陷✓ Label “类型:缺陷” created==> 类型:功能✓ Label “类型:功能” created保留官方默认标签：good first issuehelp wanted请求一，验证标签清单：bashgh label list --repo lifuchun522/springaialibabapractice --limit 100请求二，非交互式建一个带中文标签的 Issue，验证标签联动：bashcat > /tmp/issue-body.md <<‘EOF’### 发生了什么执行 gh label list 后没有输出### 复现步骤1. 干净环境克隆仓库2. 执行 scripts/gh-labels.sh3. 观察无任何输出### 版本或提交号githubops/03-chinese-localization### 受影响模块CLI 脚本### 提交前确认- [x] 我已搜索过已有 Issue- [x] 我已阅读 CONTRIBUTING.mdEOFgh issue create --repo lifuchun522/springaialibabapractice --title “[缺陷] 验证中文标签生效” --body-file /tmp/issue-body.md --label “类型:缺陷” --label "优先级:中"请求三，交互式验证中文表单与必填校验：bashgh issue create --repo lifuchun522/springaialibabapractice --web在浏览器里选中「缺陷报告」，留空任一必填项，确认提交按钮不可用；填满后提交，确认 Issue 自动带上 `类型:缺陷`。Release Notes 中文化：bashgh release create v0.3.0 --repo lifuchun522/springaialibabapractice --title “v0.3.0 全面中文化” --notes-file docs/github-ops/release-notes-v0.3.0.md验证清单：`gh label list` 中除官方默认标签外无英文同义标签；浏览器 New issue 里两个中文表单可见且校验生效；提交后自动带上正确标签；`.github/` 下社区文件首屏均为中文；`docs/github-ops/03-verification.md` 记录了上面每条命令与示例输出。提交：bashgit add .git commit -m "docs(gh03): localize repository community assets"git push -u origin githubops/03-chinese-localization> 先跑通一条> 再铺开一片> 铺前留证据> 后来者可验# 06、排查现象一：仓库首页的 Good first issue 入口消失了，新人找不到入门任务。怀疑：某次整理标签时，把 `good first issue` 重命名成了中文。检查：bashgh label list --repo lifuchun522/springaialibabapractice --limit 100证据：列表里没有 `good first issue`，只看到 `难度:入门` 和一个中文标签。根因：`good first issue` 与 `help wanted` 是 GitHub 为新仓库自动创建的默认标签，并被仓库首页与搜索当作官方入口使用。重命名只改了标签的名字，不会改变 GitHub 对这两个名字的识别逻辑。修复：bashgh label edit “入门好任务” --repo lifuchun522/springaialibabapractice --name "good first issue"执行前先用 `gh label list` 确认没有同名标签；`gh label edit` 的 `--name` 会同时更新所有已引用该标签的 Issue。现象二：用中文表单提交 Issue 后，没有自动带上 `类型:缺陷`，只带了 `状态:待确认`。怀疑：表单 `labels:` 字段里的名字拼错了。检查：bashgh api repos/lifuchun522/springaialibabapractice/contents/.github/ISSUE_TEMPLATE/01-bug.yml --jq .content | base64 -d | head -20证据：仓库里的实际内容是 `labels: ['类型：缺陷']`，冒号是全角；而 `gh label list` 里是半角的 `类型:缺陷`。两个字符串不相等。根因：Issue Form 的 `labels` 是机器键，必须与仓库已有标签名逐字符一致，全角半角、空格、大小写都会导致匹配失败。若标签名不存在，Issue 仍会创建，但该标签不会生效——此行为需按当前官方文档核验。修复：把 `labels.txt` 作为唯一来源，统一使用半角冒号，重跑同步脚本，并把这个修法写进 PR 模板自检项。**错误尝试：** 我一度想装一个非官方汉化浏览器扩展，把 GitHub 界面变成中文，然后按界面截图写文档。这是错的。第一，它只改我这台机器的渲染结果，其他贡献者打开仍是英文，照着我的截图找不到入口；第二，扩展会向页面注入第三方脚本，属于往账号会话里塞外部代码；第三，官方 UI 文案一旦变化或扩展失效，文档立刻失真。正确的做法是只对仓库内可版本化的资产负责，UI 层不做任何承诺。现象三：`gh issue create --template` 在非交互终端里卡住不动。怀疑：命令在等交互输入。检查：观察终端是否停在 `? Title` 之类的提示符上不返回。证据：脚本与 CI 环境里没有可交互的 TTY，命令一直等待。根因：`--template` 会进入交互式表单填写流程，天生不适合非交互环境。修复：需要脚本化建单时，改用 `--title` 加 `--body-file` 加显式 `--label`；把 `--template` 只留给人工在浏览器里验证表单渲染。> 先看真名单> 再猜哪一步> 猜错不要紧> 别丢证据链# 07、优化基于第 06 章的三条根因，做 V2。根因一，官方默认标签被改名。修改：脚本末尾增加 `grep -E '^(good first issue|help wanted)$'` 检查，缺失就打印警告。原因：把“不该动的东西”变成可执行断言，而不是写在文档里的口头约定。新行为：任何人跑一遍脚本，都会看到这两个标签的状态。验证：示例输出如下。bash保留官方默认标签：good first issuehelp wanted根因二，表单标签与仓库标签不一致。修改：标签名进入单一来源 `docs/github-ops/labels.txt`，所有 Issue Form 的 `labels` 值只从这份清单复制；`glossary.md` 增加一条硬规则——标签名一律半角冒号、不含空格；PR 模板自检项加一条对应检查。原因：全角半角、空格这类差异靠人眼校对不可靠。新行为：新增标签只改一处清单，再跑一次脚本。验证：bashgh label list --repo lifuchun522/springaialibabapractice --limit 100 --json name --jq ‘.[].name’ | grep ‘：’ || echo '未发现全角冒号标签’根因三，模板在非交互环境不可用。修改：把“验证表单”和“创建 Issue”拆成两条命令，前者用 `--web`，后者用 `--body-file`。原因：交互与非交互是两种场景，混用会出现“命令没报错但什么都没发生”。新行为：脚本与 CI 永不使用 `--template`。验证：在无 TTY 的 shell 中执行 `--body-file` 版本，能拿到 Issue 链接。V2 之后新增 `docs/github-ops/03-verification.md`，把本章全部命令、示例输出、UI 与 CLI 的词汇对照表落盘。到这为止，其他维护者可以照着重跑一遍，而不是只看结论。> 一处不一致> 往往非巧合> 追到单一源> 才叫真修好# 08、演进text[同一个请求：让中文贡献者看懂并提一个 Issue] | ±-[V1] 只翻 README | 代价：表单、标签、Release 仍英文，贡献漏斗在第一步断掉 | ±-[V2] README + .github/ 约定文件 + 中文标签 + 中文表单 + 词汇表 | 代价：多一层清单与脚本；仍需人工保证 YAML 内标签名与清单一致 |[Trade-off]得到：一条从“看得懂”到“提得对”的完整链路，且每一步可复现失去：部分“好看但没用”的汉化，以及把 UI 也翻成中文的幻想适用边界：有外部贡献者、标签数量较多的仓库收益明显；单人仓库不必正确性：V1 只保证人读得懂；V2 保证人读得懂，同时机器认得出，标签能匹配、表单校验能拦住空值。稳定性：V1 靠人工维护，加一个标签就多一处漂移；V2 靠清单加幂等脚本，重跑不会产生重复标签。复杂度：V1 是一个文件；V2 是一个清单、一个脚本、五个社区文件、两个表单、一个 PR 模板、一份词汇表。复杂度上升明显，这是真实代价，不是可以忽略的噪音。成本：脚本每次运行会调用若干次 `gh` API，属于低频操作，不构成成本压力；真正的成本在学习曲线——新维护者要先读词汇表和清单才能改文档。适用范围：跨语言、有外部贡献者的公开仓库收益最大；闭源单人或两人仓库，直接手改更快。遗留问题：一，Issue Form 无法直接读取 `labels.txt`，只能复制名字，漂移风险仍在，是否有官方引用机制需按当前官方文档核验。二，Discussions 的分类名可以中文，但分类 slug 仍是英文，URL 不会中文化。三，Release Notes 若用 `--generate-notes`，正文由 PR 标题拼成，只有 PR 标题中文，Notes 才中文。四，GitHub.com 没有官方完整简中 UI，本项目不对 UI 做任何承诺。> 旧版能跑通> 新版能自证> 中间差一步> 那步叫证据# 09、洞见## 9.1 中文化的边界由“谁定义名字”决定凡是名字由 GitHub 定义并被平台逻辑读取的（Topics、Actions 关键字、API 字段、默认标签名），一律不动；凡是名字由仓库自己定义的（社区文件名、标签名、表单 `name` 值），一律可以中文或按规范改写。判据不是“看起来像不像界面”，而是“这个名字会不会被平台当键用”。这一步想清楚，后面所有争论都能一句结案。## 9.2 反直觉判断：中文化不是给人看的，是给筛选器看的所有人都以为中文化是为了让人看得舒服。真正的收益在筛选：一个四十个标签的仓库，如果同义标签有三组，维护者每周都要在视图里手动剔除。统一命名后，视图一次配好，长期有效。反直觉判断：中文化的第一价值是减少筛选歧义，第二价值才是阅读体验。顺序反过来，就会去做那些好看但无法验收的事。## 9.3 反直觉判断：最该保留英文的，恰恰是最像入口的地方`good first issue`、`help wanted`、Topics、URL slug——这些看起来最需要“翻译给新人看”的位置，恰恰是官方入口。翻掉它们，等于把平台的推荐与筛选能力关掉，而收益只是首页上少几个英文字母。正确的做法是保留英文键，在 CONTRIBUTING 里用中文解释它是什么。## 9.4 可复现性优先于覆盖率追求百分之百中文化，会逼着你去做两件错事：汉化 UI、翻译 YAML 字段。而完成度高的中文化加一份可复现的验证文档，价值远高于“看起来全中文”的幻觉。本章最终交付的不是全中文界面，而是一套任何人照着能重跑的操作与证据。反直觉判断：中文化项目的验收标准不是看起来多中文，而是别人能不能复现你的中文。> 洞见须有据> 无据不成见> 见自前文来> 方能立得住# 10、系统落地原来有什么：`springaialibabapractice` 有英文默认 Issue 模板、混用中英的标签、中文 README 和英文 Release Notes，七类资产各说各话。本篇新增什么：`docs/github-ops/labels.txt` 单一标签清单、`scripts/gh-labels.sh` 幂等同步脚本、`docs/github-ops/glossary.md` 中英词汇表、`.github/ISSUE_TEMPLATE/01-bug.yml` 等中文 Issue Form、`.github/pull_request_template.md`、五个中文社区健康文件、`docs/github-ops/03-verification.md` 验收记录。现在能做什么：中文贡献者从仓库首页进入，看到中文 README，点 New issue 看到中文表单，选模块、填版本、勾自检，提交后自动带上 `类型:缺陷`；维护者用中文标签筛选视图，一眼看到待确认与进行中；Reviewer 用中文 PR 模板收自检清单。还缺什么：Issue Form 与标签清单之间没有强绑定，仍有漂移风险；Discussions 分类的 URL slug 仍是英文；Release Notes 的中文程度取决于 PR 标题；词汇表还没有接入自动化检查。下一步如何演进：把“标签清单到 Issue Form labels 字段”的一致性做成校验脚本，在 CI 里跑；把词汇表检查接进 Markdown lint，禁止正文出现未登记的同义词；再把 Security 政策与 Release 流程纳入同一套中文规范。这三件事都不改变架构，只增加一道自动化断言。> 有了清单后> 再谈自动化> 先守住一致> 再谈扩规模# 11、小结textQ1 → 没有。GitHub.com 与官方 Desktop 均无完整官方简中 UI，本章不对 UI 做承诺Q2 → 内容层全翻；约定层翻值不翻键；平台层（Topics、Actions 关键字、API 字段）不翻Q3 → 表单提交后标签不生效、官方入口消失、筛选视图失控、文档对不上真实界面状态 → 社区资产完成中文化，附可复现命令与验收记录，分支 githubops/03-chinese-localization```> 一问有无中> 二问翻哪层> 三问错何价> 答完再动手# 12、作业## 12.1 理解题：为什么good first issue和help wanted建议保留英文原名？参考答案：它们是 GitHub 为新仓库自动创建的默认标签，并参与仓库首页与搜索的官方呈现。改名不会改变 GitHub 对这两个名字的识别逻辑，只会让你失去官方入口。正确做法是保留英文键，在CONTRIBUTING.md里用中文解释这两个标签的含义和领取方式。## 12.2 实战题：为一个已有三十个英文标签的仓库，设计一份最小中文标签清单。参考答案：只保留四到五个前缀——类型:、优先级:、状态:、模块:，必要时加难度:；每个前缀下不超过四个值，总数控制在二十以内。超过这个数量，通常意味着有人在用标签代替里程碑或项目字段。清单写成名称|颜色|描述三列，配一个gh label create --force循环脚本，实现幂等，重跑不产生重复标签。## 12.3 排障题：Issue Form 提交后没有自动打上设定的标签，列出你的排查顺序。参考答案：一，用gh api repos/{owner}/{repo}/contents/.github/ISSUE_TEMPLATE/xxx.yml --jq .content | base64 -d看仓库里的真实内容，而不是本地文件；二，用gh label list核对标签名是否逐字符一致，重点看全角冒号、空格、大小写；三，确认标签存在于目标仓库而不是 fork；四，若标签不存在，先修清单再重跑同步脚本；五，把结论写进验收文档，并注明“标签不存在时的实际行为需按当前官方文档核验”。## 12.4 架构判断题：有人说“中文化就是装个汉化插件，把界面翻过来，然后截图写文档”。请判断这个方案。参考答案：错。理由有三：一是汉化插件只影响本机渲染，其他贡献者看不到，照截图找不到入口；二是插件会向页面注入第三方脚本，存在会话安全风险；三是官方 UI 文案变化后文档立刻失真，维护成本反而更高。正确边界是只对仓库内可版本化的资产做中文化，并对每一步留可复现证据。> 题不在难易> 在能否复现> 答不在长短> 在有无证据# 13、思考全面中文化这件事，真正难的不是翻译，是划界。李存勖能灭后梁，靠的是把各方力量收进同一面旗、同一套号令；仓库中文化靠的也是同一件事——把散在七个入口里的名字收进同一份清单，让中文贡献者从首页走到提交 Issue，中间不换语言，也不撞上机器键。边界一旦划错，代价是隐性的：表单看起来是中文的，标签却打不上；标签看起来是中文的，官方入口却消失了。这两种失败都不会报错，只会让贡献者在第一步悄悄离开，而维护者从数据里看不出任何异常。所以本章留下的判断只有一句：凡是 GitHub 定义并被平台读取的名字，一律不改；凡是仓库自己定义的名字，一律按同一份清单写。剩下的，交给可复现的命令与证据。> 旗一立号明> 界一划键清> 证一留可复> 事一毕可续