Languages

[calcitem]

本地名称	英语名称	中文名称	使用国家/地区（示例）	使用人数（估计）	官方语言（示例）
Afrikaans	Afrikaans	南非荷兰语	南非，纳米比亚	720万	南非，纳米比亚
አማርኛ	Amharic	阿姆哈拉语	埃塞俄比亚	2200万	埃塞俄比亚
العربية	Arabic	阿拉伯语	埃及，沙特阿拉伯，阿拉伯联合酋长国	3.13亿	26个国家
অসমীয়া	Assamese	阿萨姆语	印度（阿萨姆邦）	1530万	印度（阿萨姆邦）
Azərbaycanca	Azerbaijani	阿塞拜疆语	阿塞拜疆，伊朗	2300万	阿塞拜疆
Беларуская	Belarusian	白俄罗斯语	白俄罗斯	670万	白俄罗斯
български	Bulgarian	保加利亚语	保加利亚	800万	保加利亚
বাংলা	Bengali	孟加拉语	孟加拉国，印度	2.65亿	孟加拉国，印度
Bosanski	Bosnian	波斯尼亚语	波斯尼亚和黑塞哥维那	240万	波斯尼亚和黑塞哥维那
Català	Catalan	加泰罗尼亚语	西班牙，安道尔	1100万	安道尔，西班牙
Čeština	Czech	捷克语	捷克共和国	1100万	捷克共和国
Cymraeg	Welsh	威尔士语	英国（威尔士）	54万	英国（威尔士）
Dansk	Danish	丹麦语	丹麦	600万	丹麦
Deutsch	German	德语	德国，奥地利，瑞士	9500万	德国，奥地利，瑞士
Ελληνικά	Modern Greek	现代希腊语	希腊，塞浦路斯	1300万	希腊，塞浦路斯
English	English	英语	美国，英国，加拿大，澳大利亚	15亿	超过60个国家
Español	Spanish	西班牙语	西班牙，墨西哥，阿根廷	5.77亿	21个国家
Eesti	Estonian	爱沙尼亚语	爱沙尼亚	110万	爱沙尼亚
Euskara	Basque	巴斯克语	西班牙（巴斯克地区），法国（巴斯克地区）	75万	西班牙（巴斯克地区）
فارسی	Persian	波斯语	伊朗，阿富汗，塔吉克斯坦	1.1亿	伊朗，阿富汗，塔吉克斯坦
Suomi	Finnish	芬兰语	芬兰	540万	芬兰
Filipino	Filipino	菲律宾语	菲律宾	9000万	菲律宾
Français	French	法语	法国，加拿大，比利时，瑞士	2.74亿	29个国家
Galego	Galician	加利西亚语	西班牙（加利西亚）	240万	西班牙（加利西亚）
Schwyzerdütsch	Swiss German	瑞士德语	瑞士	490万	瑞士
ગુજરાતી	Gujarati	古吉拉特语	印度（古吉拉特邦）	5550万	印度（古吉拉特邦）
עברית	Hebrew	希伯来语	以色列	900万	以色列
हिन्दी	Hindi	印地语	印度	6.15亿	印度
Hrvatski	Croatian	克罗地亚语	克罗地亚	420万	克罗地亚
Magyar	Hungarian	匈牙利语	匈牙利	1300万	匈牙利
Հայերեն	Armenian	亚美尼亚语	亚美尼亚	670万	亚美尼亚
Bahasa Indonesia	Indonesian	印度尼西亚语	印度尼西亚	1.99亿	印度尼西亚
Íslenska	Icelandic	冰岛语	冰岛	36万	冰岛
Italiano	Italian	意大利语	意大利，瑞士，梵蒂冈	6800万	意大利，瑞士，梵蒂冈
日本語	Japanese	日语	日本	1.25亿	日本
ქართული	Georgian	格鲁吉亚语	格鲁吉亚	370万	格鲁吉亚
Қазақша	Kazakh	哈萨克语	哈萨克斯坦	1300万	哈萨克斯坦
ភាសាខ្មែរ	Khmer	高棉语	柬埔寨	1600万	柬埔寨
ಕನ್ನಡ	Kannada	卡纳达语	印度（卡纳塔克邦）	4370万	印度（卡纳塔克邦）
한국어	Korean	韩语	韩国，朝鲜	8000万	韩国，朝鲜
Кыргызча	Kyrgyz	吉尔吉斯语	吉尔吉斯斯坦	480万	吉尔吉斯斯坦
ພາສາລາວ	Lao	老挝语	老挝	700万	老挝
Lietuvių	Lithuanian	立陶宛语	立陶宛	280万	立陶宛
Latviešu	Latvian	拉脱维亚语	拉脱维亚	130万	拉脱维亚
Македонски	Macedonian	马其顿语	北马其顿	210万	北马其顿
മലയാളം	Malayalam	马拉雅拉姆语	印度（喀拉拉邦）	3800万	印度（喀拉拉邦）
Монгол	Mongolian	蒙古语	蒙古	520万	蒙古
मराठी	Marathi	马拉地语	印度（马哈拉施特拉邦）	8300万	印度（马哈拉施特拉邦）
Bahasa Melayu	Malay	马来语	马来西亚，文莱，新加坡	2.9亿	马来西亚，文莱，新加坡
မြန်မာဘာသာ	Burmese	缅甸语	缅甸	3300万	缅甸
Norsk bokmål	Norwegian Bokmål	书面挪威语	挪威	500万	挪威
नेपाली	Nepali	尼泊尔语	尼泊尔，印度	4480万	尼泊尔，印度
Nederlands	Dutch	荷兰语	荷兰，比利时，苏里南	2470万	荷兰，比利时，苏里南
Norsk	Norwegian	挪威语	挪威	530万	挪威
ଓଡ଼ିଆ	Odia	奥利亚语	印度（奥里萨邦）	3750万	印度（奥里萨邦）
ਪੰਜਾਬੀ	Punjabi	旁遮普语	印度，巴基斯坦	1.25亿	印度（旁遮普邦），巴基斯坦（旁遮普省）
Polski	Polish	波兰语	波兰	4000万	波兰
پښتو	Pashto	普什图语	阿富汗，巴基斯坦	6000万	阿富汗，巴基斯坦
Português	Portuguese	葡萄牙语	葡萄牙，巴西，安哥拉	2.58亿	9个国家
Română	Romanian	罗马尼亚语	罗马尼亚，摩尔多瓦	2400万	罗马尼亚，摩尔多瓦
Русский	Russian	俄语	俄罗斯，白俄罗斯，哈萨克斯坦	2.58亿	4个国家
සිංහල	Sinhala	僧伽罗语	斯里兰卡	1600万	斯里兰卡
Slovenčina	Slovak	斯洛伐克语	斯洛伐克	520万	斯洛伐克
Slovenščina	Slovenian	斯洛文尼亚语	斯洛文尼亚	250万	斯洛文尼亚
Shqip	Albanian	阿尔巴尼亚语	阿尔巴尼亚，科索沃	780万	阿尔巴尼亚，科索沃
Српски	Serbian	塞尔维亚语	塞尔维亚，波斯尼亚和黑塞哥维那	880万	塞尔维亚，波斯尼亚和黑塞哥维那
Svenska	Swedish	瑞典语	瑞典，芬兰	1000万	瑞典，芬兰
Kiswahili	Swahili	斯瓦希里语	坦桑尼亚，肯尼亚，乌干达	1.5亿	多个东非国家
தமிழ்	Tamil	泰米尔语	印度，斯里兰卡，新加坡	8090万	印度，斯里兰卡，新加坡
తెలుగు	Telugu	泰卢固语	印度（安得拉邦，特伦甘纳邦）	8110万	印度（安得拉邦，特伦甘纳邦）
ภาษาไทย	Thai	泰语	泰国	6060万	泰国
Tagalog	Tagalog	他加禄语	菲律宾	2800万	菲律宾
Türkçe	Turkish	土耳其语	土耳其，塞浦路斯	8800万	土耳其，塞浦路斯
Українська	Ukrainian	乌克兰语	乌克兰	3260万	乌克兰
اردو	Urdu	乌尔都语	巴基斯坦，印度	1.7亿	巴基斯坦，印度
Oʻzbekcha	Uzbek	乌兹别克语	乌兹别克斯坦	2730万	乌兹别克斯坦
Tiếng Việt	Vietnamese	越南语	越南	9690万	越南
中文	Chinese	中文	中国大陆，台湾，新加坡	14.5亿	中国大陆，台湾，新加坡
isiZulu	Zulu	祖鲁语	南非	1200万	南非

