Let me claim this work.

The Slack message was just a quick highlight, meant to capture my thoughts before I create the phab ticket. Most likely, I didn't include a 301 at that time because I was still forming both proposals.

@Mooeypoo the problem is not about fetching the data. This is easy - I can fetch data without problems. The entire problem is what kinda of data the Attribution should return - because file is on remote, do we return remote attribution, or we return local attribution.

That would be option A - use the ForeignAPIRepo -> the idea is that REST API Handler would use PageContentHelper to check if the Title exists locally, and in case of not found, it would use the ForeignAPIRepo and call RepoGroup::findFile() to load it from remote.

After a quick and a bit hacky way, I'm able to return Attribution data from a remote Title. But the work also exposed some quirks, and before I move forward, I'd like to align on the architectural approach for handling remote media.
When I say local -> I mean the environment client is querying, and remote is the environment that has the file ( most likely Commons ).

A quick question - do we want to add the wprov links here too ? cc @HCoplin-WMF

Grafana board ready: https://grafana-rw.wikimedia.org/d/pm7xkjs/mediawiki-rest-api-attribution?orgId=1&from=now-30d&to=now&timezone=utc

sorry for confusion, removing the sprint tag - as this is an epic and still has some subtasks that have to be done, therefore I cannot close it yet.

Grafana board is ready: https://grafana-rw.wikimedia.org/d/pm7xkjs/mediawiki-rest-api-attribution?orgId=1&from=now-30d&to=now&timezone=utc

The update to enable this feature on all wikis has to be reverted due to T425580: [Spike] [BUG] POTD Gallery doesn't load, crashes upon share

@HCoplin-WMF what do we do with cases like

• 'Fair use'
• 'No restrictions'
• 'Attribution'

@Sarai-WMF @HCoplin-WMF I added also wprov param info to schema documentation:

@HCoplin-WMF do you have an idea where we can link on the site page?

In T425576#11900139, @Sarai-WMF wrote:

In T425576#11899168, @HCoplin-WMF wrote:

Notes from estimation:

• We can use linker tool/library to append the right values to the title link
• Values are assumed to be directly concatenated to the hardcoded CTAs
• Add a test that confirms presence of wprov

@HCoplin-WMF I'm not sure whether this will impact the estimation, but I had forgotten a crucial AC: We need to communicate to users that the URLs include the wprov parameters in a clear and accessible way (either via the spec or the Attribution API docs — wherever it sounds most convenient). A note on the attribution framework site sounds necessary too, so I'll draft a short heads-up there.

In T425576#11900064, @Sarai-WMF wrote:

In T425576#11898628, @pmiazga wrote:

After a deeper thought, I don't think we need different wprov values for each link -> as the we will know which link was clicked by the link ( URL ) itself. Therefore we may be totally good with just two af[s|c]w1 which would be translated to

afsw1 -> Attribution Framework, Source, Web, ver 1
afcw1 -> Attribution Framework, Calls to Action, Web, ver 1

Alright. Thank you @pmiazga! I think, though, that you might have meant afws1 and afwc1, right? Just making sure. I'll update the task description now 🙏🏻

After a deeper thought, I don't think we need different wprov values for each link -> as the we will know which link was clicked by the link ( URL ) itself. Therefore we may be totally good with just two af[s|c]w1 which would be translated to

I'm looking at t[[ https://wikitech.wikimedia.org/wiki/Provenance#Description_of_wprov_parameter | Description of wprov parameter ]] and it should be

I have some free cycles this sprint, let me pick it up.

I eagerly added text as this could be rendered as plain text, therefore it could be regular page. From what I see as built-in content models: ( source: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/818753f06b593ee6308642e64199d57ac4707d89/includes/MainConfigSchema.php#3377 )

Attribution returns the source_wiki parameter twice - once in essentials section, and once in the root.

I love it ! The only small nitpick I would propose - do not put that in the WANObjectCache, please. This class is already a hog, over 3K lines. The cache could be a param, sth like:

The easiest and best way to disable Attribution signals for Wikibase items is to use the content-model. Wikibase items use wikibase-item and wikibase-property. This way, we will stop showing the signals mentioned in the ticket.

@HCoplin-WMF where do we want to keep those logos? Probably we need to upload those to Commons. Another option would be to point directly to creativecommons.

So the T422834 is not a blocker, and FlaggedRevs is merged. @aaron can we proceed with enabling this sandbox?

The fix attached to this ticket is not the fix for the issue, but a workaround around this bug. The root cause ( invalid serialization of arrays ) still has to be handled.

Let's wait with enabling Attribution API on all Sandboxes. First, we need T421011 and T422834 merged.