Skip to content

[观察] ja-JP 包内 convert 动词面自己分成两派：14 处「変換」对 4 处「取引開始」，同一次转化有两条不同措辞的成功提示 #858

Closed
#1079
Closed
[观察] ja-JP 包内 convert 动词面自己分成两派：14 处「変換」对 4 处「取引開始」，同一次转化有两条不同措辞的成功提示#858
#1079
Assignees
huangyiirene
Labels
metadataDeclarative metadata — schema, security posture, UI surfacespm:dispatchedDispatched to a dev agent by /pm-dispatch

Description

@yinlianghui
yinlianghui
opened on Aug 6, 2026

来源：#846（B1 收口 zh-CN 五处 help）要求的「四包复核」越界发现。基线 origin/main = 9d2c787。

#846 让我逐条复测 en / es-ES / ja-JP 的对应 help 串是否有同类孤例。结论是没有——那五处 help 在另外三个包里都跟各自的 label 一致（详见 #846 的 PR #859 body 四包对照表），所以 #846 只动了 zh-CN。但复测 ja-JP 的 convert 动词面时看到另一件事：ja-JP 包自己把 convert 分成了两派词，而 zh-CN / en / es-ES 三个包各自只有一派。

这不是 #846 的 help-vs-label 类型，所以 #846 的 B1 裁定（help 跟 label）给不出答案——这里打架的是两组 label 自己。故按去重纪律另立观察单，不排期。

证据（src/translations/ja-JP.ts，行号取自 9d2c787）

口径与复核命令：

grep -c "変換"   src/translations/ja-JP.ts   # 14
grep -c "取引開始" src/translations/ja-JP.ts   # 4

「変換」派 —— 14 处，含动作 label 本身：

行 键 值
:107 crm_account.name_normalized.help リード変換の照合キー
:385 crm_lead.company_normalized.help リード変換の照合キー
:408 converted_account 変換後の取引先
:409 converted_contact 変換後の取引先責任者
:410 converted_opportunity 変換後の商談
:411 converted_date 変換日
:476 crm_lead._sections.conversion 変換
:482 crm_lead._actions.convert_lead.label リード変換
:483 同上 .confirmText このリードを変換してもよろしいですか？
:484 同上 .successMessage リードの変換に成功しました！
:998 num_converted_leads 変換済リード数
:1095 crm_campaign_member.crm_lead.help 参加者がまだ変換されていないリードである場合に設定します
:1130 crm_campaign_member.status.converted 変換済
:1257 messages.confirm.convert_lead このリードを取引先・取引先責任者・商談に変換しますか？

「取引開始」派 —— 4 处：

行 键 值
:398 crm_lead.status.options.converted 取引開始済み
:403 crm_lead.is_converted.label 取引開始済み
:1255 messages.success.converted リードを取引開始しました
:1305 dashboards…open_leads.description 未取引開始のリード

注：:107 / :385 两条正是 #846 甲组在 ja-JP 的对应 help，它们跟 convert_lead.label「リード変換」逐字一致，在 #846 的口径下是合格的（help 跟 label）——列在这里只是为了把「変換」派点全。本条要记的是另一件事：这个 label 自己跟 is_converted 那组 label 不一致。

用户看得见的两个具体后果

  1. 同一次转化有两条措辞不同的成功提示：convert_lead.successMessage =「リードの変換に成功しました！」，messages.success.converted =「リードを取引開始しました」。同一个动作，两套说法。
  2. 动作与它写的那个字段对不上：用户点的按钮叫「リード変換」，它置位的字段却叫「取引開始済み」，列表里的状态值也是「取引開始済み」。日语读者没有简体中文那种「转化/转换」同源可猜的线索，変換 与 取引開始 是完全不同的两个词。

另外三个包都只有一派（对照）

包 动作 label 状态/字段 label 成功提示 一致？
zh-CN 转化线索 已转化 线索转化成功！/ 线索转化成功 ✅ 同一词
en Convert Lead Converted Lead converted successfully ✅ 同一词根
es-ES Convertir Prospecto Convertido Prospecto convertido con éxito ✅ 同一词根
ja-JP リード変換 取引開始済み 変換 / 取引開始 两条并存 ❌

为什么只记不改

