Alphos added a comment.
Way ahead of ya ;-)
Current implementation (JS on test.wikidata
https://test.wikidata.org/wiki/User:Alphos/ytreporp.js) performs the
##action=wbgetclaimsprops=claims|info## call at window.onload time on items
that are targetted by properties of interest.
Still wrapping
adrianheine added a comment.
That sounds great :) I think you can and should use `wbgetentities`. If you set
`props=claims|info`, you only get the claims and meta data, which shouldn't be
to expensive.
TASK DETAIL
https://phabricator.wikimedia.org/T94159
REPLY HANDLER ACTIONS
Reply to
adrianheine added a subscriber: adrianheine.
adrianheine added a comment.
I'm currently working on removing wbUsedEntities, see
https://gerrit.wikimedia.org/r/#/c/197290/. You would have to do an API request
then, anyways. As for the current page, `wgCurRevisionId` gives you the revid,
but I
Alphos added a comment.
I did find wgCurRevisionId ;-)
Too bad about wbUsedEntities being dropped, it means we're either :
- facing race conditions (and potential edit conflicts) : the lastrevid of the
used entities may have changed since the loading of the current page
- or not caring (and
adrianheine added a comment.
Can you give me a use-case for editing an entity referenced by the entity
you're currently on? I think it makes more sense to provide the lastrevid with
`wbgetclaims`, and I think you definitely should run `wbgetclaims` before doing
`wbsetclaims`, otherwise you
Alphos added a comment.
I'm working on a gadget that will allow you to insert by hand only one side of
a relationship, and click for an automated insertion of the other side.
Let me clarifiy with a real world example :
- La Villette https://www.wikidata.org/wiki/Q532352 was a subdivision of
