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.comSaaS、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.shbash#!/usr/bin/env bashset -euo pipefailREPO${REPO:-lifuchun522/springaialibabapractice}MANIFESTdocs/github-ops/labels.txtwhile 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.mdmarkdown## 这个 PR 做了什么## 关联 IssueCloses ### 自检清单- [ ] 我读过 CONTRIBUTING.md- [ ] 涉及命令的改动我贴出了实际输出- [ ] 新增文案符合 docs/github-ops/glossary.md 的写法- [ ] 我没有修改 Topics、Actions 关键字或 API 字段名贡献指南CONTRIBUTING.mdmarkdown# 贡献指南## 你可以怎么贡献- 报告缺陷使用「缺陷报告」表单附最小复现步骤- 提交文档修正直接开 Pull Request标题用 [文档] 前缀- 认领入门任务筛选标签 good first issue## 提交前1. 阅读 docs/github-ops/glossary.md确认用词2. 本地跑一次 scripts/gh-labels.sh确认标签同步不报错3. 在 PR 自检清单里逐项打勾## 语言约定正文用中文技术名词首次出现写成「英文原名中文说明」例如 Label标签。安全政策SECURITY.mdmarkdown# 安全政策## 支持的版本只维护最新一个 Release。## 报告漏洞请勿在公开 Issue 中披露细节改用 GitHub 的私密漏洞报告入口Security → Advisories → Report a vulnerability。## 范围本仓库仅包含示例代码与文档不处理生产数据。CODE_OF_CONDUCT.md 与 SUPPORT.md 同样改写成中文前者首段说明适用范围与举报渠道后者列出提问前先查 README、再搜 Issue、最后开 Discussion 的三步顺序。这两个文件名保持官方形式不变。启动写标签。bashchmod x scripts/gh-labels.shREPOlifuchun522/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 assetsgit 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 定义并被平台读取的名字一律不改凡是仓库自己定义的名字一律按同一份清单写。剩下的交给可复现的命令与证据。 旗一立号明 界一划键清 证一留可复 事一毕可续