The date is incorrect on my side even with JS disabled. After looking into the code and tested locally, I have a clue and patch for it.

Do you have any errors in the log? Once I found the categorization didn't work in my test environment, after looking into the log, it's turn out that I forgot to run composer update and lacked php polyfill.

Something wrong with the REST API.
I can get the correct extract result using action API and the Accept-Language: zh-tw header: https://reqbin.com/cmpdc9g6
But not for the REST API: https://reqbin.com/6vrlbysc

The conversions mentioned in the description are implemented by Module:CGroup/IT.

Need a backport: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/772370

After this patch, local message overrides can use $2 for links:

Page '''[[:$2]]''' has been deleted {{toolbar|[[Special:Undelete/$2|view]]|[{{fullurl:$2|action=protect}} salt]}}.

I got something, in total we have lost 61 pages:

1. all move action to blame https://quarry.wmcloud.org/query/64337
2. all affected (gone) page IDs https://quarry.wmcloud.org/query/64341
3. revision info of the root page https://quarry.wmcloud.org/query/64326
4. revision info of all pages https://quarry.wmcloud.org/query/64339

oh, that script only handles completely missing actors now, not broken ones.

In T307738#7908935, @Func wrote:

actor id is the last one, 3215898

In T307738#7908040, @Ladsgroup wrote:

FWIW:

wikiadmin@10.64.16.208(enwikibooks)> select * from revision where rev_actor =0 limit 5;
Empty set (0.001 sec)

Possibly system users?

And we have some bloated SVGs get merged recently (7ce1a48).

Maybe same as T209249

Backport deployed.

Merged on the master branch after the train cut, need a backport.

I can confirm this is fixed on Windows Edge 101.0.1210.32

Weird, I am able to "add" it without removing it first.

oh why there are so many subscribers?

Direct construction with args is only used in tests, should be fine to be converted to service for T306707.
https://codesearch.wmcloud.org/search/?q=new%20SessionManager%5C(

SessionManager singleton stored an outdated ObjectFactory instance.

The service container can be destroyed by MediaWikiServices::resetChildProcessServices() which is used by ForkContoller in the core and the Translate extension.
It turns out that storing a service container instance or using closure to avoid circular dependency in ServiceWiring is not a good practice.

It seems related to ObjectFactory, a workaround found via code search: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Workflows/+/766127/3/src/Definition/Repository/DefinitionRepositoryFactory.php#20

This is a context caching problem same as T302754 but less harmful and unnoticeable.
When a page is linked in sitenotice, there is a chance that a user visited that page and the parsed notice is cached for a while, especially for a popular page.

I don't want to say this one is resolved, there are a bunch of Chinese wikis that have overrides in site js, I think logo variants can't be widely used without the fallback chain implemented.

In T305531#7834854, @Nikerabbit wrote:

I was under the impression that nobody uses <translate> tags in the MediaWiki namespace. However, search says that I am wrong: https://global-search.toolforge.org/?q=%5C%3Ctranslate%5C%3E&regex=1&namespaces=8&title=

I do not consider this a supported use case. I think these should be migrated to other solutions (which have known issues, but we can look into fixing those). For short term, the revert is the best option.

Well, there is another issue that makes me not feel very good, we can see MediaWiki:Group-$group.js is executed after the user's js, is that intended?
I think MediaWiki:Group-$group.js is site-ish and should be executed at least just after <skin>.js. (Though this should be a different task.)

In T305594#7837285, @Od1n wrote:

There is something I don't understand: as VectorResourceLoaderUserModule extends ResourceLoaderUserModule and completely replaces the function getPages(), aren't we missing loading some things such as $userPage/common.js and MediaWiki:Group-$group.js?

