As I understand things, simplified:

• sections topics are based on blue links within that section
  • e.g. for https://en.wikipedia.org/wiki/Cat#Skeleton, we’d find that “cervical vertebrae” link (https://en.wikipedia.org/wiki/Cervical_vertebrae)
• from there, we figure out what entity is linked to that page
  • e.g. for “cervical vertebrae”, that is Q900457 (https://www.wikidata.org/wiki/Special:EntityPage/Q900457)
• from there, we grab their P18
  • e.g. for Q900457, that is https://commons.wikimedia.org/wiki/File:Cervical_vertebrae_animation_small.gif
• that image would then be suggested for the “Skeleton” section of the “Cat” article

Already implemented in https://gitlab.wikimedia.org/repos/structured-data/image-suggestions/-/tree/T311289

Already implemented in https://gitlab.wikimedia.org/repos/structured-data/image-suggestions/-/tree/T311289

I would suggest closing this ticket and incorporating it into T330934's acceptance criteria instead (to ensure we don't end up wasting work by first adding P18 suggestions, then taking them away)

Note: this will probably end up being completed as part of T330934, which is to be built first and already lists opt-out among the acceptance criteria.

A discrepancy in page title format (spaces vs underscores) between 2 datasets caused all multi-word titles to not have suggestions for sections with existing images pruned.
Fixing this brings the total number of remaining suggestions for the datasets used from 237406321 down to 178212325, or a 25% decrease.

Thanks a lot!

@Aklapper I'm not sure who to reach out to - any chance you could help me, or point me to someone who can? Thanks!

Thanks, @MarcoAurelio!

@MarcoAurelio sure, sounds good, thanks!

2nd round of notifications sent (608 to 19 users).

560 notifications (35 per user, 16 users) have just been sent.
That's roughly 2/3 of the pages-with-suggestions in this category.

@CBogen Looks great, thanks!

Closing this, as it was surpassed by T326957.

There isn't too much consistency in the statements of media outlets (see a selection below)
Most have one or more P31 (instance of) statements that are one of these: (or a subclass thereof)

Correct.
Enabling it via config change would've had to happen separate from deployment train, which would've meant doing it before deployment (running on last week's code) or after (only 1 more deployment slot left, at a rather inconvenient time for any of us)
Removing all conditionals from our repo (T326957) was simpler in this case (and has been backported yesterday); that will deploy per train - alongside the rest of the new code - while accomplishing the same result: it's enabled.
(I'll leave this open until it's actually been deployed, at which point we can close both tickets)

Dry-runs with multiple configurations worked fine. Images within categories are found, users are being iterated over, etc etc.
Actual run with 3 account (2 notifications per account) seems to also have delivered notifications (for me at least; @CBogen you should have received 2x2 notifications as well)

The script manages to find 866 pages with suggestions within these categories (only 3 of which have a confidence below 80)
491 will be excluded if we filter out Q5 instances (375 pages remain)

How many images do we want to send per user? 2, like the other script, or more?
Do other filters (minimum suggestion confidence score of 80 & excluding instances of Q5) also apply here?
(I would imagine Q5 exclusion not to apply here, given thatmany categories are explicitly about people)

I only just noticed this:

Bullseye

• https://apt.wikimedia.org/wikimedia/dists/bullseye-wikimedia/thirdparty/elastic710/binary-amd64/
  • elasticsearch-oss_7.10.2 (pool/thirdparty/elastic710/e/elasticsearch-oss/elasticsearch-oss_7.10.2_amd64.deb)
• https://apt.wikimedia.org/wikimedia/dists/bullseye-wikimedia/component/elastic710/binary-amd64/
  • wmf-elasticsearch-search-plugins 7.10.2-4 (pool/component/elastic710/w/wmf-elasticsearch-search-plugins/wmf-elasticsearch-search-plugins_7.10.2-4~bullseye_all.deb)
    • Depends: elasticsearch-oss (= 7.10.2) | elasticsearch (= 7.10.2) - satisfied

In T326663#8534723, @SimoneThisDot wrote:

• Generate a new sessionId every 10 minutes of inactivity (if the user has the screen on but does not interact for 30 minutes 3 "new-session" event are sent

I am not sure my 3rd point is correct, as the AC did not specify to emit a new-session event, but I guess we need to have the new session if we have a new sessionId.

In T310284#8531957, @Sneha wrote:

most people expect this to be a link.

I am just curious who are we referring to here? Is it community feedback?

In T326383#8514354, @Sneha wrote:

So as I understand correctly if anything is part of search results container it would tend to follow the 50em width in that case we won't have to worry about overlap.

There is not currently a way for other wikis to retrieve structured data (statements/captions) from Commons other than calling the Wikibase action APIs on commons.wikimedia.org.

Those wikidata results (.wdsearch_container) are not part of the search results container (.searchresults, the one where the min-height is set), so in this specific case, it's fairly easy to change & also make sure we don't overlap with that one (see above patch)

Note: MultimediaViewer is deployed on nearly all wikis, so we could use it. I don't think it picks up on dynamically added content, so we'd have to invoke it ourselves; and I wouldn't be surprised if we'd also have to make some changes to the MultimediaViewer extension itself, but I'm pretty sure it could work.

A bit of context: WikiVoyage was running running a very old MW version on postgres with a couple of custom extensions. There were a couple of Postgres-specific things that needed some refactoring before bringing to MySQL. Some extensions also shared tables, IIRC. CreditsSource was one of those extensions that were adopted when WikiVoyage was migrated to WMF and needed some tweaking.

Moving back to QA since we're going to leave it as is for now.

AIUI, this is intentional/expected.
cc @Sneha to confirm.

In T325831#8499301, @CBogen wrote:

In T325831#8499297, @matthiasmullie wrote:

It comes from the {{Short description}} template, which uses the {{SHORTDESC}} magic word. It allows (English) Wikipedia to explicitly override Wikidata descriptions everywhere. See T184000: Magic word on English WP to override display of Wikidata short description for more context.

Thanks! So if I understand that ticket correctly, we're using the magic word override if it exists, and if not we're using the wikidata description. I'm guessing on many wikis, that will mostly mean we're using the wikidata description, is that right?

It comes from the {{Short description}} template, which uses the {{SHORTDESC}} magic word. It allows (English) Wikipedia to explicitly override Wikidata descriptions everywhere. See T184000: Magic word on English WP to override display of Wikidata short description for more context.

Looks like we had a regression with "In Wikimedia Commons" - per @Etonkovidova's comment, the text used to be black & show the icon, but it looks like that is no longer the case and it looks just like the other links, which is indeed confusing. That should certainly be fixed.

If we're decoupling the "view more images" link from the images displayed, we're going to have to rethink a few more things: "view more images" only shows when there are more images available than those shown & if both searches are different, we no longer know that.

That was merged. Should be fixed now.