Page MenuHomePhabricator

[WIPR] Connect WikiProjects in the Tools section on relevant Item pages using properties
Open, Needs TriagePublic

Description

As a wikidata editor I want to know if an Item is related to a wikiproject so that I can connect with other editors who share a common interest.

Using Properties on Items on Wikidata we will link to:

We will link to WikiProject Music for Items that use the following properties:

We will link to WikiProject Medicine for Items that use the following properties:

We will link to WikiProject Datasets for Items that use the following properties:

We will link to Wikiproject sum of all paintings for Items that use the following properties:

We will link to WikiProject elections for Items that use the following properties

The link should be displayed in the tools section following the design

Note: there is concern that this will impact the rendering time of all Item pages, so we will need to track the impact of the changes

Acceptance Criteria

  • On Wikidata, Items that have statements that use Properties related to the various WikiProjects display a link to the respective WikiProject following the default of same-window navigation
  • This link is included in the tools section of the Item page, following the design. Making sure to be enabled under a "feature-flag".
  • Items that do not have any statements that use any of the relevant properties should show no WikiProject section or link
  • All links are tracked using T421856
  • Monitor rendering time before and after implementation

Event Timeline

Arian_Bozorg renamed this task from [WIPR] Connect Music, Medicine and Datasets in the Tools section on relevant Item pages to [WIPR] Connect WikiProjects in the Tools section on relevant Item pages using properties.Apr 10 2026, 12:58 PM
Arian_Bozorg updated the task description. (Show Details)
karapayneWMDE edited projects, added: Wikidata-Omega; removed: Wikidata-Omega (The Board).

moved out of sprint board given sprint 10 priorities

Blocked by T427804: [WIPR] Allow for translations of Wikiproject names as what is included in the config depends on the translation

Making sure to be enabled under a "feature-flag".

I’m not quite sure what this entails, to be honest. As far as I can tell, the only thing that’s left to do in this task is the configuration itself; the code in Wikibase has already been taken care of (including by T427804, which is mostly done and will roll out with the train next week – the config change would have to wait for that). And the configuration itself is the feature flag – so the moment we deploy the config, the links should be live, and if we revert the config then they’ll be gone again.

Are we planning to deploy this on a specific date? Or just whenever we’re ready?

We will link to WikiProject Medicine for Items that use the following properties:

May I suggest that we also exclude has cause (P828)? A great many things have causes :)

Similarly, I’m not sure if everything with a chemical formula (P274) should be counted as in that project’s scope.

We will link to WikiProject Datasets for Items that use the following properties:

I’m not sure about some of these properties either:

Change #1298293 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[operations/mediawiki-config@master] Add Wikidata configuration for WikiProject links

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

I am happy to exclude all the properties you mentioned.

And regarding the release, it would be deployed ideally as soon as we are ready. I'll ask Mohammed to put together an announcement and we can send it out alongside the update

Testing of the above config change on mw-experimental shows that medical condition is apparently not listed as a WikiProject Medicine property ^^

image.png (1,025×383 px, 55 KB)

Apart from that, the config change seems to work as expected, as far as I can tell from some random items.

The acceptance criteria mention "Monitor rendering time before and after implementation" - what is the plan for that here?

The acceptance criteria mention "Monitor rendering time before and after implementation" - what is the plan for that here?

I was thinking of MediaWiki Engineering/Guides/Measure backend performance § Benchmarking and load testing in production – after looking into it this morning, that turned out rather more complicated than I anticipated, but I now think I have something that works.

Without the change (the curl is meant to warm up the server a little bit, and in particular ensure that the page is in the parser cache):

lucaswerkmeister-wmde@deploy1003 ~ $ curl -so/dev/null --connect-to ::mw-experimental.eqiad.wmnet:4456 https://www.wikidata.org/wiki/Q51850225 && ab -n 1000 -c 15 -l -H 'Host: www.wikidata.org' https://$(getent ahostsv4 mw-experimental.eqiad.wmnet | awk '$2 == "STREAM" { print $1 }'):4456/wiki/Q51850225
This is ApacheBench, Version 2.3 <$Revision: 1923142 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.64.16.131 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        mw-experimental.eqiad.pinkllama-57767f9587-xsm6r
Server Hostname:        10.64.16.131
Server Port:            4456
SSL/TLS Protocol:       TLSv1.3,TLS_AES_256_GCM_SHA384,2048,256
Server Temp Key:        X25519 253 bits
TLS Server Name:        www.wikidata.org

