I can't tell from Google Translate but this request looks like T331906: Add Lua function to read out previous section heading. Is it?

I think Parsoid is doing the correct-er thing here, even if it's not what the users obviously intended. You need to be able to access new page names with apostrophes in them somehow at the end of the day. There are several examples of red links on the same page where someone did the due diligence of marking them up as link text rather than as link target.

One cell in Parsoid:

Does this not run into the same security issue as described in T5593: [Epic] SVG client side rendering regarding scripts potentially uploaded before the dawn of sanitization?

In T318176#11287640, @Graham87 wrote:

The only other ones I know on here are @KaraLG84 and @codeofdusk. They use NVDA as their primary Windows screen reader.

In T268900#8256603, @matmarex wrote:

Latest spec allow alternative text to be specified in content: https://www.w3.org/TR/css-content-3/#alt but browser support is poor so far: https://caniuse.com/mdn-css_properties_content_alt_text (only Chromium and friends).

This task feels like it should be considered by someone who actually uses accessibility technology because it would be adding some repetition to someone navigating by section (e.g. heading -> next link -> next link and each of those next links would post-change read out as the same text as the heading which I anticipate would be annoying). I would be surprised if these links are navigated to differently (for example, navigating by all links would be surprising, but in the realm of possible).

In T378906#11286762, @ssastry wrote:

Ah, I had the fix narrowly target divs for navboxes. Can't do the same for tables because of fostering reasons. Short of hoisting deeper -- into the "last" <td> -- which feels very ugly, I don't have a good Parsoid-side solution at this point.

Yeah, it was a super-big parenthetical. (The infobox template does something similar to that kind of hoisting today but it's ugly and I plan to get rid of it at some point when that gets rewritten.)

I've added amboxes to the same page. (They are tables currently and probably a good chunk of the fleet, but I am incidentally working on making them divs. Which still doesn't fix the whole fleet.)

This is a browser issue; Firefox is happy to style those directly. This is on top of what I think is a gadget providing the support for the button in the first place, since buttons are not normally allowed in wikitext.

In T378906#11286249, @ssastry wrote:

https://www.mediawiki.org/w/index.php?title=User:Izno/Sandbox/Category_holder&diff=prev&oldid=7945477 fixes it for example. I'm going to close this as resolved. Please leave a comment if you disagree. Since the patch is kind of a mild hack, we mostly want to keep it as narrow as possible.

The fundamental fix is to use media query range syntax from Media Queries Level 4. Problem is that implementation is only about 3.5 years old (Safari is a little younger at about 3 years old).

That was done some time ago, and isn't particularly related to this task. T198949: Add navbox links to mobile page HTML There's other still-open friends in that context.

I didn't know search had a thesaurus!

I think this is simple suffix stripping and it is part of the language support for stemming.

Here I'm making the not-funny that crying also results in results for sob trains.

In T404454#11274457, @CCiufo-WMF wrote:

I'm not sure if all the major browsers we support have a native "desktop mode" setting.

FYI: I went and documented all the range calculators in the movement these days at https://en.wikipedia.org/wiki/Template:IP_range_calculator#Other_versions , of which that template is but one.

Ok, the adjustment of the title makes the suggested lint make sense.

I'm confused by the description? Parsoid does a better job making list items out of extension content and editors are already intending them to be lists so we want to add a lint so people stop using them as lists....?

You should ask these questions on the module's home wiki's talk page. They may be able to assist better than the audience usually-unfamiliar with modules on Phabricator, but beyond that this module appears to be quite complicated.

This looks to be validated in production based on https://en.wikipedia.org/w/index.php?title=MediaWiki:BlockedExternalDomains.json&diff=prev&oldid=1316015275 occurring.

I haven't settled on an opinion for this task, but:

It also doubles up on roles, which is no longer allowed

Multiple roles are allowed actually. The consuming system must treat the element as if it were of the first "non-abstract" role per ARIA 1.2 (2023). This hasn't changed in the editor's draft for 1.3. (Authors are required not to use the abstract roles. ARIA 1.1 [2017] indeed had little to say regarding the specification.)

