Hm, any ideas how to do that? Which APIs should be used for that and based on which conditions? I suppose it should be related to different content model?

Interesting links:
https://www.wikidata.org/wiki/Special:EntityData/Q23240.json also works for properties https://www.wikidata.org/wiki/Special:EntityData/P30.json, contains labels and description of the element
https://tools.wmflabs.org/pltools/rech/ interesting tool

In T199500#4422234, @Petrb wrote:

Hm, any ideas how to do that? Which APIs should be used for that and based on which conditions? I suppose it should be related to different content model?

General Wikidata API call can be used, e.g.:
https://www.wikidata.org/w/api.php?action=wbgetentities&format=xml&props=labels|descriptions&ids=Q42
or
https://www.wikidata.org/w/api.php?action=wbgetentities&format=json&props=labels|descriptions&ids=Q42

I think part of the reason Wikidata isn't patrolled as much is tools like Huggle don't play as nicely with it. If we had human-readable labels in our diff view, it would be much easier to quickly judge the veracity of the change. Right now I usually have to open up the diff on-wiki every time in order to draw any conclusions.

It would be great if summaries were human-readable too (perhaps deserving of a dedicated ticket?). For instance "/* wbsetsitelink-add:1|zhwiki */" should be "‎Added link to [zhwiki]" just like it is on the wiki. I imagine this is easy-ish to implement since I assume we're already using the API when displaying diffs. E.g. for the aforementioned example you could use https://www.wikidata.org/w/api.php?action=compare&fromrev=1146817510&torelative=prev&prop=parsedcomment|diff (where parsedcomment is the summary).

but is that something very specific only to wikidata? I am not sure if there is parsedcomment in other wikis? Or is there?

If these things are all wikidata related I would have to create a new extension dedicated for wikidata only, it would help if I at least knew which API calls to use and where to get the data you want to see, also for example give me a comparison of what Huggle is giving you now and what you want it to give you. I know very little about wikidata.

Wikibase is used other places too, such as Commons (compare the comment vs parsedcomment): https://commons.wikimedia.org/w/api.php?action=compare&fromrev=408380417&torelative=prev&prop=comment|parsedcomment|diff, and perhaps other situations as well. But I think it may make sense to show parsedcomments for all wikis, such that they are displayed as HTML, not wikitext. For instance instead of "[[WP:AES|←]] Created page with [[Foobar]] lorem ipsum" you'd see "← Created page with Foobar lorem ipsum". That would be pretty neat!

For Wikidata specifically, the more pressing issue is the lack of having human-readable labels and descriptions. That could be solvable by using wbgetentities API (T199500#4478716). As far as I know this problem is unique to Wikidata, so yes that might have to be an extension to Huggle, as you say.

I see

In that case if parsedcomment is native MW API property that is available everywhere (not just wikidata) then yes, I can implement this in Huggle, as optional feature (I think most of powerusers prefer summary in wikitext over parsed HTML), but it's reasonable feature request.

Regarding other improvements for wikidata - as I said, I really don't know much about it, when you talk about wbgetentities or entities, I have no idea what you talk about, so I am not sure how to improve anything in Huggle.

I would need to see some picture or simple description of what you want to achieve (how things look now and how you would like them to look)

In T199500#6017010, @Petrb wrote:

In that case if parsedcomment is native MW API property that is available everywhere (not just wikidata) then yes, I can implement this in Huggle, as optional feature (I think most of powerusers prefer summary in wikitext over parsed HTML), but it's reasonable feature request.

Thank you! Yeah I was thinking some people might prefer wikitext, say to check for [[Stupid person|Some famous person]] when you'd otherwise only see "Some famous person" and miss the edit summary vandalism. But parsed comments would help with Wikidata, Commons and on other multilingual wikis where some automated summaries are in the form of code rather than plain English.

I would need to see some picture or simple description of what you want to achieve (how things look now and how you would like them to look)

Sure, so in the screenshot you see in the description (F23712741), you'd want to see "Category:Films set in Montana" as the title, not Q6379160, just like the wiki does https://www.wikidata.org/wiki/Q6379160. The same holds true for the Queue on the left side. So for Huggle, I suppose you'd pre-fetch titles using the wbgetentities API (T199500#4478716), and show the label that matches the user's language. I'm not sure if Huggle's i18n system has knowledge about language fallbacks (e.g. if my language is en-GB, and no label for en-GB exists, just use en). When in doubt fallback to English, I suppose, and if that's not defined just show the item ID (Q6379160) as we're doing now.

@Evs also mentioned that property IDs are shown, but I think they're talking about the edit summary, so having the option for parsed comments will solve that. In the diff view, everything appears to be human-readable to me.