Looks to have been added for T149809: [A/B Test] Add 'explore similar' pages, categories and suggested languages in search results.

In T332653#8712637, @Locke_Cole wrote:

@Izno, with regard to removing Community-Wishlist-Survey-2023, I'd think this would be closely related to Native SVG support and Dark mode, both of which scored highly in the survey.

Per fix onwiki.

There's about 400 articles on en.wp with that pattern.

My opinion on whether to do user scripting separately is that we can bite the bullet now or we can bite it later. It will be a much bigger bullet later. The longer you allow the assumption to bake in, the worse it gets, and TBH it's one reason Vector should never have been loaded with Vector 2022. During 'beta', migrating could have been done essentially without any user cost, as with the previous transitions. "Nothing is loaded from your old pages, copy-paste CSS changes to the new CSS page and preferably move any JS customizations to your common.js, but copying to Vector-2022.js will suffice." (My opinion is that JS shouldn't be a skin-specific quality in most cases.) That cat is out of the bag now and waiting isn't going to help.

As framed, this issue cannot be resolved by work done in the core software indeed, and the correct place to discuss improvements is https://en.wikipedia.org/wiki/Module_talk:Footnotes . (Which may necessitate some core software change, but I doubt it. Ttm is pretty savvy about what can be fixed in the core software.)

I added T313804 as a subtask because it appears to be basically done on this work.

In T232771#7100538, @Mvolz wrote:

Not all citation templates have a DOI field, and only have a URL field. As long as we have this information, we should provide it, because some consumers will prefer to use the URL. If en wiki prefers to remove these with bots that's a preferred option imo. We can't delete fields that are being used on other wikis in the back-end just because of policy in en wiki.

Also, spec says that URL is a required field that will always returned, along with title and access-date, and although that could be changed I don't see a reason for it.

(We could consider changing *which* URL goes in in the URL field, but not providing it all is what has been declined.)

In T331227#8666797, @Nux wrote:

I agree that adding proper, common containers in extensions/skins would be nice, but not required. You can do that already in site-wide CSS (eg).

I was planning to file this task when there was a greater percentage of views supporting them and when they were no longer at working draft.

As a side note after the dupe close, the p tag in HTML does not match exactly to our notion of a paragraph these days. It's more structural. So I agree with two separate p elements before and after.

In T259240#8665070, @Ferret wrote:

I would like to suggest the header should also scroll/float with you. Not as an editor, but as a reader, when I finish an article, one of three things are going to happen: I close the tab entirely, I click to a wikilink (of which I may have already opened several in new tabs), or I use Search to go somewhere new. As the header is not sticky like the TOC, that means I have to scroll ALL THE WAY back up in order to perform a search.

In T231161#8661943, @Sbailey wrote:

Question: does the current namespace selection and invert selection check box adequately cover this feature request sufficiently. It does allow the exclusion of talk namespace while including all others.

Doesn't appear so based on a cursory review of UniversalLanguageSelector .

Use ?uselang=qqx to get the message name associated with a string on an arbitrary page.

Another special case of T66577: Large tables created by editors are not responsive and weakly related to T270741: Long URLs (=without linebreaks) increase the width of the File History's "Comments" table cell, so that some browser zoom out a lot.

In T301365#8635087, @Legoktm wrote:

The issues that you mention like: not having a generator for API list=linterrors, lack of a CirrusSearch keyword, unable to do intersections with categories, all seem like individual issues that should be fixed. But I don't think lowering Linter to using categories is a good idea.

Based on my read of this change and a request for help on IRC today, this narrowed the allowed type of the configuration global from string or array of strings to array of strings (the cast to array looks to have been removed), and probably should have been documented in release notes/announced accordingly. https://www.mediawiki.org/wiki/Manual:$wgSpamRegex 's example(s) is/are out of date as a result.

In T329966#8626560, @Tgr wrote:

...but basically [...] which is probably hundreds of places

Right, "I also know that seems like a lot of work."

In T329966#8626313, @Tgr wrote:

