mediawiki/extensions/AbuseFilter also seems to have problems, the problematic ref is refs/remotes/origin/wmf/1.44.0-wmf.20

In T389915#10675083, @jrbs wrote:

In T389915#10672660, @0xDeadbeef wrote:

Just noting here that the proposed dates could clash with UCoC Enforcement Guidelines and U4C Charter Annual Review vote. (per T388931)

This is OK so long as zhwiki doesn't need votewiki's interface to be in zh. We can still translate the ballot ("support", "oppose", etc) as usual.

The icons to be submitted may still require some discussion.

In T161859#10541035, @Ladsgroup wrote:

In T161859#10540850, @SunAfterRain wrote:

In T161859#10537549, @SunAfterRain wrote:

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

So I would like to ask if it is possible to undo it?

{{done}}

Thanks.

In T161859#10537549, @SunAfterRain wrote:

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

In T385860#10534093, @Dylsss wrote:

While duplicate categories to the same OutputPage should probably be de-duplicated in general. It also isn't correct that adding an interface message to an OutputPage adds its own categories to the category links of the OutputPage. See for example https://patchdemo.wmcloud.org/wikis/5293491307/wiki/MediaWiki_talk:Talkpageheader which has Category:Noop from the interface message, but this is actually a red herring as the page is not actually in that category.

After discussion, we think @Shizhao misunderstood, so I reopened this task.

In T384827#10509688, @sbassett wrote:

Er, writing ad-hoc javascript tokenizing and ast code is probably not what I would have recommended. That kind of code is typically extremely complex and often presents unforeseen attack surfaces and vulnerabilities. We literally just went through this with the Graph extension and its Vega dependency. Is there perhaps a less complex solution that doesn't involve giving the user access to an arbitrary javascript expressions layer?

Will the Two-factor Authentication previously set up in Wikitech still be effective for LDAP, or will it become invalid along with the migration to SUL?

https://zh.wikipedia.beta.wmflabs.org/w/index.php?title=Template:Navbox&oldid=8047 has an error message: "The text of this revision is missing or corrupted." Although the error content is somewhat different, could it possibly be related to this task?

Thanks for taking the time to investigate.

In T363087#9739890, @taavi wrote:

Since /data/project is a symbolic link to /mnt/nfs/labstore-secondary-tools-project on Toolforge, some tools such as pnpm will write /mnt/nfs/labstore-secondary-tools-project instead of /data/project to the file, so that it cannot be executed in the container.

Does this happen if you run pnpm inside a container?

Sorry, I accidentally forgot to turn off the notification option, please ignore the demo above.

According to simple research, wgContentTranslationPublishRequirements is only used on the Web side, and no interception is performed on the PHP side.
mw.cx.init.Translation.prototype.checkIfUserCanPublish to verify whether it is published in the main namespace is only used by the onNamespaceChange hook (mw.cx.init.Translation.prototype.onNamespaceChange) and the hook does not seem to be triggered during initialization.
Edit: this.veTarget.getPublishNamespace() in mw.cx.init.Translation.prototype.checkIfUserCanPublish is null in first call beacuse of unknown problem.

It seems that a gadget forgot to list oojs-ui as a dependency, causing a race condition, and the Chinese Wikipedia happens to have a gadget that may trigger a race condition. ReferenceTooltips is defined as:

* ReferenceTooltips[ResourceLoader|dependencies=ext.gadget.HanAssist,mediawiki.util|skins=vector,vector-2022,monobook,timeless,modern,cologneblue]|ReferenceTooltips.js|ReferenceTooltips.css

Sorry, I wanted to point out that no changes need to be made is problematic. Lua api mw.title:inNamespace would detect the existence of the incoming namespace and throw an error. Abruptly removing the namespace obviously destroys some modules. e.g. Module:PJBSClass#rev80701284@zhwiki

Two questions:

1. Should the redirect page use design similar to a general redirect indicating that this is a redirect instead of continuing to use scribunto-doc-page-does-not-exist/scribunto-doc-page-show?
2. Does not support any syntax that is different from return require [[Module:Target]] (even if the number of spaces is different return require[[Module:Target]], or quote return require "Module:Target", etc.) is a "feature" of this new functionality?

