Notes from tech discussion:

• We have page images extension, which allows us to retrieve all images that are on a page. This is basically what we need; people might be able to self-serve already.
  • Example: https://en.wikipedia.org/w/api.php?action=query&generator=images&titles=Warsaw&prop=info
  • Concern: The goal for the Attribution API is supposed to make attribution easy; this approach requires that the user be aware of the additional Action API, then iterate through themselves.
• There is also a challenge with some pages having many images -- for example, https://en.wikipedia.org/wiki/All-time_Olympic_Games_medal_table, every flag and medal icon would be considered an "image"
  • Example: https://en.wikipedia.org/w/api.php?action=query&generator=images&titles=All-time_Olympic_Games_medal_table&prop=info
• This would likely be a more generic solution for per image lookup: https://phabricator.wikimedia.org/T421060
• We can also support batching for multiple titles as a minor stop gap

Notes from Attribution tech sync:

• The core data should already be included from the performance monitoring task; the scope of this ticket should now be focused on visualisation.

This ticket is blocking Wikidata module creation: T422403: Create Wikibase v1 REST API Module

Let's make it clickable and follow the same naming convention as the page. Please make the email address a mailto: link as well. Thanks for the due diligence here!

Next steps here: Confirm LoE for self-service security review so we can decide if the SwaggerUI upgrade is possible. @Mooeypoo & @aaron will lead the conversation and report back on options. The main issue is that we are confident we will move away from SwaggerUI within a few months, so we should not invest weeks of effort to go through a security review. If the self service process takes a day or two, then we can do it; if it will be weeks or months of turnaround time, then we will not be able to ingest the existing Wikidata spec and will need to discuss other options.

It seems like this was covered in other tasks. Marking as invalid, but feel free to reopen if you disagree.

Marking as an epic and moving to the quarterly view

@BPirkle it seems like this is more of an epic than an actual implementation task, since everything is broken into other stories. I'm going to mark it and move it to the quarterly view to get it off the board, but feel free to pull it back if I missed something.

Hey there 👋 Just following up on this again. I specifically needed this today, so hoping we can get the data into Turnilo soon 😁

@aaron & @BPirkle -- The scope of this ticket should really focus on how we add examples for request parameters to the MW framework, and what translation support might look like. This will also be required to get the MediaWIki spec up to snuff in terms of meeting the linting rules.

Noting that this is also touched on here: https://phabricator.wikimedia.org/T402524

Cool beans. And agreed -- if the implementation isn't crazy, that does seem like the more complete solution, and one that we could potentially take advantage of elsewhere.

Fair point, @BPirkle .

Notes from estimation:

• Some of our security options are contained in extensions, which may or may not be installed.
• Let's start with CSRF + MW Session since we know they will be available everywhere; we will need to have a more robust solution for OAuth that checks for installed extensions and injects appropriately, which will require a framework change.
• Recommendation to update this to at least two tickets: Start with a spike for how to do this, then implement for MW OAD, and then assume that the linting rules will be a separate task.
• MWP is also working on OAuth right now.
• Next step: Hash this out in tech discussion on Tuesday.

Notes from estimation:

• Should this delete the old rules?
  • Part of this task is determining the restructuring; some rules might just need to be expanded instead of fully replaced. Other rules may be replaced entirely.
  • The proposed rules here are not intended to be additive with the existing rules.

Notes from estimation:

• The key is showing up without an en value. We're using them in code, but they're missing from the translation file (or has a typo in it).
• Make a recommendation for introducing a systemic fix for catching these types of issues. Determine if it would be caught by banana testing, or something else. How might we catch missing strings, misspellings, etc?

Since this is working as expected again, are we safe to close this ticket?

Just chiming in that we have a spreadsheet for the Attribution API that captures what fields are returned on which types of content, as informed by the framework: https://docs.google.com/spreadsheets/d/1-Ww-gfmS-HXd6ozux6Qv_ioOBlLICj8Oa4TWDlkyxHQ/edit?gid=508518853#gid=508518853

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)

Marking as resolved to close MWI-Sprint-30 (2026-03-24 to 2026-04-07)