Already supported.

Related/duplicate: T376564

Can't reproduce now. May have been fixed in an intervening patch in Scribunto. Please reopen if this is still an issue.

T354890 is one use case where templatelink rows to special pages would be legitimate, as special page content would actually be shown on a page, albeit indirectly. (Though then there also needs to be a way to trigger LinksUpdate on a special page.)

You can file a separate task for that – those are more controversial as they conflict with browser shortcuts for navigating between tabs on Windows. This ticket is for "basic formatting and action keyboard shortcut commands". (Not to mention being harder to implement as the VE behaviour is to use Control key instead of Cmd on Mac.)

In T189901#9475400, @Bhsd wrote:

This will automatically be fixed with CodeMirror 6 upgrade.

Suggested blurb: The 2010 wikitext editor now supports common keyboard shortcuts such Ctrl-B for bold and Ctrl-I for italics. (?) Full list of shortcuts: mw:Help:Extension:WikiEditor#Keyboard_shortcuts.

Even if users aren't going to particularly dislike it being a separate namespace, I question the need for it to be separate. ContentHandler is the recommended way to segregate pages these days. It wasn't fully the case in 2013 when the extension was written (the same year that MediaWiki core added native support for content models).

Some validation is already there - the chip doesn't get created unless you enter a valid group and press enter. If you navigate to another form element with an invalid group in the field, it becomes red.

In T335201#9858546, @Ladsgroup wrote:

In T335201#9857572, @Xaosflux wrote:

To be very clear, testwiki still collects and makes available the private data to the poll's election admins, so who can use this is still sensitve.

Seconding this, we had an incident exactly because of this a couple years ago.

Thanks @dcausse for detailed explanation.

Closing this now. Thanks everyone for the feedback and bug reports. Please file any remaining issues as separate tickets.

In T368166#10255645, @TheDJ wrote:

I think Idc554269ee52a05660fa41f065a2b3c73e2e1b9b broke the extension [in debug mode], because either it doesn't define the remoteExtPath or, it redefined the localbasepath as the remoteExtPath.

I get the same error as well when $wgSecurePollUseNamespace is true. Using MariaDb in local.

In T378287#10271575, @Novem_Linguae wrote:

At the moment, it sounds like enwiki wants to put all the SecurePoll perms in the electionadmin user group.

I suggest stalling this until T377531 is resolved.

In T356442#9851472, @Novem_Linguae wrote:

None of this looks like sensitive data, so I think I am misunderstanding something. What additional steps do I need to do to see the concern raised in this ticket?

In T301180#10258333, @Stang wrote:

I would like to know if we can test the setup of election on testwiki. I asked this several months ago and the barrier are NDA issues and some extra upstream work. I'm curious if it's ready at this time.

SecurePoll is peculiar among MediaWiki extensions in that some actions actually check if the user is in the electionadmin group, as opposed to checking for rights. This definitely seems like something to avoid.

It's a universal feature of code editors. I don't think a toggle button is necessary here. Adding user preferences for everything is not sustainable. Besides, there's no easily recognisable icon for autocompletion.

To be fair, I think it's reasonable to expect that .js pages are supposed to run in the MediaWiki environment, unlike the code blocks on wikitext pages that could for reference purposes.

@Nardog Is this still blocked on making the interface translatable? I think i18n is a good-to-have but not required for the first pass of this feature. All code pages have the page content language of English.

In T369439#10239558, @Novem_Linguae wrote:

Is https://refill.toolforge.org/ running the PHP image? If so maybe just move all the current files to a subdirectory, then add an index.php with the following code?

<?php

header('Location: https://refill.toolforge.org/ng');

To turn on syntax highlighting, click the highlighter icon in the toolbar.

In T40932#10221678, @SD0001 wrote:

In https://gerrit.wikimedia.org/r/1078975, @Jdforrester-WMF wrote:

Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)

