Change #1202869 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):

[mediawiki/extensions/CommunityRequests@master] PageDisplayHooks: add Codex message box with entity info on talk pages

https://gerrit.wikimedia.org/r/1202869

Change #1202869 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] PageDisplayHooks: add Codex message box with entity info on talk pages

https://gerrit.wikimedia.org/r/1202869

Can you extend this to subpages, page history, WhatLinksHere etc. (i.e. wherever there's wgRelevantPageName), and the Translations: namespace?

I've filed T410549 as a parent task and lumped some of the missing spots there.

What use for talk pages is a Codex message, as opposed to changing the actual <h1> displayed to the user. I think the concept is that users want the "Talk:" bit clearly shown. The Codex message component also leaves room to add more metadata for quick reference on talk pages, similar to https://www.wikidata.org/wiki/Template:Item_documentation .

I don't see a particular need to show entity tiles for subpages and the Translations namespace. The /Votes subpage could make sense, but it too like the Translations pages are not typically meant to be edited or even viewed directly.

@MusikAnimal Show Wish title on Talk page is displayed, as seen in screenshots and videos. I will mark this as Resolved. Thanks for all your work!

UPDATE: T406993#11393969

Test Result - Meta Beta

Status: ✅ PASS
Environment: Meta Beta
OS: macOS Tahoe 26.1
Browser: Chrome 142
Device: MBA
Emulated Device: NA

Test Artifact(s):
https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist
https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/FA1
https://meta.wikimedia.beta.wmcloud.org/wiki/Community_Wishlist/W26

Test Steps

Test Case 1: Display Wish Title and Proposer on Existing Wish Talk Page

1. Navigate to an existing wish talk page on the wiki.
2. Observe the top of the talk page.
3. ✅ AC1: Confirm that a message is shown at the top mentioning the entity title and proposer.

Desktop	Mobile

Test Case 2: Display Focus Area Title and Proposer on Existing Focus Area Talk Page

1. Navigate to an existing focus area talk page on the wiki.
2. Observe the top of the talk page.
3. ✅ AC2: Confirm that a message is shown at the top mentioning the focus area title and proposer.

Proposer does not show up
UPDATE: T406993#11393969

Desktop	Mobile

Test Case 3: Ensure Message Does Not Appear on Newly Created Talk Pages

1. Create a new talk page for a wish or focus area (if possible with current tooling).
2. Observe the top of the page.
3. ✅ AC3: Confirm that no message appears due to DiscussionTools limitations.

Test Case 4: Verify Message Placement

1. Open any existing wish or focus area talk page.
2. Scroll through the top portion of the page.
3. ✅ AC4: Confirm that the message appears at the top of the page before any discussion content.

Same as AC2 of the proposer not displaying
UPDATE: T406993#11393969

Wish: Desktop	Wish: Mobile	FA: Desktop	FA: Mobile

AC2/AC4: Focus areas don't have proposers.

Ok, you may want to update the task description of the AC since it says "When viewing an existing wish or focus area talk page, a message should be shown at the top mentioning the entity title and proposer"

I find the display both intrusive yet easy to miss, so I just did .ext-communityrequests-entity-talk-header { display: none; } and kept my script running on talks. The placement, color, padding, and verbosity (we all know it's a discussion, and who proposed it isn't particularly germane) all facilitate banner blindness. I didn't even notice it the first time. And once I did it was not easy on the eye. I think it should be more like a hatnote.

At the very least please get rid of "proposed by". It unduly emphasizes the submitter when wishes belong to no one but the community. In enwp's terms, it's WP:OWN.

Reviewers frequently want to ping the proposer, so mentioning it atop the talk page just making that process easier. I agree with the sentiment of WP:OWN in the Wishlist but I'm not certain it fully applies. We want every proposer to be able to express their desires as they intended. I think it's fine to fix typos and make other uncontroversial changes, but changing the meaning of a wish should seldom occur without consulting the proposer. Furthermore, there is historical precedent for this dating back to the initial annual survey in 2015.

The design is in conformance with Codex design principles, and was also inspired by how Wikidata handles it (T406993#11389685). If we want to make it closer to Wikidata and include more metadata, I think that would be great! I just didn't want to go crazy with this initial implementation.

The wish title should be shown for all visitors, not for reviewers. The implication of including "proposed by" affects all of them while the benefit you describe is relevant to only a handful. So the harm outweighs the benefit IMO.