With all filters disabled (https://en.wikipedia.org/wiki/Special:Log/MZMcBride?wpfilters%5B%5D=review&wpfilters%5B%5D=thanks&wpfilters%5B%5D=patrol&wpfilters%5B%5D=tag&wpfilters%5B%5D=newusers), this query is way faster.

Per T108443#6279559, T294716 is likely to help, but the patch connected needs to be amended, and the owner of it seems not active.

In T22807#7826975, @Winston_Sung wrote:

Would it be better to use "language" than "variant" for the key name?

Per uselang=qqx, they are fallback to [[MediaWiki:talk]].

Patch for T131300 caused this.

Weird, did the backport conducted properly? It sounds like change 775437 was being applied for a while, and somehow was overridden by another patch?
cc @Lucas_Werkmeister_WMDE

In T273578#7820241, @Jdlrobson wrote:

@Func would you be able to take care of the configuration change for this so we can QA it on the beta cluster ? https://zh.wikipedia.beta.wmflabs.org/

In T302627#7815572, @Jdlrobson wrote:

There was never official 3rd party support for skin versioned Vector. We can backport a change to skin.json to set VectorSkinMigrationMode and VectorShowSkinPreferences to false as a cautionary measure if we're concerned.

@Jdlrobson What about the 1.38 release branch, I think my simple patch should be enough, or you want to backport that big change?

@Krinkle Your test is done before or after the wmf.5 branch roll out?

Simply add var_dump($text); in PageTranslationHooks::renderTagPage() and visit history page of a translated page (language subpage),
then you can see:

In T302754#7814294, @Nikerabbit wrote:

That page is not a translatable page. I'll investigate some more.

Sadly we have a remaining conversion problem on T303855, but this should be fine to close.

Ok, I see. The change 755813 didn't catch up or backport to 1.39.0-wmf.4.
@Jdlrobson You want to backport them or wait for the next train?

In T302627#7808369, @Pythoncoder wrote:

Then I selected "Vector legacy" and clicked Save, and it reloaded the page still in Vector 2022. The menu now looked like this, with Vector 2022 still selected but the top two rows switched:

In T285216#7806550, @Majavah wrote:

Hmm, all of the requests I just checked on logstash with this warning were new account creations. Maybe some race condition somewhere?

Tag MediaWiki-extensions-CentralAuth since the lookup is implemented in it.

Hi, does this still happen frequently these days?
It's weird that an error that can cause a great difference in the appearance of UI is suppressed to a warning in advance. T302627 can be caused by this.

I think we need more information about T285216, which mentioned sometimes it failed to find a global ID for the user, which means it failed to load global preferences to override local ones or sites' defaults.

In T302627#7798495, @Jdlrobson wrote:

• If I go to https://en.wikipedia.org/wiki/Special:GlobalPreferences I see my current skin is set to Vector 2022 but when I try to change it to Vector legacy it doesn't work.

It seems only DateInputWidget supports placeholder.
https://doc.wikimedia.org/mediawiki-core/master/js/index.html#!/api/mw.widgets.datetime.DateTimeInputWidget
https://doc.wikimedia.org/mediawiki-core/master/js/index.html#!/api/mw.widgets.DateInputWidget-cfg-placeholderLabel

I noticed the input fields look weird (namespace dropdown disappeared), and I managed to move it with js disabled.
Please check out site js, since I can see a normal input with safemode=1 in url.

Also, they don't have "Reverted" or "Manual revert" tags where they should have respectively.

Maybe it's a regression, update after mass deletion works well a year ago:
https://www.mediawiki.org/w/index.php?title=Wikimedia_Technology/ru&type=revision&diff=4445234&oldid=4445226&diffmode=source
https://www.mediawiki.org/w/index.php?title=Wikimedia_Technology/ru&type=revision&diff=4445251&oldid=4445234&diffmode=source

This can't be resloved as a part of T295187, reopened with a more accurate title.

The section name can be different on the translated page, it's very likely that you can't go to the desired section even if the fragment is preserved.

It should be short-circuited at Translate/tag/PageTranslationHooks.php#66, but the expected title for message parsing in load.php (Special:Badtitle/ResourceLoaderContext) somehow is overridden and passed all the checks?

Already have in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/114066, 'options-messages' param.

It can work on real mobile devices and mobile simulation mode on desktop, but not pure desktop.

This is a feature: T212197