在 #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 「/」),不过其余包实测未见错配。
切片七的围栏是"只新增 key,⛔ 不改任何既有语言包值"(与在飞的 #3844 / #3875 共用 es/de 文件,避免合并面)。新增的 empty.interfacePageSourceMissing de 值刻意写成正确配对的 „{{name}}“ 而不是照抄邻键的错配形态,并在测试里把这处刻意分歧写明,所以那条断言就是这一单落地时必须回头看的地方。
关联:#3546(切片七)、#3866(同类"取证方法本身出错"的先例)。
在 #3546 切片七回填
empty.interfacePageSourceMissing时,照抄同族邻键empty.objectNotFoundDescription的引号风格,发现 de 包该值写的是„{{name}}"—— 开引号是德语低九分号 U+201E,收引号是 ASCII 直引号 U+0022。不是孤例。实测
packages/i18n/src/locales/de.ts,全包扫描:„…"(U+201E … U+0022)„…“(U+201E … U+201C)也就是说这个包里两种写法几乎各占一半,不存在"本包约定就是这样"的解释 —— 21 个值证明约定是
„…“。错配的 20 个 key:
几个现场(德语用户今天就看到收尾直引号):
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.interfacePageSourceMissingde 值刻意写成正确配对的„{{name}}“而不是照抄邻键的错配形态,并在测试里把这处刻意分歧写明,所以那条断言就是这一单落地时必须回头看的地方。关联:#3546(切片七)、#3866(同类"取证方法本身出错"的先例)。