[calcitem]

下面给出一套受 Gene Ontology（GO）启发的 Git commit message 编写规范。目标不是简单仿照“feat/fix”，而是把 GO 的本体（ontology）思想——标准化术语、三大“范畴”、层级与可计算性、证据与跨项目可比性——系统移植到工程协作与变更记录中，使提交记录能被机器推理、统计富集、跨仓对齐，同时保持对一线开发者易写、易读。

---

0. 设计目标（为什么要这样做）

• 标准化：像 GO 统一基因功能那样，统一“改了什么、在哪改、为了什么”的术语，减少歧义（变更语义可复用与可检索）。
• 层级化：支持从粗到细的导航（迭代回顾看宏观趋势；代码走查看微观细节）。
• 跨仓对齐：不同服务/端（Web、iOS、后端）用同一术语集，可直接比较。
• 可计算：每个提交都带结构化注释（terms + qualifiers + evidence），能做富集分析、影响面统计、自动生成版本公告。
• 因果透明：引入“证据代码”记录为什么要改（ failing test / 事故 / 指标退化 / 需求 / 静态扫描 ）。

---

1. Commit Ontology（CO）元模型

借鉴 GO 的三大分支（BP/MF/CC），定义代码世界的三元注释：

• BP（Business/Process）业务/用户流程
  对应“为什么（目标/用例/用户旅程）”。
  例：bp:checkout.payment、bp:user.onboarding、bp:data.retention