We could add .mw-parser-output to some UI elements on the software side - blockedtext is pretty clearly intended to include templates. The question is, would it be more or less confusing than the status quo, where it's at least easy to know when to expect your template to be automatically wrapped in that class?

In T217606#8623770, @Tgr wrote:

Pretty much every major preferences UI these days has a ToC.
But MediaWiki already has one, in the form of tabs, Not sure how a second level is supposed to integrate with that.

In T217606#8623495, @Aklapper wrote:

In my humble opinion if your Preferences pages become so long that you need a ToC then feature creep in your application is the problem to solve instead... :)

See response on T329809: [ reply ] button shows up for comments in tables.

I have a feeling that comments in tables was probably requested at some point to respond to barnstars, wikilove, and other such messages, many/most of which are today implemented as tables.

Going to unmerge this. The other task could potentially be declined as recently discussed, and I didn't realize when I made the comment in T300919#8276491 what the context of the statement was and what the specific intent was, which does look different enough from this task's intent. I don't think implementing the other task would resolve this one reasonably, based on the acceptance criteria therein.

Related: T25359: Present Gadget preferences in a more visually browsable manner (longer descriptions, search, images, etc.)

Ahhhhh clicking the wrong thing (first word in the header). Yup, I can repro now too.

Are you sure this is a DiscussionTools problem? I can't replicate on WP:VPT in Firefox 109 with DT turned on, which Matma Rex seems to think it will be a problem on that page. :) (Double clicking gets me the word and the space after, which is expected behavior.)

In T328610#8596303, @Tgr wrote:

You'd have to double the number of gadgets (which is a performance concern due to startup module size), ship a bunch of pointless code to all readers, it would block the loading of the actual gadget until the loader gadgets executes on DOM ready, it wouldn't work for style-only gadgets etc.

Reasonable concerns. OTOH, right now the "bad" edge case is NavPops. I bet we can enumerate the problematic gadgets on one hand for gadgets that actually need something of this sort. Separately, the bad cases probably need these fixes regardless. As a particular example of an edge case, I believe NavPops doesn't check today for the general user ability to hover and should, so that's a check that needs to be added regardless of whether it's loading on mobile or desktop, because neither of those two targets do that today. And then this problem is solved for that gadget, since it shouldn't be judging mobile use based solely on the domain or skin it's on. As I suggested above, that's a check that probably could/should be added to mw.util or other library. I don't think it could be done in the definition, especially since I could go from tablet-without-mouse to tablet-with-mouse pretty easily (as a particular example).

In T259240#8595072, @alexhollender_WMF wrote:

This brings us back to a question raised above: is the goal here to de-emphasize the table of contents? We don’t think that’s the main goal, and we also think that doing so could have negative consequences. We think the main goal is separating elements on the page from each other, so that it’s clear, for example, where the table of contents area ends and where the article area begins.

I agree.

In T66577#8567450, @Jdlrobson wrote:

@Xaosflux

Not really sure why you pinged Xaosflux, but he's as good as any to have subscribed. :)

In T328610#8595588, @Tacsipacsi wrote:

Call it technically however you want, it’s breakage in that it breaks workflows.

Yes, the skin potentially doesn't support gadget X that user Y expects to work. I would rather, as I have now said multiple times, affirmatively add a statement that says "this gadget works in this skin", along with the assessment that would likely be done for all gadgets at the same time, and tell the users "yes, gadgets aren't assumed to work in a new skin", than have the converse discussion "the gadget doesn't work for this skin", "yes, that's because the gadget is broken".

In T328610#8588245, @Tacsipacsi wrote:

How is not loading on mobile worse for caching than not loading for users who didn’t enable the gadget? I understand splitting caches on desktop vs mobile is bad if the ResourceLoader module would otherwise be loaded for everyone, but gadgets are loaded for a fraction of users anyway. (For example, NavPopups on enwiki is loaded by some 60 thousand users out of the 45 million registered users – while if we took only active users into account, the percentage would probably be higher, it’s still just a small part of the registered users, with zero anonymous users having the gadget enabled.)

