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

[yinlianghui]

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 #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.

[os-zhuang]

分诊:补 pm:queue(既有 repo:objectui 路由沿用,此前只有路由半边、缺分类半边)。

落点:objectui 记录详情页活动流(audit feed)渲染器,两处独立缺失 —— 字段标签未走同页已在用的翻译文档、lookup 新值未走既有 display resolver(详情 chip 同字段解析正常)。应用侧无任何可作者化元数据可绕,只能修渲染器。查重:与 #5076 同形(渲染器读 authored 元数据而非翻译文档)不同面,正文区分成立。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-zhuang]

Migrated to objectstack-ai/objectui#4055 under #7167 (file-at-destination ruling, maintainer 2026-08-10). Native GitHub issue transfer is not available to this session's credential, so the card was recreated at the destination; this thread stays as the authoritative history and is linked from the new card. Closing as not planned here — moved, not rejected.

---

Generated by Claude Code