• MF（Micro-Function）代码微功能（类比 GO 的 Molecular Function）
  对应“做了什么能力/原子行为”。
  例：mf:input.validation、mf:authz.policy、mf:caching.strategy、mf:txn.isolation、mf:error.recovery

• CC（Code Component）代码组分/落点（类比 GO 的 Cellular Component）
  对应“改在哪里（模块/层/运行环境）”。
  例：cc:svc.orders.db、cc:api.v2、cc:ios.profile、cc:k8s.job.reconcile

术语以层级路径表示（. 或 / 分隔），每个术语在团队字典中有稳定 ID：CO:BP:0007、CO:MF:0112、CO:CC:2031。提交中可写可读路径，CI 将其解析映射到 ID。

1.1 限定词（Qualifiers）

表达与术语的关系（类比 GO 的 regulates/negatively_regulates/part_of）：

• introduces（引入/新增能力）
• removes（移除/废弃）
• refactors（重构，不改变外部语义）
• fixes（修复错误）
• optimizes（性能/成本优化）
• hardens（鲁棒/安全加固）
• regresses（引入回退；仅在回滚提交使用）
• guards（增加保护/熔断/限流）
• documents（文档）
• tests（测试）

1.2 证据代码（Evidence Codes，类比 GO/ECO）

说明“为什么现在要改”，支持机器审计与质量度量：

