https://www.mediawiki.org/wiki/Design/Interfaces_for_Human_Knowledge (T423941):

Design with Others
We collaborate with others through means of inclusion of ideas, research sessions, and working as openly as possible.

You can check for edits with specific summaries in wikis where this is already default for a long time, like Russian Wikipedia (/* Преамбула*/ was added by the gadget, now it is /* */). That should probably lend the appropriate statistics.

To clarify, in all cases where background CSS property is set, you should also set color to something (like color:inherit) because Vector 2022 night mode is assuming that any manual declaration of a background colour needs the black text colour (since usually background colours are set only with consideration for light mode). So that page should just be fixed along those lines. That’s not specific to SyntaxHighlight.

Would be good to ask the Wikimedia communities using Parsoid what still needs to be fixed before making such a switch, since there are pretty important bugs like T422291: Wrong section edit link target with Parsoid when section is transcluded (and I’m sure many other ones) which currently are unaddressed but would cause confusion among the third-party users if Parsoid was deployed by default as is.

In T429085#12016594, @Raymond wrote:

"ignored" and "optional" are added to the translatewiki.net configuration file manually based on the message content. The message documentation could be a hint but is never the main criterion.

It would be good, however, to have both reflect the same state, probably the state from the extension (i.e. hide {{optional}} if the message isn’t really optional based on some magic word like {{TRANSLATIONSTATE}}). There is also a more general problem of translatewiki messages not being deleted after the message gets deleted from the repository (which also makes tracking errors in message documentation worse), but that’s harder to solve than this.

Visual enhancements are not applied on all pages by default so if you’re looking at a page outside of talk namespaces, the chances are, you’ll see this problem.

Discussion Tools currently displays its brackets around ‘(un)subscribe’ action like this on translatewiki.net:

I read this just now in another task related to this one:

In T368095#9971720, @ABreault-WMF wrote:

Section edit links are only relevant to what we call "read views". The way the pipeline is constructed, Parsoid parses wikitext to a canonical output, which gets cached. Then, depending on the calling client, the cached output is transformed. See core's DefaultOutputPipelineFactory for the stages that are applied for desktop clients, one of which is HandleParsoidSectionLinks. These section edit links are undesirable for editing clients, like VE, or the mobile apps, etc. If the legacy parser was asked to apply them during preprocessing then they'd be in the cached output.

This made me wonder: while the links are undesirable in page views, what stops Parsoid here from doing something like exposing them in the metadata, so that Parsoid itself could then build correct edit links in read views? i.e. something like this (or even just href)

<link rel="mw:EditSectionLink" data-page="…" data-section-id="…">

This wouldn’t pollute VE or other contexts more than the existing HTML pollution we get from Parsoid, but it would ensure that it always knows what context an edit link is required in. Seems like a potential solution to this issue.

In T428744#12007177, @Tacsipacsi wrote:

The difference is that people visiting (protected) discussion pages are much more likely to want to edit/comment than people visiting (protected) articles. And what harm do these buttons do? I don’t think your points are strong enough to remove the buttons –

In the case of your huWP page, in our current moment, unless T259824 gets resolved, they actively mislead people into thinking they can reply using the reply tool, which was my point above :-) More broadly, they present an action that cannot be taken even while we have ways to not do that. Your home wiki that protects the main discussion page while allowing the same users to participate on subpages is not a strong enough point to break the existing convention that if you cannot take a certain action, you shouldn’t be misled into thinking you can.

Additionally, it should be noted that you cannot use https://hu.wikipedia.org/wiki/Wikipédia:Törlésre_javasolt_lapok?cdenable=0&dtenable=1&uselang=en to reply even if you are allowed to edit the page:

In T428744#12005686, @Tacsipacsi wrote:

DiscussionTools is also relying on Parsoid data, maybe the current task is going to be easier to solve once T422291 is fixed.

I meant there that if Parsoid is turned on, those links point to the wrong direction if you’re an admin. They still don’t appear if you are not able to edit the page, as you can see in private browsing mode at https://ru.wikipedia.org/wiki/Шаблон:Вложенный_список (Parsoid-generated).

That sort of thing still violates MediaWiki conventions, though, since unless you’re an admin, you won’t be able to go edit sections in https://en.wikipedia.org/wiki/Template:Wikipedia's_sister_projects from the protected page (but as an admin, you can, unless you’re using Parsoid, see T422291). I think allowing people to post in that circumstance is probably more out of the ordinary than disallowing it.

I think the actual roadblock for this feature from languages like Russian is not gender but that in many contexts, what’s needed is not just different gender, but also different forms (5-й век, but в 5-м веке, в 1910-х годах). This sort of thing leads me to the opinion that where the ordinals are needed, they should be actually just written down like $1{{ORDINAL:$1|st|nd|rd|th}} (I guess English can be {{ORDINAL:$1|}} if we want to be a bit biased there), since that’s the only way that would provide the flexibilty for different languages. Anything else would eventually break down as message authors rarely think about what cases would make sense in other languages even without {{ORDINAL:}}.

Use case for this in the wild:
https://translatewiki.net/wiki/Template:Discuss_term/styles.css
The template defines a shared border-color and modifies border-left-width to be 5px. Because I can’t set variables on different states, I have to re-define entire border property instead, overriding border-left-width assignment. I ‘solved’ it by making it 5px !important but that truly shouldn’t be necessary for what should be allowed with border-color.

The current MediaWiki:Vector-2022.css styles on English Wikivoyage fixing this issue are bad for accessibility:

#firstHeading:empty {
	visibility: visible;
	display: block;
}

For the record, this is a more generic problem as well:

@Raine JFYI but T428484 was essentially resolved by setting $wgScoreSafeMode variable to false, so maybe a revert isn’t too necessary? In the config docs it says this about it:

Must be set to false for LilyPond versions 2.23.12 or newer (safe mode was removed in 2.23.12 as it could no longer be guaranteed safe). For older versions, set this to true to enable LilyPond's safe mode (default). NOTE: if set to false, all inputs should be sanitized and/or trusted, and the LilyPond binary must be appropriately sandboxed.

