Format links to items or properties in edit summaries with labels

[lucaswerkmeister]

Wikibase augments MediaWiki’s default edit summary rendering in order to render links to items and properties with their label, so that, for example, the edit summary

[[Property:P2694]] statement: replace [[Property:P1327]] qualifier with [[Property:P4070]] ([[:toollabs:editgroups/b/CB/6abd6a71a977|details]])"

is rendered like this (if the interface language is English):

ISU figure skater ID (P2694) statement: replace professional or sports partner (P1327) qualifier with identifier shared with (P4070) (details)

EditGroups doesn’t do this yet: on the group detail page, the same summary looks like this:

Property:P2694 statement: replace Property:P1327 qualifier with Property:P4070 (details)

It would be neat if EditGroups had the same feature to make the summaries more readable :)

[wetneb]

@lucaswerkmeister I have been wanting to do this for a while. Do you know if there is an estblished way to do this in third-party tools? I would be tempted to just add some javascript to do this rendering client-side, ideally via some efficient API calls.

[lucaswerkmeister]

Hm, I was going to suggest action=query&prop=revision&rvprop=parsedcomment&revids=IDs, but apparently that doesn’t apply the same transformation?

That almost feels like a bug, to be honest.

[wetneb]

Thanks! But that would need to take the language as a parameter somewhere, right? I can't see where it is…

One thing I have noticed is that the parsed comments returned via the EventStream are localized using the locale selected by the user making the edit. If we can do this rendering in EditGroup's frontend instead, it would make it possible to adapt it to the locales of our users.

[lucaswerkmeister]

uselang=CODE should be supported by all API requests. (In the API sandbox, the parameter is in the “main” section, because it’s not specific to the query or revision APIs.)

[wetneb]

Ah, makes sense, thanks.

[wetneb]

This should now be much easier thanks to the new API module:
https://lists.wikimedia.org/pipermail/wikidata-tech/2018-December/001356.html

[wetneb]

@lucaswerkmeister Thanks again for implementing wbformatentities. I have added UI-side support for this with a simple jQuery script:
https://github.com/Wikidata/editgroups/blob/master/editgroups/static/js/render-entity-values.js
Ideally this could be made reusable so that other tools can do similar things. My JavaScript quite naive so I am sure there are ways to improve it. At least it should do as few API queries it can.

Also, not all entities are rendered yet - only those which were already rendered in their own <a> tag. This is not the case for entities mentioned in batch summaries (as raw summaries are raw wikicode). It is not entirely clear to me what is the right solution for these. In the batch list, batch summaries are currently links (to the batch page) so we do not want the entities ids in them to be links. The wbformatentities API can probably still be used, but we will need to manually replace the containing <a> tags in the rendered results.

This still needs to be localized (#9). It is not hard to do but I have not enabled it yet as the rest of the UI is not localized either.

[wetneb]

@lucaswerkmeister by the way, I just noticed that wbformatentities renders entities without appending the entity id at the end of the label: P31 is rendered as instance of whereas they would be rendered instance of (P31) in the history, contributions or recent changes on Wikidata. (It's obviously fine like that, it is just not identical.)

[lucaswerkmeister]

Yes, it renders entities like they’re rendered in statement values, not as in edit summaries.