User Details
- User Since
- Aug 21 2017, 4:16 PM (412 w, 3 d)
- Availability
- Available
- IRC Nick
- cormacparle
- LDAP User
- Cparle
- MediaWiki User
- CParle (WMF) [ Global Accounts ]
Wed, Jul 16
Mon, Jul 14
Jun 9 2025
Jun 4 2025
Oh I agree - I was thinking that pagination-plus-filtering might make more sense than having separate pagination for each namespace
This might be simplified by filtering by namespace rather than grouping by namespace
May 29 2025
So should we close this?
May 7 2025
May 6 2025
May 2 2025
May 1 2025
Do we really want to monitor template-favouriting-use on a continuous basis? If not then a dashboard seems like overkill for this. We can test the hypothesis by querying the db, right? A dashboard that nobody is gonna look at seems like a waste
Apr 29 2025
I created T392896: Add a community-configurable list of "useful templates" to a tab in the template picker to cover the first bullet point under number 2 in the previous comment, so now I think all the ideas contained in this ticket are covered elsewhere. Closing in favour of the more detailed tickets
@Esanders - see @Samwilson 's comment ... basically all the bits of T55590 are now covered by other tickets except for this, so I've created this and am about to close T55590 (unless you have an objection?)
Apr 28 2025
Done
This is done, and the data is currently being gathered and stored in hive in mediawiki_upload_tracking.upload and mediawiki_upload_tracking.commonswiki_deletion_request
Apr 25 2025
Apr 23 2025
Apr 18 2025
Apr 17 2025
Apr 15 2025
Apr 12 2025
Apr 11 2025
Apr 9 2025
Ok updated - it's kind of a tiny task now really
Apr 8 2025
Ok so after talking this through last night we think we're going to have 2 templates - {{focus-area-header}} and {{focus-area-footer}}, and this one will be used in the footer
Apr 7 2025
Mar 31 2025
show partitions commons_entity; OK partition snapshot=2025-01-06 snapshot=2025-01-13 snapshot=2025-01-20 snapshot=2025-03-03 snapshot=2025-03-10 snapshot=2025-03-17
Mar 28 2025
Updated to use page id
Removed the PK from community_requests_focus_areas based on the reasoning in https://phabricator.wikimedia.org/T387957#10659061 (i.e. we don't really need a separate auto-incrementing PK as there will always be a corresponding page)
Mar 27 2025
Source | before deployment external links patches (from this comment above) | count on Commons 2024-12-16 | count on Commons 2025-03-27 |
---|---|---|---|
0 | 710 | 2589 | |
1 | 14664 | 18475 | |
0 | 366 | 1002 | |
2 | 49 | 285 | |
YouTube | 1 image, 7 videos | 1319 images, 42 videos | 4461 images, 143 videos |
GettyImages | 0 | 29 | 78 |
0 | 37 | 260 | |
shutterstock | 1 | 4 | 5 |
alamy | 0 | 22 | 53 |
istockphoto | 0 | 0 | 2 |
tiktok | 0 | 1 | 15 |
amazon | 1 | 40 | 176 |
fandom | 0 | 138 | 699 |
Mar 26 2025
All the above seems reasonable ... I can't remember the reason why I used title instead of the page_id, maybe it was so we wouldn't have to join page to get the title for making the link. Do you remember @Samwilson ?
Mar 20 2025
We can get equivalent data to that in wmf.wikidata_item_page_link and wmf.wikdiata_entity by first defining a udf
Hey Eric - we've had big problems with the data pipeline since Jan (flaky upstream dependencies), and we kinda have to deal with those before we get to this, sorry!
Mar 19 2025
Here's how to replace structured_data.commons_entity ...