Hi,

Kateryna is working on this: https://meta.wikimedia.org/wiki/Research:Matching_Red_Links_with_Wikidata_Items

Please ping or write something in the discussion page if you want to know more about that project.

This is very good idea,. However, the task description is slightly too technical, e.g can someone add a kind of "user story" to explain how a regular user is expected to link between the article to be created and Wikidata entity? (I'm missing what, if any, user interface support for it should be made)

I imagine that the following UI components are to be affected:

1. wikitext editor - some additional field (possibly with autocomplete) to link to entity
2. VisualEditor - it should be possible in the advanced options to link article to item
3. ContentTranslation - content translation should be aware to it without explicitly setting the item.

If this is correct, this means 2 implementations in the backend side?

1. index.php?action=edit - e.g for the classic usage
2. RESTBase-API the new contenttranslation is using REST-base and we need it there too (see also T199310)

In T178249#4704878, @eranroz wrote:

This is very good idea,. However, the task description is slightly too technical, e.g can someone add a kind of "user story" to explain how a regular user is expected to link between the article to be created and Wikidata entity? (I'm missing what, if any, user interface support for it should be made)

In my opinion, you described rather a large topic, which combines many different tasks, and each of them can be implemented. But at the same time, they are completely independent and can be done in small iterations. Specifically, this task is solely about the wikitext editor, as described, and does not pretend to solve all problems at once.

API support can also be useful, but the API already allows to solve this with two requests. VE could also already link new pages by making these two requests, but it has no source to take the ID to do this (and if this task is done, it will be able to take it from the GET parameter). True, with VE there is another problematic part: previewing a page that has not yet been created (using a Wikidata item). So almost every part can be done separately and does not block any other.

The user story behind this is quite simple: for more than five years, modules that output information from Wikidata can also generate links for creating new articles, which already can include the necessary IDs. That is, it does not require any user interaction and no fields to select the right Wikidata item (although this can be added later as a separate task). In this case, it would be possible for users to start creating an article not from scratch, but at least with a filled infobox.

At the moment ruwiki has learned how to do this through editintro and the item ID template parameter (e.g. https://w.wiki/4fQp), but this looks more problematic, requires much more effort from the communities to support, and accordingly scales much worse.

I want to describe how things are (almost) implemented in ru-wiki to give some context regarding how this functionality can help community.
The desired user story is pretty simple:

1. When I'm editing an article and have a red link, but knows that article exists in another language wikipedia, I'm leaving a hint there (e.g. {{Interlanguage link|Arthur Kaan|de||vertical-align=sup}} in en-wiki)
2. When someone else is clicking on the red link ...
   1. ... browser open an article creation page with some content pre-generated based on wikidata (e.g. correct infobox) and language sitelinks are already displayed
   2. ... preview shows infobox populated from the specified wikidata item
   3. ... and save article, it automatically placed as a sitelink in the corresponding wikidata item

In order to achieve this, in ru-wiki we have several components:

1. Most of infoboxes accept parameter from= (e.g. {{Infobox enzyme|from=Q1262082}}), so it can be used to display infobox for (yet) non-existing article
2. Infobox modules, that shows info from wikidata are able to show redlinks and associate it with wikidata element (both visually and via url parameter from=Q1117754) see
   
3. JS-gadget, that
   1. looks for interlanguage links such as {{Ill|HD 165493|it}}
   2. gets wikidata element (Q2399598) for https://it.wikipedia.org/wiki/HD_165493
   3. adds from=Q2399598 to red link url
4. JS-gadget, that invoked when a new article page is opened (e.g. url contains redlink=1) and url contains from=Qxxx This gadget
   1. finds an appropriate infobox and put it in the article text with from parameter
   2. generates human-readable article preamble based on wikidata item
   3. shows language links
      
5. Bot that monitors newly created articles and
   1. adds article as a sitelink to the corresponding wikidata item (e.g. https://www.wikidata.org/w/index.php?diff=1397217877)
   2. removes from= parameter from the infobox (e.g. https://ru.wikipedia.org/w/index.php?diff=113447669)

How native support of from=Q1234 (or itemid=Q1234 like proposed above) url parameter could simplify those five components?

1. If parser functions invoked on non-existing page will consider this url parameter, we won't need from= parameter in infoboxes. Ru-wiki already invested into that, but a lot of other communities does not, so this will save them a lot of effort
2. Nothing really changed here. Server-side generation of redlinks with new parameter is bad idea, so we recommend to keep it on js-gadget (code is trivial, but unfortunately depends on the formatting, that differs from project to project)
3. Same here, we will keep it in js-gadget, (wbgetentities + above)
4. We will still have to do A and B, but C will be done for us by engine
5. That piece can be done by engine easily. Existing bot runs once a day, so for majority of new articles sitelinks are added manually. We are planning to rewrite bot so it will monitor Page creation stream, but streams are not particularly reliable

So to summarise, this feature (with small additional contribution from community) can effectively helps editors to create new articles more efficiently and provides clear incentives to enhance wikipedia-wikidata integration.

Also see

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023/Wikidata/Popup_to_link_to_or_create_a_new_Wikidata_object_after_creating_an_article

Also see
https://phabricator.wikimedia.org/T308059