最近在 Go Learning & Documentation v2 的翻译流程里，我遇到过一种很让人困惑的情况。
独立 Reviewer 审核一个完整页面以后，给出了 B。
finding 里也明确列出了几个问题。
Generation 按照这些问题逐项修改。
机器校验通过。
然后进入 successor re-QC。
结果 Reviewer 再次给出：
B。
而且新一轮指出的问题，和上一轮其实还是同一种问题。
最开始看到这种结果，很容易怀疑：
Generation 是不是没有认真按照 finding 修改？
但继续拆解以后发现，真正的问题并不一定是“没有修改”。
更常见的情况反而是：
Reviewer 只列出了几个代表实例，Generation 又把这些实例误认为完整修订边界。
于是最终形成了这样一个循环：
第一次独立审核判定为 B
→ Reviewer 列出若干实例
→ Generation 修复这些实例
→ successor re-QC
→ 同一类别仍有残留
→ 再次判定为 B这类问题后来促使我把 Reviewer finding 和 Generation exact revision 的边界重新梳理了一遍。
最后形成了一条现在看来非常重要的原则：
finding-anchored 不等于 example-anchored。
也就是说：
修订必须由正式 finding 授权，但 Reviewer 举出的几个例子，并不默认等于这一类问题的全部范围。
这篇就专门整理这个问题。
最开始的问题：Reviewer 发现了“类别”，却只写了“例子”
假设一个中文页面里，某类 inline Go API identifier 与前后中文正文之间存在重复性的间距问题。
完整页面中实际有 8 处。
Reviewer 阅读时先看到了其中 3 处，于是在 finding 中写：
某些 inline API identifier 与中文正文粘连，例如 A、B、C，请修正。
从人的阅读习惯来看，这段 finding 很自然。
因为“例如”已经表达了：
我是在举例。
但对精确修订工作流来说，它存在一个很大的问题：
到底授权修多少？
Generation 可能有两种理解。
第一种理解是：
Reviewer 列出的 A、B、C 就是全部正式授权范围，我只能改这 3 处。
第二种理解是：
Reviewer 已经识别出一种重复 defect category，A、B、C 只是 evidence，我应该在当前 TranslationUnit 内继续检查同类实例。
如果合同没有说清楚，这两种解释都看起来有一定道理。
而正式工作流最怕的就是：
依赖猜。
“例如”对人很自然，对机器工作流却很危险
自然语言审核里经常会写：
例如……
比如……
等。
这种写法对普通人工协作没有太大问题。
因为接收者通常会自行理解：
这是一个类别，请顺手把同类情况一起处理。
但 v2 的 exact revision 不是普通编辑。
它有一个很重要的限制：
Generation 不允许借一个 finding 扩大成整页自由润色。
也就是说，Generation 不能看到：
某处标点有问题。
然后顺便去修改：
- 其他语序；
- 自己觉得不够自然的句子；
- Reviewer 没有授权的术语；
- 无关标点；
- 其他 style preference。
所以工作流一直强调：
finding-anchored。
问题也正好出在这里。
如果把 finding-anchored 理解成：
只允许修改 finding 里逐字列出的几个实例。
那么重复型问题就很容易漏。
如果把它理解成：
只要感觉类似就可以全页随便改。
又会造成 scope expansion。
所以中间必须有一个更准确的概念：
defect category + bounded scope。
Reviewer 真正应该提交的，不只是几个 examples
后来正式规则变得更明确。
Reviewer 对一个完整 current TranslationUnit 做 fresh judgment 时，一旦决定给出 B、C 或 D，并且已经识别出某个 defect category，就不能看到两三个例子以后直接停止。
而应该：
在当前完整 TranslationUnit 内，对这个类别再做一次 same-class scan。
这里的 same-class 可以理解成：
同一缺陷类别的完整扫描。
它不要求数学意义上的绝对穷举。
但至少不能：
明明已经看出来这是一个重复模式，却只写两个代表例子，然后把剩余实例留给下一轮 Reviewer 再发现。
例如已经确定问题类别是：
当前 Page 中，inline Go API identifier 与紧邻中文正文之间存在不符合中文排版习惯的粘连。
那么 Reviewer 后续就应该检查：
当前完整 Page 中还有没有同样满足这个 predicate 的位置。
如果只有 4 处，就尽量把 4 处都列出来。
如果有几十处，不适合全部逐条写，也至少应该给出：
一个足够精确的 predicate，加一个明确的 bounded scope。
finding 应该描述“问题类别”，而不是只有“这里错了”
我现在越来越觉得，一个高质量 finding 最核心的不是例子数量。
而是能回答四个问题。
第一：
Finding category 是什么？
也就是到底是哪一类问题。
第二：
Observed instances 是哪些？
已经观察到哪些实际实例，以及它们在哪里。
第三：
Revision scope 到哪里为止？
Generation 允许在什么范围里做同类完整扫描。
第四：
Out of scope 是什么？
哪些东西明确不能顺便改。
例如，一个相对清楚的 finding 可以表达成：
问题类别：
当前 Page 中，inline Go API identifier 与紧邻中文正文之间存在同一种不当粘连。
已观察实例：
列出已经发现的实例，并提供稳定的段落、section 或相邻文本定位。
修订范围：
当前完整 Page 内，仅针对上述同一类别做完整扫描与修复。
范围外：
其他措辞偏好、普通润色、其他标点类别、术语调整，以及所有 protected 内容。这样 Generation 才真正知道：
我应该继续找什么。
以及：
我绝对不应该顺手改什么。
examples 是 evidence，不默认是完整 revision boundary
这是后来我觉得最关键的一条规则。
Reviewer 提供的 examples，首先是：
finding evidence。
它们证明：
这个问题真实存在。
但它们不默认意味着：
只有这些具体位置才能修改。
只有 Reviewer 明确说明：
这是 exact-instance-only finding。
Generation 才应该严格限制在列出的几个实例上。
否则，对于已经清楚定义：
- defect category；
- predicate；
- bounded scope；
的重复型问题，Generation 还需要继续做：
same-class complete sweep。
也就是：
在同一个当前 TranslationUnit、同一个问题类别、同一个授权范围内，把明确属于同一 predicate 的其他实例一起处理掉。
finding-anchored 不等于只改 finding 里的字面例子
这也是 Generation 一侧最容易误解的地方。
项目一直强调：
exact revision 必须 finding-anchored。
这个规则没有问题。
因为如果没有 finding 约束，Generation 很容易退化成：
“既然已经打开这个 Page，那我顺便把整页重新润色一下。”
这会破坏：
- Reviewer 授权边界；
- candidate identity；
- revision provenance；
- unaffected 内容的稳定性。
所以必须保持：
finding-anchored。
但是它真正的含义应该是：
所有修改都必须能回到 persisted finding 的 defect category 和授权 scope。
而不是：
只允许修改 finding prose 中逐字列出的几个 example。
这两种理解差别很大。
locally complete 也不是“把这一句话修完整”
还有一个容易误解的词：
locally complete。
以前很容易把它理解成：
找到这个位置，把这句话修完整。
后来才发现，这样还不够。
在重复型 finding 里，locally complete 真正应该表达的是：
在已授权的局部范围内，把同一类别的问题完整关闭。
这里的“local”限制的是：
scope。
不是：
instance count。
例如 Reviewer 的 finding scope 是：
当前 Page 全文中的 inline identifier spacing。
那么 local 就是：
当前 Page。
Generation 不能扩到其他 Page。
但在这个 Page 内，属于同一个 predicate 的 8 个实例，就不应该只修其中 3 个。
为什么“只修 examples”看起来很安全，实际却会制造 re-QC 循环
从 Generation 的角度看，只修 Reviewer 明列实例其实非常保守。
因为它最大程度避免了：
scope expansion。
但副作用是：
把 Reviewer 的 examples 错误地当成 exhaustive list。
于是第一次 revision 以后：
Reviewer 明列实例：3
Generation 修复实例：3
页面真实同类实例：8
剩余残留：5机器 validation 仍然可能完全 PASS。
因为：
机器 validator 通常只能验证结构、protected content、identity、schema 和正式机械语义。
它不会替 Reviewer 判断：
另外 5 处中文排版是否仍然存在同样问题。
所以最终只能等 successor re-QC 再发现。
机器 validation PASS 并不能关闭语言 finding
这也是这个循环里一个很重要的误区。
revision 完成以后，如果看到：
validation：PASS很容易产生一种心理：
修订应该已经完成了。
实际上 validation 只能证明：
这个 replacement 在机器合同上合法。
例如：
- protected token 没有丢；
- source identity 没变；
- 结构合法；
- 输出格式正确；
- 没有修改禁止修改的技术内容。
它不能证明：
Reviewer 指出的语言类别已经完全关闭。
所以：
machine validation PASS ≠ finding closure PASS。
这也是为什么必须继续有独立 successor re-QC。
Generation 在提交前也应该做 finding closure check
为了减少这种明显的往返，Generation 一侧后来也需要承担一个任务完成性检查。
注意，这不是自审。
Generation 不能给自己 A。
也不能说：
我觉得翻译质量已经通过。
它应该做的是更机械的：
finding closure check。
也就是在提交 replacement 前确认：
- 明列实例是否都已处理；
- persisted finding category 是否已经理解；
- bounded scope 内是否仍有明显 same-class residual；
- 是否意外修改了 finding 之外的其他内容；
- protected 内容是否保持不变；
- 如果 category 或 scope 不清楚，是否应该停止并报告 ambiguity。
这是一种：
任务完成性检查。
不是：
正式语言质量审核。
最终 rating 仍然只能由独立 Reviewer 给出。
same-class sweep 也不能变成“顺便润色全文”
规则收紧以后，另一个风险马上出现了。
Generation 可能会想：
既然要求同类扫描，那我看到类似问题都一起修。
这个方向本身没错。
但“类似”不能无限扩大。
比如 persisted finding 是：
当前 section 中中文标点前存在同一种异常空格。
那么 same-class sweep 可以检查：
当前授权 section 里，是否还有同样的异常空格。
但不能顺手扩展到：
- 另一种标点问题；
- 术语风格；
- 标题语气；
- 句子重写；
- 其他 section 的无关表达。
所以 same-class completeness 需要同时满足三个约束：
同一个 category。
同一个 bounded scope。
同一个正式 Unit / slot authorization。
只要超出其中一个，就不再属于这次 finding-anchored revision。
不能靠“看起来差不多”判断 same-class
这个边界也非常重要。
假设 finding 是：
inline API identifier 与中文正文粘连。
Generation 又看到另一个地方有：
英文品牌名与中文正文之间没有空格。
这两个从视觉上可能很像。
但它们是否属于同一 defect category，不一定。
可能前者涉及：
- code / identifier formatting；
后者涉及：
- 品牌名的中文排版规范。
如果无法可靠判断：
这是不是同一个 predicate。
那么 Generation 不应该猜。
正确处理方式应该是：
保持该处不变，并报告 ambiguity / blocker。
因为 same-class completeness 的目标是：
把已经授权的一类问题修完整。
而不是借这个机会扩充新的语言判断。
Reviewer 的 completeness 也不能变成无限找问题
Reviewer 一侧同样需要边界。
same-class scan 并不是：
判了一个 B 以后，再重新寻找整页所有可能的语言问题。
如果 Reviewer 在 fresh judgment 中另外发现一个独立问题，当然可以记录。
但应该把它作为：
新的 defect category。
而不是混进原来的 finding。
例如页面同时存在：
- inline identifier spacing；
- 某个术语译法错误；
- 某张表格中的语义遗漏。
这应该是三个独立类别。
每个类别分别定义：
- observed instances；
- predicate；
- bounded scope；
- revision boundary。
不能最终写成：
页面还有一些语言问题，请整体优化。
因为这种 finding 几乎等于授权：
整页重译。
这正是 exact revision 想避免的事情。
successor re-QC 也不能只检查旧 examples
这一轮规则真正闭环的地方，在 successor re-QC。
以前 re-QC 很容易退化成：
Reviewer 上次列了 A、B、C。
现在看看 A、B、C 修没修。
如果全修了：
PASS。
问题是，这样仍然会漏掉同类残留。
所以 successor re-QC 必须重新对：
完整 current TranslationUnit
做 fresh judgment。
尤其对于 persisted finding，还要检查：
这个 finding category 在原授权 scope 内有没有完整关闭。
也就是说，它不仅要问：
上次列出的 3 个 examples 修了吗？
还要问：
当前 scope 里还有没有第 4、第 5 个同类 residual？
如果还有残留，就应该明确写成 same-class residual
假设上一轮 finding 是：
当前 Page 中存在 inline identifier spacing 问题。
Generation 修掉大部分。
re-QC 后仍发现 1 处。
这时候最准确的表达不是：
新发现一个 spacing 问题。
因为它并不是一个全新的类别。
它是：
persisted category 的 same-class residual。
这样历史链条才清楚：
原 finding category
→ revision
→ successor re-QC
→ same-class residual而不是看起来像：
旧问题已经完全关闭
→ Reviewer 又突然发现一个全新问题这对后续 revision scope 也更准确。
为什么旧 finding 不应该回写
规则变得更完整以后，很容易产生另一个冲动：
既然现在知道第一次 finding 写得不够完整，要不要把历史 finding 改掉？
答案应该是：
不要。
因为历史 evidence 应该记录：
当时 Reviewer 实际提交了什么。
后来的 successor re-QC 如果发现残留，就创建新的证据。
而不是回头把旧 evidence 改成：
“其实我当时已经发现了全部问题。”
否则历史就不再可信。
所以正确方式是：
旧 finding：保持不变
新的 re-QC：记录 same-class residual
新的 revision：继续处理 residual历史可以不完美。
但不能被重新书写。
为什么这条规则不要求数学意义上的穷举
看到 same-class completeness，可能会担心：
Reviewer 是不是必须证明整页绝对一个都没漏？
其实不是。
语言判断很难做到数学意义上的 exhaustive proof。
正式要求更接近：
reasonable complete scan。
也就是说：
一旦 Reviewer 已经识别出重复型 pattern，就应该有意识地扫描整个授权范围，而不是随手看到两个就停止。
如果实例非常多，可以用：
exact predicate + bounded scope。
而不是必须写几十行列表。
真正禁止的是：
明知道是重复型 defect，却故意只给几个 example，然后把剩下的问题留给下一轮。
一个好的 predicate 可以比几十个 examples 更有价值
假设一个页面有 30 处相同问题。
逐条列 30 个实例当然可以。
但更稳定的 finding 可能是：
当前 Page 全文中，所有按中文排版规范应与相邻正文分隔、但实际发生不当粘连的 inline Go API identifier。
这里已经明确了：
- category；
- predicate；
- scope。
然后再列几个具体实例作为 evidence 和定位参考。
Generation 就可以在当前 Page 内做完整 sweep。
而 Reviewer 在 successor re-QC 时也知道：
应该验证哪个 predicate 已经关闭。
这比：
例如 A、B、C 等。
稳定得多。
bounded scope 为什么一定要明确
如果只有 predicate，没有 scope，也会出问题。
例如：
修复所有 API identifier spacing。
这里的“所有”到底是：
- 当前 paragraph；
- 当前 section；
- 当前 Page；
- 整个 package；
- 整个 locale？
都不清楚。
所以 scope 必须被限定。
例如：
当前 Page 全文。
或者：
当前 Page 的 Security Considerations section。
或者：
当前表格的 description 列。
或者：
当前授权的 teaching-comment 区域。
这样 Generation 才不会跨 TranslationUnit 扩散。
exact-instance-only 什么时候才应该使用
并不是所有 finding 都适合 same-class sweep。
有时候 Reviewer 判断的问题就是：
某一句具体翻译存在一次性语义错误。
例如某句话漏掉了一个否定关系。
而页面其他位置并不存在同类 pattern。
这时候完全可以明确：
exact-instance-only。
也就是：
只授权修改这一个具体实例。
这样 Generation 就不需要为了“完整”再去全页寻找一个并不存在的类别。
所以关键不是：
每个 B 都必须扩大范围。
而是：
重复型问题应该完整扫描；一次性问题应该明确限制。
Reviewer examples 和 Generation examples 的角色不一样
这里还有一个很值得区分的地方。
Reviewer examples 是：
evidence。
Generation 输出中的实际修改，则是：
finding closure。
二者不是一一对应关系。
例如 Reviewer 提供 3 个 examples，但 category + scope 明确覆盖当前完整 Page。
Generation 最终可能修改 7 处。
这不代表：
Generation 擅自扩大范围。
只要新增修改的另外 4 处都满足：
- 同一个 defect category；
- 同一个 predicate；
- 同一个 bounded scope；
- 没有跨 formal authorization；
那么它仍然是：
finding-anchored revision。
这就是后来我觉得特别重要的一点：
finding-anchored 描述的是“修改的因果来源”，不是“修改实例数量必须和 finding examples 数量一样”。
这能明显减少无意义的 Reviewer 往返
如果没有 same-class completeness，一个重复型问题可能变成：
QC：发现 3 处
→ revision：修 3 处
→ re-QC：发现另外 2 处
→ revision：再修 2 处
→ re-QC：又发现 1 处每一轮都是真实工作。
但大量成本其实不是语言问题本身，而是：
第一次 finding 边界表达得不够完整。
这会额外消耗：
- Generation invocation；
- Reviewer invocation；
- Bundle export；
- validation；
- Snapshot；
- evidence；
- re-QC；
- 人工协调时间。
所以 completeness 并不仅仅是质量问题。
它也是非常直接的：
成本优化。
但这和“让 Reviewer 一次找完所有问题”仍然不同
这里需要特别避免走向另一个极端。
same-class completeness 不是要求 Reviewer：
第一次 QC 必须找出整个 TranslationUnit 未来所有可能的问题。
Reviewer 仍然是一次 fresh judgment。
它应该尽力发现当前看到的问题。
区别只在于：
一旦已经识别出某个重复型 defect category，就不要故意只审几个代表实例。
换句话说：
要求的是类别内部完整，不是要求 Reviewer 拥有预知能力。
如果 successor re-QC 后确实出现一个此前完全没有识别过的新类别，那么它仍然可以作为新的 finding。
这套规则仍然保持 Reviewer 和 Generation 独立
增加 completeness 以后，也不能让两个角色合并。
Reviewer 的职责仍然是：
判断质量，定义 finding category、evidence 和 revision scope。
Generation 的职责仍然是：
在正式 finding 授权内生成 replacement。
Generation 可以做 same-class complete sweep。
但它不能：
因为自己觉得已经修好了，就给自己 A。
Reviewer 可以指出完整 category。
但它不能：
顺手直接生成 replacement 再批准自己的修改。
角色隔离仍然保持。
machine scope 和语言 scope 也不能混在一起
same-class completeness 只解决：
语言 finding 的完整关闭。
它不改变：
- TranslationUnit membership；
- package membership；
- parser slot authorization；
- protected token；
- candidate identity；
- Snapshot；
- machine validation；
- A-only finalization。
例如当前正式 scope 只有一个 Page TranslationUnit。
即使 Reviewer 发现另一个 Page 似乎也有相似问题，也不能顺手把另一个 Page 纳入本轮 revision。
那已经属于：
新的正式 affected scope。
需要走它自己的 authority。
这件事其实暴露了一个很普遍的问题
回头看，这并不只是翻译流程的问题。
很多工程协作都会遇到：
报 bug 的人给了两个 example。
修 bug 的人只修了这两个 example。
测试人员下一轮又找到第三个。
真正缺少的是：
问题类别是否已经定义清楚。
例如一个 parser bug，如果只修：
fixture A 和 fixture B。
而没有定义：
什么样的输入属于同一个 failure predicate。
那未来很可能还会出现 fixture C。
所以 same-class completeness 其实是一种更一般的工程习惯：
不要只修样本，要理解样本背后的 defect class。
但是 defect class 也必须有边界
这句话同样不能被滥用。
“理解类别”不代表：
发现一个问题后顺便重构整套系统。
在翻译 revision 里 especially 如此。
正确的问题应该是：
这个 instance 为什么属于当前 finding？
而不是：
既然这里有问题，那我还有什么地方看着不顺眼？
前者是：
category closure。
后者是：
scope expansion。
这两者必须严格区分。
我现在更认可的 Reviewer finding 结构
如果以后再遇到 B/C/D，我会更倾向于让 finding 至少具备下面四部分。
第一部分说明：
Finding category：具体缺陷类别。
第二部分说明：
Observed instances：尽量完整的已观察实例，或者 exact predicate。
第三部分说明：
Revision scope：当前 TranslationUnit 内允许执行 same-class complete sweep 的明确范围。
第四部分说明：
Out of scope：其他类别、普通润色和 protected 内容明确不允许修改。
这并不需要新增新的 JSON schema。
也不需要增加 CLI 字段。
它完全可以继续存在于 Reviewer 的自然语言 evidence 中。
但表达精度会高很多。
Generation 也有一套对应的问题清单
收到 revision Bundle 以后，Generation 应该先问：
Reviewer 定义的 defect category 是什么？
然后问：
bounded scope 到哪里？
再问：
examples 是 evidence，还是明确的 exact-instance-only boundary？
如果不是 exact-instance-only，就继续问：
当前授权 scope 里还有没有明确满足同一 predicate 的其他实例？
最后还要问：
我是否碰到了其他 category、普通润色或者 protected content？
如果碰到了：
不改。
如果同类归属本身无法可靠判断：
不猜。
这时候报告 ambiguity，反而比擅自修改更正确。
successor re-QC 最后负责真正关闭这条链
Generation 完成 replacement 后，最终仍然必须回到独立 Reviewer。
Reviewer 不能只看：
原来列出的 examples 都改了。
而应该检查：
当前完整 TranslationUnit 里，这个 persisted finding category 在原 revision scope 内是否已经真正关闭。
如果全部关闭：
才能根据完整 fresh judgment 给 A。
如果仍有 residual：
继续给 B/C/D，并明确这是 same-class residual。
如果发现完全新的独立问题：
新建另一个 category。
这样整个链条就会变成：
Reviewer 定义 defect category 和 bounded scope
→ Generation 在 scope 内完成 same-class sweep
→ machine validation 验证 replacement 合法
→ successor re-QC 验证 category 是否完整关闭
→ 全部通过后才进入 A-only finalization这比：
Reviewer 举几个例子
→ Generation 改几个例子
→ Reviewer 再找几个稳定得多。
这次规则变化真正想解决的不是“Reviewer 要更认真”
如果把这件事简单总结成：
Reviewer 第一次应该看仔细一点。
其实并不准确。
因为真正的问题是：
工作流以前没有把 category、example 和 revision boundary 之间的关系定义得足够清楚。
Reviewer 可能以为：
“例如”已经足够表达同类问题。
Generation 又可能因为 fail-closed 倾向而认为：
只有明列实例才是正式授权。
双方其实都在做各自看来合理的事情。
最后却形成无意义循环。
所以改进的重点不是：
要求某个角色更聪明。
而是：
把交接合同写得更精确。
一个好的工作流应该减少“靠默契理解”
这也是整个项目越来越明确的一条原则。
越是正式、可恢复、跨 session 的流程，就越不能依赖：
“你应该知道我的意思。”
因为 Reviewer 和 Generation 本来就是两个独立 session。
甚至可能跨不同时间执行。
它们真正共享的应该是：
- Bundle；
- persisted finding；
- exact source；
- candidate；
- formal authority。
而不是：
隐含默契。
所以 defect category 和 bounded scope 越明确，后续越稳定。
这次最值得保留的几条原则
经过这几轮 B → revision → re-QC 的反复，我觉得可以把现在的规则浓缩成几条。
第一：
Reviewer 一旦识别出重复型 defect category，就应该在完整 current TranslationUnit 内进行 reasonable same-class scan。
第二：
Reviewer examples 是 evidence，不默认构成 exhaustive revision boundary。
第三：
实例过多时，可以使用 exact predicate + bounded scope，而不是用“例如”“等”留下开放边界。
第四：
只有 Reviewer 明确标记为 exact-instance-only，Generation 才只修改列出的具体实例。
第五：
finding-anchored 不等于 example-anchored。
第六：
locally complete 表示在授权局部范围内完整关闭同一类别，不表示只修一个局部句子。
第七：
Generation 应在 persisted category + bounded scope 内做 same-class complete sweep，但不能扩展到其他 category 或普通润色。
第八：
同类归属无法可靠判断时不猜，应该保持原文并报告 ambiguity。
第九：
successor re-QC 不仅检查旧 examples，还要验证 persisted category 在授权 scope 内是否完整关闭。
第十：
如果仍有同类残留，应明确记录为 same-class residual，而不是伪装成一个完全新的问题。
最终我现在最想保留的一句话是：
修订真正应该关闭的是“问题类别”，而不只是 Reviewer 当时碰巧写出来的几个例子。
这并不意味着扩大 revision scope。
恰恰相反。
它要求我们把：
类别、范围和边界
定义得更加精确。
只有这样，才能同时做到两件事：
不漏掉明确属于同一问题的残留。
以及：
不借一个 finding 的名义去重写本来没有问题的内容。
这才是我现在理解的：
finding-anchored，locally complete。
Go 学习与文档多语言本地化项目
本系列完整记录 Go 学习与文档多语言本地化项目从 A Tour of Go 起步，逐步扩展到站点首页、项目说明页、学习内容、文档以及未来内容包的实际开发过程，包括架构设计、统一术语治理、整页翻译、结构保护、自动校验、独立质量审核、生产发布与长期维护。
项目源码：
✅ GitHub：shuijingwan/go-tour-i18n
语言版本：
当前跨项目目标语言池共包含 66 个语言版本。Go 项目本身目前提供 65 个社区 Production 语言版本，下面每一门 Go 语言版本都直接链接到其当前公开站点。语言列表沿用项目首页现有的展示顺序。
英语（美国）仅作为跨项目目标语言纳入列表，并不是单独的 Go Production 语言版本。当前 Go 的英文源内容仍为官方 generic English，因此英语（美国）链接到 Go 官方站点，而不是不存在的本地社区部署。
- 阿姆哈拉语
- 阿拉伯语
- 孟加拉语
- 葡萄牙语（巴西）
- 保加利亚语
- 加泰罗尼亚语
- 克罗地亚语
- 捷克语
- 丹麦语
- 荷兰语
- 英语（美国）（Go 官方英文站点）
- 英语（澳大利亚）
- 英语（加拿大）
- 英语（印度）
- 英语（新加坡）
- 英语（南非）
- 英语（英国）
- 爱沙尼亚语
- 菲律宾语
- 芬兰语
- 法语（法国）
- 法语（加拿大）
- 德语（德国）
- 德语（奥地利）
- 德语（瑞士）
- 希腊语
- 古吉拉特语
- 希伯来语
- 印地语
- 匈牙利语
- 印度尼西亚语
- 意大利语
- 日语
- 卡纳达语
- 哈萨克语
- 韩语
- 西班牙语（拉丁美洲）
- 拉脱维亚语
- 立陶宛语
- 马来语
- 马拉雅拉姆语
- 马拉地语
- 书面挪威语（Bokmål）
- 波斯语
- 波兰语
- 葡萄牙语（葡萄牙）
- 旁遮普语（果鲁穆奇文，印度）
- 罗马尼亚语
- 俄语
- 塞尔维亚语（西里尔文）
- 简体中文（中国大陆）
- 简体中文（新加坡）
- 斯洛伐克语
- 斯洛文尼亚语
- 西班牙语（西班牙）
- 斯瓦希里语（坦桑尼亚）
- 瑞典语
- 泰米尔语
- 泰卢固语
- 泰语
- 繁体中文（台湾）
- 繁体中文（香港）
- 土耳其语
- 乌克兰语
- 乌尔都语
- 越南语
项目正在持续扩展新的 Go 学习与文档内容，并长期维护各语言版本的术语一致性、翻译质量、独立审核、生产发布与后续更新。
本项目属于非官方社区多语言本地化项目，与 Go 官方无隶属、授权或背书关系。