I work for or provide services to the Wikimedia Foundation, and this is the account I try to use for edits or statements I make in that role. However, the Foundation does not vet all my activity, so edits, statements, or other contributions made by this account may not reflect the views of the Foundation. For my personal account, see @Deskbanana.
Tue, Jun 19
Including shortcut keys in buttons like that is a pattern I'd definitely like to avoid. I'm not sure what a good solution is here.
Part of the description here is also a more generalised version of T95695: When I add "last1" to a citation template, automatically add the related "first1" parameter.
This seems like a duplicate of T192385: Support for conditional parameters in TemplateData, and others. Such tasks are technically feasible, but there is currently no active development taking place on TemplateData.
I can't reproduce these problems. Perhaps the users in question have some script or extension that is interfering?
I'm not calling this "Unbreak Now!" any more because it's an incredibly transient issue, but considering @Trizek-WMF can now also transiently reproduce this, it needs looking in to again.
Mon, Jun 18
I don't see this in Chrome on macOS. Hm...
As noted, cannot be completed until RemexHtml is enabled.
Thu, Jun 14
I want to make sure I'm understanding this fully first.
Bad. You can see this in action on https://fr.wikipedia.org/wiki/Fabrice_Balanche#Ouvrages: you can delete and add characters, but you don't get the normal dialogue to edit the link.
I can't reproduce your problem. When editing the San Francisco Chronicle article on the Hebrew Wikipedia (https://he.wikipedia.org/wiki/סן_פרנסיסקו_כרוניקל) the references, which are generated by a template, are still visible; see the bottom right of the screenshot below.
This won't happen until the English Wikipedia changes its mind about it happening. When that happens, feel free to reopen.
Wed, Jun 13
By design the API—and by extension the visual editor—won't let you save an edit if you're blocked; if the user tries to do so, then the API returns an error, and the visual editor passes on to the user the value of the key info from the response, which in the case of a block is "You have been blocked from editing". If the API gives a different or more specific error message, visual editor will use that instead.
Removing browser specificity from task title, as it turns out to have been unrelated to this issue.
(Perhaps I should only have put the Collaboration-Team-Triage project on? Sorry if I did it wrong.)
That issue with the content not loading looks like an issue with the maps service, not the visual editor. The maps test infrastructure is notably unreliable, so I highly doubt that the failure means anything, but I'll add the relevant maps tags just in case. @Catrope, @Mooeypoo, @SBisson may want to take a look at this to verify that it is indeed nothing to be concerned about.
Tue, Jun 12
Please put things in the VisualEditor (Current work) project when you're working on them.
In future, please mention the device and operating system that you're testing on. I tested this on my desktop computer because you didn't specify, and couldn't reproduce it at first, which wastes time.
I am unconvinced that these messages when switching are useful, honestly. Fixing this isn't not a priority issue.
Citoid is not set up on your wiki, which is why it does not work. There is work you will need to do to get it set up. You may find the instructions on how to enable Citoid on your wiki helpful. @Mvolz may also be able to help you, time permitting.
I don't think it's good to block the user from proceeding using a modal dialogue in order to let them continue editing. Blocking users from proceeding using modals should be used only when strictly necessary.
This is what already happens. If you try to merge two cells, and either one of them is empty, then it puts the content of the nonempty cell into the new, merged cell. @Whatamidoing-WMF thinks her test case may have been different somehow.
Mon, Jun 11
This issue is fixed. Any requests about changing the behaviour of MobileFrontend's handling of section editing should go in a different task.
Wed, Jun 6
Tue, Jun 5
This seems like an edge case.
Eugh. Another one of these "junk inserted when the user pastes" ones.