@Cparle, would you know the rate of updates we'd have to expect?

Some search operator setting should show all images like it's the case with MediaSearch so this can be used e.g. in the template

@Jdforrester-WMF so just delete those lines from the deploy config?

@MusikAnimal 's comments above suggest to me that we can answer all the questions we're interested in using https://pageviews.wmcloud.org/ ... even if we don't think a pageview fully captures "engagement" we also have votes on focus areas plus watchlist-additions for the wishes (esp if we highlight "number of watchers" on each wish page)

Causes indexing failures in the legacy indexes due to type mismatch on trace.id

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?

Weeks, most likely. It's part of our work for this quarter

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

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.

@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?

Title field has already been updated to "Date work was created or first published"

I'm curious whether @Cparle or @mfossati has any thoughts on where the previously-used testwiki tasks came from

May be update the title of date field to be more clear on what date we are asking [TBD]

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 "海豚" ("dolphin" in Chinese) would be ok because Chinese characters typically use 3 bytes compared to 1 for Latin characters

Uploaded in 2023

Just a couple of extra data points on logos (from https://gitlab.wikimedia.org/cparle/notebooks/-/blob/main/logos.ipynb)

Closing this - it's superceded by T350797

@KStoller-WMF so can we close this ticket?

Ok deployed early. Should be fixed now @simon04 @Herzi.Pinki

Good catch @simon04 thank you! Fix scheduled for deployment at 1300UTC

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*)

@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

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)

@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

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?