Part of objectstack-ai/hotcrm#1004
下游应用(hotcrm,平台依赖 @objectstack/* 17.0.0-rc.3)在修复过程中发现:页面组件的用户可见文案(卡片标题、卡片描述、KPI 块 label)在翻译契约里没有任何键位,zh/ja/es 语言包写不进去(strict 拒收),运行时也无处可读——而同一契约里形状几乎相同的 dashboards.widgets 是有翻译面的。
契约现状(rc.3)
node_modules/@objectstack/spec/dist/translation.zod-*.d.ts:
pages: Record( name, { label?, description?, title?, subtitle? } ) // .strict()
- 四个键、
.strict()——任何额外键都被拒; title / subtitle 的语义是 page:header(header 实例没有稳定 id,页面名是唯一能够到它的键;下游 test/i18n-references.test.ts 的注释与断言均按此口径);- 于是
page:header 以外的组件文案没有翻译位,值链是 *.page.ts 字面量直通 dist/objectstack.json。
不对称证据
同一契约中仪表盘组件有翻译面:
dashboards: Record( name, { label?, description?, actions?, widgets? } )
widgets: Record( id, { title?, description? } ) // 按 id 定位
widget 按 id 定位即可翻 title/description;page 的组件同样有稳定 id(ai_briefing、kpi_revenue_won …),却没有对应的 components 面。两棵几乎同形的 UI 组件树,一个能翻一个不能——更像 spec 侧缺一个面,而非下游用法问题。
下游实测面(从 dist 产物统计,非源码 grep;基线 hotcrm main = 86010ffb)
8 个页面,12 处用户可见英文字符串在 zh/ja/es 下无法本地化:
sales_home_page (10)
quick_create.title "Quick Create"
my_recent_items.title "Recent Items"
key_metrics.title "Key Performance Indicators"
kpi_revenue_won.label "Revenue (Won)"
kpi_deals_won.label "Deals Won"
kpi_pipeline_value.label "Pipeline Value"
kpi_open_leads.label "Open Leads"
ai_briefing.title "Ask the AI Assistant"
ai_briefing.description "Open the assistant panel from the right edge …"
upcoming_events.title "Today's Schedule"
lead_detail_page (1)
related_tasks.title "Open Tasks"
utility_bar_page (1)
quick_notes.title "Quick Notes"
sales_home_page 是 isDefault: true、发给 sales_rep / sales_manager 的落地页:zh-CN 用户登录后页头是「销售看板 / 欢迎回来,…」(有翻译位),同屏的四张卡片、四个 KPI 块全是英文。
建议方向
给 pages 补组件面,与 dashboards.widgets 对齐,例如:
pages: Record( name, { label?, description?, title?, subtitle?,
components?: Record( id, { title?, description?, label?, help? } ) } )
(键面按 spec 侧实际组件模型定;下游诉求只是「有稳定 id 的页面组件的用户可见文案要有翻译位」。)
关联(下游侧)
Part of objectstack-ai/hotcrm#1004
下游应用(hotcrm,平台依赖
@objectstack/* 17.0.0-rc.3)在修复过程中发现:页面组件的用户可见文案(卡片标题、卡片描述、KPI 块 label)在翻译契约里没有任何键位,zh/ja/es 语言包写不进去(strict 拒收),运行时也无处可读——而同一契约里形状几乎相同的dashboards.widgets是有翻译面的。契约现状(rc.3)
node_modules/@objectstack/spec/dist/translation.zod-*.d.ts:.strict()——任何额外键都被拒;title/subtitle的语义是page:header(header 实例没有稳定 id,页面名是唯一能够到它的键;下游test/i18n-references.test.ts的注释与断言均按此口径);page:header以外的组件文案没有翻译位,值链是*.page.ts字面量直通dist/objectstack.json。不对称证据
同一契约中仪表盘组件有翻译面:
widget 按
id定位即可翻 title/description;page 的组件同样有稳定id(ai_briefing、kpi_revenue_won…),却没有对应的components面。两棵几乎同形的 UI 组件树,一个能翻一个不能——更像 spec 侧缺一个面,而非下游用法问题。下游实测面(从 dist 产物统计,非源码 grep;基线 hotcrm main = 86010ffb)
8 个页面,12 处用户可见英文字符串在 zh/ja/es 下无法本地化:
sales_home_page是isDefault: true、发给 sales_rep / sales_manager 的落地页:zh-CN 用户登录后页头是「销售看板 / 欢迎回来,…」(有翻译位),同屏的四张卡片、四个 KPI 块全是英文。建议方向
给
pages补组件面,与dashboards.widgets对齐,例如:(键面按 spec 侧实际组件模型定;下游诉求只是「有稳定 id 的页面组件的用户可见文案要有翻译位」。)
关联(下游侧)
tabs[].label同样无翻译位——两条合起来说明「无翻译位」不是个别键遗漏)