Document Path:          /wiki/Q51850225
Document Length:        Variable

Concurrency Level:      15
Time taken for tests:   26.162 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      70874000 bytes
HTML transferred:       64969000 bytes
Requests per second:    38.22 [#/sec] (mean)
Time per request:       392.427 [ms] (mean)
Time per request:       26.162 [ms] (mean, across all concurrent requests)
Transfer rate:          2645.57 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.9      3      31
Processing:   207  384  50.4    382     604
Waiting:      202  383  50.4    381     603
Total:        210  387  50.4    385     607

Percentage of the requests served within a certain time (ms)
  50%    385
  66%    405
  75%    419
  80%    426
  90%    452
  95%    472
  98%    501
  99%    517
 100%    607 (longest request)

With the change:

lucaswerkmeister-wmde@deploy1003 ~ $ curl -so/dev/null --connect-to ::mw-experimental.eqiad.wmnet:4456 https://www.wikidata.org/wiki/Q51850225 && ab -n 1000 -c 15 -l -H 'Host: www.wikidata.org' https://$(getent ahostsv4 mw-experimental.eqiad.wmnet | awk '$2 == "STREAM" { print $1 }'):4456/wiki/Q51850225
This is ApacheBench, Version 2.3 <$Revision: 1923142 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.64.16.131 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        mw-experimental.eqiad.pinkllama-57767f9587-xsm6r
Server Hostname:        10.64.16.131
Server Port:            4456
SSL/TLS Protocol:       TLSv1.3,TLS_AES_256_GCM_SHA384,2048,256
Server Temp Key:        X25519 253 bits
TLS Server Name:        www.wikidata.org

Document Path:          /wiki/Q51850225
Document Length:        Variable

Concurrency Level:      15
Time taken for tests:   29.508 seconds
Complete requests:      1000
Failed requests:        0
Non-2xx responses:      1
Total transferred:      71383683 bytes
HTML transferred:       65484411 bytes
Requests per second:    33.89 [#/sec] (mean)
Time per request:       442.613 [ms] (mean)
Time per request:       29.508 [ms] (mean, across all concurrent requests)
Transfer rate:          2362.47 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.4      3      12
Processing:    47  433  63.0    427     682
Waiting:       47  433  63.0    427     681
Total:         55  437  63.0    430     684

Percentage of the requests served within a certain time (ms)
  50%    430
  66%    460
  75%    476
  80%    488
  90%    519
  95%    548
  98%    573
  99%    597
 100%    684 (longest request)

Repeating this, with the change:

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.4      3      13
Processing:    44  403  60.4    397     710
Waiting:       44  403  60.4    397     709
Total:         47  407  60.5    401     712

Percentage of the requests served within a certain time (ms)
  50%    401
  66%    423
  75%    439
  80%    453
  90%    481
  95%    511
  98%    544
  99%    592
 100%    712 (longest request)

And with the change removed again (two runs):

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.5      3      10
Processing:    47  382  54.9    376     638
Waiting:       47  381  54.9    376     638
Total:         51  385  54.9    380     642

Percentage of the requests served within a certain time (ms)
  50%    380
  66%    402
  75%    415
  80%    425
  90%    451
  95%    472
  98%    512
  99%    572
 100%    642 (longest request)
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        2    4   1.4      3      11
Processing:   174  390  51.6    388     612
Waiting:      172  389  51.7    387     611
Total:        176  393  51.7    391     616

Percentage of the requests served within a certain time (ms)
  50%    391
  66%    409
  75%    422
  80%    431
  90%    456
  95%    481
  98%    516
  99%    543
 100%    616 (longest request)

That sure looks like a measurable difference of at least 10 ms if not more :/

I did another round of performance testing and put the results on a wiki page, which has more formatting options (especially mw-collapsible). The overall result is similar: a performance cost of ca. 20–40 ms (somewhat more for the larger item, albeit taking up a smaller percentage of the total request time there).