Might be worth re-testing that to see if it's still an issue, or trying slightly larger values close to 1 "frame" (e.g. 0.01s, 1/30s).

One approach is to use tiny animation times of 0.001s for reduced motion, in instead of 0s or none, so the transitionend still fires.

We probaby want a way to display the values of arbitrary template parameters, e.g. reason and date (as found in {{Citation needed}}, {{Contradictor}}, etc):

;Rhakotis
:[[Rhacotis|Rhakotis]] (from [[Coptic language|Coptic]] {{transliteration|cop|Rakotə}},{{Contradictory inline|date=August 2021|reason=In the introductory sentence, the Coptic name is given as 'Rakodī', with ref. There's no explanation of the discrepancy. A different dialect?}} "Alexandria") was the old city that was absorbed into Alexandria. It was occupied chiefly by Egyptians.

I think submitting jobs would be better, as the JobQueue will handle them asynchronously as quickly as it can, and hopefully throttle them where it needs to slow down?

Deployed earlier today!

After the above patch:

cc @matmarex as the original author

The above patches reduce these to 10ms each (from 600ms). The save dialog feels like it opens instantly instead of hanging.

We could just use pageId % 100 < targetPrecentage although as that samples consecutive pageIds that might lead to clumps of pages created by certains users or bots.

I find the placement of the lightbulb indicator in the top right blocks the reading of the edit pencil and/or makes it look like it is part of the edit pencil:

https://www.mediawiki.org/wiki/Citoid/Enabling_Citoid_on_your_wiki#Step_2.c:_Configuring_a_special_MediaWiki_message

FWIW for the biggest and most obvious case listed here, French, I'm not aware of complaints from frwiki about the lack of space before the :, nor proposals to add it (an on-wiki CSS fix would be trivial).

In T315893#12128387, @doctaxon wrote:

You must know that it's indeed not a language issue or an orthography issue, to put a space behind the colon. We are not talking about sentences or word terms in any language. We are talking about namespaces and page titles, that are bound to a string by a colon. So it's not advisable to change anything to something that looks like colon-space with the intention to correctify a language-based issue.

@SD0001 Filed as T432346

Given the lack of requests for translating the separator I don't think that is a priority for now, and while our APIs are mostly tolerant of additional whitespace, they would not handle different separators so it would be a vastly more complicated undertaking and beyond the scope of this task.

And you cannot easily disable this enhancement while keeping all the other ones, so that point is moot.

A global vote would make sense because this is a global change that was not consulted about with any language community.

For enwiki at least, this changes applies to ~76% of namespace prefixed pages. I'd like to get this to the remaining 24%. The main issue is that the current feature and preference lives in DiscussionTools, so we need to:

• Move the feature to core
• Create a core preference that is initially disabled for anyone who has DT visual enhancements disabled.

I can still reproduce in the sandbox

Now that ResourceLoader has sourcemaps, and Chrome V8 reports coverage, this should be feasible.

In T304753#12119066, @Esanders wrote:

The current logic means enhancements are available on most talk pages, and can be added to more with __NEWSECTIONLINK__ (excluding the main namespace):

// Visual enhancements are only enabled on talk namespaces (T325417) ...
return $title->isTalkPage() || (
	// ... or __NEWSECTIONLINK__ (T331635) or __ARCHIVEDTALK__ (T374198) pages
	(
		static::hasPagePropCached( $title, 'newsectionlink' ) ||
		static::hasPagePropCached( $title, 'archivedtalk' )
	) &&
	// excluding the main namespace, unless it has been configured for signatures
	(
		!$title->inNamespace( NS_MAIN ) ||
		$services->getNamespaceInfo()->wantSignatures( $title->getNamespace() )
	)
);

The current logic means enhancements are available on most talk pages, and can be added to more with __NEWSECTIONLINK__ (excluding the main namespace).

For phase 1 we have decided this will be an MW JobQueue triggered by article edits.

Ready for deployment.

In T424606#12091817, @ppelberg wrote:

Resulting question: as a first step, why wouldn't we defer to volunteers to adjust the addReference config?