It would be more convenient if {{#isredirect}} is an alias of {{#isredirect}} instead of an alias of {{#isredirect}}, since the main use case would be inside an {{#if:}} statement and {{#if:{{#isredirect}}||}} feels more natural than {{#ifeq:{{#isredirect}}|true||}}.

The resize bar appears on mobile, but it doesn't seem to do anything. Dragging the bar just scrolls up and down as it would with any non-interactive content.

To be clear, I don't think I will ever want to change the size of the edit window on mobile. I personally would prefer it to be removed than to have it actually resize the window.

This happens when a discussion takes place outside of a talk namespace and without NEWSECTIONLINK magic word.

This is normal lua behavior. pairs is not expected to keep the order.

This task was resolved by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1213958

I noticed that bracket matching is incorrect inside regex and escaped brackets are matched with brackets. I do not know if it should be corrected or if bracket matching should be disabled inside regex.

In T201233#11551573, @Wellverywell wrote:

@Jdlrobson-WMF user @Bezik on Russian Wikipedia has reported that this is actually a breaking change.
In any theme (MinervaNeue, Timeless, Vector-2022), any browser (Firefox, Vivaldi), without user CSS, when increasing browser scale/decreasing window width any punctuation marks after formulas go on the next line. Example on this page:

I've investigated this issue and pinned down that it's due to commit https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Math/+/1154054. What I think is happening is when window width goes below @max-width-breakpoint-tablet, width: 100% is activated even for .mwe-math-element-inline elements, which makes them non-inline, and the punctuation mark goes off. In my opinion that style should not be applied to .mwe-math-element-inline elements.

In T415206#11544198, @Bhsd wrote:

Some templates can have custom parameters, so it is difficult to recognize "non-existent" parameters from TemplateData.

I tried a basic implementation of this with plain text search

Hello,
I tested it and noticed an encoding issue:

In T414331#11513305, @SarthakSingh2904 wrote:

Hello! I’ve completed the requested changes and pushed the update. I’d appreciate it if you could review it when convenient.
Thanks in advance.
@Escargot_rouge

Thank you @SarthakSingh2904 .
I tested by copying your code like this, but I still have the same issue of sticky header hiding content.

In T413751#11494787, @Bhsd wrote:

JSON linting inside <templatedata> will be available when we upgrade WikiParser-Node to v1.34.0.

This is still an issue in CodeMirror 6.

As a contributor from frwiki myself, I can say that I rarely mark edits as patrolled. This action does not feel sufficiently meaningful currently, as marking an edit as patrolled does not appear to prevent other patrollers from reviewing it again. In addition, I mark edits as patrolled only when I am confident that they are correct, which is relatively infrequent. Confidently assessing the quality of an edit in a subject area in which I lack sufficient expertise is more difficult than identifying clear vandalism on the same subject. That said, I do relatively little patrolling.

In T409165#11488673, @Novem_Linguae wrote:

Good food for thought. But I still worry about it being an infinite queue (never reaches zero backlog) even with the 1 month dropoff.

This is a temporary fix for night mode originating from the WikimediaMessages extension. As explained here, to disable it you need to create the page https://de.wikivoyage.org/wiki/MediaWiki:Wikimedia-styles-exclude and set its content to theme-night-portal.

In T413129#11480357, @MusikAnimal wrote:

How does this look?

With CodeMirror, there is now a lot of red waves under word that are not recognised by the browser

mediawiki.api itself is one of the offenders: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/HEAD/resources/src/mediawiki.api/edit.js#121

In T412623#11458288, @Hex wrote:

Tapping the watchlist star on an article on mobile takes me to this page:

That's at
https://en.wikipedia.org/w/index.php?title=2024_Championship_League_(invitational)&action=watch

I tested more, and the issue is related to font size. The problem doesn't actually lie with the cursor, which is correctly displayed considering the expected text size, but with the text size which is always small in the form. It only occurs with medium and big font size.

• Big font size with beta feature enabled:

• Small font size with beta feature enabled:

• Big font size with beta feature disbled:

In T412117#11444353, @Bhsd wrote:

In T412117#11444050, @Escargot_rouge wrote:

I have the same issue. This happens with every character and not only space.

Are you also using Android? I cannot reproduce it on iOS.

I have the same issue. This happens with every character and not only space.

You can do this using transforms.

Maybe the same issue as in T404514: User name gets misplaced in mobile watchlist and recent changes

Are you using actual dark mode or dark theme from the app?

This is the expected behavior. You have to either add the skin-invert class on the image to invert its colors in dark mode or to explicitly define color as black (or better var(--color-base-fixed, #202122) ).
I added the skin-invert class on the div. There might be a parameter in Image label begin template to do that.

The page in the video is https://fr.wikipedia.org/w/index.php?title=Saint-Lucien_%28Québec%29&section=10&action=submit. I did not mention it initially because the faulty template should be corrected soon and these lint errors will disappear.

Yes, it could be helpful to limit the number of displayed tooltips and, if possible, to merge all 17 identical messages into a single one, indicating “×17”.
I think here there is also an issue with the positioning of tooltips in cases where a lint error originates from a template. This problem would persist even with a single tooltip. It would be preferable for tooltips to appear below the cursor—or in another location that does not obscure either the cursor or the content the user is trying to edit.

If you are on mobile, this might be T350270.
If you are not, there are some issues when Parsold is enabled and caracters with accents are typed. Is Parsoid enabled for you?

@cscott T406594 is a restricted task. Could you copy here what you said there?

I looked at gerrit:893815 from T331058 and it does not seem to me to have introduced this behavior, but only to have extended it to temp accounts.

I am merging the two tasks since these links are both generated in Syntaxhighlight. They were introduced in T368166: Enable clicking on wikilinks and external links in syntax-highlighted code

The forthcoming update to logo policy somehow reads that any logo change should receive prior approval from the Foundation, which means that modifications made directly on-wiki would not suffice to ensure compliance and that maybe this task will have to be declined, at least for Wikimedia wikis. (The policy update is not validated yet)

Probably a duplicate of T323169: nytimes.com periodically blocks citoid service in production

This would break a lot of things. It is not uncommon to put a template documentation inside <code> tags.
Example on enwiki: more than 700 000 use of <code>{{....

In T146771#2679134, @IKhitron wrote:

Well, @matmarex, what do you think about (in pseudocode)

return $('<syntaxhighlight>', {lang: 'css', html: super()});

will it work?

In T393240#11106773, @Etonkovidova wrote:

In T393240#11106727, @Escargot_rouge wrote:

I am interface admin and not admin.

Thanks! I'm checking now whether or not the form works for Interface admin. If a user is able to edit MediaWiki:BlockedExternalDomains.json, then, logically, the Special:CommunityConfiguration/BlockedDomain form should be editable.

I am interface admin and not admin.

I saw the new page on frwiki, but it does not work for me.
When I click on "View form", the page is just reloaded and nothing happens. I can still edit MediaWiki:BlockedExternalDomains.json manually without issue.

I don't know if I should tell it here or on T359644, but theme-night has been deactivated on frwiki, so corrections specific to frwiki can be removed from theme-night.less.

CommunityConfiguration extension also does this.

The button is still here. It looks like this: https://commons.wikimedia.org/wiki/File:OOjs_UI_icon_signature-ltr.svg. If you are using the 2017 wikitext editor, it is in the insert dropdown.

It's any diff, for example https://en.m.wikipedia.org/w/index.php?title=Draft:Typhoon_Podul_(2025)&curid=80691989&diff=1305855111&oldid=1305855040. If you are accessing it from a desktop, you must reduce the window width until the bottom card appears, and then click on the icon (the issue is otherwise not visible).

I don't see duplicate icons in diffs directly anymore, but it still appears in info cards:

The square is the default Minerva icon when no icon is specified. Gadget icons need to be set directly inside gadgets CSS, like what is done here.
The link to Commons is different since an eye icon is defined for it and should be an visible but is not.

In T395679#11070251, @Nemoralis wrote:

In T395679#11058166, @Escargot_rouge wrote:

An issue in completing this task would be that many of the bots lose their status due to inactivity, but almost all are correctly categorised within subcategories of the local Q3681760.

It is possible to check their usernames for "Bot" keyword.

I renamed, UTC is used on English Wikipedia, but not on all wikis.

In my case (UTC+2), I see 2 hours ago for an account just created on English Wikipedia.

Hello, I tested user info cards today. I clicked random article and landed on https://fr.wikipedia.org/w/index.php?title=Ungerhausen&action=history. At first glance, seeing the user-like icons made me assume that many human users had contributed to the article. However, in reality, almost all edits in this history were made by bots. It would be really useful to have a bot icon to more easily distinguish automated contributions from those made by human editors.

This is a general issue affecting Codex messages. Initially, the problem concerned the width, but following T398529, it now pertains to the height.

In T379880#11038958, @Ponor wrote:

Reminds me of T350270