Repository navigation
[观察] zh-CN.ts 的 help 串与它自己的 label 打架:help 说「线索转换」「关闭为赢单」,而 label 是「转化线索」「成交」 #846
Description
来源:#829(PR #842)实施时的越界发现。基线 origin/main = a501812。不是用户今天会踩到的新缺陷,是语言包内部四处自相矛盾,且第 2 组牵扯一个已被裁定过的方向问题,故打 finding 不排期。
#793 起的一串单子(#794 #803 #825 #829)都建立在同一条前提上:语言包是契约,文档跟包。这条前提成立的隐含条件是包自己前后一致。实测有四处不一致 —— 都是 help / description 串用了包自己的 label 不用的词。
甲、convert 动词面(2 处)
convert_lead.label 是「转化线索」,is_converted 是「已转化」,'success.converted' / 'confirm.convert_lead' 也都用「转化」。但:
zh-CN.ts:110crm_account.fields.name_normalized.help—— 「线索转换的匹配键:客户名称转小写……」zh-CN.ts:400crm_lead.fields.company_normalized.help—— 「线索转换的匹配键:公司名称转小写……」
值得注意的是 PR #825 已经把这两条 help 的文档渲染改成了「转化」(leads.zh-Hans.mdx:41「线索转化与重复检测按它匹配」),#842 又把 accounts.zh-Han{s,t}.mdx:62 描述同一机制的那句改成了「转化」。也就是说文档侧已按 label 统一,现在是包里这两个 help 串成了唯一的孤例。
乙、阶段名(2 处)
crm_opportunity.stage 的 closed_won = 「成交」、closed_lost = 「失败」(#829 已裁定文档跟这个)。但同一对象的:
zh-CN.ts:935win_reason.help—— 「赢单原因。将商机关闭为"赢单"时必填。」zh-CN.ts:944loss_reason.help—— 「丢单原因。将商机关闭为"丢单"时必填。」
即:help 文本用引号点名一个阶段值,而点的是两个阶段选择列表里都不存在的词。用户在关单时看到这句 help,去阶段下拉里找「赢单」,找到的是「成交」。
注意 win_reason.label「赢单原因」/ loss_reason.label「丢单原因」/ loss_details「赢/丢单详情」本身没有问题 —— #842 已确认 赢单/丢单 是包自己的成败词汇,文档里这些位置都原样保留了。有问题的只是 help 里被当作阶段值引用的那两个词。
与 #829 A/B/C 之争的关系
#829 正文提过方向 B(改包,closed_won/closed_lost 用「赢单/输单」),维护者裁定走 A。本条不是要翻案 —— 但它是 B 方向当时唯一没被摆上台面的证据:包自己在 help 里说的就是「赢单」。所以两种收口都自洽,需要维护者点一下:
- B1(跟 label):改 help,「关闭为"成交"/"失败"」。最小改动,与 zh 文档里 crm_opportunity 的 7 个阶段名有 4 个与语言包不符(开发期/资格审核/赢单/输单),且这一组该动哪边未定 #829 的 A 裁定同向。
- B2(跟 help):那就是 zh 文档里 crm_opportunity 的 7 个阶段名有 4 个与语言包不符(开发期/资格审核/赢单/输单),且这一组该动哪边未定 #829 的方向 B,要改
stage的两个 label 并回头再扫一遍文档。代价已经变大了 —— docs(sales): name the seven opportunity stages the way the locale pack ships them (#829) #842 刚把 24 处「输单」和 20 处阶段名「赢单」按 A 扫完。
我的建议是 B1:#829 已经裁定 label 是事实来源,help 是对 label 的解释,解释跟被解释者走;且 B1 不产生任何文档返工。
影响面
四处都是 help,即字段旁的帮助气泡,用户看得见但不会据此点错按钮(阶段那两处会让人多找一下)。不影响 os validate / lint / 测试 —— 现有闸门没有任何一道读 help 串与 label 的一致性(这正是 #802 记的那道缺闸的另一半:#802 管「文档 vs 包」,本条是「包 vs 包自己」)。
复核:
grep -n "线索转换\|关闭为\"赢单\"\|关闭为\"丢单\"" src/translations/zh-CN.ts
Activity
yinlianghui commentedon Aug 5, 2026
第五处同类不一致:
crm_opportunity.fields.crm_campaign.help来源:#830(crm_campaign 的 zh-Hans 文档译名统一)实施时的越界发现。基线
origin/main= 3912845。按去重纪律不另立单 —— 这与本单甲/乙两组是同一类(help串用了包自己label不用的词)、同一文件,且本单已pm:queue,谁来收口都该顺手带走这一处。同一行上自相矛盾:字段 label 是「营销活动」,紧挨着的 help 却写「市场活动」。对象自身的 label / pluralLabel(
zh-CN.ts:742-744)同样是「营销活动」。比本单原有四处更干脆的一点:「市场活动」在整个 zh-CN 包里是零-label 词 —— 全包唯一一次出现就是这个 help 串本身。甲组的「线索转换」、乙组的「赢单/丢单」至少还各自是包里活着的词(
win_reason.label等),这一处点的词包里根本没有任何 label 用它。四个语言包实测:zh-CN 是唯一的孤例
本单正文提醒「⚠️ 若决定动手,四个语言包的对应 help 串都要一起看 —— 本条只实测了 zh-CN」。这一处四个都测了,其余三个都自洽:
en.ts:538CampaignMarketing campaign that generated this opportunityzh-CN.ts:925es-ES.ts:545CampañaCampaña de marketing que generó esta oportunidadja-JP.ts:540キャンペーンこの商談を生み出したマーケティングキャンペーン即三个语言都用「(marketing 修饰词) + 对象名」的构词,help 里的中心词就是 label;只有 zh-CN 换了个中心词。收口写法对应本单的 B1(help 跟 label):
help: '带来此商机的营销活动'。零文档返工 —— PR #TBD(#830)已把文档侧的「市场活动」清零。与 #830 的边界
#830 ⛔ 不动语言包,故本 PR 一处未修;#830 之后
市场活动在content/全仓零命中,这个 help 串是它在整个仓库里仅存的一处。也就是说:本条不修,「市场活动」就仍然只在用户看得见的字段帮助气泡里活着,而文档和 UI label 已经全部统一到「营销活动」。Refs #830 #802
Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
[PM 认领 · R19] session_01VHrPAGEgFDoHjphqYG4BMa · 分支
claude/issue-846-help-strings-follow-labels· 文件面:src/translations/zh-CN.ts(必要时含其它语言包对应串)+ 引用这些 help 原文的文档行(如有)+ changeset裁定与边界:
win_reason/loss_reason/loss_details的 label 本身不动(docs(sales): name the seven opportunity stages the way the locale pack ships them (#829) #842 已确认 赢单/丢单 是包的成败词汇)。zh-CN.ts:925crm_opportunity.fields.crm_campaign.help「带来此商机的市场活动」→「营销活动」(zh-Hans 文档里 crm_campaign 有两个译名:administration 两页写「市场活动」,语言包与其余 14 个文件写「营销活动」 #830/PR docs(zh-Hans): call crm_campaign 营销活动 everywhere, not 市场活动 (#830) #849 后「市场活动」在 content/ 已零命中,这是全仓最后一处)。content/docs/ai-copilot/**请只报不改(工单分流页宣称的检索与产出,case_triage 的工具面根本够不着(只有 describe_object + get_record);Customer 360 的能力清单同样超出 skill instructions #847 同轮在飞,文件面互斥)。⛔ 不升级 @objectstack/*;不动
content/docs/releases/。Generated by Claude Code
yinlianghui commentedon Aug 6, 2026
[PM 验收] PR #859 ACCEPT — 已转 ready 并挂 auto-merge(session_01VHrPAGEgFDoHjphqYG4BMa)
复核结论:
win_reason/loss_reason/loss_details三个 label 与loss_details.help(成败词汇的正常用法)一字未动,边界拿捏与 docs(sales): name the seven opportunity stages the way the locale pack ships them (#829) #842 裁定完全一致。第六处疑似(:288closed_amount)判为「结果义,非阶段值引用」刻意不改并披露——正确。dist/objectstack.json做结构化走查——五条新串落到正确翻译路径、旧拼法零残留、help 引号内的词与stage.options逐字命中。这正是本单要修的用户可见事实的直接证据。automation.zh-Hans.mdx:57的「线索转换流程」正确留给 convert 动词面:zh-Hant 侧整体没跟上简体侧,marketing/analytics/guides 等 20 余处仍写「轉換」而包里是「转化」 #844(其 ROW_LABEL 钉子同属 convert 动词面:zh-Hant 侧整体没跟上简体侧,marketing/analytics/guides 等 20 余处仍写「轉換」而包里是「转化」 #844)。测试零钉子,故未改测试——如实。越界发现处置:#858(ja-JP 包内 convert 词汇两派分裂,label-vs-label,B1 覆盖不了,需维护者点头的译名决定)保持
finding——dev 填单后自查更正计数(13→14)并附复核命令,值得记一笔的严谨。finding 池升至 12,R19 落地后执行分诊轮。Generated by Claude Code
fix(i18n): make five zh-CN help strings follow the labels they explain (