The code path looks unrelated to the issue you encountered.
Are you unable to remove a preference via Special:Preferences, or do you literally mean a pref named someprefname-local-exception that initially registered via API?

@matmarex Thanks for the pointers. With display: flow-root, we are free from the alignment and resizing issues of the previous attempts, and I made some improvements for smaller container sizes just now.

It's very unfortunate that the original patch for T360589 got merged, the test cases are so broken and assert the wrong behaviour. And the unchanged size was used for the actual scaling, so now we have thumbs smaller than the claimed size in the production storage.

Same underlying issue as T276855

I tried to reimplement it using flex layout, but it seems impossible to replicate the intended behaviour of the current implementation: "for the elements in the last row, only grow if they can fill the row nicely within their max-width, (grow to the average zoom factor otherwise)".

In T402959#11556928, @bking wrote:

WDQS is under attack again, and I have re-implemented the stricter rules that block (or at least attempt to block) bot traffic. Apologies once again for the anyone who was disrupted.

This is blocking changes on MobileFrontend: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php82/22563/console

In T411459#11443300, @cscott wrote:

Just bumping the cache version would be sufficient for the 1.39 to 1.43 upgrade, wouldn't it?

Final diff with only trivial diffs: P86446, filtered with change 1216181 for a cleaner diff.

Oh, I am not familiar with this area. I filed for MediaWiki-Codesniffer just because they mentioned that particular sniff, which may also need to be fixed.

Just run the diffConfig CI on change 956060 again, the diff is huge, at P86437

Rebased - merge conflict due to moved files.

@Chuiimuii_ofc Please don't abuse the Gerrit system.

Oh, I didn't think of backports. @Reedy, should we update the version numbers for wfDeprecated to minor versions of the next release of each branch?

In T401080#11416438, @Bewfip wrote:

rebuildLocalisationCache.php accepts the parameter --lang. You can limit it to the languages of interest.

Currently, setting manualRecache to true requires running the rebuildLocalisationCache maintenance script for all the languages; otherwise, messages would be in English if the language requested is not cached.

In T410217#11376986, @SD0001 wrote:

Will be fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1205720 and/or its parent.

Sorry for taking this over, I think it's just easier to fix my oversights on the original implementation (b67c7962) myself with solid comments, along with some other quirks I found.

In T391882#11376547, @Chuiimuii_ofc wrote:

i am aware but I wanted to create a fresh commit for my better
understanding of the code as im new to this

@Chuiimuii_ofc You can always update existing changeset (with git commit --amend and git review -R) instead of creating a new one.

I can't reproduce this anymore (of course, for other language codes without their subpages created). I think this is fixed by my work on T229992, because all languages have implicit fallback to en.

In T229992#9409518, @Xaosflux wrote:

Reject closure due to the unresolved concern I re-raised above. If it needs to be split out, that should be done first.

Described different problems with different root causes.

There are some files now with duplicate @license tags, e.g. includes/libs/HtmlArmor/HtmlArmor.php

Example of EXPLAIN query outputs as requested on Gerrit:

In T407593#11285938, @Jdlrobson-WMF wrote:

This is intentionally blocking by design. Without it sections will not be expandable on mobile until all the HTML has loaded which is a problem on slower connections and larger pages. You can replicate this by loading the page France on a 2G or 3G connection and trying to expand a section as soon as the page loads.

Stalling for now as the patch doesn't match the problem statement in this ticket (please reword or create a new ticket given this new nformation)

In T170659#4568391, @Bugreporter wrote:

API also returned (already passed) block status:

https://www.wikidata.org/w/api.php?action=query&list=allusers&aufrom=GZWDer%20(flood)&auprop=blockinfo&aulimit=1

This may confuse other bots and external tools which do not check blockexpiry.

Why changing to {{#pageviewlanguage}}?

Since marked as skipped

In T296188#10993978, @gerritbot wrote:

Change #1118140 merged by jenkins-bot:

[mediawiki/core@master] MessagesZh.php: Using English special page names by default

https://gerrit.wikimedia.org/r/1118140

I saw this twice today.

(fix edit conflict(?) on subscribers)

I think we should also fix the Sanitizer::safeEncodeTagAttributes function, it's not as safe as it sounds, if at all.

In T46667#11055254, @Winston_Sung wrote:

We would actually need pages to be able exist in multiple sort keys at the same time (e.g., "章" has 2 defined radicals "音" and "立" ) to completely get the feature work.

In T46667#11052753, @Func wrote:

With MediaWiki 1.36+ requiring php-intl, at least for Pinyin and Bopomofo, we can use transliterator_transliterate directly without fiddling with ICU, Unihan, etc.

With MediaWiki 1.36+ requiring php-intl, at least for Pinyin and Bopomofo, we can use transliterator_transliterate directly without fiddling with ICU, Unihan, etc.

This can also be a Debian 13 support issue, some MW installations may have had $wgLocaltimezone set to deprecated values like PRC by the installer or manually. After they upgrade to Debian 13, the tzdata package no longer provides these timezones, and the tzdata-legacy package is not to be installed by default.

It's also possible that some error thrown after $this->mTablesLoaded was set to true, but before $this->mTables is actually set. If something outside caught the exception and didn't fail the request, the next call to the language converter would have the initial value of an empty array.

Request URL: https://meta.wikimedia.org/wiki/Special:Contributions/80.128.0.0-80.146.159.255

@dcausse Sorry for reopening, could you fix Q23809290 (diff) too? These two edits happened at around the same time. I guess updates between these (and probably some before and after) are also missing, but they are not on my radar.

example 2