A more scalable approach would be a parser function that returns the specified property given a wish or focus area number, e.g. {{#CommunityRequests:link|W123}} returns the title, {{#CommunityRequests:link|W123|status}} (or {{#CommunityRequests:link|id=W123|prop=status}}) returns the status, and so on. Then a template can be created e.g. [[Special:MyLanguage/Community Requests/{{1}}}|{{{1}}}: {{#CommunityRequests:link|{{{1}}}}}]]. That way each editor can use whatever markup.

That's a good idea, although perhaps the call should just be called data rather than link in that case.

The fields that can be provided are status, focus_area (for wishes), vote_count, title, and title_lang.

Just a minor note: it would be great if links to phab code issues linked like [[phab:Tid]] across the Wikimedia projects (such as here) would also show the issue title, for example when hovering over the link. This is pretty similar to what's suggested here but since phab is not a wiki, it may not be readily possible and if it is possible probably in a quite different way than for wishes. If however there is a way to implement this, please let me know so a separate issue can be created.

I've often wondered why we don't have the ability to do that, it'd be really useful! There are some gadgets that do it, but really we should make a proper extension. As it's something that'd be useful on all wikis, it probably doesn't make sense to build it into CommunityRequests.

Sounds like a good wish :)

There should also be a parser function to retrieve the vote count for a particular wish or area.

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

[mediawiki/extensions/CommunityRequests@master] EntityDataRenderer: Parser function to retrieve data for an entity

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

Change #1198675 merged by jenkins-bot:

[mediawiki/extensions/CommunityRequests@master] EntityDataRenderer: Parser function to retrieve data for an entity

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

Here's the docs, which hopefully is enough for QA: https://www.mediawiki.org/wiki/Help:Extension:CommunityRequests#Data_parser_function

@MusikAnimal: The confirmed parser function to retrieve data, as mentioned in the Description, works properly, as seen in the screenshots and videos below. I will move this to Sign-off. Thanks for all your work!

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):

Test Steps

Test Case 1: Parser function returns correct data for a wish entity

1. On the beta wiki, create or locate a test wish entity (e.g., with ID “W123”).
2. Edit a talk page and insert the parser function: {{#CommunityRequests:Data|wish=W26}| field= <field name> }}.
3. Save the page and review the rendered output.
4. ✅AC1: Confirm the output shows the correct status, focus_area, proposer, vote_count, title, title_lang of the wish.

Wish Edit with form W26	Wish- Page info W26	Focus Area- Page info FA12

Status	Focus Area	Proposer	Vote Count	Title	Title Lang

Test Case 2: Error handling and invalid input

1. Insert the parser function with a non-existent ID: {{#CommunityRequests:Data|wish=W999999}}.
2. Save the page and review the rendered output.
3. ✅ AC2: Confirm the output shows a meaningful error or fallback message (e.g., “Wish W999999 not found”).

4. Insert the parser function with missing parameters: {{#CommunityRequests:Data}}.
5. Save the page and review the output.
6. ✅ AC3: Confirm the output shows a meaningful usage or error message indicating that either ‘wish’ or ‘focusarea’ parameter is required.

Test Case 3: Performance / caching behavior

1. On the sandbox page for a wish using the parser function, open browser dev tools and clear cache.
2. Reload the page and measure load time for the parser output.
3. Modify the underlying wish (e.g., change title or vote count).
4. Reload the page again.
5. ✅AC4: Confirm the updated data appears in the parser function output without excessive caching delays (within acceptable thresholds e.g., < 2s).