Should Wikibase be using a Linker hook or something for this? So it works in all of the UI?

Now that additional links were removed from the notifications, my idea is obsolete...

What about having an optional interface message for the titles which would by default be "$1" and on Wikidata could be changed to "{{label|$1}}"? (Otherwise some hooks are needed.)

Not sure if I need to make another task, but there are also other notifications showing a Q id.

Yes, showing just the Q number is not very useful in most cases - it would be good to add label and perhaps description if these are available in the relevant language.

And yes, this should not just apply to revert notifications but to notifications on Wikidata more generally.

We discussed this with the team earlier this week.

On a technical note (from me): this would require some Echo work to allow Wikibase to plug in and change how titles are rendered in notifications. I'm not sure offhand how that would be done, maybe through a hook. But I'm assuming that Wikibase already has a utility to get the display label of a given QID in a given language, in which case the hardest part of this task is figuring out how to cleanly integrate this into Echo (or rather, let Wikibase hook into Echo) without making the code in Echo overly Wikibase-specific/dependent.

On a product/planning note (from @MMiller_WMF): How important is this in the scheme of things that are being worked on for Wikidata? Our team is pretty busy, so we want to figure out what to do here.

In T116762#4874473, @Catrope wrote:

On a product/planning note (from @MMiller_WMF): How important is this in the scheme of things that are being worked on for Wikidata? Our team is pretty busy, so we want to figure out what to do here.

I think it's not super critical on Wikidata itself. People there are used to the IDs and it's mainly an annoyance to have to take an additional step to figure out what's behind the ID. The picture changes for me when we're also showing IDs in notifications we're showing to Wikipedians because they are not as familiar with them. I'm not sure if we do have this issue right now as I don't remember the exact texts. There is one for example where we notify an editor about an article they created being connected to an item. It will become much more of a problem later this year when we start working on allowing editing of Wikidata directly from within the other projects.

Thanks, @Lydia_Pintscher. I'm going to triage this to Growth's "Q4" column, which means we will re-triage it again in April, and consider it as a task for Q4. Please let us know if something changes on your end, or if you all get to this task first.

We are moving this task to External on our board as we believe Wikidata should work on it in parallel with T223686

So this and T223686 are both slightly different.

This task requires work to go into echo first to allow extensions to plug in and optionally format page titles / change the way they are displayed, as described in T116762#4874473.
The other task requires echo to allow extensions to plug in and optionally format edit summaries / change the way they are displayed.

I'm not 100% sure if the Wikidata teams should be poking around in echo too much when another team technically owns it though?
But perhaps a discussion has happened elsewhere that decided that we should do the whole thing? (not sure if I missed something)

In T116762#4875193, @Lydia_Pintscher wrote:

I think it's not super critical on Wikidata itself. People there are used to the IDs and it's mainly an annoyance to have to take an additional step to figure out what's behind the ID. The picture changes for me when we're also showing IDs in notifications we're showing to Wikipedians because they are not as familiar with them.

I guess technically these messages do appear on wikipedias and other sites as we have global notifications!

For example, if I scroll through my read notifications:

In T116762#5251929, @Addshore wrote:

I guess technically these messages do appear on wikipedias and other sites as we have global notifications!

This is more than just technically true. Every day I start on my Wikimedia activities on my svwiki watch list and have a dropdown like this:

I can't be expected to be able to make an informed decision based on the q-id's. It would be useful with the labels to at least have a chance to know whether these seem to make sense or not and if I should further inspect them.

I started on a userscript that could show the labels instead of QIDs but was unable to get it to work and kind of gave up. Here's the link if anyone would like to try to get it to work: https://www.wikidata.org/wiki/User:Lectrician1/WikibaseEcho.js

I forked @Lectrician1's userscript and made a first working version: https://www.wikidata.org/wiki/User:Zvpunry/WikibaseEcho.js

So far, I've tested it with the "A link was made from Q218728 to Q202886." notification. That kind of notification should now read after a few seconds: "A link was made from Shire (Q218728) to Mordor (Q202886)."

Let me know what you think 🙂

I think: 💯

Please add it to https://www.wikidata.org/wiki/Wikidata:Tools/Enhance_user_interface!