Important note: if your user script is supposed to support third-party wikis (such as https://www.mediawiki.org/wiki/Translator_Buddy), updating it to the new version of mw.util.addPortletLink is going to break the portlet link addition for third-party users unless they also update MediaWiki to 1.47. This could be an important consideration before updating.

I’m sorry to say, but overall, the new icons became very much generic and soulless. If anything, they became less tied to the current MediaWiki style, especially here:

In T428484#11996282, @stjn wrote:

Accidental update aside, if the decision would be to keep Lilypond 2.24.1 version (currently running on the websites as a result of T427820), then at least these tasks can be closed after everything gets checked:

SVG one can’t since https://en.wikipedia.org/wiki/Dynamics_(music) still renders files in PNG. Would be nice if someone can figure out what’s missing there.

Accidental update aside, if the decision would be to keep Lilypond 2.24.1 version (currently running on the websites as a result of T427820), then at least these tasks can be closed after everything gets checked:

• T385404: Deploy LilyPond 2.24 with Cairo support to shellbox containers
• T49578: Score should output SVG

Seems to have caused T428484 regression of Score extension (no music scores are shown any more).

Ah, it doesn’t support cases like https://ru.wikipedia.org/wiki/Модуль:Вложенный_список#L-10 or https://ru.wikipedia.org/wiki/Модуль:NumberOf#L-376 which is why I thought it’s not currently implemented. Apologies.

Tested on en.wikipedia.beta.wmflabs.org, the field now gets hidden without JS. Thanks to @Samwilson for review.

A function like the above also enables SyntaxHighlight to make the link clickable similar to require(), mw.loadData() and mw.loadJsonData().

Although I agree with having a simpler way to add styles since it’s such a common thing, I should note that currently all of those aren’t links either.

In T219543#11080628, @DLynch wrote:

There we go. Vector-2022 completely throwing away the toc classes that other skins use made it more of a pain, but...

Just a postmortem comment but allowing to search by canonical page name in English, which was the quoted part, was never done. (It should be some day.)

Apparently this was also the topic of T42307: mw.notification Usability Improvements (from 2012!) but it also has some other focus so this more specific task can probably stay.

URL-based tracking seems much more intrusive to me than mw.track on the feature itself without any additional data collection 🤷 (I don’t think I want to spearhead adding this to ruWP as a gadget since in my personal opinion, it is not helpful enough of a feature at any wiki with Unicode URLs, and the plan to remove it from Minerva because of a WMF-only experiment is especially strange. Maybe someone else can take that up though.)

Potentially instead of guessing the impact of it, maybe you could just track how many times the feature was clicked on? Seems like a reasonable use of that if you want to measure how useful it is to people.
https://www.mediawiki.org/wiki/Gadget_kitchen:_recording_metrics

In T418382#11847736, @egardner wrote:

You can test on production using that URL plus mobile view, i.e. https://en.wikipedia.org/wiki/Paris?useskin=minerva&useformat=mobile&mmvBeta=1#

Since I don't know what this could even be tagged as if I file a separate task, please be aware that you need to introduce some background for transparent PNG and SVG images: https://en.wikipedia.org/wiki/Paris?useskin=minerva&useformat=mobile&mmvBeta=1#/media/File:Ville_de_Paris_logo.svg

The best actual use for it isn’t even necessarily interactivity but the ability to use CSS on SVG contents. As we are currently providing the night mode by default to all readers, this is incredibly important even if there was zero interactivity, as an SVG in base URI would have to be either given a white background or reproduced twice to work in night mode. Either way, not the best.

Now that WMF returns 429 more frequently for various requests, including file requests, returning 429 here is even more confusing on what the actual cause of the issue is. People in topics like https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#c-Sneeuwschaap-20260603181600-Неотображение_иллюстрации cannot tell that this is an issue caused by an erroneous file since it says too many requests. Even I thought at first that it was caused by bot-fighting throttling, not by a thumbnail error, and I’m probably more knowledgeable than most regular users encountering a broken file in their articles.

I agree with @jhsoby here. It doesn’t make sense to show Hindi language at Hindi Wikipedia, it makes sense to just ignore the list or show other preferred languages.

Icon from FY25-26 WE3.5 Donor Identification and recognition project gets added and then hidden for mobile users, which moves the search icon to the left even though it’s not supposed to be there.

Can we at least do this for logged-in users, please? It’s a very bad experience to type in https://translatewiki.net/ in the browser bar and end up on a page that doesn’t have a sidebar, any notification indicators, or a normal search bar, as well as no easy way to go anywhere else other than through my user page. As a semi-regular user of the website, I really struggle to understand who is helped by the main page functioning like that.

In T422291#11923669, @ABreault-WMF wrote:

Try .mw-parser-output[data-mw-parsoid-version]

You can’t target .mw-parser-output itself in TemplateStyles, unfortunately (and putting it in Common.css for everyone would probably be too much for this bug).

I think Manage labels is fine there since it’s a very new feature so its placement increases awareness about it. Eventually, of course, that could be moved too. Edit raw watchlist should probably be moved to Special:EditWatchlist page as well, though.

After reading up at T417244, it is similarly questionable now to have the link to edit raw watchlist at all times. Maybe both of them could just be moved inline at Special:EditWatchlist since that page now has good performance.

This has a bunch of causes:

• The new View watchlist message for the page tab in English translates to Beobachtungsliste anzeigen on the screenshot and originally translated to Посмотреть список наблюдения in Russian. Would be good to just shorten it to Watchlist since that’s pretty much understandable already and follows the logic for page tabs everywhere else. I ended up translating it that way in Russian because all of the possible literal translations were too long.
• The new Watchlist labels page tab also increased the size.
• The Edit raw watchlist page tab is also hard to translate in a way that ends up short and sweet in most other languages. In Russian it was translated as Редактировать как обычный текст (Edit as normal text) before I changed it to slightly shorter Править текстовый список (Edit list as text). In German we see Quelltext der Beobachtungsliste bearbeiten (Edit source text of watchlist) which is very long. Since Special:EditWatchlist was improved and is now easily accessible even for people with bigger watchlists, maybe the solution here is to
• Clear watchlist is another page tab that is long in translation (Beobachtungsliste leeren, Очистить список наблюдения) and doesn’t make sense to have available at all times. I filed T427272: Move Clear watchlist link from page tabs to Special:EditWatchlist only just now to consider moving it only to Special:EditWatchlist.

FWIW I also found it very confusing when someone thanked me for both the edit and the comment recently. I feel like there isn’t really a circumstance where allowing people to thank for edits that are simultaneously comments is warranted enough. Obviously you wouldn’t want to prohibit such thanking entirely but it looks like a bug more so than a feature.

The logic for these decisions would also apply to desktop editors.

Does this mean that it doesn’t matter where a person edits, their edit level would reflect what they see on mobile, or something else? Because if the answer is ‘something else’, then this is a huge breaking change that would never be accepted by Wikimedia communities. The notion that certain features need to be hidden from people is not something that should be decided by WMF developers (which, let’s face it, don’t have enough hands-on experience here to know what they’re doing is good) without community approval.

A bit confused about this task because Advanced Mobile Contributions mode already includes that link in More dropdown (option 2):

FWIW it didn’t get a lot of questions in Russian Wikipedia, just this one (with some suggestions that it should link to the actual start of the article instead):
https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#c-Jet_Jerry-20260503213500-Редактирование_первого_раздела_статьи

This basically breaks the easiest ways to edit sections for templates with documentation pages. It is quite unfortunate that there is also no way to differentiate Parsoid-rendered pages from non-Parsoid ones via CSS since I’d rather hide those edit links while this bug is still active than mislead people into thinking they lead somewhere useful, like they did before.

Are you sure you’ve visited just the page with underscore? Because that’s where the problem lies here: unless you go through a Parsoid URL with a space instead of an underscore, it is not highlighted as visited, even if you already visited it. I doubt that’s different in different browsers, and I am on Windows 10 anyway.

In T379645#11921970, @cscott wrote:

This seems to be a Safari bug, though, not an inherent feature of URL normalization.

No, this happens in every browser and is different from the Safari bug reported in T425211: Link colours on mobile not changing to purple when clicked on. I use Firefox only and on my own user page I don't see the page for the script I wrote marked as visited because the interwiki link uses spaces:
https://ru.wikipedia.org/wiki/Участник:Stjn (Ctrl+F for Translator Buddy)

@OSleger-WMF are you sure it’s the same bug? I was also under this impression but it seems different since users report that they don’t see it just for interwiki links.

In T294188#10435047, @CCiufo-WMF wrote:

Not sure how much of an interest there still is in updating this icon, but the Design System Team may revisit the icon set holistically some time this year, and we can take this icon into account (cc @DTorsani-WMF).

Now that it’s being used by Vector 2022 for all users, definitely something that’s needed. Someone put it best that this is a move icon for photo editing software (or some drag and drop situation), not an icon for renaming something.

I’m not sure if POC is purely for demonstration purposes as it’s unclear from the task text but, if it’s not, please be aware that changing the order of the sections with CSS does not change the accessibility tree of the elements, so any potential section-swap should only happen server-side for accessibility reasons.

2026 version of this bug does this at https://ru.wikipedia.org/wiki/Макмиллан,_Дональд

<a href="//ru.wikipedia.org/wiki/en:Peary_Polar_Expedition_Medal" title="en:Peary Polar Expedition Medal"><img resource="//ru.wikipedia.org/wiki/Файл:Perry_Polar_Expedition_Medal_ribbon.png" src="//upload.wikimedia.org/wikipedia/commons/thumb/9/91/Perry_Polar_Expedition_Medal_ribbon.png/60px-Perry_Polar_Expedition_Medal_ribbon.png" decoding="async" data-file-width="212" data-file-height="60" data-file-type="bitmap" height="17" width="60" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/9/91/Perry_Polar_Expedition_Medal_ribbon.png/120px-Perry_Polar_Expedition_Medal_ribbon.png 2x" class="mw-file-element"></a>

The link is not to a wrong place but because it’s not resolved properly, you see a failed Page Previews popup.

Ugh. Thought so at the first glance but then thought it was too weird to be true on a wiki that uses Parsoid by default :-/

https://en.wikipedia.org/wiki/MediaWiki:Blanknamespace is locally defined to be (Article). If the dropdown somehow displays (Main) despite that, that’s a bug that should be fixed in a separate task. FWIW I see (Article) there.

@JSengupta-WMF I don’t think this is a correct link since it’s not about watchlist star at all?

Same with Special:MovePage btw (and I assume Special:Undelete? no idea).

I feel like even if you are able to add your own username via preferences to Special:Mute, this is definitely not something that should be visible to the end-user. @Dreamy_Jazz, do you have objections if I submit a simple patch that removes the link to Special:Mute from my own contribs?

I prefer the current dropdown to stay so I’ll brainstorm my own solution. To be honest, I really dislike typing in those selects that @matmarex proposes, so I feel like that would be an even bigger downgrade in comparison to a plain old <select>. To me the ideal for most people would be something like this:

1. We show the full title in the page title field while keeping the select. The validation for how long that title should be can happen on the server/client without counting namespace name, but we could limit the field itself to 256 + [number of symbols in the longest namespace name or alias] if we really cared. I think MW JS code that can count remaining symbols can be used to count it to specific amounts of characters, so we could adjust how many symbols are max allowed depending on the input before the first :.
2. When the namespace part of the title field changes without adjusting the namespace select, there is a checkbox prompt shown to user to confirm changing the namespace to the new one.
3. If they check the checkbox with JS enabled, the select instantly changes to the new namespace choice and the title gets normalised (WP: → Wikipedia: etc.). The prompt gets unchecked and hidden again until the next change. The label could be something like Confirm namespace change to Wikipedia (bolded).
4. If they have JS disabled, the prompt to confirm the namespace change gets displayed on form submission before a rename. The resulting name of the page should be displayed, so something like Confirm move to Wikipedia:Foo (bolded).
5. When someone changes the namespace in the namespace select on their own, we assume they did this willingly and don’t ask to check. With JS there should be a simultaneous corresponding change to the text field text. Without JS there should be a confirmation prompt if the title ends up to be something like User:Wikipedia:Foo.
6. There are titles like Category:Wikipedia:Articles for deletion in a number of wikis. Those shouldn’t be touched or asked about unless someone changes the namespace field.
7. Just so it’s not confusing, there should be a label above namespace select and the label beside the input can be changed to Full title.

Yeah, just tested share API at https://6e9260483c.catalyst.wmcloud.org/wiki/Алан_Тьюринг with Firefox for Android and it also only copies URLs encoded. I think that’s a definite ‘no’ for anything aimed at the editors (and honestly why I might end up switching experimental flag off on desktop once T18691 hits the production).

In T418197#11886303, @matmarex wrote:

Should DiscussionTools's option do the same, or be different?

The other parts of DT copying don’t use share API so probably best not to use it here, either. Especially since right now it allows to quickly copy something while share API is a bit more intrusive to editor experience (at least I found it so while testing in Firefox), and doesn’t actually allow to copy Unicode as Unicode in all contexts (definitely not on Windows 10 where I tested).

It's the same as with not having Talk tab on most wikis even though that’s the basic feature of all MediaWiki websites: the development team is thinking of mobile website as a cut-down, dumbed-down, readers-only version of the desktop interface, so anything too inconvenient was cut a long time ago and now there’s resistance to getting it back there. Which is ironic considering that the WMF seems to want to improve the mobile editing experience in the following year.

Sorry, may have been premature. This is specific to mobile Parsoid according to reports:

• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Links_not_changing_colour
• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Some_new_mobile_(web)_issues

but probably not exactly the same as that other task.

T379645: Parsoid does not convert underscores to spaces for interwiki links is what causes this discrepancy from Parsoid, and I doubt there is another reason for it so I closed this as a duplicate. On mediawiki.org specifically, it is also the fact that there are Special:MyLanguage/ links there which do not lead exactly to the pages you end up on.

Similar thing with disambiguation box styling missing on mobile:
https://en.wikipedia.org/w/index.php?title=Alexander_(disambiguation)&useparsoid=1&useformat=mobile

I do somewhat worry that this implementation would cause newcomers to fill in the section part instead of writing after it, but they already do it sometimes, I guess.

Heads-up for others after updating https://ru.wikipedia.org/wiki/MediaWiki:Gadget-edittop.js that this is now inserted automatically when editing section=0 (T2156#11881517).

Would be nice to somehow add it to their overflow menu on mobile. Not a necessity of course but this is probably one of the most useful feature applications for the editors.

In T18691#11882580, @egardner wrote:

Introducing similar functionality outside of the experiment (but at the same time) is just going to add confusion.

I don't see a problem with this going out to Vector but I'm opposed to making this change on mobile right now. We can revisit after we have A/B test results from the ShareHighlight experiment.

Then ShareHighlight experiment could remove that link for people using it, as I mentioned. This is going to be a core feature so turning it off for a WMF-run experiment would also affect, for instance, translatewiki which also uses the latest alpha but won't have the WMF-specific extension.

It feels to me that hiding the link from Minerva is extremely wrong if it's something that's going to be in MediaWiki core. The icon ID should just be fixed to display a supported icon, third-party wikis won't have the same experiment (never mind that it's also not a given it'll be kept) for the WMF wikis. If the experiment devs decide section links are detrimental, they could just hide it themselves.

In T18691#11881882, @DLynch wrote:

The no-js display issue is because VisualEditor assumes that when there's no JS .editsection-divider should be given display:none, which is normally correct because it's part of hiding the "edit with VE" link... but now there's another element present and it all falls apart.

But isn't this link practically useless without JS? Or at least should be renamed to 'link' or something since it's not going to pull up a share menu.

Looks like this with JS disabled:

Meant to tag the other Sam, apologies to both.

It seems to be a bug since unwatch popup closes with Esc. It's also a clear accessibility violation and probably not intentional. @Samwalton9-WMF any ideas?

I very strongly dislike the suggestion of experienced editors that newbies should know some keyboard shortcut to use site features beneficial to everyone. I use temporary watching and it's amazing. I don't have a use for watchlist labels yet but it doesn't mean someone else won't. There is no access issue to doing two taps on mobile, people do them there every day. If anything, it's more beneficial on mobile because you cannot accidentally unwatch something any more.

In T417847#11877950, @Samwilson wrote:

A few people have said that one-click unwatching would be good, but I'm still not sure how that should work now that we've got watchlist labels — is unwatching more useful than being able to change the labels (or expiry) for a page? Because if you click to unwatch, then you also discard your labels. We thought about adding a second button next to the watchstar, but that's a lot more complicated (especially now that the watch link is also more likely to appear in the tools menu, if Reading Lists is enabled).

Discord (and maybe some other apps) offers to skip the confirmations with Shift-click. I think that's sensible as a way for experienced editors to adjust to it, as long as it's shortly mentioned in the popup.

Currently on latest Firefox, Windows 10. I see a variation of the same thing happening on latest Edge (old suggestions appear, then new ones replace them). It happens on Special:Search pages for some result when you do the actions described in the task. I do them because unfortunately Special:Search input suggestions do something different from regular ones on top (they do not redirect to the page directly, see T210649: Suggestions in a search field on Special:Search should act the same as suggestions in search bar).

All of this was logged out since I don't use Vector 2022 logged in. I just visited the page again and did the same and the same thing happened, so there's definitely something. I suspect it might have something to do with search suggestions from the search input on the page maybe?