@MusikAnimal Thanks!

I think the expectation should be that the icon will be shown as long as the corresponding oojs-ui.styles.icons-* module is loaded (without the need to add your own CSS).

Are the votes that have been removed before the patch for this went live going to be restored?

It doesn't work the way I expected. The selection happens on mouse up, not down, so it's impossible to drag the selection and expand it to lines above or below.

In T130134#9571174, @thiemowmde wrote:

Sounds like this is effectively the same issue as T130888: Category addition/removal should be displayed in the watchlist independently of further edits on articles?

Different issue I'd say. This is about making it possible to subscribe to non-H2 sections.

Done: T420555: Triple-clicking on brackets should select the block of code

Too bad a third click doesn't select the entire lines. I found that quite handy in CodeEditor.

Merging the votes but also pinging the users will also allow them to retract it from the target wish in case they disagree with the target wish. Wouldn't that be enough @FonAfon?

You're not echoing my point. I was talking strictly about when the wish being closed and the wish it's being merged into both already have a support vote by the same user. It's a no-brainer to transfer the votes by users who have not voted for the target wish.

I imagine there should be consideration on which should be kept if the same user has voted for both wishes. I'd say don't transfer the vote for the closed one if it has no comment, and do if it does and the vote for the non-closed one doesn't. The question remains what to do if both have comment (and they differ). don't transfer the vote at all, given the two wishes may not describe the completely identical problem/request.

OK, I'll defer to @MusikAnimal. It is my opinion that it defies ASTONISH to go against most other editors, including Notepad, TextEdit, Vim, VSCode, Sublime, Notepad++, and gedit.

That Ace/CodeEditor did something poorly is a terrible excuse to continue doing it that defeats the whole point of replacing it. Name an editor besides Ace that considers the initial caret position to be line 1 but column 0.

Thanks for working on this! I've filed the related issue mentioned above as T418975.

Resubmitted original issue as T418345: Columns start at 0, not 1.

The caret is already blinking at the first position, so I doubt that. I don't know of a text editor whose status bar says "line 0, col 0" after opening a blank tab.

Still happening (note the removal of the votes at 2024-09-15T09:41:33.091Z, 2025-06-26T13:23:19.559Z, and 2025-07-02T17:57:40.216Z).

Video added in case it wasn't clear. (ETA: Replaced for clarity.)

Why? Why does the whole page need to change its scroll position instead of just inside the editor?

Has rECMI34d8c5eedca5: CodeMirrorSearch: allow native Ctrl-F to work when focus is on search been a solution, or at least a mitigation?

@Jdlrobson So you're not proceeding with your proposal, which I said is still an improvement to the status quo?

Fixed upstream: https://github.com/codemirror/dev/issues/1668

That's still an improvement to the status quo, isn't it. It does sound like allowing, if not requiring, specifying a class or classes when registering an "associated navigation link" would be a more robust approach, however.

How are those "pages where special page subpage can be any title"? What you're proposing is precisely what this task is asking for; I'm just confused about the "downside of this is" bit.

The downside of this is for pages where special page subpage can be any title this would mean you'd need to rely on attribute selectors, but I assume that's okay?

Related: T416594: Watchlist tabs don't have semantically specific IDs or classes

My assumption was that browser: true and es2024: true make it recognize more globals so CM already has a list of them somewhere. That's not the case?

Thanks for investigating this. But I disagree that environment-specific globals need not be highlighted. As long as browser globals are set to be recognized as they already are, I don't see why not. Couldn't they be dynamically (de)highlighted to reflect config.env?

padding: 12px on .cdx-table-pager is pretty weird when it's already inside #mw-content-text, which has plenty of space around it. It makes "n items" look like it's randomly indented.

Around 2026-01-23 12:00–15:00 UTC I received the emails I had missed in seemingly random order, and now it looks back to normal. Thanks for your effort @jhathaway.

After deployment, run a script to add the auto-votes for all the wishes created prior to this feature being released.

This criterion is clearly not yet met.

Wait, so you're not retroactively filling in support votes on behalf of the authors of existing wishes (even though wishes created after the patch for this task went live already automatically have one vote minimum)? That seems... not good.

As the task title and description make clear, specifying the language is one of the requirements, so I'm at a loss as to why it's already at QA.

The wish title should be shown for all visitors, not for reviewers. The implication of including "proposed by" affects all of them while the benefit you describe is relevant to only a handful. So the harm outweighs the benefit IMO.

It feels strange to update the search input with Ctrl+H which places focus on the replace input.

Ctrl+F/H should also update the input while the panel is open.

The caret in CodeMirror is thin and sometimes almost invisible. CodeEditor's thick caret seems better.

This is especially so when the cursor is next to a matching bracket. Adding .cm-cursor { border-left-width: 2px !important; } to my CSS solved it, but I wonder if it can be upstreamed.

