Thanks!

There is a special case in the code checking summaries, described as "Don't force edit summaries when a user is editing their own user or talk page":
https://gerrit.wikimedia.org/g/mediawiki/core/+/3831d53eb9ca5091be622aa68b1b21eda848bf4e/includes/editpage/EditPage.php#1307

and the last one gets a DiscussionTools new-thread button.

In T195546#10067861, @Tacsipacsi wrote:

Because it results in an easier-to-understand history: instead of seeing that the page has been renamed from Broken/Talk:WP:FOO to Wikipedia talk:FOO (this example assumes that 48e90e8ec547 hasn’t happened, but just because it’s easier to understand), the user looking at the page history sees that the page was renamed from Talk:WP:FOO to Wikipedia talk:FOO, which is closer to the reality.

Backported, but the patch on master is still waiting for review. It should be merged no later than Monday to avoid regressing this in the next WMF branch.

Previously: T351461: InvalidArgumentException: Multiple conflicting values given for wgDiscussionToolsPageThreads

I didn't get around to this during the hackathon as I planned, but here it is.

Thank you for tagging this task with good first task for Wikimedia newcomers!

This seems to have been fixed, no idea when.

Thank you @Pppery!

Works for me again.

I've been seeing failures with this error message once a week or so recently. I (and others) usually comment in Gerrit with this task number, so you can find most of them here: https://gerrit.wikimedia.org/r/q/T282893

Changing that fragment in checkSettingsMessage() as follows fixes that test failure:

		if ( is_string( $value )  ) {
			$msg = $module->msg( $value );
		} elseif ( is_array( $value ) ) {
			$msg = $module->msg( ...$value );
		}

Sure! Let's look at the first test failure from the list:

You're right that it's archaic. We have recently removed support for this mode from CentralAuth: T348852: Remove CentralAuth support for mixed-protocol HTTP/HTTPS wikis. But that was easier than doing it in MediaWiki, since we didn't need to worry about users other than Wikimedia wikis.

The pages can be also listed on-wiki using Special:PrefixIndex: https://he.wikisource.org/wiki/מיוחד:דפים_המתחילים_ב/T314733/

My use case: I rely on email notifications to follow the updates on tasks I work on, and I would like to know when someone e.g. reports a new problem caused by my changes in the comments. Sometimes they do it by substantially editing their last comment (e.g. because they discovered a new problem related to something they already wrote about), in which case I do not see it, until I visit the task for some other reason.

I've been hoping that someone would do all of them at once, so that we wouldn't have to bother translators and the communities with these changes more times than necessary.

I added the note to next week's Tech News: https://meta.wikimedia.org/wiki/Tech/News/2024/34 (please edit) and scheduled the maintenance script for Monday afternoon: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20240819T1300, which should be about the same time as the newsletter goes out (the script will take a few hours to run across all wikis).

I was going to use T314733 as the prefix, to make it possible to find this task in the future (since the script does not create any log entries). We can use any prefix you want though, if something else would be more convenient.

I'm sorry, I didn't realize I was changing a public field. It was late at the hackathon :) Thanks for fixing it quickly, and I'll submit another patch to add back a soft-deprecated accessor later today.

(Maybe better to do it in the week after the next, to give Tech News translators time. It's not urgent.)

Thanks to @Pppery we can run cleanupTitles.php now.

Based on the dry run we did in T196088, the following number of pages on each wiki is affected. It shouldn't be a great burden on the users to correct them, even if all of them required manual fixes (except for hewikisource, which is a unique situation: T314733). I suppose I could schedule it some time next week, unless anyone has objections.

Yes, and thank you for reviewing that log!

I think ideally we'd change the core parser behavior here. Comparing the two renderings for your example, the Parsoid one looks like what was intended. I wanted to avoid wrapping bare <hN> tags in the old parser too, but it is currently impossible due to T68637.

Do you mean the notifications that you signed up for here? https://www.mediawiki.org/wiki/Git/Reviewers#mediawiki/extensions/Lingo

This may be silly, but… would it be better if DT was setting isNotEmptyTalkPage rather that isEmptyTalkPage?

It seems like the expected behavior in this case for me. It has been like this for a long time, I found e.g. T194945#4392118 and T51955 where it was considered to not be a bug.

In T371839#10044834, @thiemowmde wrote:

It appears like the code highlighted here should have been made part of the Cite codebase years ago, not copy-pasted to 100+ wikis without any change. Maybe I'm missing the point. Why was this done?

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1057993/3/includes/frontend/FlaggablePageView.php#b353 I think this Html::closeElement( 'div' ); should not have been removed.

I can have a look.

@Dragoniez Class fields are actually an ES13 (ES2022) syntax feature (see https://en.wikipedia.org/wiki/ECMAScript_version_history#13th_Edition_–_ECMAScript_2022), which is not yet allowed by the validator (T357197), because MediaWiki still supports browsers that don't understand it (compare https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes/Public_class_fields#browser_compatibility and https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix).

Indeed, the template was adding stuff with display:none to the beginning of the next paragraph. Should be fixed by this edit: https://www.mediawiki.org/w/index.php?title=Template:MW_file&diff=prev&oldid=6690158 (although the Parsoid parse for 'oldid=6369900' seems to be cached with no way to purge it… but I tested in preview with the same HTML)

You can look at https://www.mediawiki.org/w/index.php?title=Manual:ForeignResourceManager.php&oldid=6369900&useparsoid=1 to try to investigate.

Same as T371125: When using Parsoid rendering, DiscussionTools "empty state" appears on all talk pages?

My bad, this change wasn't actually live when you tested it @Ryasmeen (assuming you tested with MediaWiki and not VE standalone). Probably best to test this again once the submodule update is merged. I'm sorry about that.

Released https://www.npmjs.com/package/cssjanus and https://packagist.org/packages/cssjanus/cssjanus version 2.3.0 with these changes.

I suggested a fix: https://meta.wikimedia.org/wiki/User_talk:TheresNoTime#c-Matma_Rex-20240806095700-User:TheresNoTime/stewResponseHelper.js

package.json is definitely portable between OSes, and package-lock.json is probably also portable (I mean, it works on Windows and Debian Bookworm, but it wouldn't work on Buster?). This confuses me somewhat, but my knowledge about npm is also minimal. How does the installation actually fail?

This was previously fixed in T153027, but that fix no longer works as a result of T287701.

You might also want to update the advice in https://www.mediawiki.org/wiki/Directionality_support. For now I just removed a fragment that isn't true any more: https://www.mediawiki.org/w/index.php?title=Directionality_support&diff=prev&oldid=6688338

Hi @Destiny, the issue was filed only 2 hours ago, so naturally it is still open. You're welcome to work on it, if you think you can find out why this problem is happening. Note that we probably won't be able to guide you if you get stuck, though.

This is probably some gadget doing this wrong (I am guessing because it's near impossible to cause this bug in PHP code – we don't even have access to the encoded value without going through some hoops). I can see you have some gadgets enabled (the red "(Stale)" marker is also provided by a gadget), we just have to find out which one is doing this. It should be easy to fix once we know where to fix it.