I wrote this on [[Talk:Community Wishlist]] but it's germane here too: I for one don't understand why we can't vote for wishes under review. It adds the burden of having to remember or make notes of wishes you intend to vote for. Why not just hide the votes until the wish is accepted... It might even facilitate the review process since the numbers of support votes would indicate which wishes have merit.

I would add another acceptance criteria that the author of a wish won't be able to remove their support.

There should also be a parser function to retrieve the vote count for a particular wish or area.

Are the :set... methods not chainable?

An iteration of the idea: T407086: Make edit summaries more specific

Sounds like a good wish :)

A more scalable approach would be a parser function that returns the specified property given a wish or focus area number, e.g. {{#CommunityRequests:link|W123}} returns the title, {{#CommunityRequests:link|W123|status}} (or {{#CommunityRequests:link|id=W123|prop=status}}) returns the status, and so on. Then a template can be created e.g. [[Special:MyLanguage/Community Requests/{{1}}}|{{{1}}}: {{#CommunityRequests:link|{{{1}}}}}]]. That way each editor can use whatever markup.

I mean the fact you can search for aliases should be obvious in the UI.

It does do something different from the browser-provided search: it includes the aliases.

The table of contents does not get updated while searching. This is especially bad UX in non-Vector 2022 skins.

I'm at a loss as to why you didn't remove the search box too. Duplicating what all browsers already provide (find in page) seems like such an uncalled-for addition to the mounting tech debt.

Are you sure you're using CodeEditor and not CodeMirror? CodeEditor is not enabled in the Template namespace.

Sure, it would certainly make my use case simpler and future-proof if all it had to do was load an RL module.

You should see a menu like this.

For one, I need it in my CatChangesViewer script (source). I want users with IP access to be able to reveal IPs inside a dynamically created list that includes temporary accounts just like on Watchlist etc., and the only way I figured I could provide the same experience as on those special pages is using non-public APIs (dispatcher.js and initOnLoad.js). If there's a stable API I can use instead, please let me know.

FWIW you can press F1 and select "Show settings menu".

@Waddie96 Are you trying to enable or disable autocompletion? This task was closed as resolved because it was turned on by default.

In T373711#11007507, @Novem_Linguae wrote:

A quick note that Extension:AbuseFilter has a code editor at pages such as https://en.wikipedia.org/wiki/Special:AbuseFilter/1. Might want to investigate adding that to your list of code editors to replace with CodeMirror.

AbuseFilter uses a custom programming language, so that part might be challenging.

It shouldn't remove broken URLs, its whole job is to add the archived versions. I'm at a loss as to how that would "help". (And how was it "redundant"? The DOI isn't open-access.)

It's not garbage if you let the InternetArchiveBot handle it. Your bot mistaking a dead link as subscription-required is undeniably a bug.

The Android app has been adding top for quite some time, see T280308. That seems like a bug that needs to be opened for Wikipedia-Android-App-Backlog in and of itself.

Oh, that's even worse. If I'm on an old revision (i.e. permalink or diff) I don't expect the page to be updated to the latest state even after replying.

(Note you can still reply to a thread when viewing a non-latest revision. Changing the URL makes no sense especially in such a case because the version of the page you see (the old revision + your reply) doesn't exist anywhere as a permalink.)

I don't think it would be an unexpected behavior for most users if the reply you just posted disappeared after reloading the page, especially when viewing a permalink (which the content under a diff is). What would be unexpected is if simply replying changed the URL in the address bar (but didn't load it).

in order to show your just-posted comment, the latest version of the page content needs to be loaded.

Except it doesn't. DT just adds the posted reply to the display but doesn't reload the page and just changes the URL via History API. I fail to see the point of this.

In T396118#10887937, @Esanders wrote:

We should strip diff= as well.

In T309446#10883877, @Cparle wrote:

This might be simplified by filtering by namespace rather than grouping by namespace

Once you disable the tooltips, "Enable Reference Tooltips" appears at the bottom of the page. The script even shows you the message "You can re-enable Reference Tooltips using a link in the footer of the page" after disabling them.

I see; it's just a nice-to-have anyway, not a must.

Anyway, may I ask why you'd like to use Ace?

I mean I want to stay on the editing page (without reloading) and go back and force between Ace and CodeMirror. The default WikiEditor interface affords this (by toggling "<>" and pencil), so it would be a shame if you had to choose between the two or keep reloading the page.

Is there support for other languages (especially the site's) than the user's?

Will there be a way to use both (switch between Ace and CodeMirror)?

"hist" is now not linked again.

I just noticed this in the Advanced section and it is indeed super neat, but I really wish the button was a toggle so a second click hid the panel. (The same could be said about the find-and-replace button.)

@SD0001 Can you look into this? The inability to live-preview template gadgets is frustrating.

Why not have "Copy as CSS", "Copy as Less", etc. rather than a dropdown then. There's enough room in each row.

Not done for WikiEditor.

That's not the point. Even if the empty span was not generated, margin-inline-end: 3px; to the icon would still result in awkward space before the semicolon.

Adding some margin-inline-end: 3px to the info icon results in:
Which imo looks fine.

Codex/OOUI now has literal, which is fairly similar to the cursor example above. That would be quite an improvement over the current "both axes" icon.

But then testing on https://en.wikipedia.org/wiki/Help:IPA/Turkish I think things look well spaced out with the margin.

With margin	Without margin

How is the former better? "ⓘ[6]" looks grouped so it looks like the reference is about "ⓘ" and not "erkek". Perhaps the gap between the icon and the label could be reduced too but I'm at a loss as to how you can look at these and think the former better conveys which component is related to which.

The issue is not specific to Phonos but applicable to all content with dark-mode-tailored styles that can appear in a reference or notification.

Why wasn't this change applied to OOUI?

How on earth is the patch still not merged?! We've been missing errors and warnings for weeks!

In T381537#10411269, @MusikAnimal wrote:

Related, I wonder why we don't take more advantage of polyfills. Array.prototype.includes() for example is a tiny implementation, and would make JS developer life so much easier.

One way to mitigate the problem is to make EditRecovery compare the current form values against the defaultValues instead of keeping an originalData object. That way a script would be able to modify the defaultValues to "reset" EditRecovery.

Hmm, I can't reproduce it without turning it off either anymore.

No, but either way I get the same error.

per-wiki, using $wgPhonosButtonClasses, which can be set to eg. [ 'noexcerpt' ] to preserve the current behavior;

Couldn't this be an abuse filter?

That ticket makes clear the feature tests were carefully discussed and designed. It's the linter that's out of sync, not the other way around.

It's in T178356.

Searching for "Chini.png" and "Queer Man Peering Into A Rock Pool.jpg" does accurately bring up https://en.wikipedia.org/wiki/Chini.png and https://en.wikipedia.org/wiki/Queer_Man_Peering_Into_A_Rock_Pool.jpg, so they're clearly capable of indexing wikipages ending in an apparent extension (NB Bing fails to show the latter in the main results). One wonders why that doesn't apply to the File namespace.

The only downside I see is that it might be confusing to select these options, and then for nothing to happen - clicking away from the dialog is an opaque requirement. As such, maybe a 'confirm' or 'update' button inside the dropdown would be helpful, to make this explicit?