The main reason we want to start with "non voting" is taht we're about to add a linter we want to start telling people to adhere to -- but they may not have yet, and may require some work from their side. I am nervous of suddenly adding a helpful tool that basically immediately blocks all merges in their repos 😅

In T426081#11935377, @gkyziridis wrote:

In T426081#11932154, @apaskulin wrote:

The usual pattern for this is to create an API endpoint that serves the OpenAPI file. For example: https://api.wikimedia.org/service/lw/recommendation/api/openapi.json although YAML will also work

We would like to avoid building a dedicated API serving the /docs, since they are just static files exposing the openapi specs for LiftWing models.
We found a way to expose them to the RestSandbox using the https://raw.githubusercontent.com/wikimedia/machinelearning-liftwing-inference-services/main/docs/openapi.yaml url.
In this way, the RestSandbox is configured to fetch the /docs from the above url as the simplest solution.
This change is committed in this patch: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1286862

I am not sure this will fully help things, but I added this endpoint during the hackathon for these types of checks for what thumb sizes exist for an image in a wiki instance based on the new thumb limits config: https://www.mediawiki.org/wiki/Special:RestSandbox#/default/get_v1_file__title__thumbnails

I think I am confused, I might need to delve deeper on this, but when I was working on T425499: Create a REST endpoint solution for "imageinfo" it seemed the instantcommons query used the internal MediaWiki imageinfo operation, which gets populated by the CommonsMetadata extension through the GetExtendedMetadata hook, etc.

I wasn't fully involved in the other conversations around this, but can't we use the native MediaWiki core ForeignAPIRepo ? that's what instantcommons uses....

Merge request: https://gitlab.wikimedia.org/toolforge-repos/wmf-openapi-linter/-/merge_requests/22

New repository at https://gitlab.wikimedia.org/repos/ci-tools/wikimedia-spectral-ruleset

In T419576#11906866, @KBach wrote:

I linted the OAD example to check why the test fails and discovered the following:

• The OAD example had a few missing fields. I submitted a merge request that fixes this.

In T425499#11903825, @HCoplin-WMF wrote:

Minor requests for changes:

• REST APIs use snake_casing. Please update property names to match that convention.
• user is confusing. Consider changing it to uploader (assuming that's what it is; confirm it's not the most recent change person or something instead) and the name field to user_name (again, confirming that's actually what this field is for)
• For versioning, suggestion is to keep it v0 if we expect it to change. I'd also suggest keeping the -beta if there is a chance we remove it entirely (like if things go sideways after launch).
• Rename the endpoint to just be /info, given that there are more types of media available in commons. File is also already in the route.

In T425814#11904133, @BPirkle wrote:

I see a patch uploaded, so moving this into the sprint as In Progress

I've moved all the fiels from the doc repo (including the README) into a dedicated sub-folder in the tests, and made a special test to run all rules on the example OAD yaml.

In T425181#11884353, @Husky wrote:

Thanks, this will be a very useful endpoint. Has there been some thought of maybe adding IIIF support? I could imagine that would be useful, especially for GLAM organizations.

(reopening just to get the patch merged -- unless we want it abandoned, but since it's such a small one, let's just get it out.)

I've added an example and descriptions to the response component. The OpenAPI section looks like this now:

Followup from a discussion we had, I'm posting here an idea for a general-purpose outline for documentation about generally REST API management for developers; This does not necessarily mean the ticket should include the entire writeup for everything here, but it might give context to the general purpose of the section that this ticket relates to.

In T420780#11746973, @AGhirelli-WMF wrote:

That said, the two questions I raise are:

• Should I fix Issue 1 in the PHP code (strip hidden elements before extracting text), or should I have to report it to Commons (or whoever) to fix the template?

In T420784#11742463, @pmiazga wrote:

I wouldn't use any regex magic here; this info comes from templates, and those aren't edited often. IMHO it's better to create a map and map some of those into other:

$standarizedLicenceShortTextMap = [
  'PD' => 'PDM',
  'PUBLIC DOMAIN' => 'PDM',
  ...
];

$licenceShort = mb_strtoupper( $licenceShort );
return $standarizedLicenceShortTextMap[$licenceShort] ?? $licenceShort;

The regex magic may return some weird output on our texts, the one attached for sure will fail when whitespaces are mixed ( added extra or removed )

I've created two tickets for followup work:

Thanks all for the quick help on this!

1. Investigation questions

Yeah it won't be possible to get unique references from the regular expression search; we'll need to do something a lot heavier, and parse the HTML (which is not performant on every request; so we'll need to find a way to do that that's more performance, potentially in the save operation if needed).

I am ... kinda torn with whether the demo should have those or not, honestly... you could make the point that adding those would HIDE this problem, which means that developers would expect this problem to work out-of-the-box when they use it in their system, rather than ... maybe realizing that it's not the widget's responsibility, it's a property of how we organize/define texts.

I guess a <bdi> can help here by assuming that "1 one" is LTR and "1 אחד" is RTL regardless of the ltr/rtl general context (the one we flip with the toggle)...
But it will stil "fail" on things like "one שתיים" etc. In these kind of cases, you want to create internal isolations, etc, which... well... it's a bit much for the demo, and won't work when you take the value of the label from a textbox.

How is the imageinfo API workign with that, though? does it call the parsing of the DOM for the image or does it have some stored value? it sounds like the DOM manipulation is a pretty heavy operation, are we not storing those things somewhere for the imageinfo API that we can then utilize for the Attribution API?

I wrote this in the epic, but repeating here as an iterative plan:

To make this more iterative, here's my suggestion for MVP/step-one:

Similar to the author information, for a first iteration, we can use what imageinfo provides, since it is, if nothing else, somewhat consistent with VisualEditor and MediaViewer, and is a cheap first step that probably gives us correct results about 90% of the time.

For a first iteration, we can use what imageinfo provides, since it is, if nothing else, somewhat consistent with VisualEditor and MediaViewer, and is a cheap first step that probably gives us correct results about 90% of the time.

In T417674#11641004, @Ottomata wrote:

~~Just FYI: https://doc.wikimedia.org/generated-data-platform/aqs/analytics-api/reference/edits.html#get-number-of-edits-to-a-page~~

Sorry, that is just # edits.

Yup, welcome to BiDi (lolsob) numbers are auto-aligned differently than alphabet/letters. Ideally, we would not mix them in these contexts.

That's definitely something we could look into, or we could try and get something similar to "PageViewInfo" from AQS but for the contributor count (they have already an API endpoint). They, however, *also* have time limits, though it might be easier to look for expanded timespans than doing that within MW...?

Just to clarify -- while this will likely be used by Enterprise, I don't think they'll be calling it on every hit on THEIR API, I think they may use this when they do their periodic fetch + every time a page changes/gets edited.