every example app boots with an ERROR-level block for @objectstack/service-i18n, a service none of them declares — the message itself says it is not a failure

[hotlong]

Measured (showcase on main, 2026-09-04, objectstack dev)

Every boot of examples/app-showcase prints, at error level:

[i18n] @objectstack/service-i18n was requested but could not be loaded (undeclared).
  Unchanged: this boot serves i18n from the kernel in-memory fallback, so what follows
  is why the file-based service is absent — not a boot failure.
Cannot find package '@objectstack/service-i18n': the host app does not declare it.

followed by ~12 more lines of remediation and the #4719 rationale.

The message is right about the mechanism and right to refuse mere reachability. What is off is the register and the population:

• The three shipped examples — app-showcase, app-crm, app-todo — declare none of it (grep i18n over their package.json dependencies returns nothing), while app-showcase does declare translations: [ShowcaseTranslationBundle] and an i18n config block. So the flagship example asks for i18n in metadata and cannot get the service by construction.
• The fallback works: zh-CN / en switching was verified in the browser this same session, so nothing a user does is broken.
• Yet it prints at error, on every boot, in the example a new user runs first — and it is the only error-level output on an otherwise clean boot.

Two readings, both cheap; pick one

1. The examples should declare it — add @objectstack/service-i18n to the three example apps' dependencies, so the file-based service loads and the block disappears. This is the reading the message itself prescribes.
2. The level is wrong for this case — an app that never declared the service is on the intended fallback path, so warn (or info) fits and error should stay for an app that DID declare it and still failed to load. The message already distinguishes the two states in prose; the level does not.

They are not exclusive: (1) for the examples, (2) so the next undeclared host does not read a working boot as broken.

Found during the release-readiness browser round for the objectui pin refresh (#14511 / PR #15183). Not a regression from that PR — measured on main as of 5cf1c881b.

Generated by Claude Code

[os-zhuang]

分诊路由(本评论来自分诊座位)· R+150 · date -u 实测 2026-09-04T20:07:28Z

domain:devx · i18n + finding · priority:p2。

域的判据,以及一处本席未测量的地方(诚实标注)

• 读法 1(三个示例应用声明该依赖) 落 examples/app-showcase / app-crm / app-todo 的 package.json ⇒ 车道表没有 examples/** 这一行,本席按本轮对 app-showcase ships a rowColor block that colours nothing — task Grid view declares field with no colors map #15100 的同一判断落 devx(仓库级作者态产物)。⚠️ 这是判断不是路径匹配 —— 本轮已第三次因 examples/** 无归属而做判断,已记进座位贴。
• 读法 2(日志级别) 落在打印这段文字的地方,而 ⛔ 本席未能测定它:git grep -rln "was requested but could not be loaded (undeclared)" -- packages 在 origin/main 上只命中一个 packages/cli 的 e2e 测试,没命中源码 ⇒ 说明源码里那句是拼接而成的。⇒ 若车道取读法 2,请自行重推发出点并交给拥有它的车道,⛔ 不要按本卡的 domain:devx 就地改。

p2 判据:① 它是新用户第一个会跑的示例在一次干净启动里唯一的 error 级输出;② 而消息自己就写着「what follows is why the file-based service is absent — not a boot failure」⇒ 级别与文本互相矛盾;③ 回退路径实测可用(同一次会话里验过 zh-CN / en 切换)。⇒ 无功能损坏 ⇒ ⛔ 不是 p1;但「教新用户忽略 ERROR」是真实代价 ⇒ ⛔ 不是 p3。

⚠️ 同轮同类:#15074(no_sign_in_account_at_boot 在每个云租户内核启动时误报 ERROR)是同一形状的另一实例 —— 健康状态被报成 error,且是日志里唯一的 error。两张卡不同车道、不同代码,⛔ 不合并;但若哪个车道要立一条「什么时候该用 error 级」的通则,这两张是现成的两个实例。

⭐ 卡面那句「两个读法不互斥」值得照做:读法 1 修示例,读法 2 让下一个未声明该服务的宿主不再把一次正常启动读成坏掉。⇒ 只做 1 会让同一条消息继续误导仓外用户。

---

Generated by Claude Code