This mostly sounds like Chrome is not finding the appropriate Hewbrew italic font in the Android system installation. It certainly wouldn't be anything MediaWiki is responsible for or causing.

The issue of tables at small resolutions is a broad issue and isn't going to be solved by designating some arbitrary wikitext as a pile of divs. Which I assume is what is wanted given the example in the parent.

From a semantic perspective, I haven't decided if it makes sense for JSON to be represented as a table or if it should be represented in some flavor of div e.g. or section. I think I get the argument for a table, so I think you could maybe flip a coin. (Based on the history, this was never anything but a table but it doesn't look like there was a ton of consideration to how it should display, at least on the bug tracker. And also flex/grid were still nascent in 2014.)

In T404979#11194457, @Izno wrote:

I have also been thinking in no-temp-accounts land that it is very tiring to work past all IP contributions sometimes.

How is this task about CodeEditor relevant to a patch changing a message to use gender neutral language in Special:NewFiles?

We don't do this for any other special pages.

Something I'm entertaining is whether Special:SI could surface staleness data directly. It would be nice not to have to rely on a staleness script checker which is only guessing anyway as to whether data is available for an account.

Were we to add the link rather than replace the user link (which I am fine with either approach, both have some utility if accounts are tagged which is definitely more English WP-specific than not AFAIK), I'd personally prefer the contributions link first. I currently have not been finding myself using this check user link and instead have been navigating straight from Special:Contributions to Special:CU. (I imagine I probably would with T405653 done but I doubt its placement would be preferably first rather than second given how most of the other interfaces are oriented which is usually contribs near to talk/user links.)

Probably it should point to some list on mediawiki.org or elsewhere rather than being namedropped in the message directly and thus hard to change in a cross-language way. I've thought to do that with the list currently splattered in that same spot.

JS editing isn't the only action where we'll have this problem.

Ran into this with a new CheckUser today.

The example wikitext
|- style=font-size:85%|0 – 2
probably wants to be

|- style=font-size:85%
|0 – 2

Some thoughts and I'm not sure if they're actionable or useful even:

I basically can't reproduce this at resolutions supported for Vector 10 any longer. The only thing remaining is the 1px difference on the search page in Vector 10, but only for the top border of the search box. Vector 22 is fine in that same area. Given the general maintenance mode of Vector 10, I think this is resolvable.

In the Step 3 section there is a well formed

== Step 3: synchronize the changes to the cluster ==

I can no longer reproduce this with the couple of image descriptions listed in the originating discussion nor a spot check of a few others. I would guess the use of Parsoid and/or improvement of Parsoid is how that happened.

Ok, in today's world post the above patch this is now the issue with this task:

In T215271#7026578, @Jdlrobson wrote:

The long term solution is to remove the handling inside Minerva here:
...
https://gerrit.wikimedia.org/g/mediawiki/skins/MinervaNeue/+/5a3925dfdec7c9817d1c50ff9c3e62c3a2bb1e01/resources/skins.minerva.content.styles/hacks.less#30

So, in the version of the article that was provided above, there is now no longer an issue.

I corrected this for en with this change a few years ago which moved side boxes to use divs.

In T327893#11002680, @gerritbot wrote:

Change #1166234 merged by jenkins-bot:

[mediawiki/core@master] jquery.makeCollapsible: Avoid extra borders etc. on un-rendered elements

https://gerrit.wikimedia.org/r/1166234

MediaWiki:Minerva.css imports MediaWiki:Common.css/Messages.css . Lines 259-279 are responsible for the issue. This was corrected directly in Common.css with this edit. You will want to sort out whether that should live in Common.css or the apparent shared Messages.css.

It is already enabled. As I noted out-of-band,

Probably the search should be something more like this one, which catches non-Common.js pages that do appear quite relevant.

Already vanished by further work.

I see a several other places in core and elsewhere that could use this kind of change. search that has many false positives and maybe also some false negatives. mediawiki.hlist parentheses and middots, makeCollapsible brackets, skinStyles.less, and so on (and eyeballing, what look like a lot of clearfixes that given the number of less files appearing could potentially be a mixin).

This request was discussed in some degree at T338836#9556620 also.