收口需要先选一个词，而两个方向都说得通、代价不同，属于要维护者点头的译名决定：

  • 甲（统一到「変換」）：改 4 处，动作 label 是既有多数派（14 : 4），与其余三个包「同一词根贯穿」的构词一致。但「変換」在日语商务语境里偏技术义（数据变换），SFA 产品里 lead 的这一步通常说「商談化」「取引開始」。
  • 乙（统一到「取引開始」）：改面大得多，且要逐条判断哪些「変換」其实指别的机制（例如 crm_campaign_member.status.converted「変換済」是另一个对象的状态值，未必该跟着动）。业务语感更自然。

我倾向甲——理由是本仓已有的裁定口径是「跟 label / 跟包里的多数派」（#801/#825/#829/#846 一路如此），甲同时满足这两条；乙要另立一条「按目标语言业务惯用语重译」的口径，那是比本条大得多的决定。但这是日语母语者的判断，不该由实施 agent 替维护者定。

影响面

纯显示文本。不影响任何 value、不影响 os validate / lint / 测试——现有闸门没有任何一道检查同一语言包内的词汇一致性，这正是 #802 记的那道缺闸在包内的一面（#846 正文已指出「#802 管文档 vs 包，#846 是包 vs 包自己」，本条是同一缺闸的第三个实例：包内 label vs label）。

去重结论：搜过 open issues（关键词 ja-JP / 语言包 / 译名 / 词汇 / 转换）。#844 是文档侧 zh-Hant 的 convert 动词面，#846 是 zh-CN 的 help-vs-label，#837 是 crm_case 在中文文档里的三种叫法，#802 是缺闸本身，#760 是 tabs 标题拼法，#494 是 i18n 报警与坏 option key。没有一条覆盖 ja-JP 包内 label-vs-label 的词汇分派。

Refs #802 #846 #844

Activity

  1. yinlianghui
    added
    metadataDeclarative metadata — schema, security posture, UI surfaces
    finding
    on Aug 6, 2026
  2. yinlianghui
    changed the title [-][观察] ja-JP 包内 convert 动词面自己分成两派：13 处「変換」对 4 处「取引開始」，同一次转化有两条不同措辞的成功提示[/-] [+][观察] ja-JP 包内 convert 动词面自己分成两派：14 处「変換」对 4 处「取引開始」，同一次转化有两条不同措辞的成功提示[/+] on Aug 6, 2026
  3. yinlianghui
    added
    needs-user-decisionNeeds the maintainer's call before work proceeds
    and removed
    finding
    on Aug 6, 2026
  4. huangyiirene
    removed
    needs-user-decisionNeeds the maintainer's call before work proceeds
    on Aug 11, 2026

  5. huangyiirene commented on Aug 11, 2026

    @huangyiirene
    huangyiirene
    on Aug 11, 2026 – with Claude
    Collaborator

    Ruling (maintainer, 2026-08-11, PM chat, verbatim: 「接受你的全部建议」): Option 甲 — unify on 「変換」 (the 14:4 majority), consistent with the established follow-the-label/follow-the-majority ruling pattern. Option 乙 declined: it would open a new "retranslate by business idiom" precedent and require per-occurrence judgment of which 「変換」 means something else.

    Queued as a standalone S card (language-pack edit — deliberately NOT part of the docs-truth sweep #1063, different file class). Scope: the 4 「取引開始」 occurrences in ja-JP align to 「変換」; verify the two success messages for the same conversion end up identical.

    Generated by Claude Code

  6. huangyiirene
    added
    pm:dispatchedDispatched to a dev agent by /pm-dispatch
    on Aug 11, 2026
  7. huangyiirene
    self-assigned this
    on Aug 11, 2026

  8. huangyiirene commented on Aug 11, 2026

    @huangyiirene
    huangyiirene
    on Aug 11, 2026 – with Claude
    Collaborator

    Claim: PM loop round 5

    Session: session_01NM6o28jmBgsyTRQHutn7LC
    Branch: claude/issue-858-ja-jp-convert-verb
    Worktree: hotcrm-issue-858
    File surface: src/translations/ja-JP.ts (stop on breach; explain in the report)
    Container & model: S-grade mechanical (4 string values, correctness machine-checkable by grep counts + i18n lint), mode:subagent, model: sonnet
    Serial constraints cleared: src/translations/** was held by #740 — closed, PR #1077 merged (23aee256). #1061 also edits all four language packs and is therefore deliberately held out of this round, serialized behind this card.

    Ruling already recorded above (Option 甲 — unify on 「変換」); this dispatch implements it, it does not reopen it.

    Generated by Claude Code

  9. huangyiirene commented on Aug 11, 2026

    @huangyiirene
    huangyiirene
    on Aug 11, 2026 – with Claude
    Collaborator

    os-dev-report

    {
  "issue": 858,
  "status": "done",
  "branch": "claude/issue-858-ja-jp-convert-verb",
  "pr": "https://github.com/objectstack-ai/hotcrm/pull/1079",
  "premise_still_valid": true,
  "summary": "Verified the issue's premise on origin/main (e6e43be4): grep -c \"変換\" / \"取引開始\" over src/translations/ja-JP.ts read 14/4, matching the issue exactly (baseline 9d2c787a is stale but counts still hold). Read all 4 取引開始 occurrences in context; all four refer to the same crm_lead → convert_lead mechanism (status.options.converted, is_converted.label, messages['success.converted'], executive_dashboard open_leads.description) — none named a different business action. Aligned all 4 to 変換 per the maintainer's Option 甲 ruling, leaving the existing 14 変換 occurrences (including crm_campaign_member.status.options.converted, a different object) untouched. Post-edit counts: 変換=18, 取引開始=0.",
  "tests": "pnpm validate: exit 0, only pre-existing warnings unrelated to this change. pnpm lint (package.json's current script, still carries --skip-i18n as of this branch's origin/main — #1060 concurrently removing that flag, not this PR's doing): exit 0. npx objectstack lint WITHOUT --skip-i18n (real i18n coverage): exit 0, only pre-existing warnings, none touching the 4 edited keys. pnpm typecheck: exit 0, clean. node scripts/check-source-hygiene.mjs: clean (includes the repo's raw-control-byte scan). grep -rl \"取引開始\" over *.test.ts/*.spec.ts: zero hits before the change, so no test asserted the old strings. No new tests added — pure display-text change, no behavioral surface.",
  "open_questions": [],
  "out_of_scope_findings": []
}

    Generated by Claude Code

  10. huangyiirene commented on Aug 11, 2026

    @huangyiirene
    huangyiirene
    on Aug 11, 2026 – with Claude
    Collaborator

    ACCEPT — PR #1079 (claude/issue-858-ja-jp-convert-verb), reviewed against the PR itself rather than the report's self-description.

    What shipped: the 4 「取引開始」 occurrences in src/translations/ja-JP.ts aligned to 「変換」 per the Option 甲 ruling — crm_lead.status.options.converted, crm_lead.is_converted.label, messages['success.converted'], and the executive dashboard's open_leads.description. Counts 14→18 / 4→0. The existing 14 「変換」 were left alone as ruled, including crm_campaign_member.status.options.converted (a different object's status value, already on the majority side).

    Verified by the PM, not taken on trust:

    One judgment call worth recording, because it is the card's own acceptance criterion. The two success messages for one conversion now share the 変換 verb root but are not byte-identical: convert_lead.successMessage = 「リードの変換に成功しました！」 and messages['success.converted'] = 「リードを変換しました」. Rather than force them identical, the dev checked the other three packs and found the same shape there (en: Lead converted successfully! on the action vs Lead converted successfully in the message catalog). Convergence here therefore means "no longer two different verbs," which is what the issue actually reported. Accepted as the right reading.

    Useful side reading for #1060 (in flight): this dev additionally ran objectstack lint without --skip-i18n and got exit 0 with only pre-existing warnings. That is a second, independent data point that the i18n debt is zero at the rc.6 pin — #1060's own measurement remains the authoritative one.

    CI at review time: link-check, Check Changeset, Quality Checks, Label Pull Request, Vercel green; Build and Test (22.x), Playwright, and the CodeQL jobs still running. ⛔ Not flipped to ready yet — the ready-flip waits for those jobs' actual conclusions, not for the absence of a failure. PM owns the flip and the landing.

    Generated by Claude Code

  11. huangyiirene
    closed this as completedin #1079on Aug 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

metadataDeclarative metadata — schema, security posture, UI surfacespm:dispatchedDispatched to a dev agent by /pm-dispatch

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions