In T345793#9370793, @Ladsgroup wrote:

@Ammarpad Add me as reviewer, I'll take care of it.

Already reported at T345793 which I intended to fix but forgot. My approach in the uncommited change was to convert the user-provided offset to DB timestamp and proceed if it works, otherwsise return no result (as does MySQL currently). That seems easier for the short term, but changing the field would be more effective long-term.

bl_timestamp is field alias and WHERE clause can be evaluated before the alias is created

On the translate subpage, if $wgSecurePollTranslationImportSourceUrl is set, there's currently a message that presumably claims anyone can 'import translations'

It depends on how you're making the request.

In some cases that's even desirable, see T257966: URL shall be terminated by %2E or _ if page name ends with dot

doesn't test what it is supposed to

So what should it test for and what is it testing now?

MobileFrontend already provides its own navigation links and now core navigation links are also being shown

Seems it's still happening https://gerrit.wikimedia.org/r/c/mediawiki/core/+/971331

There's uptick of these warnings. In PHP 8 they will be elevated to ValueError exception

@Jdlrobson do you think the fix in T348539 will allow re-enabling this test?

In T327007#9293743, @Reception123 wrote:

an extension that is currently broken as a result.

Which extension? I can't reproduce the issue

Thanks, this has been fixed in T301632

@Xiaotai99 Please copy the complete exception trace and add it to this task.

There's also recent repeated failure in Math repo because of this. It seems no one is interested in fixing it. I think it should be disabled like the other test in the suite T313775 which was disabled with even lower failure rate.

@Aram, on which wiki?

This is happening at greater frequency now, adding @zeljkofilipin who will know better

In T348539#9260801, @Michael wrote:

Not sure if this is (almost) the same as T313775: MinervaNeue "Wikitext Editor.Closing editor (overlay button)" test is flaky?

In T346332#9237344, @Jdforrester-WMF wrote:

does this need back-porting to REL1_40?

done

In T348934#9253387, @Karima wrote:

@Ammarpad Thanks. Do you have an example in another extension?

See https://www.mediawiki.org/w/api.php?action=help&modules=shortenurl. The url parameter has description, which is defined at UrlShortener/i18n/api/en.json#9

How can I check if it's fixed in local?

Visit api.php?action=help&modules=pushallinfo locally. You'll currently see something like

This is due to missing API parameter description messages.

Please add browser and version. I suspect this is a duplicate of T277904

Probably more fallout from T345766. See T348530

Likely caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/935761, which does not have associated phab task.

This task (just like T196861) is also duplicate of T164357 (which is the oldest task).

This is essentially the same issue as T164357

This redirection is prevented by $wgDisableHardRedirects, which is true on all Wikimedia wikis save DonateWiki.

See T164408. Apparently that did not happen. So it needs special casing in the installer.

I actually don't think this requires any community consensus. Why are notices selectively hidden? I believe wgMinervaEnableSiteNotice was supposed to be temporary flag. If a community doesn not want to (for whatever reason) show notices on mobile there's already nomobile class which I believe works.