[finding] 8 处 auth 调用点的内联 defaultValue 与 en 包值不一致 —— key 存在故兜底是死代码,三道 i18n 门禁按设计都看不见这一类

[yinlianghui]

在 #3546 切片三(PR 回填 auth 家族 54 个缺失 key)顺手量出,不在该 PR 范围内,单独记录。观察级:用户今天看到的字串是包值,包值本身没问题;坏的是同一个调用点还写着一句永远不会渲染、且与包值说法不同的英文。

量法

对 auth / oauth / acceptInvitation 三个命名空间的全部 122 个 t() 调用点做 AST 抽取(key + 内联 defaultValue 字面量),与 packages/i18n/src/locales/en.ts 的实际叶子值逐字节比对。其中 54 个是缺 key(#3546 切片三已补,补的时候 52/52 与站点默认值取到逐字节相同),剩下 68 个 key 是已经存在的 —— 这 68 个里有 8 处 en 值与站点默认值不同:

key	en 包值(实际渲染)	站点内联 defaultValue(死代码)	位置
auth.forgotPassword.description	Enter your email address and we'll send you a link to reset your password	Enter your email and we'll send you a reset link.	ForgotPasswordPage.tsx:33
auth.forgotPassword.submitButton	Send Reset Link	Send reset link	:39
auth.forgotPassword.submittingButton	Sending...(三个半角点)	Sending…(U+2026)	:40
auth.forgotPassword.successDescription	We've sent a password reset link to {{email}}. Please check your inbox.	If an account exists, a reset link has been sent.	:46
auth.login.errors.invalidCredentials	Invalid email or password. Please try again.	Invalid email or password	LoginPage.tsx:368
auth.login.submittingButton	Signing in...(三个半角点)	Signing in…(U+2026)	LoginPage.tsx:386
auth.verifyEmail.resendFailed	Cannot resend verification email	Failed to resend verification email	VerifyEmailPromptPage.tsx:81
auth.verifyEmail.resendFailed(同一 key 第二个站点)	同上	同上	VerifyEmailPromptPage.tsx:128

为什么它是 finding 而不是 bug

i18next 只在 miss 时用 defaultValue。这 8 个 key 十包都有,所以包值恒胜 —— 那些 defaultValue 是结构性死代码。用户看不到任何异常。

但它有两处真实代价:

1. 误导读者。 读组件的人(和写代码的 AI)会以为按钮上写的是 Send reset link,实际是 Send Reset Link;以为忘记密码成功页遵守了"不暴露账号是否存在"的写法(If an account exists, …),实际渲染的是 We've sent a password reset link to …,断言了一个可能没发生的发送动作。改文案的人改错那一行,门禁一片绿。
2. 一旦哪天 key 被删/改名,渲染会静默跳回这 8 句里的另一种说法,而没人在 review 里预期到文案会变。

第 3、6 行只差一个省略号字符(... vs …),是包内排版一致性问题(en 包里两种写法混用);其余 6 行是语义差异。

三道门禁为什么都看不见

• scripts/check-i18n-call-site-keys.mjs([finding] 没有任何守卫断言组件 t() 引用的 key 存在于 en 包 —— parity 测试只管包际一致,调用点→包的一致性是盲区 #3530):只问"这个 key 在 en 里存不存在",存在即绿。
• packages/i18n/src/__tests__/all-locales-key-parity.test.ts:只比键名集合与占位符形状,从不读值。
• scripts/check-i18n-en-drift.mjs(i18n 门禁:en 文案变更时其余九包必须同批跟改(或显式挂账)——#3582/#3625 族缺陷缺的那道不变量 #3650):只在 en 值发生变化时要求九包跟改;这 8 处的 en 值静止不动。

所以这是 #3582 / #3625("key 在、值陈旧")之外的又一个值域盲区,而且更容易复发:任何人给一个已存在的 key 加内联 defaultValue,都可以自由写成另一句英文。

可能的收口方向(未裁决)

• A. 一次性对齐 8 处,把内联 defaultValue 改成与 en 包值逐字节相同(258 个 t() 调用点引用的 key 在任何语言包里都不存在(#3530 守卫首跑实测),其中 8 处直接把 raw key 渲染给用户 #3546 切片一/二/三补新 key 时用的就是这条纪律,切片三给出 52/52 的脚本证据)。治标,不防复发。
• B. 加一道门禁:凡调用点带字面量 defaultValue 且该 key 在 en 有值,则两者必须逐字节相同,否则红。[finding] 没有任何守卫断言组件 t() 引用的 key 存在于 en 包 —— parity 测试只管包际一致,调用点→包的一致性是盲区 #3530 的守卫已经把 key 与 defaultValue 都解析出来了,加这条判定几乎是零增量成本;先跑一遍全仓量出存量再决定是否落基线。
• C. 更彻底:禁止对已存在的 key 写内联 defaultValue(它此时唯一的作用就是误导),只在"key 还没进包"的过渡期允许 —— 但 258 个 t() 调用点引用的 key 在任何语言包里都不存在(#3530 守卫首跑实测),其中 8 处直接把 raw key 渲染给用户 #3546 正说明那个过渡期会长达数月,所以这条得配 B 才有意义。

倾向 B(声明即强制,让写错的那一刻就红),存量按 A 一次性对齐。规模未量:本次只扫了 auth 家族三个命名空间,全仓 2320 个字面量 key 的调用点里还有多少同类未知 —— 这是这张单最该先做的一件事。

关联:#3546(存量缺 key 的账,切片三顺手量出本条)、#3530(调用点→en 门禁本体)、#3650(en-drift 门禁)、#3582 / #3625(值域盲区的前两个实例)。

[yinlianghui]

#3546 切片四(console 命名空间)的实测,回填本单正文点名"最该先做"的那件事:规模。 这里只报 console.*,不是全仓;另外报一个本单的门禁设计漏掉的同根异形。

1. console.* 的同类存量:1 处(新增,由切片四引入)

对全仓 308 个 console.* 的 t() 调用点做 AST 抽取(key + 内联字面量 defaultValue),与 en 实际叶子值逐字节比对。其中 47 个站点属切片四回填的 41 个缺 key(46/47 逐字节相同),剩下的都是已存在 key。

唯一一处不同的,是切片四自己造成的,而且结构上无法避免 —— 一个 key 在同一个按钮上被写了两句不同的英文:

key	站点	内联 defaultValue
console.ai.dock.open	ChatDock.tsx:562 (aria-label)	Open assistant
console.ai.dock.open	ChatDock.tsx:563 (title)	Open assistant (⌘⇧I)

key 缺失时两个站点各渲染自己的 defaultValue,所以两句今天都是活的;把 key 补进 en 之后包值恒胜,其中一句必然变成本单描述的死代码。切片四取了 aria-label 那句(无障碍名不能带一串被读屏念成符号的字形;且 ⌘ 是 mac 专有字形,语言包无法按平台分叉),于是 title 上的 (⌘⇧I) 提示消失 —— 该快捷键是真的(chatDockState.ts:168 的 matchChatDockShortcut 匹配 ⌘/Ctrl+Shift+I),只是它没有出现在 KeyboardShortcutsDialog 的 aiChat 组里(那里只列了 ⌘⇧O 与 ⌘⇧S),所以补键之后这个快捷键在 UI 上没有任何发现面了。是否把它加进快捷键面板属产品裁量,记在这里。

这条也说明本单选项 A(一次性对齐)对这一类无效:两个站点声明了两句不同的英文,对齐到哪一句都是决策而不是机械操作。选项 B 的门禁如果要覆盖它,判据得是"同一个 key 的所有站点的字面量 defaultValue 必须彼此相同,且等于 en 值" —— 前半句本单正文没写,而它恰好是能在写错的那一刻就红的那半句(缺 key 时期两句都不算错,补键时才爆)。

2. 门禁设计漏掉的同根异形:t(key) || '英文',5 处

同一次扫描顺带量出:packages/app-shell/src/views/ObjectView.tsx 还有 5 处兜底,写法不是 defaultValue: 而是 ||,机制完全一样 —— key 在 en 有值 ⇒ t() 返回真值 ⇒ 右侧永不求值:

:909  t('console.objectView.deleteViewConfirm', { name: viewLabel }) || `Are you sure you want to delete the view "${viewLabel}"? …`
:912  t('console.objectView.deleteViewTitle') || 'Delete view'
:913  t('console.objectView.delete')          || 'Delete'
:914  t('console.objectView.cancel')          || 'Cancel'
:1921 t('console.objectView.systemViewReadonly') || 'System view defined in code — read-only.'

五个 key 在 en 全都有值(Delete view / Delete / Cancel / System view defined in code — read-only. 与 Are you sure you want to delete the view "{{name}}"? This cannot be undone.),所以五条右侧都是死代码。前四条的死句与包值同字面,只是冗余;:909 那条不同 —— 包值用 i18next 插值 {{name}},死句用模板串内联 viewLabel,是本单第 1 项"误导读者"的完整形态。

为什么它不在 #3546 里:#3546 切片一(PR #3583)删的是同一个文件里 key 缺失的 5 处 ||(854/872/906/923/976 行,那时 || 因 i18next miss 返回 key 恒真而失效,是用户可见的裸 key)。这 5 处的 key 存在,所以从来没进过 i18n-call-site-key-baseline.json,谁也扫不到它们。

对本单的影响:选项 B/C 若只判 defaultValue 这一种写法,|| / ?? 这一支会整支漏掉,而它在本仓是有存量的。建议门禁的判据按"兜底"这个语义写,把 t(...) 作为 || / ?? 左操作数的形态一并纳入 —— #3530 的守卫已经拿到了 AST 节点,拿 node.parent 判一下二元运算符几乎零成本(切片三/四的死兜底扫描就是这么做的)。

未量的部分

本次只覆盖 auth 家族(本单正文)+ console,共约 430 个调用点;全仓 2320 个字面量 key 站点里其余 ~1900 个仍未量。两次扫描的脚本形态一致,可以直接推到全仓 —— 那是决定 B 是否要配基线落地的前置数据。

关联:#3546 切片四(引入第 1 项、量出第 2 项)、#3530(守卫本体,已有现成 AST)、#3837(同一次扫描量出的另一类,组件侧语言门控,与本单无关)。

---

Generated by Claude Code

[claude]

Findings round: PROMOTED — finding → pm:queue.

• Scoped tooling/gate fix with a measured signal: 8 of 68 existing-key call sites in the auth family carry an inline defaultValue that diverges from the en-pack value (dead code that misleads readers and becomes a silent fallback on key rename). Spot-checked live @ f5f8744: ForgotPasswordPage.tsx:39 (Send reset link vs pack Send Reset Link), :47 (If an account exists, … vs pack asserting a send happened).
• Direction as the body prefers: B (gate — literal defaultValue must byte-equal the en value when the key exists; near-zero increment on [finding] 没有任何守卫断言组件 t() 引用的 key 存在于 en 包 —— parity 测试只管包际一致,调用点→包的一致性是盲区 #3530's parser) plus A (align the measured 8). First step stays the full-repo census; if the count balloons, run it as sweep material (one card, one PR, itemized list). Gate-addition promotion precedent: docs(skills): guide 里反引号包裹的仓内路径无任何门禁校验 —— #3713/#3730 两轮 13+ 处死路径都是靠人肉发现的 #3735.
• Dedup: value-domain blind spot distinct from console.objectView 的 2 个 key 在 8 个语言包里是英文原文,其中 systemViewReadonly 还是与 en 不一致的旧文案(全部门禁皆绿) #3582/view.readonlyTooltip 在 8 个语言包里译的是「duplicate to customize」这句已废弃语义 —— 因为它是真译文,任何「值是英文」判据都看不见它 #3625 (key-exists-value-stale) per body; no open shadow.

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code

[yinlianghui]

#3546 切片五(marketplace + preview 两命名空间)的实测,继续填本单正文点名"最该先做"的那件事:规模。 本次的结果对本单有两个方向相反的意义 —— 一个干净的对照组,和一个单文件 16 处的 || 存量。

1. 内联 defaultValue vs en 值:65/65 逐字节相同,0 分歧

对 marketplace.* + preview.* 的全部 172 个 t() 调用点(11 个文件)做 AST 抽取,取带字面量 defaultValue 的站点与 en 实际叶子值逐字节比对:

marketplace.*/preview.* call sites: 172 in 11 files
  with a literal inline defaultValue: 65
  defaultValue === en value: 65/65
  DIVERGED: 0

65 个里 36 个是切片五刚补的缺 key(补的时候取的就是站点默认值,所以必然相同),另外 29 个是早已存在的 key —— 这 29 个也全部相同。

这是本单目前第一个零分歧的命名空间。对比:

范围	已存在 key 的站点	与 en 分歧
auth / oauth / acceptInvitation(本单正文)	68	8
console(切片四评论)	~125	1(且是切片四自己引入的一 key 两句英文)
marketplace / preview(本次)	29	0

对本单的判断有用的地方:分歧不是均匀分布的,它集中在 auth 家族。这支持选项 B 落成硬门禁而不是配基线 —— 存量若真的集中在一处,一次性对齐(选项 A)完了就可以直接硬红,不必背一个基线文件。前提是把剩下 ~1900 个站点扫完。

累计进度(本单要的全仓普查):auth 家族 122 + console 308 + marketplace/preview 172 ≈ 600 个站点已量,全仓 2320 个字面量 key 站点还剩 ~1720。三次扫描的脚本形态一致。

2. t(key) || '英文' 存量:16 处,全在一个文件,全在已存在的 key 上

同一次扫描量出,packages/app-shell/src/console/marketplace/MarketplacePackagePage.tsx 有 16 处 || 兜底,涉及 10 个不同的 key,每一个 key 在 en 都有值,所以 16 条右侧全是死代码:

|| / ?? fallback constructs: 16 (all on keys en defines: true)
  {"packages/app-shell/src/console/marketplace/MarketplacePackagePage.tsx": 16}
  distinct keys: 10

10 个 key 与它们的 en 值:

key	en 值	站点数
marketplace.detail.purgeConfirm	Delete all sample records seeded by this package? User-added records will NOT be touched.	2
marketplace.detail.purgeSuccess	Removed {{count}} sample record(s).	2
marketplace.detail.purgeNoData	No sample records found to purge.	2
marketplace.detail.reseedAgain	Re-seed sample data	2
marketplace.detail.addSampleData	Add sample data	2
marketplace.detail.purgeSampleData	Purge sample data	2
marketplace.detail.reseedQueued	Sample data will be re-seeded on next environment access.	1
marketplace.detail.reseedLocalSuccess	Re-seeded sample data: {{inserted}} inserted, {{updated}} updated.	1
marketplace.detail.reseedPartialErrors	({{count}} record(s) failed to write)	1
marketplace.detail.moreOptions	More install options	1

其中三条是本单正文第 1 项("误导读者")的完整形态,而不只是冗余:

• moreOptions:包值 More install options,死句 More options。读组件的人会以为下拉的无障碍名是 More options。
• purgeSuccess:包值用 i18next 插值 {{count}},死句是模板串 `Removed ${removed} sample record(s).`。
• reseedLocalSuccess:包值 Re-seeded sample data: {{inserted}} inserted, {{updated}} updated.,死句 `Sample data re-seeded (inserted=${ins}…` —— 连句式都不同。

为什么它不在 #3546 里:#3546 切片一(PR #3583)删的是 key 缺失的 5 处 ||(那时 || 因 i18next miss 返回 key 恒真而失效,是用户可见的裸 key)。这 16 处的 key 都存在,所以从来没进过 i18n-call-site-key-baseline.json,守卫扫不到。切片五因此零组件改动 —— 先量再动,量出来的 16 处一处也不属于本切片的 37 个 key。

对本单的影响,与切片四的结论一致并加强它:|| 这一支的存量现在不是 5 处而是 21 处(ObjectView.tsx 5 + MarketplacePackagePage.tsx 16),且第二处集中在一个文件里。选项 B/C 若只判 defaultValue: 这一种写法,会整支漏掉,而它已经是本仓 defaultValue 分歧存量(9 处)的两倍多。判据应按"兜底"这个语义写,把 t(...) 作为 || / ?? 左操作数的形态一并纳入。

3. 顺带:一个方向相反的同类,已单独立单

本次扫描还量出反向的一种参数/值不匹配:调用点传了插值参数、而值里没有对应的 {{hole}},i18next 静默丢弃。全仓 1055 个站点里 1 处(marketplace.action.updateTo 传 version、en 值是裸 Update,而同文件的姐妹键渲染 Update → v{{version}})。已立 #3845,并在那里建议它与本单选项 B 的判据同批实现(同一个 AST 位置,双向都判:传了没洞的参数红,值里有洞没人传也红)。#3845 里还记了一个实现陷阱:参数名提取必须先消掉嵌套的 t() 调用,否则内层参数会被当成外层的(第一遍扫描就在 ImageField.tsx:105 上误报过一次)。

关联:#3546 切片五(量出本条)、#3530(守卫本体,已有现成 AST)、#3845(反向的参数/洞不匹配)、#3844(同一次裁定量出的 es 语域分裂,与本单值域盲区同族但又是新一类)。

---

Generated by Claude Code

[yinlianghui]

#3546 切片六(perm + home)的普查数据 —— 本单正文自陈"规模未量"是最该先做的一件事,这里再交一段。方法同切片五:AST 抽取该命名空间全部 t()/tt() 调用点的 key + 内联字面量 defaultValue,与 en.ts 实际叶子值逐字节比对。

perm.*/home.* call sites: 153 in 14 files
with a literal defaultValue: 53   en === defaultValue: 49/53
dead `t(key) || …` / `?? …` constructs: 0

4 处分歧,全部在 packages/app-shell/src/console/home/HomePage.tsx,全部是已存在的 key(所以包值恒胜、defaultValue 是死代码,与本单的类型完全一致):

key	en 包值(实际渲染)	内联 defaultValue(死代码)	位置
home.loading	Loading workspace...(三个半角点)	Loading workspace…(U+2026)	:274
home.welcome	Build your business system with AI	Welcome to {{product}}	:296
home.welcomeAdminDescription	…from the menu on the left.	…from the Administration menu on the left.	:325 附近
home.noAppsDescription	Your workspace is being set up — apps your admin shares with you will show up here.	There are no applications available to you yet. Please contact your workspace administrator.	:325

第 1 行与本单表格第 3/6 行同类(... vs …,en 包内混用);第 2、4 行是整句换说法的语义分歧,尤其 home.welcome:读组件的人会以为首屏大标题是"Welcome to <产品名>",实际渲染的是"Build your business system with AI"。累计已量:auth 家族 68 + marketplace/preview 29 + perm/home 53 ≈ 150 个"已存在 key + 字面量 defaultValue"的站点,分歧 8 + 0 + 4 = 12。

另一条与选项 C 直接相关的机制,建议记进本单:对经 createSafeTranslation 的组件,内联 defaultValue 在两条路径上都是死的。provider 路径包值恒胜(本单已述);无 provider 路径 fallbackT 读的是 defaults[key] || key,根本不看 options.defaultValue —— 它只被当成一次 {{defaultValue}} 替换。所以那里既不渲染兜底文案,也不渲染包值,而是渲染 raw key。已另立 #3865(含 useDetailTranslation 一个 hook 的实测:146 条表 / 16 个 key 不在表内)。

这对本单的选项裁量有影响:选项 C(禁止对已存在的 key 写内联 defaultValue)在这些组件上没有任何代价,因为那个 defaultValue 现在两条路都不读;选项 B 的门禁若按"key 在 en 有值则两者必须逐字节相同"实现,顺带也能把这 12 处一次性逼出来。

关联:#3546 切片六 PR、#3865(同一 helper 的另一半)、#3863。

---

Generated by Claude Code