de 语言包 20 个值把德语开引号 „ 和 ASCII 直引号 " 配成一对(正确配对的只有 21 个),德语用户看到的收尾引号是错的

在 #3546 切片七回填 empty.interfacePageSourceMissing 时,照抄同族邻键 empty.objectNotFoundDescription 的引号风格,发现 de 包该值写的是 „{{name}}" —— 开引号是德语低九分号 U+201E,收引号是 ASCII 直引号 U+0022。不是孤例。

实测

packages/i18n/src/locales/de.ts,全包扫描:

形态	数量
错配 `„…"`(U+201E … U+0022)	20
正确配对 `„…“`(U+201E … U+201C)	21

也就是说这个包里两种写法几乎各占一半,不存在"本包约定就是这样"的解释 —— 21 个值证明约定是 „…“。

错配的 20 个 key:

lookup.createNamed
console.objectView.objectNotFoundDescription
console.objectView.deleteViewConfirm
console.objectView.viewTypeUnavailable
console.objectView.ufShowAllRecords
home.gettingStarted.description
search.resultsCount
search.resultsCountPlural
empty.objectNotFoundDescription
empty.pageNotFoundDescription
empty.dashboardNotFoundDescription
empty.reportNotFoundDescription
navigationSync.addedPage
navigationSync.addedDashboard
navigationSync.removedPage
navigationSync.removedDashboard
navigationSync.renamedPage
navigationSync.renamedDashboard
marketplace.install.localSuccess
preview.empty.notReadyTitle

几个现场(德语用户今天就看到收尾直引号):

empty.pageNotFoundDescription = "Die Seite „{{name}}" wurde nicht gefunden. …"
console.objectView.ufShowAllRecords = "Registerkarte „Alle Datensätze" anzeigen"
search.resultsCount = "{{count}} Ergebnis für „{{query}}""
home.gettingStarted.description = "… wird automatisch unter „Zuletzt geöffnet" angezeigt."