I see ext.pygments.view is not being loaded in Parsoid DOM, even though we are adding the module to ParserOutput via the parser hook. I guess something else needs to be done for Parsoid compatibility?

Workaround is to turn on syntax highlighting. The shortcuts don't work with CodeMirror enabled.

@rook I still can't get kubectl to connect to the cluster with any of the config files in /opt. Which one is the current config that's supposed to be used?

In https://gerrit.wikimedia.org/r/1078975, @Jdforrester-WMF wrote:

Note that this feature isn't Parsoid-DOM compatible (compare https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=0 and https://hu.wikipedia.org/wiki/Sablon:K%C3%B6nyvsorozat_infobox?useparsoid=1)

Sure, done.

The only benefit with supporting templates is that using them in interface messages won't weirdly cause a category to show up at the bottom in unexpected contexts like special pages. It also doesn't need a row in categorylinks, sure, but I suspect communities would toss in a category anyway for tracking.

I have emailed the details requested in T374993#10215543 to @KFrancis.

In T62928#10214676, @stjn wrote:

AFAIK he new provided patch and the suggestion would make it impossible to use this feature for people on non-Latin keyboards (since e.key for K doesn’t match to K or k on a Russian keyboard, it would match to Л or л), therefore reducing the usability of this tremendously. I understand the concern with Dvorak keyboards, but maybe there are better ways to resolve this than this.

As of today, the docs at https://www.mediawiki.org/wiki/Extension:WikiEditor/Toolbar_customization seem to be fairly comprehensive.

Just pressing Enter in the edit summary field saves the page in the 2010 editor.

Can we support modifier + click on the [[wikilink]] syntax as well?

Category:Living_people contains as many as 1.1 million pages, so presumably the way to do this would be to allow setting the max number of pages returned. For every 50 (?) pages returned, increment the expensive function counter by 1.

Suggested text: <syntaxhighlight> code blocks will now offer a "Copy" button if copy=1 attribute is set on the tag.

In T368166#10142874, @Quiddity wrote:

For Tech News, timing-wise, is this ready for inclusion in Monday's edition (or should it wait another week, for the latest patch to be merged)?

Content-wise: What should the entry say?
My best guess (please clarify or confirm) is something like:

Readers can now click on wikilinks and external links that are written within syntaxhighlight tags. Thanks to SD0001 for these improvements. [1]

In T368166#10146824, @Msz2001 wrote:

This feature fails for jsdoc for objects as well:

@param {{ key1: valueType1, key2: valueType2 }} paramName

is linked to Template:key1: valueType1, key2: valueType2 even though it's unwanted. This is a valid template name but it can be checked for jsdoc keywords presence (in fact, I did it in my script for links in source code).

In T368166#10146333, @Od1n wrote:

There is a link on the Projet:JavaScript/Script part, that points to Modèle:Projet:JavaScript/Script, but it should be to Projet:JavaScript/Script.

To demo the use case mentioned in the ticket - which is enabling templatization of SVGs, we can use some SVG-writing lua library. https://gitlab.com/hansonry/luasvgwriter is the one I found in 5 minutes of searching.

In T368166#10136195, @Ioaxxere wrote:

Using JavaScript for this in MediaWiki core makes no sense

Is there a benefit to doing this? According to T178520, disk usage was 112 GB in 2017. I seem to recall it being around 195G last time I checked. Although now, it appears to have mysteriously shrunk to 100G:

In T92795#10100842, @Ciencia_Al_Poder wrote:

However, editing a page is not that hard. If you look at maintenance/edit.php, it's pretty simple:

In T92795#9961318, @Ciencia_Al_Poder wrote:

Change #1043060 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/core@master] Don't check for editcontentmodel right while creating pages

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

I think SpecialPages creating pages should decide *themselves* if the editcontentmodel right should be honored, not MediaWiki core.

In T85372#8815895, @Galobtter wrote:

If T50175 is doable, it's probably the best way to do this. That would enable other functionality and enable wikis to properly customize when they load editnotices.