Sorry, it seems it was a misunderstanding on my part.

In T352592#9380789, @Umherirrender wrote:

Trying to put some information here
The default skin on zh.wiki is: vector-2022
It seems you visit the page logged in with account having the skin set to vector (legacy vector from 2010)

• Does this needs a specific language or variant?

No.

• Mobile site or desktop site?

Desktop. (It seems to be no reason to use vector-2010 on mobile site?)

• Could you reproduce this also for a old revision view as linked above or only when the special page is in the current revision?

Both.

According to testing, although AbuseFilter was indeed recorded after the patch, edits were not properly blocked. Moreover, the differences left by AbuseFilter are not correct, and a JSON escape sequence appears.
log: https://zh.wikipedia.beta.wmflabs.org/wiki/Special:AbuseLog/1210
diff: https://zh.wikipedia.beta.wmflabs.org/wiki/Special:Diff/23457

In T346760#9227269, @Urbanecm_WMF wrote:

@ Func @SunAfterRain Do you mind testing this again on zhwiki, and reporting in case this still happens? It appears to work fine on my end now.

It seems to still happen, but it doesn't seem to happen in safemode.
normal reqId = 366bbc88-ad74-46d9-b8fb-06b7c57179a3 (skin=vector-2022)
safemode reqId = db24ffe6-0264-41b5-9b3b-3fd07491971f (skin=vector-2010)

The following deprecation message was captured after applying patch 958540:

PHP Deprecated: Use of RequestContext::getMain while called from MediaWiki\SpecialPage\SpecialPageFactory::capturePath is deprecated since 1.41. [Called from GrowthExperiments\WelcomeSurveyHooks::onSpecialPageBeforeExecute]
#0 [internal function]: MWExceptionHandler::handleError(integer, string, string, string)
#1 /path/to/mediawiki/REL1_40/includes/debug/MWDebug.php(382): trigger_error(string, integer)
#2 /path/to/mediawiki/REL1_40/includes/debug/MWDebug.php(352): MWDebug::sendRawDeprecated(string, boolean, string)
#3 /path/to/mediawiki/REL1_40/includes/GlobalFunctions.php(791): MWDebug::deprecatedMsg(string, boolean, boolean, integer)
#4 /path/to/mediawiki/REL1_40/includes/context/RequestContext.php(551): wfDeprecatedMsg(string)
#5 /path/to/mediawiki/REL1_40/extensions/GrowthExperiments/includes/WelcomeSurveyHooks.php(138): RequestContext::getMain()
#6 /path/to/mediawiki/REL1_40/includes/HookContainer/HookContainer.php(160): GrowthExperiments\WelcomeSurveyHooks->onSpecialPageBeforeExecute(GrowthExperiments\Specials\SpecialManageMentors, NULL)
#7 /path/to/mediawiki/REL1_40/includes/HookContainer/HookRunner.php(3729): MediaWiki\HookContainer\HookContainer->run(string, array)
#8 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPage.php(694): MediaWiki\HookContainer\HookRunner->onSpecialPageBeforeExecute(GrowthExperiments\Specials\SpecialManageMentors, NULL)
#9 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1475): SpecialPage->run(NULL)
#10 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1545): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext, boolean, MediaWiki\Linker\LinkRenderer)
#11 /path/to/mediawiki/REL1_40/includes/context/RequestContext.php(577): MediaWiki\SpecialPage\SpecialPageFactory->MediaWiki\SpecialPage\{closure}()
#12 /path/to/mediawiki/REL1_40/includes/specialpage/SpecialPageFactory.php(1541): RequestContext::withDeprecatedGetMainAccess(string, string, Closure)
#13 /path/to/mediawiki/REL1_40/includes/parser/Parser.php(3205): MediaWiki\SpecialPage\SpecialPageFactory->capturePath(MediaWiki\Title\Title, RequestContext, MediaWiki\Linker\LinkRenderer)
[removed as unimportant]

There is no consensus and no specific direction for practice.