• FT（Failing Test）有失败用例驱动
• IR（Incident Report）事故/故障单
• BM（Benchmark）基准或性能回归
• SC（Spec Change）需求/规范变更
• CR（Code Review）评审建议
• SA（Static Analysis）静态扫描
• UF（User Feedback）用户反馈/工单
• EXP（Exploratory Experiment）试验性改动
• IA（Impact Assessment）事前影响评估结论

每条证据可带 source（链接/编号）、with（相关测试/脚本）、confidence（0~1）。

1.3 影响与环境（Impact / Taxon）

• Impact：受影响域与指标（area,metric,before,after,unit,confidence）
• Env/Platform（Taxon）：运行域，如 env:prod|staging，platform:android|ios|web|server，region:eu|us（类比 GO 的物种/组织背景）。

---

2. 消息格式（语法 + 约束）

2.1 头行（≤ 72 字符）

<qualifier>(BP:..., MF:..., CC:...) [impact] - <concise title>  #<issue>

• 必须至少出现 BP、MF、CC 各 1 个（可多选，逗号分隔）。
• 允许只写路径别名，由钩子映射为 ID。
• impact 为可选短标签（如 p95↓、security↑、cost↓）。

示例

fix(BP:checkout.payment, MF:txn.isolation, CC:svc.orders.db) p0 - prevent double charge  #4231

2.2 正文（What / Why / How 分段）

• What：做了什么（面向读者）
• Why：动机与风险/替代方案（结合证据代码）
• How：关键技术要点/迁移说明

2.3 结构化注释块（机器可读，YAML）

置于正文末尾，以 CO: 开头。CI 解析校验、入库用于富集/看板/发布说明。

CO:
  bp:
    - id: CO:BP:0007
      term: bp:checkout.payment
  mf:
    - id: CO:MF:0112
      term: mf:txn.isolation
  cc:
    - id: CO:CC:2031
      term: cc:svc.orders.db
  qualifiers: [fixes, hardens]
  evidence:
    - code: IR
      source: INC-421
      confidence: 0.9
    - code: FT
      with: test_double_charge_spec
  impact:
    - area: payments
      metric: double_charge_rate
      before: 0.32
      after: 0.00
      unit: "%"
      confidence: 0.9
  env:
    platform: server
    region: us
    stage: prod
  links:
    issues: [4231]
    prs: [8821]
    docs: ["runbook/charge-retry.md"]

规范允许最小合规版本：若时间紧，头行合规 + 证据一个即可；CI 可按仓库成熟度分层门禁。

---

3. 受控词汇（初始树）

组织可在 co-terms.yml 维护层级；以下给出种子集，作为落地起点。

3.1 BP（业务/流程）

• bp:user.onboarding
• bp:authn.login / bp:authz.policy
• bp:checkout.payment / bp:checkout.refund
• bp:search.results / bp:discovery.recommendation
• bp:data.lifecycle.ingest|process|retention
• bp:observability.alerting|tracing|metrics

3.2 MF（微功能）

• mf:input.validation
• mf:api.contract / mf:serialization
• mf:caching.strategy / mf:caching.invalidation
• mf:concurrency.control / mf:locking
• mf:error.recovery / mf:retry.policy
• mf:txn.isolation / mf:idempotency
• mf:crypto.hash|encrypt|sign
• mf:io.batch|stream
• mf:query.optimization
• mf:rate.limit|circuit.breaker

3.3 CC（代码组分）

• cc:svc.orders / cc:svc.search / cc:svc.auth
• cc:api.v1|v2 / cc:ui.web / cc:ios / cc:android
• cc:db.postgres / cc:cache.redis
• cc:k8s.operator / cc:worker.job
• cc:infra.terraform / cc:ci.cd

---

4. 写作与门禁（Lint）规则

1. 头行必须匹配：
   ^(introduces|removes|refactors|fixes|optimizes|hardens|regresses|guards|documents|tests)\((?=.*BP:)(?=.*MF:)(?=.*CC:).+\)\s.*- .*
