Aug 7 2018
Since my previous comment I've discovered a workaround to the workaround. The goal is: load arbitrary bookmarked filter X; disable sub-filter Y; re-enable sub-filter Y with minimum mental load (i.e. re-enabling sub-filter Y should be made by muscle memory over a visible item, without making a choice on an initially hidden widget.)
Aug 3 2018
Jul 17 2018
My user at all Wikipedia projects is [[User:Diego Moya]].
Mar 9 2018
Apr 11 2017
Apr 6 2017
Apr 4 2017
A very typical wording for the save button would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.
A very typical wording would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.
Mar 11 2017
Feb 16 2017
P.S. It looks like me and the other users posting at this thread are not the only one who prefer plain text as the default for copy/paste operations; it seems to be a frequent pain point, when it's got applications specifically built to solve it.  I've never met someone asking to paste formatted text when working with code. (Syntax highlighting doesn't count, it's a different beast entirely).
Feb 15 2017
Another use case to consider for you designers of this "feature", which just happened to me:
Feb 13 2017
The simplest solution is to create a button for "paste formatted code". In the 2017 wikitext editor, other "magic" features for creating wikicode automatically (tables, sourcing and templates) are enabled by buttons in the toolbar. It would be inconsistent for the standard "copy/paste" tool (the one supported by the browser's standard key bindings) to behave differently, and introduce wikicode when pasting from web pages with rich format (but not when pasting from other sources, so its behavior would feel random).
Feb 8 2017
You have changed the title to "selecting text beyond the screen with mouse is glitchy", but it also happens with the keyboard, and with the text selector on mobile (I don't know if my fingers count as "the mouse") ;-)
Feb 7 2017
Several comments in the Feedback page point in that direction: 1 2 3 4 5 6 - plus Samwalton9's and Dvorapa's comments above. This matches my own experience as well; the whole point of using a wikicode editor is having direct and full control over the text, and any magic from the editor breaks that expectation.
Feb 6 2017
I can confirm Pearli's report of the editing experience at the Overwatch article. Repeatedly pressing shift + up will perform weird screen flashes, and eventually revert the scrollbar to the starting position.
Jan 29 2017
Jan 24 2017
Jan 23 2017
Jan 20 2017
Edit: I've noted that this only happens when I copy the text from the HTML page, not when I copy it from a plain text editor, so this is likely related to the text formatting.
Jan 19 2017
I've opened a related feature request to improve the usability of the Preview panel, matching that of the classic Wikitext editor.
Jun 12 2015
This way, we power users could still set particular preferences for special topics, but quickly change the global settings for everything else (all the topics that we have not tweaked explicitly).
As for Capt_Swing concern that per-topic settings override the Notifications panel, that could be solved by adding a new entry at the "Notification volume", and making this the initial value for new topics:
I like the overall design. I wanted to provide a little feedback of a few problems I've found while testing the prototype, before reading the description of how it's supposed to work.
Apr 24 2015
There should also be some kind of "previous" and "next unread" buttons, for discoverability, maybe placing them in the current floating bar that contains the ToC.
Apr 9 2015
I've posted a bug for the Reply button, it seems it's an instance of this problem. I've added an instance with real data here.