It would be nice to know who those devs are. I've posted many patches on Gerrit since April, some still awaiting review (including some which were posted in April).

Ah, but in fact, T65665 has been tagged (on the Tracking-Neverending workboard) as a task that should be a workboard column. Can that be any more confusing?

I still think we need a broader solution. This is the fourth tracking task on WikiEditor (2010), and the other three correspond to specific components of the editor. You can't just do a multi-tag search for those.

Well, I'd say that less than half of the subtasks I added are tagged Design, so either this is broader by design (no pun intended) and should be kept (or preferably converted into a workboard column, which I lack permissions for), or the other tasks need to be re-tagged.

What do we want the key press behavior to be? I see a few options:

In that case, there should be a task to fix it in core (whether it's re-scoping this task or creating a subtask).

CodeMirror gives you two search/replace buttons. The one from WikiEditor (which is next to the Preview button) clearly has the internal type button and not toggle (line 80 of modules/jquery.wikiEditor.dialogs.config.js).

Search/replace is not implemented as a toggle button in WikiEditor, just a regular button. (Whether it should be a toggle can be a separate task.)

You didn't mark the actual task as completed. You just tagged it as completed for RoadToWiki. I don't know what they expect from you, so I'll let an actual developer or mentor answer that.

The Syntax button is part of CodeMirror, not WikiEditor. I will post a patch for the Preview button shortly, but I've found that the core OOUI stylesheet also overlays its own translucent background color on toggle buttons, so it will still appear off even with the fix.

I should have been less specific. Are there buttons other than the live preview button which need to be fixed in WikiEditor?

Noting that WikiEditor doesn't use Codex, can you be specific on which buttons need to be fixed?

There are still undocumented functions and the docs have not yet been published to the web. This task is not complete.

This issue specifically occurs when opening the pop-up which asks the user whether to enter a link on the same wiki as an internal or external link. In other words, when a second modal dialog opens on top of the current dialog. Since the second dialog is never actually deleted from the DOM when it's closed, its z-index is used as the new base when the main dialog (in this case, the link insertion dialog) is closed, which causes it to keep increasing.

Chrome 148.0.7778.178 has converged with the Firefox (151.0.2) behavior of (a) warning on leaving the page, (b) keeping the modifications when returning to the page, and (c) still not having working undo/redo when returning to the page. (I'm using Linux, so I did not have ready IE or Edge access.)

Removed Codex replacement as a subtask, as it also auto-focuses the first element.

I would like to try tackling this, but I need to know if this bug still exists. It appears RefToolbar (or at least the enwp version) catches the TypeError now, but I don't know if it pops up elsewhere.

33bdc34577dc573650f009143a2f834df042ec55 added a new PHPUnit test in the process of fixing T424010.

Add a jQuery event handler (not a hook) for the wikiEditor-toolbar-buildSection-characters event. It will fire with the section's configuration data as its argument, which you can use to inject the necessary characters.

What exactly is this asking for? Additional pages (which can already be done using addToToolbar)? Replacing the whole section with the wiki's cheat sheet? The task description is vague.

Since the OP requested a gadget-like syntax, I have re-profiled this task with that in mind. This should hopefully differentiate it enough from T25624.

In T426996#11946802, @jhsoby wrote:

@happy5214 I added a couple points in the description to make it clearer how to reproduce this. The issue is that when syntax highlighting is on, it for some reason uses the messages codemirror-keymap-bold/codemirror-keymap-italic (which aren't yet translated into Czech), whereas WikiEditor without syntax highlighting uses the messages wikieditor-toolbar-tool-bold-example/wikieditor-toolbar-tool-italic-example, which are translated into Czech.

Based on the edited description and my tests, this only occurs when the syntax highlighting (i.e. CodeMirror) is enabled, so I'll redirect this task to that project.

In T426996#11946229, @Bhsd wrote:

It is already localizable, but someone needs to translate the messages into Czech on TranslateWiki.

I should also add that (to my knowledge) this is not about the BÉPO layout driver officially supported by Microsoft (which was added in Windows 11), but rather a third-party driver released by the organization promoting the layout. I do not believe Microsoft's layout supports "alternative" keyboard shortcut overrides.

https://unix.stackexchange.com/questions/214273/multiple-keyboard-layouts-and-shortcuts says Firefox (and other GTK applications) use the BÉPO value of the key rather than the physical value, though that doesn't seem to match the OP's experience on Windows with other text boxes. Have you tried doing a BÉPO-style Ctrl+V in the edit area?

In T426462#11927036, @Ivan-r wrote:

This can be done by changing content model to plain text

I actually feel the optimal behavior is a hybrid of the two: