• Possible pushback on this
• Question on where to get the imaged from
• We cannot provide images outside of our production systems

Ref: https://www.mediawiki.org/wiki/Manual:$wgRightsIcon
https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/CommonSettings.php#555

• There's varying levels of granularity for this.
  • Modules may want to define reusable schemas, we may want to have truly global concepts defined e.g what is a title in Mediawiki? and then the title be consistent across all mw.
• First off in the openapi spec we should be able to atleast have the reusable components within the openapispec
• Should probably start as a spike limited in time so we don't overstretch.
• $ref could help us solve this for the handlers - can we use it to merge stuff or do we have to have the logic separately within the framework?

• While documentation says creating a new Message class without passing the language "defaults to current user language" - that happens within the getLanguage call and flow which is not a call we make for the attribution case
• On commons we can have 3 languages, user, page and project - We might be slowly mixing these together. We want for attribution to ignore the user language.
• Spike question: Do we always want to stick to page and project language..?
• On the unified front door with the rest sandbox being dynamic will need to request specs based on the user's requested language for the site e.g if user chooses Spanish they'll be getting everything in Spanish
• More clarity required from Halley on the immediate goal of the spike.
• We expect that majority of calls to our signas will be anonymous - not logged in
• We should fallback to content language
• End goal should be to make the language requestable - pass it in the request to the page and site signals(very soon/couple of months) for Unified Front Door(Project FroDo)

Thanks for the patch @VadymTS1

• It would be great to have this before 1.47 release process starts
• We may not catch the npm upgrades with this so will have to do as is

• Adjusting a regex or 2 and a tiny code tweak that maps functionality sets to audience designations
• Almost a housekeeping task..other heavy lifting should be already done by the time we take this up

• Could be about comparing what we have with the standard industry spec
• To refine later with Kamil

• There's already a rule in the underlying ruleset and we should just cancel it.
• Sometimes the harder thing is how to make the rule recognise the right structure.
• During estimation we should give ourselves some leeway

• No config changes meaning it won't be displayed on the REST Sandbox
• Good for onboarding onto REST modules
• We could get the Product Safety and Integrity to review the patch
• Should we then remove it from the extension json so it does not appear anywhere?
• We are just matching what we have right now

• We'll have to think about how much we have to do here v/s automating
• We are not yet supporting much caching for authenticated users
• As long as this is "don't send dumb headers" this should be a simple coding task
• To revisit previous patches to extract the simple first solution before next year's major caching SPIKEs

• We usually rollback because of an error but the rollback itself should not also error out.
• These should usually be suppressed, just logging them is enough no need to raise errors.
• Not simple fix enough for chore duty so will have to add this to a Sprint to account for the time.
• Fix to include unit tests

Hi @Ottomata Is there more work to be done for this apart from the already merged patches?

This is poassibly resolved since T386208 was resolved.

Patch merged. Marking this as Resolved.

• We have short, url and usage terms that can be used as long. This information does not exist everywhere e.g per project request has only short.
• We need to provide some config to store short and long form
• Images return as different content as articles one coming from metadata hence forming the short v/s long difference
• Check T417664, T420784, T421051 for more info

• Implemeting a method to trigger statsd to push the stats(prometheus_
• Next part is in grafana to expose these metrics
• We should align on overlaps with T421905

• Depends on T422508

• Idea is to optimize handler by passing the data builder as a service.
• The data builder is currently extremely hard coded to page signals. A possible follow up is to generalize the builder for other use cases like site signals.
• The tracer will also have to be passed since it is per request

• Some of what's listed here might already been done.
• This is about putting prometheus calls inside the if statements..it's very specific to the listed stuff e.g how many times do we not get the data.
• We want to see the shape of data - how many times do we have cache misses

Update on this being a blocker to launch::

Picking this up as part of T421891 so the new Handler injects the builder as a service

Noted. Then moving it to Radar for us.