Ok, I did some investigation as to how entity page links on Wikibase wikis on your watchlist, Q templates, and other special pages currently render. Wikibase uses the https://www.mediawiki.org/wiki/Manual:Hooks/HtmlPageLinkRendererEnd hook to output a new title link that will be in the label and QID of the entity page if the page link requested is an entity page and is not an API request or non-Special page.

However, we don't need a HTML page link to output for an Echo notification. We just need the page title in the form of "<entity label> (<entity ID>)" as a string. To get this, we can use the same methods that Wikibase's HtmlPageLinkRendererEnd currently uses to output the entity label and ID. How should we implement this technically though? Should we make a RenderPageTitle Mediawiki hook for Wikibase to use?

Actually, what would be easier to implement and what would also make more sense from a UX perspective is if we changed the presentation model of Echo page notifications so that individual page names are links inside of the notification and not strings. That way we can use the current LinkRenderer which fires the HtmlPageLinkRendererEnd hook to render the page names as labels in the correct language.

I have filled a separate task proposing this change: T324848

Change 870732 had a related patch set uploaded (by Lectrician1; author: Lectrician1):

[mediawiki/extensions/Echo@master] Change notification page names to links

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

Change 874030 had a related patch set uploaded (by Lectrician1; author: Lectrician1):

[mediawiki/extensions/Wikibase@master] Output entity labels for page links API requests

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

2023 sprint 1 note - if review shows the patch is not ready, pass back to author and remove from sprint

@karapayneWMDE FYI the Growth team may not find the implementation I made to be be suitable as it makes the page names inside of notifications links instead of strings. In the past, Echo used to have links for page names in notifications but that was removed. I personally find benefits though to having links instead of strings though.

If you need me to create an implementation that does output strings instead of links, I can create a new MediaWiki hook for when the the string title of a page is retrieved that Wikibase can then modify to output the label of the entity page instead. I just need to know if that's what you need me to do - or some other implementation you come up with.

Also, tests have not been added on the Echo change yet as I don't know if this patch is good, but I'll add them when you let me know it's okay.

In T116762#8493231, @gerritbot wrote:

Change 874030 had a related patch set uploaded (by Lectrician1; author: Lectrician1):

[mediawiki/extensions/Wikibase@master] Output entity labels for page links API requests

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

Note that this wouldn’t just affect Echo: Wikibase would add entity labels to links in edit summaries whenever API requests return edit summaries. For example, if you get the edit summary of this edit using this API request, it currently looks like this:

‎<span dir="auto"><span class="autocomment">Changed claim: </span></span> <a href="/wiki/Property:P460" title="Property:P460">Property:P460</a>: <a href="/wiki/Q112795079" title="Q112795079">Q112795079</a>

‎Changed claim: Property:P460: Q112795079

With the change, it would look like this:

<span dir="auto"><span class="autocomment">Changed claim: </span></span> <a href="/wiki/Property:P460" title="‎said to be the same as‎ | ‎this item is said to be the same as that item, but it's uncertain or disputed‎"><span class="wb-itemlink"><span class="wb-itemlink-label" dir="ltr" lang="en">said to be the same as</span> <span class="wb-itemlink-id">(P460)</span></span></a>: <a href="/wiki/Q112795079" title="‎Wikidata Sandbox 4‎ | ‎sandbox for testing‎"><span class="wb-itemlink"><span class="wb-itemlink-label" dir="ltr" lang="en">Wikidata Sandbox 4</span> <span class="wb-itemlink-id">(Q112795079)</span></span></a>

Changed claim: said to be the same as (P460): Wikidata Sandbox 4 (Q112795079)

(Note that the “rendered” representation is pretty incomplete due to Phabricator limitations.) Is this something we want? (IMHO this could be considered a significant change according to the stable interface policy.)

Is this something we want? (IMHO this could be considered a significant change according to the stable interface policy.)

Decision from a call with Lydia: Yes, we want to do this; tracked at T327062: Show entity labels in parsed edit summaries in API requests as well.

Moving to Waiting until we’ve implemented T327062 (with feature flag) and decided when to announce and deploy the change.

Change 870732 abandoned by Lectrician1:

[mediawiki/extensions/Echo@master] Change notification page names to links

Reason:

Uh yeah this ain't happening

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

It looks like although the updates have been made to show entity labels in parsed edit summaries in API requests: T327062

There is still a piece missing here for Echo. Here is a screenshot of a recent notification:

This appears to not be stalled.