search.resultsCount 尤其明显:结尾是 „{{query}}"",连着两个直引号(一个是错配的收引号,一个是 TS 字符串的结束符,源码里写成 \")。

为什么三道 i18n 门禁都看不见

all-locales-key-parity.test.ts 比键名集合与占位符形状,不读引号;
check-i18n-call-site-keys.mjs 只判 key 在不在;
check-i18n-en-drift.mjs 只在 en 值变化时要求九包跟着改 —— 这些值从落地起就是错的,没有"变化"事件。

建议修法

把 20 个值的收引号从 \" 改成 “。可顺带落一条断言:de 包里 „ 的数量必须等于 “ 的数量(今天是 41 : 21)。同类检查对其他包也成立(fr «/»、zh “/”、ja 「/」),不过其余包实测未见错配。

未在 #3546 切片七里修

切片七的围栏是"只新增 key,⛔ 不改任何既有语言包值"(与在飞的 #3844 / #3875 共用 es/de 文件,避免合并面)。新增的 empty.interfacePageSourceMissing de 值刻意写成正确配对的 „{{name}}“ 而不是照抄邻键的错配形态,并在测试里把这处刻意分歧写明,所以那条断言就是这一单落地时必须回头看的地方。

关联:#3546(切片七)、#3866(同类"取证方法本身出错"的先例)。

Triage: pm:queue — concrete defect, enumerated key list, mechanical fix plus a proposed pairing assertion; German users see the wrong closing quote today.

Anchor (read, not inferred): verified on origin/main @ b750823 (de.ts untouched by the just-merged PR fix(i18n): es 的 preview.draftBar 统一 usted,横幅不再在发布后换人称 (#3844) #3874) — full-file scan of packages/i18n/src/locales/de.ts counts 44× U+201E („) against 24× U+201C (“), with 22 mismatched „…" pairs by regex. The card's own census (41:21, 20 keys) was taken slightly earlier / by-key — same class, marginally different numbers; the claimant should recount at landing rather than trusting either figure (main moves ~daily on this file family).
Gate blindness confirmed by the card: parity/key/drift gates never read values — same value-domain blind spot family as es 语言包的 preview.draftBar 同一条横幅两种敬称 —— messageClean 用 usted、message 用 tú，西语用户按「有无待发布变更」看到不同人称 #3844/es 的 preview.empty.notReadyDescription 用 tú,与同屏的 preview.draftBar(usted)混用 —— 草稿预览未就绪时一屏两种敬称 #3875/[finding] 8 处 auth 调用点的内联 defaultValue 与 en 包值不一致 —— key 存在故兜底是死代码,三道 i18n 门禁按设计都看不见这一类 #3810.
Scope note: fix = flip the closing quote on the mismatched values; the proposed invariant (count(„) == count(“) in de.ts) is the durable half — without it the next backfill re-introduces the drift. Other packs measured clean by the card (fr/zh/ja) — do not expand scope without measuring.
Coordination: 258 个 t() 调用点引用的 key 在任何语言包里都不存在(#3530 守卫首跑实测),其中 8 处直接把 raw key 渲染给用户 #3546 slice 7 (in flight, no PR yet) touches de.ts additively and deliberately wrote its new key correctly paired — claimant should re-read the file at claim time.
Dedupe: no open card or PR names these keys or the quote-pairing invariant; [finding] PR #3847 的「括号复数记法」普查用了 ASCII \w,所以 ru 的结论(0 处)是错的(实为 13 处),同一写法的断言对全部非拉丁语言包空转 #3866 is the adjacent "census method itself wrong" precedent, distinct face.

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

Generated by Claude Code

🔒 分诊 + 认领(objectui shard PM 亲跑分诊轮,session session_01GTRjn8xBqp75dk7kFupVRt)

定级:concrete —— 切片七 dev 立卡带实测(de 包 20 个值把德语开引号 „ 与 ASCII 直引号 " 配对,正确配对仅 21 个),德语用户可见的排印错误;三道 i18n 门禁按设计都看不见(不读引号/只判 key/只在 en 变化时触发)。

分支:claude/issue-3876-de-quote-pairs
修法:20 个值的收尾引号改为德语闭引号 “(以卡片清单为准、逐值复核邻域;en 一字不动,drift 门应报 0 changed);钉子按精确值断言 + 「新的 „…" 错配不得再入」的扫描钉(正则注意 \p{L}+u,[finding] PR #3847 的「括号复数记法」普查用了 ASCII \w,所以 ru 的结论(0 处)是错的(实为 13 处),同一写法的断言对全部非拉丁语言包空转 #3866 教训)。
文件面:packages/i18n/src/locales/de.ts + 独立钉子文件(名带 3876);⛔ 不碰 3546 家族测试。
与在飞 metadata-admin 的 record:details.sections 块设计器没有 name 输入位 —— Studio 搭出来的 section 结构上无法翻译,且必然挂着上游 translation-section-name-missing #3819、ActionRunner.execute 的 condition 门用真值判定:condition: false(最明确的「永不执行」)照样执行(实测 handler 跑了) #3872、AiChatPage 发给 agent 的四条确认文本仍按 UI 语言取值:zh 控制台 + 英文会话把「确认，开始搭建。」发进英文线程,planAnswerMessage 更是完全没有会话语言门控 #3896 零相交。

Generated by Claude Code

fix(i18n): de 包 20 个值把德语开引号 „ 配到 ASCII 直引号,收尾引号改回 „…“ (objectstack-ai…

fix(i18n): de approvalsInbox 三值用德语引号 „…“ 而非 ASCII 直引号 (objectstack-ai…

Navigation Menu

Repository navigation

de 语言包 20 个值把德语开引号 „ 和 ASCII 直引号 " 配成一对(正确配对的只有 21 个),德语用户看到的收尾引号是错的 #3876

实测

为什么三道 i18n 门禁都看不见

建议修法

未在 #3546 切片七里修

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

de 语言包 20 个值把德语开引号 „ 和 ASCII 直引号 " 配成一对(正确配对的只有 21 个),德语用户看到的收尾引号是错的 #3876

Description

实测

为什么三道 i18n 门禁都看不见

建议修法

未在 #3546 切片七里修

Activity

claude commented on Aug 8, 2026

yinlianghui commented on Aug 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions