And looking through things, not fundamentally a Parsoid issue. This would be an issue with Parser.php rendering also (just applied the broken CSS there also).

I don't think this can be fixed in the CSS without removing the rule. Which I honestly can't see a reason for existing: infoboxes which include content that would need a treatment like this are probably non-existent.

Honor a ?diff-type=inline URL parameter on both views

This would be different compared to how (actual) diffs interact with the user (i.e. no such parameter is typically added to the URL - if this can be done today, it's just not the normal way of interaction).

The output looks like it also didn't get the (Parsoid) figure treatment so it needs correction for that also, and which may be the fundamental issue.

Yes. That one is solved by fixing the wikitext.

Hah, codesearch failing me in a good way for once.

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

But not occurring on other pages? Anyway, no, not one I would expect for those pages.

This looks more like it's of the T310001: Bloomberg is redirecting us to "Are you a robot?" captcha or T210871: Citoid is overwriting editor provided values without notification (was "Bloomberg - Are you a robot?") flavors rather than something for Zotero to fix....

On WP:AN, not since I last readded the label I don't believe, no.

Personally, the current hist legend is kind of icky, and it probably merits spinning out in several messages, with the HTML construction done in PHP instead. I suppose that would be part of T65321: Add or expand legend on action=history.

coc-com wiki (give or take a dash), short for code of conduct committee, seems marginally better to me. Conduct is too broad.

for WMF wikis - 3 months

I am actually uncertain that this one should be consigned to local-wiki tag. Fandom for example seems to have had some success making their infoboxes collapsible in some quantity in the mobile use case. (Until infobox is divs on enwiki this won't be a thing.) Prior art locally it would be similar to how WikimediaMessages supports click-to-expand amboxes (which I've talked about not being necessarily good or bad before).

A VPT thread that I believe traces here.

In T426978#11945643, @Aklapper wrote:

URL should stay in one single line (should always have linebreak in front if not fitting into viewport)

The example uses an ombox template on English Wikipedia. If wanted, the CSS of that ombox template could be adjusted, for example to use white-space: nowrap;, so that web browsers knew not to wrap lines.

Templates are local on-wiki content. Local content is managed independently on each wiki, by each wiki community themselves.
Phabricator is mostly used for MediaWiki, MediaWiki extensions, or server configuration, or by developers and teams to organize what they plan to work on.
This needs fixing on the local wiki by editing its local content. Thus I am closing this task here - thanks for your understanding.

Did it support right-to-left languages when right and left were selected in antiquity?

In T378906#11901342, @ssastry wrote:

This is now fully deployed to all wikis and we have ironed out most of the kinks. Can you give this a go and report back?

And needed a followup to keep the old version until Parsoid is the only parser.

I've fixed this for hatnotes.

https://global-search.toolforge.org/?q=%22mediawiki.ui.input%27%22&namespaces=&title=

I'm sorry, but this is an insufficient search. Try something closer to this which has many more uses just on English Wikipedia.

I expect this search will catch anything that might need correction pertaining to this template. It can be narrowed by namespace if needed, e.g. templates and modules.

In T425364#11895381, @SomeRandomDeveloper wrote:

This is caused by the selector at https://en.wikipedia.org/w/index.php?title=Module:Hatnote/styles.css&oldid=1320445320#L-19, which doesn't apply on parsoid, as there are no link elements for the deduplicated styles between the divs. There should probably also be a selector for .hatnote + .hatnote that applies the same styles.

This is not an issue in Firefox on the mobile website. On VPT there appears to be a belief this may be a Safari bug.

Was https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend#Communication_of_changes_to_developers_of_wiki-hosted_code followed? I do not recall seeing anywhere a note in tech news that mediawiki.ui was being yoinked, but perhaps you know of one such.

Was https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend followed in regard to this removal?

I have never had an issue with either the toggle, which is toggle_view_mobile, or useformat.

?useformat=mobile for the casual check.

In T425290#11887404, @Xaosflux wrote:

Aside: is there a reliable method to access the 'mobile' layout on desktop anymore?

I'm guessing this was caused by T378906: Categories as link tags cause navboxes to have a rendering difference but I can't see in the MF code (since this isn't an issue on desktop Parsoid) what's ripping out .mw-empty-elt elements. (MF rips out content in wgMFRemovableClasses and see related code, but not listed in that area.)

(nb there is a logo set correctly for Vector22 at/around https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/ca2f57fe1efb4abeaa4f5934a3ebe27b47c009fe/wmf-config/logos.php#7936 )

Thanks a lot for working on this!

This is (indeed) an issue strictly with the dropdown.

There are two things going on:

Modules are deliberately limited from existing outside of the Module namespace. That you get an error is correct. (Whether that error should have that wording is perhaps questionable.)

Yeah, I'm gonna go with "I see neither a need nor desire for this".

That revision works now.

In T422984#11827442, @1234qwer1234qwer4 wrote:

In T422984#11810846, @Izno wrote:

User rights actually might be a link that could be removed since it's accessible from the user's page.

Not sure I understand this; if you mean the portlet link, that also contains logs, block, and (local and) global contribs. That does not make it less convenient to have it in the user links? (I agree some cleanup would be in order though.)

The code for this is gone as documented at T409370: Media Viewer settings 'cogwheel' icon is missing, preventing users from disabling it. I am declining accordingly.

Yeah, more difficult.

My impression is that this task is blocked by the likes of T20493: RFC: Unify the various deletion systems because the query for Special:Contributions would be too slow if it included deleted contributions directly.

Parsoid's behavior is not just reasonable but preferable. (See also T223277: List embedded in description list <dd> (descriptions) causes LISTGAP issues (old Parser only; does not affect Parsoid) which I think is the same bug identified for Parser.php or close enough to it.)

Seems like a reasonable column/subproject of Technical-Debt .

In T422458#11798157, @awight wrote:

And when I section-edit and preview a ref usage which is defined in a LDR outside of the section, I see an error (which is also problematic) rather than the raw tag: "<ref> tag with name ldr1 cannot be previewed because it is defined outside the current section or not defined at all."

In T118538#11801597, @STei-WMF wrote:

@Ladsgroup @Izno would we like to be more specific on how soon this is happening?

I make no comment on whether there has been sufficient notice, only that there was notice. And that notice is ancient (like this task is).

It's marked as deprecated at the page describing the formats: https://www.mediawiki.org/wiki/API:Data_formats

In T421973#11776548, @Ladsgroup wrote:

[snip]