Page MenuHomePhabricator

Connect template parameter to corresponding Wikidata property
Closed, ResolvedPublic3 Estimated Story Points

Description

As a template editor I want to connect local template parameters with their corresponding Wikidata property in order to ensure correct edits from the Wikidata Bridge.

Problem:
In order to know which value to edit on Wikidata we need to know what the local template parameter corresponds to. The template editors need to provide this information.

Example:

BDD
GIVEN
AND
WHEN
AND
THEN
AND

Acceptance criteria:

  • Template editors can indicate which property an infobox parameter corresponds to.
  • Define the parameters the links should have and communicate them (documentation) to the template editor
  • Ensure the connection between the parameter to edit and the property on wikidata

Open questions:

  • Do we want to restrict this initially to only data from the connected Item or do we also indicate which Item the data comes from right away? -> no need to restrict so let's make it possible
  • Do we do this with Template Data, as parameters in edit links or something else? -> edit links and spans
  • How are the "edit links" assembled? -> by the template editor/Lua module
  • Where do we document the pattern of those items? Subpage on the client documentation? -> on the wikidata bridge page on mediawiki and linking to it from the client documentation

Event Timeline

I created an initial version as basis for discussion and improvement:

https://www.mediawiki.org/wiki/Wikidata_Bridge/Development/DocDrafts/How_to_Enable_Wikidata_Bridge_for_your_Infobox

Open questions:

  1. Do we want an extra top-level section "Documentation Draft" or similar in the project documentation? @Lea_Lacroix_WMDE

Further considerations:

  1. Do we want to get our data from the href or data-attributes? (I like href, because then we can ensure correct no-js behaviour. But they cannot edit this without js on wikidata.org either...)
  2. Do we want to enable this based on a class on the link or differently? Is the class name fine?
  3. Do we want to make any assumptions about the surrounding DOM?
  4. Do we want a Lua function that does this correctly?

For harvesttemplates, it would be great if this could be queried/defined somewhere

Do we want to get our data from the href or data-attributes? (I like href, because then we can ensure correct no-js behaviour. But they cannot edit this without js on wikidata.org either...)

A working link is also useful for middle-clicking (open in new tab).

Do we want to enable this based on a class on the link or differently? Is the class name fine?

I would suggest a class on the link and a class on some surrounding element (e. g. the whole infobox <table>). I think on many wikis the link is generated in one place (e. g. enwiki’s Module:WikidataIB createicon function), and requiring the class on a surrounding element allows the editors to add the class in that one place while still enabling/disabling the Wikidata Bridge integration per infobox (type).

[The edit link] has to link to the respective property of that item on Wikidata

What if the link points to a specific statement, e. g. https://www.wikidata.org/wiki/Q1#Q1$a5887543-4c91-e37d-712f-9362af351f80? Do we want to support that? (I don’t know if any templates currently do this.)

@Michael Yes, for now I'll add a "documentation draft" section in "development" and later, when we have a product ready, I'll create a proper "documentation" section.

Is the class name fine?

It should probably be databridge-enabled rather than wikidatabridge-enabled, unless we want to make the class name configurable. (And I think elsewhere we’re hyphenating “data bridge”, so perhaps data-bridge-enabled too.)

I was bold and updated the page, renaming the link class to data-bridge-enabled and adding a wrapper class of data-bridge-capable, because I want to upload a Gerrit change (edit: this Gerrit change) that applies these requirements to the current link counter. Of course, we can still discuss and change them.

I was bold and updated the page, renaming the link class to data-bridge-enabled and adding a wrapper class of data-bridge-capable, because I want to upload a Gerrit change (edit: this Gerrit change) that applies these requirements to the current link counter. Of course, we can still discuss and change them.

👍

Change 518713 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] bridge: only count data bridge-enabled links

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

I think I’ve discovered a problem while preparing an example on the documentation draft. Currently, enwiki’s Module:WikidataIB createicon function uses plain image links to create the icon, with something like this:

[[File:OOjs UI icon edit-ltr-progressive.svg|…|link=https://www.wikidata.org/wiki/Q2013?uselang=en#P856]]

(I assume other wikis’ infobox modules work similarly, but I didn’t check.) You can add a |class=data-bridge-enabled parameter to that, but this results in the class being added to the <img> element, not the surrounding <a> element. So if we search for a.data-bridge-enabled we won’t find it.

In fact, MediaWiki has no built in way to add link attributes, so we can’t require the class="data-bridge-enabled" on the <a> element directly, as far as I understand.

So I think we can require .data-bridge-enabled on some descendant of the <a>, such as the <img> (easy to implement in wikitext, probably slightly annoying to implement for us); on some parent of the <a>, such as a <span>/<div> or a <td> (probably slightly annoying to implement in wikitext, easy to implement for us); or both (maximum flexibility for wikitext authors, probably somewhat annoying to implement for us).

We could also continue to allow .data-bridge-enabled on the <a> itself, but if it’s not possible to generate such links in MediaWiki I don’t really see the point unless we get it for free (which I don’t think is likely – there’s no CSS selector for “class on this element or a child/descendant” as far as I know).

I think we should require the .data-bridge-enabled either on a parent tag or a child tag, not both. Allowing it on both would be too confusing and I think it makes sense here to follow Python's Zen: There should be one-- and preferably only one --obvious way to do it.

I would favor requiring the class on the parent <td>. This would allow us to work even on somewhat buggy fields, like the Mounting field in the infobox of South Pole Telescope, which has two edit links for a single value.

However, I think this is in part also an UX/product issue as the template editors are also our users. @Lydia_Pintscher, @Charlie_WMDE what do you think?

Also, I still haven't been able to create a simple wikidata-template locally. Should we create an example implementation for both options to be better at deciding this?

I think we should require the .data-bridge-enabled either on a parent tag or a child tag, not both. Allowing it on both would be too confusing and I think it makes sense here to follow Python's Zen: There should be one-- and preferably only one --obvious way to do it.

That seems right.

I would favor requiring the class on the parent <td>. This would allow us to work even on somewhat buggy fields, like the Mounting field in the infobox of South Pole Telescope, which has two edit links for a single value.

However, I think this is in part also an UX/product issue as the template editors are also our users. @Lydia_Pintscher, @Charlie_WMDE what do you think?

I am not sure I fully understand the issue yet so let's sit together and go over it.

Also, I still haven't been able to create a simple wikidata-template locally. Should we create an example implementation for both options to be better at deciding this?

I think that'd be super useful.

I’ve updated the documentation draft with some of the new decisions we made, but we’ll need to know more about the possible edit flows before we can finalize it.

Change 518713 abandoned by Lucas Werkmeister (WMDE):
bridge: only count data bridge-enabled links

Reason:
very outdated

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

I think this is more or less done – we’ve decided, for now, how the connection will work, and implementation is covered by T226994: Extract and log data bridge parameters from edit links.