[Decision] Do docs-site breadcrumb labels follow the console-navigation convention or the page titles? Three spellings currently point at the same page

[os-sales]

Raised by the repo:hotcrm PM seat, off an observation from #1125's R32 run. ⛔ Not dispatchable as filed — no convention exists to enforce, and inventing one is not a dev's call.

The observation

Docs-site breadcrumb link labels — the [Section › Page](/zh-Hant/docs/…) form used to cross-reference one docs page from another — are spelled inconsistently across zh-Hant pages while pointing at the identical target:

target	spellings in use
/zh-Hant/docs/administration/automation	[管理 › 自動化] ×5 · [Administration › Automation] ×4
the Extending Objects page	[Customization › Extending Objects] ×5 · [自訂 › 擴充物件] ×4 · [定制 › 擴展物件] ×3

⭐ Note the third row: 定制 › 擴展物件 is Simplified vocabulary in Traditional script — 定制 and 擴展 are the mainland word choices, where Taiwanese usage is 自訂 and 擴充. So one page's breadcrumb is neither the English form nor the Traditional form.

Why this is a ruling and not a cleanup

#1113 and #1368 settled that console navigation is labelled in English on zh-Hant pages, for a measured reason: the platform ships no Traditional pack, so the console falls back to Simplified, and a Traditional page names console paths in English rather than mix Simplified glyphs into Traditional prose.

⛔ That reason does not transfer. A docs-site breadcrumb does not name a console screen — it names another page of this documentation, which does exist in Traditional and whose own title: frontmatter is written in Traditional. The argument from "no Traditional pack" is silent here, and applying the console convention by analogy would mean a zh-Hant page linking to a zh-Hant page under an English label.

So there are two defensible conventions and the repo is currently running all three:

A — breadcrumbs follow the linked page's own title. [管理 › 自動化]. Internally consistent: the reader clicks through and sees that title. ⚠️ Means two different conventions live in adjacent sentences on the same page — English for console paths, Traditional for docs paths — which is exactly the "spelled two ways" complaint #1125 was filed about.

B — breadcrumbs follow the console convention, i.e. English. [Administration › Automation]. One rule for every X › Y form on the page, nothing to remember. ⚠️ Labels a Traditional page in English for a reader who is about to land on Traditional prose, and the measured reason for the console rule does not support it.

C — something narrower, e.g. English for sections that mirror console apps, Traditional for the rest. ⛔ The seat does not recommend this; a rule keyed on a distinction readers cannot see is how the current three-way split happened.

⚠️ Whichever is ruled, 定制 › 擴展物件 is wrong under all three — Simplified vocabulary in a Traditional page is not an option any convention endorses. That much can be fixed without a ruling if the maintainer prefers to split it out.

What is deliberately not being done

#1125's dev left guides/import-and-export.zh-Hant.mdx:163 [管理 › 設定] untouched on purpose, despite it being on a page that claim held exclusively and despite containing 設定. ⭐ That was the right call and the seat is recording it: it is a docs breadcrumb, not a console path, so #1368's ruling does not reach it and fixing it would have quietly established convention B by fait accompli.

If ruled

Scope is a sweep of every [… › …](…) breadcrumb across content/docs/**/*.zh-Hant.mdx (and ⚠️ the question applies to .zh-Hans.mdx too — the seat has not measured whether the same three-way split exists there, and whoever takes it must, rather than assuming symmetry). ⚠️ A guard is worth considering so the answer does not drift back, but ⛔ do not build one in the same PR as the sweep — the ledger-and-prose coupling on #1544 shows why that pairing wants its own round.

[os-sales]

⚠️ A landed ruling bears on this card and was not cited when it was filed — the seat found it while selecting the next dispatch batch.

#1329 was ruled A on 2026-08-31 (maintainer, verbatim 「其他同意」, via the director seat): Chinese docs pages spell the view-name column in zh-CN locale-pack translations, and zh-Hant follows the existing script-conversion convention. Option C — keeping the split — was excluded outright, with the reason stated as 「分裂本身即缺陷:语料教 AI「这列随便写」,守卫永久残废」.

What that does and does not settle here

⛔ It does not decide this card. #1329's subject is view names — labels the console renders through the locale pack. This card's subject is docs-site breadcrumbs — cross-references to other documentation pages. Different objects, and the seat is not treating a ruling on one as a ruling on the other.

⭐ But it establishes a principle that points at option A, and that principle is worth putting in front of whoever rules here:

Spell it the way the thing actually renders to that reader.

That is the stated basis for #1329 — 「屏幕上渲染的正是它,文档字符串可直接在界面搜到」 (it is exactly what renders on screen, so the doc string can be searched for directly in the UI). Applied to a docs breadcrumb, the thing being named is another documentation page, and that page's title does render in Traditional to a zh-Hant reader. ⇒ option A (breadcrumbs follow the linked page's own title) is the reading consistent with #1329; option B would name a Traditional page in English on the grounds that a different surface — the console — falls back to Simplified.

⇒ the apparent inconsistency the card describes ("two conventions in adjacent sentences on the same page") is not incoherence once #1329 and #1368 are read together. They partition cleanly:

what is being named	convention	why	ruled by
a console navigation path	English	no Traditional pack; console falls back to Simplified, so English avoids mixing scripts	#1368
a view name	zh-CN translation (zh-Hant: script-converted)	it is what the console renders, and the reader can search for it	#1329
a docs-site breadcrumb	⚠️ unruled — this card	the linked page renders in Traditional	—

⚠️ This does not shrink the card to a formality. A maintainer may well hold that one page should not carry two spelling conventions at all regardless of which surface each names, which is an argument for B that #1329 does not touch. The seat is recording the pull toward A, not asserting it.

One thing the card said that is now sharper: 定制 › 擴展物件 — Simplified vocabulary in Traditional script — is wrong under #1329 as well, since item 2 requires zh-Hant to be produced by script conversion of the zh-CN form, and 定制/擴展 are not the conversion of 自訂/擴充. ⇒ that one spelling is fixable under a landed ruling and does not need this card. ⛔ Still not a rider: #1329 is now in flight and holds content/docs/service/cases.*, marketing/campaigns.* and revenue/products.*, which is not where the breadcrumb sits.

---

Generated by Claude Code

[os-sales]

A third face of this question, measured during #1538 (PR #1560). ⛔ Not folded into this card's options — recorded because a ruling here will probably be read as covering it, and it should be ruled deliberately rather than by implication.

The zh-Hans surface contradicts itself about console paths

administration/sandbox-and-releases.zh-Hans.mdx:44   「**设置 → 云连接**」        fully localised
reference/performance-and-limits.zh-Hans.mdx:297     「设置里真正提供的是 **Setup → System Overview**」
                                                      Chinese prose, English path

⚠️ Note the second is the mirror image of the defect #1538 just fixed on the Traditional side — and on the Simplified side it may well be the wrong half that got fixed, because the reasoning differs:

• zh-Hant has no pack, the console falls back to Simplified, so English avoids mixing scripts (The zh-Hant navigation convention rests on a false reason: the console falls back to Simplified, not English #1368). Settled.
• zh-Hans has a pack. The console renders 设置 to that reader. So the [Decision] Should a Chinese docs page spell a view name in English or in its zh-CN translation? Five pages split two ways today, and no guard can be written until this is settled #1329 principle — 「屏幕上渲染的正是它，文档字符串可直接在界面搜到」, spell it the way it renders, so the reader can search for it — points at the localised form, i.e. sandbox-and-releases is right and performance-and-limits is wrong.

⭐ #1538's dev declined to file this, in its own words, because it "had no evidence that lets me call it either way" and would not file "a card on a coin flip." ⛔ The seat agrees it is not the dev's call, and is not making it either. Deriving a third surface's convention from two rulings that each addressed a different one is exactly the elaboration-is-not-the-ruling trap this lane has already paid for twice.

⚠️ But it is not quite a coin flip: rule 2 of the navigation guard resolves 设置 through APP_WORDS, so a fully localised zh-Hans path is checked today while an English path on a zh-Hans page is not. Whichever way this is ruled, one of those two lines is currently unguarded.

What the seat is asking for

⛔ Nothing added to this card's option list. Just: if the ruling here is meant to reach the zh-Hans console-path form, say so explicitly, because the three surfaces now in play are genuinely distinct —

surface	what is named	status
zh-Hant console navigation	a console path	ruled (#1368) — English
Chinese docs view-name column	a view label	ruled (#1329) — pack value
docs-site breadcrumbs	another docs page	this card
zh-Hans console navigation	a console path	⚠️ unruled, and self-contradictory today

---

Generated by Claude Code

[os-sales]

More measured data for the zh-Hans surface, from #1559's run (PR #1563). ⛔ No verdict offered — the dev declined one and the seat is not supplying one.

#1559 checked whether the zh-Hans siblings of the two pages it fixed carry the same shape. They do:

content/docs/administration/index.zh-Hans.mdx:40   - **设置 UI** —— 在齿轮图标下（右上角）找到它。…
content/docs/guides/integrations.zh-Hans.mdx:33    …另外八个是*概览*、*应用*、*人员与组织*、*访问控制*、*审批*、*配置*、*诊断*与*高级*…

⚠️ Reported, not fixed — on a Simplified page the console really does render Simplified, so this may be the convention working, which is exactly the question this card holds.

⭐ Three facts that sharpen the question, and one of them is a different defect

1. The zh-Hans roster does NOT carry the Traditional page's mistranslation. Its entry six is 配置, correctly distinct from 设置. So whatever is decided here, the zh-Hans roster is at least internally right in a way the zh-Hant one was not.
2. ⚠️ Its entry one is 概览, where the shipped zh-CN pack label is 总览.
3. ⚠️ The app label the zh-CN pack ships is 系统设置, not 设置.

⇒ items 2 and 3 are not the convention question this card asks. They are a pack mismatch: the zh-Hans page uses Chinese, which may well be right, but it uses the wrong Chinese — a term the pack does not ship. ⛔ That is a different defect class, and it would still be a defect under either answer to this card.

⭐ Worth noting because it changes what a "leave zh-Hans alone" ruling would mean: leaving the convention alone does not make those two strings correct.

Where the roster's nine labels actually come from — now measured at the source

#1559 reached the platform rather than inferring:

node_modules/@objectstack/platform-objects/dist/apps → SETUP_APP
  exactly nine type:'group' entries:
  group_overview · group_apps · group_people_org · group_access_control · group_approvals
  group_configuration · group_diagnostics · group_integrations · group_advanced

Four independent sources agreed on the same nine in the same order (the platform, the English twin, and the two landed zh-Hant rosters). ⭐ And the platform's own zh-CN pack labels group_configuration as 配置 and the Setup app as 系统设置 — which is what proves the Traditional 設定 at position six was never Configuration's name and never the app's. That is the trap PR #1537 flagged, now confirmed against the package rather than against a sibling page.

---

Generated by Claude Code