In T116561#5701530, @thiemowmde wrote:

https://www.mediawiki.org/wiki/Manual:Coding_conventions#Line_continuation currently reflects this by saying "The operator separating the two lines should be placed consistently (always at the end or always at the start of the line)."

How can MW developers access the output of currently-runinng (or recently-completed) scheduled maintenance scripts that execute in Kubernetes?

@Ebrahim That is a very large patch indeed. Fortunately, that is a link to a mostly unrelated (and not merged) pull request to solve a different issue.

In T353817#9961942, @Ottomata wrote:

Move docroot/mediawiki.org/beacon/event/index.php to w/beacon.php

@Joe, to not squat w/beacon.php, in case there are other usages of /beacon that we'd want to route, would this perhaps be better at w/beacon/event.php

Questions to think about:

• When looking for the normalized message across mediawiki-errors Logstash dashboard, does it affect specific domains, hosts, data centers, or {module} values more than others?
• How long do the peaks last?
• Does it have literally zero ocurrences outside the peaks, or is there a continuous trickle at a lower level as well?
• Do the peaks happen at a regular interval?
• Do the recurring peaks align with any recurring SAL entries?

The bootstrap-3.0.3 test case is enabled in CI and thus passing in the context PHPUnit and compare.php as a fixture:

In T368921#9946169, @Jdforrester-WMF wrote:

Can you write a stylelint-config-wikimedia rule to detect (and ideally auto-fix) this?

We discussed this in the MwEng-SvcOps meeting (13 June 2024). Extstore was enabled on a few hosts in the DC. Some stats differered, but we weren't able to come up with a testing strategy to prove or disprove an observable benefit from the MW application in this state since keys are sharded across all hosts, and traffic generally involves many different keys.

Marking this as resolved since the review was completed above. Feel free to ping me in Phab or Gerrit with questions on follow-up work, or ask in our team channel on IRC.

Re-tagging for triage. Up to team to triage accordingly. (I'm cleaning up an old note pad, this isn't time-sensitive or related to me.)

/docroot/wikimediafoundation.org/.well-known contains a matrix/server file.

This redirect is coming from Apache and known as DirectorySlash. It's a way to make sure that directory index responsees have a reliable and consistent way that relative images, hyperlinks, etc are resolved.

In T362425#9922153, @Lucas_Werkmeister_WMDE wrote:

In T368385#9921825, @kostajh wrote:

Is it possible to specify a fallback source […] only used in CI context?

In a change where the foreign resources are touched, […].

In a change where the foreign resources aren’t touched, I think the test serves almost no purpose […].

(Moving per Roan's comment on Gerrit. Awaiting updated patch before I can re-review/test.)

In T242712#9919028, @Ottomata wrote:

SULWatcher does not rely on creations happening on login.wikimedia.org. In reviewing its code, I find that it is using stream.wikimedia.org and looking across all wikis for newusers log events

Really!? Interesting. Link to code?

In light of T348388, I'm checking to make sure SULWatcher does not rely on creations happening on login.wikimedia.org. In reviewing its code, I find that it is using stream.wikimedia.org and looking across all wikis for newusers log events. The reason this doesn't double report auto creations is that autocreation skips the RC publish step (as detailed in T242712#5858564). Even if we did RC_publish them, SULWatcher coudl be easily fixed by checking for newusers/create specifically since we do differiate that subtype from newusers/autocreate already.

I'm proposing this as a maintenance task next quarter to take on between Hannah and Derick (writing and review, respectively).

These are examples of issues that this improvement would have avoided or reduced the priority of:

• T351610: Support minification of ES2020 Nullish operator syntax
• T343499: Add minification support for async-await (ES2017)
• T287526: Minifier can sometimes split "..." spread operator (affects Vue 3.1.5-compat)
• T277161: Minify v2.2.0 incorrectly minifies vue.js (faulty line break resulting in early return)
• T201606: Bad newline after return statement by JavaScript minifier
• T34548: Possible bug in minifier: exponents can be incorrectly broken across lines

In T366917#9903501, @BTullis wrote:

[…]
So I suspect that it should still be fixed. The repository from where the code runs is here: https://gerrit.wikimedia.org/g/performance/asoranking
@Krinkle was the last person to commit to that repository, so may know more about this report and what should happen to it.

I think in the past it was not uncommon for power users on larger wiki farms (i.e. Wikipedia and WMF projects) to have a user page indicating preferered ways to be contacted, especially when they're not active on that wiki. E.g. placeholders like "contact me on Meta-Wiki instead of here as I won't see your message otherwise".

The /zh-cn/ path is for automatic language variant conversion. This is enabled on certain wikis only (incl zh.wikipedia.org). This displays meaningfully different text in the article content body, and gets its own canonical URL in the HTML. E.g. compare https://zh.wikipedia.org/wiki/關東地方 to https://zh.wikipedia.org/zh-sg/關東地方 (linked from the variants menu in the toolbar), which contains notably different characters in the content, and each have their own <link rel=canonical>. This conversation resides close to the Parser and is part of the MediaWiki-Language-converter component, both maintained by the CTT team under MwEng. I don't think this component is playing a role in what URL Google is displaying.

Tagging CTT for scope (ParserOutput support). Tagging @daniel since he started the work previously. Feel free to un-assign or forward if someone else can/should work on this instead.

From a quick glance, it seems support was added in core. I don't see a change in TemplateData to use it. A draft change for it was abandoned/reverted.

The filters are (if I recall correctly) fairly efficient and allow batch queries. Otherwise we could not filter the list of changes by it in production.

In T342267#9899857, @mforns wrote:

I think "Other" is not a good name for that bucket. […]
But actually, the current "Other" bucket in, say, ("Windows", "iOS", "Android", "Other", ...) does mostly contain requests from "Windows", "iOS", "Android", etc.
So, I think the name is misleading. […]

Fake input data to better understand "Idea 1" for T342267.

Might get to this next quarter with @Hokwelum as part of focussing on MW tech debt and onboarding with RL, along with T343492: Phase out SqlModuleDependencyStore.

The installer has historically been associated as being "for third-party support". In recent history we've reframed this to also be seen as an essential part of Quickstart, dev environment, contributing (e.g. Hackathon events., and onboarding (incl for WMF staff). While this doesn't mean that the installer now has an owner, it does mean it's now more normalized for individual teams to improve/fix things as they see fit when it also benefits these other use cases.

Apologies if I'm asking too soon, or if this is already taken into consideration...

In the FSG meeting yesterday, @Catrope, @lwatson (Design System Team) and myself went through the various ways jquery.chosen is used today (Codesearch). Removal of the module may still be a few releases out as migration is non-trivial and we haven't started deprecation yet. But, keeping it without replacement is cheap. More important is the general direction we want to go in. We agree that we do not want to support a standalone replacement for jquery.chosen. Generally speaking MediaWiki core should not be shipping (new) standalone UI component libraries, besides OOUI/Codex.

Jdlrobson removed a project: MediaWiki-Platform-Team.

In T367103#9878184, @Od1n wrote:

development of https://github.com/leafo/lessphp seems to be almost stale for 10 years…

Keeping on radar, as I did testing and code review for this and the other stacked patches related to it.

As part of a review at https://gerrit.wikimedia.org/r/c/mediawiki/libs/less.php/+/1038745/6/test/Fixtures/lessjs-3.13.1/override/math/strict/css.css#72, I found a change related to calc() that might be relevant or useful.

Can/does the site in question communicate their enforced limit in an HTTP standardised and machine-readable way? For example, a 429 Status with Retry-After header, or (even better, to avoid hitting a failure first) a crawl limit in robots.txt.

We've previously removed commands when promoting them to the default. Installing both sounds good to me as well. I'd suggest literally installing twice for simplicity and portability of the installer.

@Ahecht Are you thinking of using this in the context of a gadget?