New line numbers alone is fine. Could also do something like "Line X became line Y".

I am pretty sure this task is a duplicate of already-linked T334941: Vector 2022: consider displaying References in two columns on narrow screens. I can follow-up on anything specific to the template.

In T63007#9192707, @Krinkle wrote:

In T63007#9192636, @Izno wrote:

In T63007#9192492, @Krinkle wrote:

[…] you could narrow your gadget to actions=edit,specials. […]

[…] but |namespace=-1 also would fit how special pages are dealt with (if that isn't already supported).[…]

namespace=-1 should already work indeed. The reason I suggest also supporting specials as an action is because a number of gadgets enhance the functionality of wikitext textareas, which appear on action=edit in many different namespaces, and on special pages like Special:Upload. action=edit would mean we (correctly) avoid loading the gadget on page views, but also (currently) makes it impossible to load on Special:Upload. namespaces=0,-1 would correctly load both on edit page and upload page, but would also load during page views. From a routing perspective, special pages are the equivalent of action="" or action=null, but to avoid hardcoding that or locking into no other possibilities in the future, I was thinking action=specials could represent that for completion within the Gadgets extension.

Anyway, if that doesn't work for your case, no problem. I'd rather not increase complexity until there's a use case that needs it, and benefits performance in a way that can't be achieved by other means already.

In T63007#9192492, @Krinkle wrote:

I think one thing we can do here, given that page actions are special pages with actions (diagram: an index.php request is routed to either an Action handler or a SpecialPage handler), is to perhaps treat "specials" as a symbolic value in the actions filter.

That way you could narrow your gadget to actions=edit,specials. With the primary goal being to not load it during main-namespace page views. Anything else we save toward perfection is small in comparison.

I don't think it's appropriate for a cache not to expire inside a week. The content was reverted on September 6, now some 11 days ago.

In T313058#9175581, @Reedy wrote:

In T313058#9173376, @Izno wrote:

The upstream for Firefox was https://bugzilla.mozilla.org/show_bug.cgi?id=1547294

https://phabricator.services.mozilla.com/D158911

Looks like this has been, in theory, "fixed" for a while?

While https://caniuse.com/?search=one-time-code doesn't seem to agree, I only have (seemingly) 1Password trying to annoy me when entering the codes... Which is a different issue (and technically, 1Password could fill the TOTP there)

The upstream for Firefox was https://bugzilla.mozilla.org/show_bug.cgi?id=1547294

Provide a parser function for adding Codex button markup

I use wikEdDiff and have definitely gotten used to reading diffs in sans-serif. So personally I'm fine with as-built.

There are discussions also happening around T296689 that it is probably worth discussing with them also.

(Given how few uses of NavFrame pl.wp has (around 600, I'd be happy to make it so you don't need that default loading anymore ;).)

In T345960#9154990, @AlexisJazz wrote:

[snip]

In T345960#9154958, @AlexisJazz wrote:

The developers are in for a world of hurt if CommRel doesn't get involved in this.

I think you're looking for https://toolhub.wikimedia.org/tools/patchdemo ?

In T111565#9135467, @AlexisJazz wrote:

I can't find the relevant comment, but this is deemed to be an insufficient UX on touchscreens by the WMF devs.

I guess this is https://en.wikipedia.org/wiki/Help:Pictures#Vertical_alignment , which I had no idea you could set in an image.

Right now the gadget syntax checker doesn't even let you write ES6

A minor point, but this is not true. requiresES6 can be set in the gadget definition which allows ES6 syntax (basically by turning validation off entirely right now and leaving it to the author to ensure their software is void of error).

T164009: Add a HTML5 validator to output of Special:Expandtemplates also exists but would be much more limited in scope I think.

In T193454#9110060, @Arlolra wrote:

I opened T344712 which hopefully captures what was lost. Again, sorry for misunderstanding.

(While looking around for tasks, T200562: Consider not outputting content model violations to help editing clients showed up where ironically I had almost said the exact same thing regarding it and just never posted it. So maybe I haven't mentioned it....)

In T306205#9115467, @ssastry wrote:

This is something I had once asked back in the day after Tidy had been replaced but didn't act on it - I think we should retire some of these linter issues. These existed to give editors a chance to fix up content that might have changed rendering. Given that Tidy is long gone, the rendering we see is what exists and if someone wants to change the appearance, they can do so without needing a linter category.

My proposal is to retire this and also examine all the other tidy-centric issues after examining which of those still have value in a post-Tidy HTML5 world.

Honestly I'm not entirely sure. I probably did mean the second part of T151362, just on ?action=info. It's long ago enough that I don't honestly remember. Declining is as good as anything now. If I need I'll file another task for what was proposed there.

That is not a resolution to this task, no. It might be reasonable to say "click the links in Special:Info and then click those edit links is good enough for the product and so we're declining this request" and/or "what you want is the part of T151362: Linter: Display lint errors for a single page which wasn't done which Izno is still sad about", but T301374 is not a resolution.

Categories probably shouldn't even be generated for items. https://www.wikidata.org/wiki/Category:Pages_with_maps has got a few others. Maybe a leftover from some bad deployment or another?

First thought that comes to mind is that Hiero tends to output images that are a pretty solid size, whereas the Unicode basically fits into the size of a normal text character. So some sort of template is probably called for. https://en.wikipedia.org/wiki/Egyptian_hieroglyphs#Phonetic_reading seems exemplary for sizing. IDK if that's necessarily desirable in all places....

See also T323088: Global blocks should be displayed below local blocks.

@PerfektesChaos since you recently edited the template, you might take a look here and see if anything from your edit needs adjustment?

Special:Search already has a help link (at least on en.wp, IDK what stock MediaWiki provides) in the top right of the page where indicators usually sit. Adding more help to this page doesn't seem like an interface win.

This probably also impacts MediaWiki-Watchlist and MediaWiki-Recent-changes among others.