2. 术语合法性：BP/MF/CC 仅可取 co-terms.yml 中的受控词（支持别名→规范名映射）。
3. 证据必填：fixes|hardens|optimizes|removes 需至少 1 个 evidence。
4. 破坏性改动：如 api 断裂，需增加 qualifiers: [removes] 且正文写迁移指引。
5. 度量建议：optimizes 提交需带至少 1 个 impact.metric（如 p95、CPU、成本）。

门禁等级：L1（仅头行术语合法）、L2（+证据）、L3（+影响度量）。按仓库成熟度逐步提升。

---

5. “GO 风格”的分析与产出

借 GO 的“富集分析/知识图谱”工作流，把提交变成可推理数据：

• 富集分析（Release Enrichment）
  基于版本区间的提交集合，对 BP/MF 做超几何富集，自动输出“本次版本显著聚焦：bp:checkout.payment、mf:txn.isolation”。用于发布说明与路线图回顾。
• 根因/风险知识图谱
  将 evidence.code=IR/SA 与 mf:*、cc:* 关联，沉淀“哪些微功能在事故中高发”“哪些组件常被 SA 指出问题”。
• 跨仓对比
  不同服务沿共同的 BP/MF 统计——像比较基因组学一样，看“安全加固在各端的覆盖度差异”。
• 变更→效果闭环
  通过 impact 度量可量化“提交-指标”边，持续校准“优化是否有效”。

---

6. 与现行规范的关系（兼容 Conventional Commits）

• Conventional Commits 的 type(scope): subject 是展现层；CO 是语义层。

• 兼容策略：

  • type 由 qualifier 映射（fixes→fix、introduces→feat、refactors→refactor…）。
  • scope 推荐填 主 CC 术语最后一级（如 orders.db）。
  • 标题 subject 与 CO 头行保持一致或更自然语言化。

---

7. 模板与示例

7.1 Git 提交模板（.gitmessage）

<qualifier>(BP:<bp1>[,<bp2>], MF:<mf1>[,<mf2>], CC:<cc1>[,<cc2>]) [impact] - <title>  #<issue>

What:
- <做了什么>

Why:
- <为什么要做；风险与替代；关键信息>

How:
- <关键技术要点/迁移说明>

CO:
  bp:
    - term: <bp1>
  mf:
    - term: <mf1>
  cc:
    - term: <cc1>
  qualifiers: [<qualifier>]
  evidence:
    - code: <FT|IR|BM|SC|CR|SA|UF|EXP|IA>
      source: <id/link>
      with: <test/benchmark>
      confidence: <0~1>
  impact:
    - area: <domain>
      metric: <name>
      before: <number>
      after: <number>
      unit: <%,ms,cpu,$,...>
      confidence: <0~1>
  env:
    platform: <web|ios|android|server>
    region: <us|eu|...>
    stage: <dev|staging|prod>
  links:
    issues: [<ids>]
    prs: [<ids>]
    docs: ["<paths>"]

7.2 示例（映射你给出的 7 类 GO 应用场景）

① 功能“注释”/语义定位（Gene Annotation → Commit Annotation）

introduces(BP:user.onboarding, MF:input.validation, CC:api.v2) - enforce email format  #5123

What:
- 新增正则校验，避免下游退件。

Why:
- CR 建议 + UF（用户反馈 37 次注册失败）.

How:
- 使用 RFC 5322 兼容模式；对 iOS/Android 端返回 422.

CO:
  bp: [{ term: bp:user.onboarding }]
  mf: [{ term: mf:input.validation }]
  cc: [{ term: cc:api.v2 }]
  qualifiers: [introduces]
  evidence:
    - code: CR
      source: PR-9012
    - code: UF
      source: ticket-221
  impact:
    - area: signup
      metric: invalid_email_rate
      before: 4.8
      after: 0.9
      unit: "%"
      confidence: 0.7
  env: { platform: web, stage: prod }

② 高通量分析（富集）

