User Details
- User Since
- Aug 21 2017, 4:16 PM (364 w, 4 d)
- Availability
- Available
- IRC Nick
- cormacparle
- LDAP User
- Cparle
- MediaWiki User
- CParle (WMF) [ Global Accounts ]
Fri, Aug 2
Sorry @Eevans this has been sitting in an open tab for > 1 month now ... is it possible to access the data gateway from beta so we could test it that way?
Tue, Jul 30
Weeks, most likely. It's part of our work for this quarter
Mon, Jul 29
We have this ticket to allow users to add custom licences for their own work, so that should cover you I think? https://phabricator.wikimedia.org/T366501
Fri, Jul 26
Thu, Jul 25
Wed, Jul 24
Mon, Jul 22
Aha, ok! I thought maybe you were Robert Myers IRL ... this was actually a deliberate choice on our part, because images uploaded under "this is someone else's work and is free to share" can be scans and downloads and sometimes the EXIF date doesn't mean what we expect it to mean. Let me bring it back to the team ...
Are you uploading these are your own work, or as someone else's?
Ok so we've reduced the weight of main subject in MediaSearch because it's much less precise than depicts when searching, and we've removed main subject as a source of image suggestions.
Fri, Jul 19
@Sannita I can't reproduce this. If I download the image the user had trouble with, rotate it, and re-upload it (without publishing) then the date field gets populated from the EXIF as expected
Maybe the user could give us another image of theirs that hasn't been uploaded and we can try with that?
Jul 18 2024
Title field has already been updated to "Date work was created or first published"
Jul 17 2024
Jul 16 2024
May be update the title of date field to be more clear on what date we are asking [TBD]
Jul 15 2024
I think validating on characters in the frontend is fine - there will always be at least as many bytes as characters, so once something passes frontend validation (on min characters) it'll also pass backend validation (on min bytes)
"title" validation has always been on byte-length rather than the number of characters - so for example "
Jul 11 2024
Jul 10 2024
Jul 9 2024
Uploaded in 2023
Just a couple of extra data points on logos (from https://gitlab.wikimedia.org/cparle/notebooks/-/blob/main/logos.ipynb)
Jul 8 2024
Closing this - it's superceded by T350797
@KStoller-WMF so can we close this ticket?
Jul 5 2024
Jul 4 2024
Jul 3 2024
Ok deployed early. Should be fixed now @simon04 @Herzi.Pinki
Good catch @simon04 thank you! Fix scheduled for deployment at 1300UTC
Jul 2 2024
https://phabricator.wikimedia.org/T369053 will cover the warning style, so it's only the text of the warning left. Waiting for feedback, hopefully can just close this
@Sneha @Etonkovidova can we keep the text of the main subjects warning as "items" rather than "main subjects"? This warning is used for any structured data field, so it'll be used for anything that's added by a campaign too ... different rules/warning text for different structured data properties is tricky and would take a lot of work to implement for a rather small benefit
Checked on production commons - seems to be working fine
@Etonkovidova maybe you could confirm?
So we think we'll proceed like this for now (simplest approach, because it's a PoC*)
Jul 1 2024
@Jdlrobson is there anything else we need to do?
Just +2ed this https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikibaseMediaInfo/+/1051166 - we think it should fix the problem
It looks like ddebcc1a9637dfb7fa1318924d8201b51aff88a9 is the problem - in particular the replacement of $.extend() with Object.assign(). @Jdlrobson any thoughts?
Possibly related to T368736
Note that this should NOT be part of UploadWizard, because we want the detection to happen for all uploads. Note that non-WMF installs won't have access to the logo detection endpoint
Jun 28 2024
Looking at this again
Ok - this component is used on the File page as well, is it ok if we also make the change there? To have it behave differently in the 2 places it's used seems like a bad idea (and tricky to implement)
Jun 27 2024
@Sneha it'd be way simpler to do this the way it's already done on the File page. Do you think that'd be acceptable instead?
Thanks @Nosferattus - there's already a wikidata api endpoint for this, so I we're planning to use that
Jun 21 2024
Maybe re-reading the guidelines maybe you are right 🤔 We may need to make some adjustments to media search and to image suggestions ...
"Main subject" when referring to a photo or drawing, and "main subject" when referring to a scanned text document mean two different things - I think that's the main issue here. @Dominicbm do you have some way of distinguishing between the two? If you do the perhaps we could indicate that somehow in the structured data?
Jun 20 2024
Jun 19 2024
Jun 18 2024
Jun 17 2024
Jun 14 2024
Jun 13 2024
Number 2 should be fixed now