I'm sorry, I found your commenting so quickly on something so tangential when you didn't comment on the substance of the issue for weeks (passive-)aggressive. That's not to say anything about you personally, but I hope it goes without saying if you "disagree" with someone's negative experience without concrete counterevidence, that's going to provoke a certain kind of reaction in them (whether they show it or not).

That makes even less sense (which is possible somehow). All buttons on that toolbar is related only to the textbox right beneath it. And replying only when you have something to say in preference to addressing a report of bad UX is appalling.

Funnily enough, the MediaWiki-extensions-CodeMirror button is always enabled... cc @MusikAnimal

No, mw-userlink was added to links inside edit summaries and log entries on Watchlist, Contributions, etc. I'm talking about distinguishing interface and other links on special pages.

Adding a class to all user links is fine, but there'd better be a way to still distinguish the interface ones ("... (talk | contribs)" etc.) and the others.

@STei-WMF Something like

🛠️ Interface elements such as diffs and categories generated by MediaWiki used to have the attribute data-mw="interface" to distinguish from wiki content. The attribute has been replaced with data-mw-interface="", to avoid potential conflicts with other data-mw attributes, which are generated by Parsoid.

Still happening.

Please announce these kinds of changes beforehand...

I'm assuming the problem with wish authors being renamed (as there was with W91, W105, W371) hasn't been fixed, given that proposer is still the username. I wonder why user IDs aren't being stored instead of usernames, for wishes and votes alike.

Why is this happening? If it's solely because of T409613: Support voting for wishes under review it strikes me as premature, as "accepted" and "under review" communicate clearly different—basically opposite—things to users. Wouldn't creating something more neutrally worded like "unclassified" (and merging both into it) be an even better option?

@TheDJ I can see that, but closing a task that's not fully resolved is also disruptive. Feel free to make T411605 the "suggest" task or whatever but please don't close this as resolved, because it's not.

I will update the task description to reflect what was done. You can file separate task with any further work if you like.

The "accept" part is resolved, but the "suggest" part is not.

Thanks for working on this! However, it's unfortunate that in LivePreview, the unaltered page is still downloaded and the error is detected only front-end, which partly defeats the point of the wish because we still have to wait for the entire page to be downloaded before we see the error. Couldn't the API be made to return just an error instead of text if templates doesn't include templatesandboxtitle?

add brand new classes for links that looks like user links in content areas, with equivalents for the all different types of user

This seems like the obvious way to go (maybe except the "with equivalents for the all different types of user" part).

At the very least please get rid of "proposed by". It unduly emphasizes the submitter when wishes belong to no one but the community. In enwp's terms, it's WP:OWN.

I find the display both intrusive yet easy to miss, so I just did .ext-communityrequests-entity-talk-header { display: none; } and kept my script running on talks. The placement, color, padding, and verbosity (we all know it's a discussion, and who proposed it isn't particularly germane) all facilitate banner blindness. I didn't even notice it the first time. And once I did it was not easy on the eye. I think it should be more like a hatnote.

In T406957#11389344, @MusikAnimal wrote:

In T406957#11388367, @Nardog wrote:

I hope the title will link to the main page ([[Community Wishlist/W...]]) when the list item is about a subpage, talk page, etc. I made my script do this and I've found it useful.

Couldn't that be adverse to patrollers? The linked page should be the page that was actually changed, I think. I was nervous even showing the wish titles in recent changes.

As a patroller scanning titles on recent changes, at quick glance you'll see the wish titles stand out as if they were actual titles. The descriptive and sometimes lengthy names may appear like vandalism or nonsense pages. This isn't a problem on Wikidata because most of the editing is done to entities, so recent changes patrollers are used to going by labels and not page titles there. It's possible to only show the wish titles for watched pages. I was considering doing that, depending on how reception goes. Patrollers may only care about the actual title, while page watchers would more likely prefer the entity title.

We also need to keep in mind the extension may eventually be used on other more content-focused wikis, so the aforementioned problem may become more pronounced. If it comes down to it, we could introduce a preference or something.

I find this intrusive and ugly, inhibiting the reading experience. If it's how it's going to be implemented, I'll keep using the edittop gadget, which defeats the whole point of this task viz. to make the gadget redundant.

What I'm saying is that the edit summary shouldn't contain English words that part of the user don't understand.

I have news for you: The source of virtually any wikipage that's not in English contains—if not is littered with—English words. Sure, magic words and template names and parameters can be translated, but they frequently are not, and HTML(-like) tags can't be translated at all. Not to mention many punctuation characters in the ASCII set are culturally specific to Europe/anglosphere (less tech-savvy East Asian users are frequently confused when full-width characters don't generate code). /* top */ is code that generates a link to #top, which is in the HTML specs. That's no different from <b> or <span> or class=. If you think top should be translated then you should think those should be translated too (which I don't). If you think you're doing non-English speakers a service by translating it, I find that naive and short-sighted.

There shouldn't be any non-localized strings in the interface :)