• 按版本 v2.4.0..v2.5.0 聚合所有提交，计算 MF 富集：mf:query.optimization、mf:caching.invalidation 显著（p<0.01）。发布说明自动生成“本版本聚焦：查询性能与缓存一致性”。

③ “疾病机制”→ 事故根因

fix(BP:observability.alerting, MF:error.recovery, CC:worker.job) p0 - stop dead-letter loop  #INC-734

...
CO:
  ...
  evidence:
    - code: IR
      source: INC-734
    - code: FT
      with: test_dlq_loop_spec

• 图谱累积发现：mf:error.recovery 与 cc:worker.job 在近三月事故中高频共现 → 进入季度专项整治。

④ “药物靶点”→ 技术靶点与副作用评估

optimizes(BP:search.results, MF:query.optimization, CC:svc.search) p95↓ - shard routing hint

Why:
- BM 显示 p95=480ms；预期降至 ≤250ms。
Risk:
- 可能影响一致性评分（相关性）。
Evidence:
- BM: bench/search-2025-09-01

Impact:
- latency.p95: 480 -> 210 ms (conf=0.85)
- relevance.nDCG@10: 0.912 -> 0.910 (conf=0.6)

• 显式权衡“疗效/副作用”，为灰度与回滚提供依据。

⑤ 比较“基因组”→ 跨服务对比

• 统一术语后，可对比 bp:authz.policy 在 cc:svc.auth 与 cc:ios 的覆盖度与缺陷率，指导投放人力。

⑥ 合成“基因回路”→ 组合式特性

introduces(BP:observability.tracing, MF:serialization, CC:svc.orders) - add W3C trace-context

Why:
- 为后续 lightstep/tempo 链路观测改造铺路（模块组装式推进）。

⑦ 知识图谱

• CO 注释 + 证据 + 指标构成“提交—模块—指标—事故—需求”的多模图谱，可支持“查询所有与 mf:txn.isolation 相关的事故和修复提交”。

---

8. 落地与工具链

• 术语字典：在根目录维护 co-terms.yml（ID、术语、别名、说明、owner、示例）。

• 提交钩子：prepare-commit-msg 注入模板；commit-msg 校验正则与术语合法性；自动把路径映射为 ID。

• CI 解析器：解析 CO: YAML，入库（如 BigQuery/ClickHouse），提供

  • 富集分析（版本/迭代粒度）
  • 看板（按 BP/MF/CC 统计趋势）
  • 自动发布说明（拉取高频 BP/MF + 影响指标）

• IDE 辅助：补全 BP/MF/CC；证据代码下拉；近期常用术语提示。

• 门禁策略：仓库按 L1→L3 分期启用；关键域（安全/支付）优先 L3。

---

9. 迁移策略（从“现状”到“本体化”）

1. 冷启动 2 周：仅要求头行包含 BP/MF/CC（别名可用），收集自由文本以反哺术语树。
2. 第 3–6 周：开启证据必填（fix/optimizes/hardens），推送 20 个“常用术语包”。
3. 第 2 季度：启用 impact 建议项与版本富集报告；跨仓对齐评审术语树。

---

10. FAQ（实际写作的取舍）

• 写不全会不会很重？
  可用最小合规（头行 + 1 条证据），后续通过编辑器补全。优先保证术语正确。
• 复杂改动涉及多个 BP/MF/CC？
  允许多值；头行展示主语义，YAML 列出次要项；富集时按权重（主=1，次=0.5）。
• 与 PR 模板冲突？
  不冲突。PR 面向评审流程；CO 面向长期可计算知识。PR 合并时由 CI 抽取 CO。

---

结语

这套规范把 GO 的优势——标准化术语、三维注释、证据与可计算性——映射到 Git 提交：提交不再只是“一句话”，而是可被统计、关联、推理的知识单元。按此规范执行数周后，你会得到：更清晰的发布说明、更快的事故定位、更客观的工程洞察，以及跨团队真正可比的工程度量。