Record activity feed prints the untranslated English field label and the raw lookup ID (`Rating Owner: ∅ → oBK25BVuz…`)

[os-zhuang]

Migrated from objectstack-ai/objectstack#5142 under the file-at-destination ruling (objectstack-ai/objectstack#7167, maintainer 2026-08-10). Originally filed 2026-08-04T06:03:01Z. The full prior thread — including triage rulings and hold/restart conditions — remains on the source issue and MUST be read before acting on this card.

---

Summary

The record detail page's activity feed (「讨论」 → 「全部动态」) renders field-change entries with

• the field's English label, ignoring the translation bundle that the rest of the same page honours, and
• the raw lookup ID as the new value, where every other surface on that page renders the user's display name.

Both halves are visible on the demo route of a Chinese deployment, at the bottom of a screen that is otherwise entirely Chinese.

Evidence

@objectstack/* 17.0.0-rc.1, fresh database, browser locale zh-CN, admin user.

Customer-rating detail page, one screen, DOM text:

评级概览
  评级编号        RT-2025-0003
  评级负责人      Dev Admin          ← same field, translated label + resolved name
…
所有者           Dev Admin
讨论 (1)
全部动态
  系统  2分钟前
  Rating Owner: ∅ → oBK25BVuzyGBLkdUXD8M7pnYR62WyBbQ   ← feed entry

The account detail page shows the identical pattern for its own owner field:

Account Owner: ∅ → oBK25BVuzyGBLkdUXD8M7pnYR62WyBbQ

So on one page the same field appears twice: once as 「评级负责人 / Dev Admin」 (correct) and once as Rating Owner: ∅ → oBK25… (wrong on both counts).

Mechanism

Two independent misses in the feed renderer:

1. Label. objects.crm_customer_rating.fields.owner.label is 评级负责人 in the zh-CN bundle and resolves correctly everywhere else — the detail section, the list column, the form. We verified against /api/v1/meta/object/crm_customer_rating under Accept-Language: zh-CN: the served label is 评级负责人. The feed is using the object's authored English label (Rating Owner) rather than the translated document.

2. Value. The field is Field.lookup('sys_user', …). The detail chip resolves it to Dev Admin; the feed prints the stored ID verbatim. A 32-character opaque string is not a change description a user can read, in any locale.

The ∅ → arrow notation for "was empty" is fine and readable — it is only the two operands that are wrong.

Why an app cannot work around it

The feed is rendered entirely by the console from the audit trail. There is no authorable metadata for it: no key in TranslationData targets feed entries, and there is no per-object switch for how a lookup change is formatted. Nothing in the app's translation bundle, object definition or page definition reaches these strings.

Suggested fix

1. Resolve the field label from the same translated object document the detail page already uses, instead of the raw authored label.
2. Render lookup values through the existing lookup display resolver (the one the detail chip uses) so the feed shows Dev Admin, falling back to the ID only when the referenced record cannot be resolved.

Related

• Analytics surfaces resolve select-option labels but never apply the i18n bundle — reports and dashboards show English while lists and forms show the translation objectstack#5076 — analytics surfaces resolve option labels but skip the i18n bundle. Same shape of defect (a renderer reading authored metadata instead of the translated document) on a different surface.

Filed from a downstream app (hotcrm-heimao), tracked there as issue #60.

[yinlianghui]

Claim: PM loop round 2 (objectui whole-repo seat — queue fill per the maintainer's 2026-08-10 five-concurrent directive)
Session: session_017Qqyix2QcnpUC9XeYVDzx3
Branch: claude/issue-4055-activity-feed-i18n-lookup
Worktree: objectui-issue-4055
Domain: repo:objectui (whole-repo seat)
File surface: the record activity/audit feed renderer in app-shell (the component rendering 「全部动态」 field-change entries) + tests. ⛔ Region-exclusive vs in-flight siblings: not the create-dialog/form-seeding path (#4047), not GridField* (#3569 branch), not containers.tsx (#4027), not packages/cli (#4061/#4062), not packages/fields packaging (#4059).
Container & model: M, mode:subagent, model: opus
Serial constraints cleared: no open claim or PR on the activity-feed path; #3055 (approvals entry points, which touches the record detail page) is pm:on-hold per the maintainer's 2026-08-10 pause — this card must not absorb its scope.

Source triage (objectstack#5142, 2026-08-05): renderer-level fix, two independent misses (label not read from the translated object document the same page already uses; lookup new-value not run through the existing display resolver); no authorable workaround exists. No holds or rulings on the source thread.

---

Generated by Claude Code

[yinlianghui]

Re-routed to objectstack-ai/objectstack#7230 — closing here (moved, not rejected). objectui seat PM, session session_017Qqyix2QcnpUC9XeYVDzx3, 2026-08-10.

The dispatched dev's premise-first verification falsified the card's Mechanism section and the 2026-08-05 "renderer-level fix" triage ruling: the string Rating Owner: ∅ → oBK25… is composed server-side at write time by @objectstack/plugin-audit (audit-writers.ts:330 / :308; single call site :882 passes no translator while all three sibling branches do) and persisted into sys_activity.summary; objectui renders that column verbatim (RecordDetailView.tsx:1482 → RecordActivityTimeline.tsx:473-477). The ∅ glyph does not occur anywhere in objectui's feed path. There is no correct-by-construction objectui fix — a client-side re-composition would compensate one of four consumer surfaces and silently redefine the summary column's contract.

Both halves of the defect and the full evidence are recorded on the transfer card. The 2026-08-10 file-at-destination migration (objectstack#5142 → here) was made in good faith on the card's own mechanism claim; the measurement supersedes it — the file-at-destination is objectstack.

Verdict on this dispatch: premise_still_valid: false with zero files touched is the process working — logged as a successful run, not a failure. Claim released with this close.

---

Generated by Claude Code