Fixed by the patch for T306862

In T326071#8657491, @Ovvldc wrote:

I get errors very reminiscent of this problem when I try to use the refreshlinks.php maintenance script in the new version 1.39.2. Is that coincidence, or is the bug still somewhere? And if so, do I need to open a new bug?

Should be resolved with or without the linked patch? It got +2 but the parent change was still pending review.

Recalling T203583 and commit 465954a, maybe the misleading comments should be removed.

Note: This works for pre-save transform ({{subst:REVISIONTIMESTAMP:{{subst:PAGENAME}}}}) before commit 5cb4693, because fake revision was not yet set up during PST.

In T320338#8334752, @Shizhao wrote:

The previous version was not like this. Used {{REVISIONTIMESTAMP}} on edit notice for several years in zhwiki. The problem has only recently occurred. see:
https://zh.wikipedia.org/w/index.php?title=Template:Itn&action=edit
https://zh.wikipedia.org/wiki/Template:ITN-Update

In edit mode, {{ITN-Update}} in edit notice shows "0 seconds ago"

In T328838#8641322, @Winston_Sung wrote:

The guessVariant function is already considered a bad practice and will not implement in Parsoid.

In T330409#8641330, @Winston_Sung wrote:

I think it's already a long-time unexpected issues and side effects, especially for the main page problem.

You should have on-wiki discussions first.

In T328838#8641098, @Winston_Sung wrote:

I think there should always be NO badly mixed translation memories (TM). It's always a bad practice for translators.

In T326997#8641093, @cscott wrote:

How exactly is PageContentLanguage different from UserLanguage?

This should be declined.
The Translate extension and other components should try to address the issues you mentioned, not asking translators to translate into multiple variants of Chinese.

@Winston_Sung Please extend the task description. I assume this is for multilingual wikis, am I right?

The default message is Intended blockee for a long time, and only have a refactor recently (but the parsed result is the same).

Can you give the use case? I saw the one in Special:Preferences works fine with styles from mw.widgets.TagMultiselectWidget.base.css

That's not how task triaging works.

I finished the import with the patch applied, but I noticed that around 1.15G of memory was consumed by ParserObserver->previousParseStackTraces after around 151000 images were imported.

I want to mention https://github.com/nbdd0121/MW-PinyinSort, not sure which one works better, the patch here or the existing extension.

Seems fixed by refactors, though I found a new bug introduced by refactors, will file a report and submit a patch for it.

In T326071#8556045, @Tgr wrote:

@Func this is fully fixed now and just waiting for a point release, right?

I can still reproduce the case I found with Timeless skin and the latest Chrome in my laptop screen size, and I have more information to share now:
In the screenshot below, the 2em of padding was added to .CodeMirror by Timeless. We can see the edge of elements matching the selector .CodeMirror * is uneven, and somehow the position of line breaking was different compared to the edit area.

Noticed this in some build artifacts of test failure when investigating T324879, I thought that was some unexpected state of the CodeMirror since it was not fully loaded/unloaded before typing.

In T326813#8540894, @Jdforrester-WMF wrote:

This was fixed in OOUI's v0.46.2 release (e.g. https://gerrit.wikimedia.org/r/c/mediawiki/core/+/880992/1/resources/lib/ooui/oojs-ui-widgets-wikimediaui.css for the particular line you noticed).

I think the patch should be backported to 1.39, so I cherry-picked it to the v0.44 branch of ooui.

In T291656#7424733, @Jdlrobson wrote:

There is no way to easily determine which skins this setting applies to.

No, this message is only for the database limit, which is fixed to 65530.

So, somehow wikimedia-ui-base.less was not updated in the MediaWiki core for 2 previous OOUI updates?
It was bumped to 20.0 by commit a222a13 which contains the fix (3e13426), and then we have cd023d2 and e1d7d17 in the ooui side, f8a7e46 and fc0acab3 in the core.
What's the process of upgrading ooui in the core? manually? without CI checking?

In T320296#8540271, @Daimona wrote:

Commit d716fee for CampaignEvents extension added more validations, do we need that in core?

I would say yes

This is by design.
This parser function would try to use the link cache, if it found matches then return early without increasing the counter or checking again.
You added internal links to each page, then the existence was checked and recorded before processing #ifexist.
Note: The cache would be kept for a while, so if you remove links, would not reflect as too many expensive function calls instantly.

In T320296#8302256, @Daimona wrote:

We would also benefit from proper error handling in CampaignEvents.

In T302200#8532931, @Jdlrobson wrote:

@Func is there a page on the beta cluster we can QA this on?

Unpaired escaped quotes would not affect anything.
As you mentioned before, there is only a blank call to mw.user.options.set(), which means nothing to do with js on the client side, but failed to encode json in the backend.
API was designed to give an output when the error is not fatal, so it would normalize the string; while the resourceloader is strict on encoding json.

I reproduced this bug, the problem is how the database truncates the string. I saw a broken Unicode mark at the end of it when retrieving options from API, which means a Chinese character was truncated in half.

Lower the priority since backported.

In T326696#8526256, @LuciferianThomas wrote:

Setting it to a blank string fixed things... I think.

You can save a copy of your current preferences via Special:ApiSandbox#action=query&format=json&meta=userinfo&formatversion=2&uiprop=options and check if there are any suspicious values.

In T326788#8524690, @stjn wrote:

This should be backported as soon as possible since wikis like French Wikipedia currently don’t have language switching at their main pages:
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal

Too many tasks, these two are nearly identical.

In T54429#8522573, @Winston_Sung wrote:

Due to technical limitations (there should be only one canonical for one variant), it is controlled by the $wgVariantArticlePath configuration option.

In T54429#7981483, @YLJ wrote:

I would suggest we remove the canonical url.

Kindly refer to this discussion on Search Console Help

The combination of such subtle differences with correct implementation of hreflang and country targeted folders should exclude any necessity for canonicals anyway.

https://support.google.com/webmasters/thread/130615008?hl=en&msgid=130651877

Impact of commit d39b5c9 for T316559.

Cool, blank call to mw.user.options.set(), that's interesting. I will try to investigate later today.

The log provided seems not helpful to me, but the description reminds me of T311799. You may try to follow the reproduce steps and my debug suggestion, and share more information here.

The patch is for MoblieFrontend, I think this should not fall into tracking tag.

In T326829#8520561, @Jdlrobson wrote:

T302200 will require changes in Extension:Translate .

Sounds like this can solve T302200?

Duplicate of T294716, https://gerrit.wikimedia.org/r/c/mediawiki/core/+/735753.

Similar to T326591.

After studying the log provided in T326071#8493256, I found that the problem is bigger than I thought.
The problematic change would destroy the database when updating from versions before 1.33, though not in the way mentioned in T326071#8493877.

I would like to mention commit 24115a8f4cc0f079f30894bc07eb7476f2dffb3e, it removed the revision_actor_temp table, but the maintenance script was not updated and still try to write to that table rather than the rev_actor field of revision table.

Resolved. 1.37 was EOL, so no backport.

For your second error on 'revision.rev_comment_id', it was fixed in T297031, you should try to use the last release of 1.37 instead.

The rev_user field was removed since 1.35, you may try to use populateUserTable.php provided by the StubUserWikiAuth extension. It supports using the actor table to populate the user table.

Patch merged.