There are default gadgets on multiple wikis that in fact load for everyone.

NavPops is a hard question to me, I think, and worthy of thought regardless. Popups extension too, I wonder what that one does today for systems where the normal mode of use is touch. (Consider that if I really wanted, I could manage to use a mouse with a phone. SO has an interesting comment.)

In T270741#8576369, @TheDJ wrote:

Even with break-word, if you put a long url in there, its still going to overflow in some places. Really we should be looking at creating a completely different view..

Because.. why is this a table ?

• Does it absolutely have to be ?
• The history page of an article isn't...
• There aren't even row headers
• What will break if we just turn it into a nice list ?

The answer is: No one looked at any of this since 2004.

side effect of a trick that the table does

@TheDJ well of course the fact we're cheating is causing it. :) (It's not the only one specifically tied to the cheat that's shown up in the past few week, had to back and forth with Matma for the display-the-lead talk page work.)

In T43869#8584294, @Malnadach_Konkno wrote:

Most (nearly all?) wikis define infobox in common.css so the current patch is sufficient for them.

In T43869#8572444, @Jdlrobson wrote:

To fix it, many wikis use the below workaround in their MediaWiki:Common.css table.mw-hiero-table td { vertical-align: middle;}

To be honest, I believe this was the correct fix here, since infoboxes are maintained on-wiki.
The only reason I merged the patch here is the age of this task, the fact that very few articles use hieroglyphics, the fix is small and the fact we don't have a concept of global templates to widely distribute such a fix.

The root issue is T281974: Fix alignment of coordinates and page indicators (Vector 2022).

It's not just pre. An image with the appropriate wide image template as explicitly recommended doesn't fix the issue. I left this on another task discussing an issue in V22 but since you think it's one cause, it's not. https://en.wikipedia.org/wiki/Sixth_Amendment_to_the_United_States_Constitution?useskin=vector-2022 with limited width turned off exhibits the same issue.

In T66577#8133045, @Jdlrobson wrote:

The only generic skin-level solution that can be applied here is to wrap a large table in a div container with horizontal overflow as suggested on the recommendations page.

Yes, intentional for separating rows. Most questions using SecurePoll probably have more than one response e.g. ArbCom elections.

Yes, this is a known issue from several years now. Should just be

Related to T327886: Long string of characters comes out of the body content and overlaps the Article tools menu in Vector 2022 and other related tasks there.

The display of https://en.wikipedia.org/wiki/Sixth_Amendment_to_the_United_States_Constitution?useskin=vector-2022 with the toggle set to "wide" but with any reasonably sized monitor resolution probably needs to be of interest here.

Also relevant to T66577 and T270741.

In T289212#8563088, @TheDJ wrote:

I'll also note that the potential impact of ppl not being able to find the login link is on a pretty long tail, as sessions last quite a while. So analytics data on this is gonna be pretty hard to build i think.

I've actually been coming to like the idea behind Zebra 9. It tends more toward how Timeless does its sidebar and main column support in that like Zebra 9, we're shooting for bounding the reading area, not "almost" bounding the reading area as in Blue whale. Even if the right toolbar becomes sticky, it may still not be full height relative to the main content.

This is still missing the span. If there is a reason not to add the span, that's fine, but that was not documented in this task and should be if it's deliberate.

In T327714#8559568, @Edtadros wrote:

Test Artifact(s):

QA Steps

❓ AC1: There should not be a lot of whitespace at the top of an article before you get to 'From Wikipedia, the free encyclopedia'
@Jdlrobson, Using the URL in the description https://en.wikipedia.org/wiki/Cristina_Pi%C3%B1a?safemode=1 the 'From Wikipedia, the free encyclopedia' does not appear on the page.

Without the safemode param this appears correctly.

Is this expected?

This is a special case of T66577: Large tables created by editors are not responsive and would be as fixed as it needs to be if that were resolved. In the meantime, this is one place the software could take care of the issue in some way, such as with

This is functionally a duplicate of T319387: Random <i> tag wrapping .mw-content-container in Vector-2022.