Uh oh!
There was an error while loading. Please reload this page.
fix(i18n): 十包补齐 organization 命名空间的 90 个缺失 key (#3546 切片二) - #3605
Merged
Conversation
#3546 切片二。#3547 的守卫量出 258 个 t() 引用但十个包都没有的 key, organization 是其中最大的一批:90 个 key、93 个调用点、7 个组件。 全部 90 个 key 补进 en.ts 新增的 organization 顶层段(与既有的 organizations 相邻但相互独立:单数是组织管理面,复数是组织选择器),九包按各自邻键的语气、 词汇与标点惯例逐条实译。en 文案与调用点内联 defaultValue 逐字节一致。 ⛔ 未新增任何 defaultValue。组件未改:先量后动,93 个调用点全部裸用 useObjectTranslation,无 defaults map、无死 || 兜底。 棘轮基线精确减 90(missingKeys 253 → 163);missingPrefixes 4 条未动, organization.invitations.status. 属模板 key 家族,是另一种修法。 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
The latest updates on your projects. Learn more about Vercel for GitHub. |
yinlianghui
marked this pull request as ready for review
August 7, 2026 15:46
Uh oh!
There was an error while loading. Please reload this page.
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes-part-of #3546
#3546 切片二,接 PR #3583(切片一,已合并)。#3547 的守卫量出 258 个
t()引用但十个包都没有的 key,organization是命名空间轴上最大的一批:90 个 key、93 个调用点、7 个组件。本 PR 只处理这一批,其余 163 个 key 与 4 个前缀家族一条未动。⛔ 没有新增任何
defaultValue。动手前的核实:这批全部是"英文可见、十语不可译",没有一处裸 key
切片一验收把严重度框架修正为"8 处里 6 处真渲染裸 key,另 2 处属 #3517 类"。本批按同一标准逐点核实,结论是整批 90 个 key 都属于较轻的 #3517 类,而且三个前提都是量出来的,不是推断的:
defaultValue,0 处无兜底useObjectTranslation(),无createSafeTranslation所以组件一个字没改 —— 切片一认领时写的"仅当有死兜底需删(先量再动)",量下来是没有。这也是本 PR 只有语言包、基线、测试和 changeset 的原因。
另外两处值得记录的量测:
organization.backToList、invitations.copyFailed、invitations.linkCopied三个 key 各有两个调用点。守卫计数器统计的是调用点不是去重 key,这个差额下面预测表里会再出现一次。defaultValue逐字节一致,93/93 零漂移,脚本比对而非目测。带defaultValue的站点上,包里有值时 i18next 用包、无值时用默认值,两条路径文案不一致就是静默分叉。改了什么
1. 新增
organization顶层命名空间,插在既有organizations段之后 —— 十个包同一锚点,方便对读。两者刻意保持独立:单数是组织管理面(console/organizations/**七个组件 + 工作区切换器),复数是组织选择器,在调用点上二者只差一个字母,合并会静默重指 90 个 key。en 包里为此写了注释,测试里也钉了一条断言。段内按调用点顺序分 6 组:
tabs(3)、members(10)、invitations(24)、settings(32)、accept(14)、switcher(4),外加 3 个顶层 key。2. 九包逐条实译,按各自邻键的惯例写,不照抄切片一的用词。 每包的依据(摘要,非 90×10 逐条):
组织 / 成员 / 邀请 / 角色(随capability.group.org、workspace.members);全角标点。?,fields.file.uploadFailed的全角引号惯例用在输入“{{slug}}”以确认;第二人称用「您」,随organizations.heading。Retirer ce membre ?),随该包 55 处同类;引号用« »(随fields.file.uploadFailed);失败类统一Impossible de …,与detail.linkCopyFailed完全一致 ——copyFailed直接复用了那句既有译文。organizations.subtitle);失败类用… konnte nicht … werden被动式(随detail.linkCopyFailed);破折号用该包主用的—。organizations.heading= "Tus organizaciones"、emptyDescription= "Crea tu primera…"、workspace.createDescription= "para que tu equipo colabore"。全仓 es 正式/非正式各 42/43 对半,所以按邻域定,而非按切片一(wizard.*邻域是form.*/validation.*,那边是正式体)。引号« »。組織 / メンバー / 招待 / ロール;失败类…に失敗しました;引用用「」(随fields.file.uploadFailed)。구성원而非멤버(随workspace.members);助词处理写全{{name}}을(를)、{{role}}(으)로,随lookup.selectFirst的既有写法。Excluir(随common.delete)、Gerenciar、Salvar alterações;views 译作exibições,与切片一在同包里定的objectView用词一致。удалён、приглашённому),随该包 152 处;失败类统一Не удалось …;引号« »。المؤسسة(随cloudConnection.bound.organization、organizations.*,而非capability.group.org的منظمة);占位符按阿语语序自然落位。3. 棘轮基线精确减 90(
missingKeys253 → 163),脚本断言removed === 90且删除项全部以organization.开头、missingPrefixes一条未动、note未动。一处诚实的偏差:12 对与 en 逐字相同的译文
切片一的"九包不得与 en 逐字相同"断言在 5 个 key 上是干净的空集。铺到 90 个 key 上不是 —— 有 4 个 key 在部分语言里本来就该跟英文一样:
settings.logoLabel= "Logo"appDesigner.logoUrl在这五包里同样保留 "Logo"settings.slugLabel= "Slug"workspace.slugLabel在这四包里也保留 "Slug"settings.generalTitle= "General"tabs.invitations/invitations.title= "Invitations"没有为了让断言好看而扭曲译文。 做法是把这 12 对写成显式白名单,断言用集合相等而不是包含 —— 多一对相同会红,把其中一条改成不相同也会红并强制删掉那一行,白名单没法悄悄变成一张通行证。810 对里 12 对例外,即 90 个 key 中 86 个在九包里全部不同。
验证:方向与数字都是跑之前先写下的
预测原文在提交前落盘。守卫
node scripts/check-i18n-call-site-keys.mjs:missingKeysmissingPrefixes最后一行我预测错了,如实记录。 我把
2319当成了去重 key 数,它其实是调用点数(工单正文的276 处 / 258 个不重复 key、2319 − 2043 = 276就是这个关系)。90 个 key 里有 3 个各有两个调用点,所以增量是 93 不是 90。数字对得上、方向也对,错的是我对分母的理解 —— 补记在这里,免得下一个切片照抄这个错误。逆向验证 A —— 中间态(只补 en,九包与基线不动)
预测:平价 RED ×9 + 棘轮 stale RED。两条都精确命中:
missingPrefixes: organization.invitations.status.没有混进 stale 列表 —— 预测过它不会,因为本 PR 没有任何 key 以那个静态前缀开头。补齐九包后平价转绿而棘轮仍红,补完基线才全绿:三步各自独立,顺序符合守卫头注的设计。逆向验证 B —— 新断言真的有鉴别力(用了保存的补丁分级,未用
git stash)两个方向分别验,因为它们抓的是不同的东西:
B1,删掉 fr 整段 → 4 条红:平价的
fr defines every en key、本文件的fr defines every organization key as a non-empty string、集合相等的防抄袭断言(fr 的 3 条 cognate 消失了)、占位符一致性。这条顺带证明了防抄袭断言单独看是空的 —— 键不存在时undefined !== en,它反而会变绿,是"存在性"那条兜住的。B2,把 fr 的
settings.dangerZone改成英文 "Danger zone" → 只有防抄袭断言红,平价全绿:平价绿是正确的 —— 键集合没变,它按设计就看不见值。这正是这条断言存在的理由:"九包抄英文"能拿到全键平价、十包全绿,而九种语言仍在读英文。B2 是这个盲区的直接演示。
两次逆验后把 fr 还原,并用
diff比对补丁确认与逆验前逐字节一致。测试与门禁
消费半径扫过了,不只改动包:
WorkspaceSwitcher.test.tsx里有getByText('Working organization')/'Switch organization'/'New records are created here…'三处硬编码英文断言。它们保持绿,而且是有理由保持绿 —— en 包值与该组件的defaultValue逐字节一致,provider 两条路径不分叉。这也是前面那条零漂移量测的实际价值。新测试为什么长这样
packages/i18n/src/__tests__/organization-namespace-3546.test.tsx,20 条:useObjectTranslation(),不挂 provider 时 i18next 根本不是应答方,断言描述的就不是控制台里的那条路径 —— 工单记录的假绿陷阱。organization.key,并且organization.invitations.status.前缀仍在 —— 那条断言就是防止这个前缀家族被顺手忘掉的记号。本 PR 不做、留给后续的
organization.invitations.status.这个整族缺失的模板前缀(InvitationsPage.tsx:161、:206)留在基线里没动。它跟 90 个字面量 key 不是同一种修法 —— 要先定下邀请状态的取值集合再整族补,属于工单正文列的"4 个整族缺失的模板 key"那一批。切片二认领范围写的是 90 个 key、棘轮恰减 90,所以按范围停手,并在测试里立了标记。顺带发现:无。本批没有量到范围外的缺陷。
文件面
十个语言包(仅新增 organization 段)、
scripts/i18n-call-site-key-baseline.json(仅删 90 条 organization)、1 个新测试、1 个 changeset。组件 0 改动(死兜底量测为 0)。与在飞的 #3363(types/mobile)、#3584(CONTRIBUTING)、#3578 / #3575(runner)零文件相交,起分支时已核。Generated by Claude Code