Overleg Wikipedia:Overleghulpmiddelen/Archief 2

Translatewiki.net

Gebruiker:Amire80, could you please remind me when the translations at TranslateWiki.net usually appear on wiki? I thought it was once a week. Whatamidoing (WMF) (overleg) 8 apr 2020 22:28 (CEST)

I thought it usually comes along with the train, and the train usually comes here on Thursday. Mbch331 (overleg) 8 apr 2020 23:00 (CEST)

It used to be every day, but now it's with the train. So if the translation is done before Tuesday, there's a good chance it will be on the wiki before the end of the week. --Amir E. Aharoni (overleg) 8 apr 2020 23:09 (CEST)

Thanks, Amir. We should see this tomorrow, then. It'll be nice to have that settled.

By the way, while we're talking about the Reply button, the team is going to look at changing colors/style/whatever, to make it a little easier to spot. In Arabic and Chinese (and probably other languages), "Reply" is only two letters long, and therefore very easy to miss. If you all have ideas or preferences, please feel free to share them. Whatamidoing (WMF) (overleg) 9 apr 2020 01:49 (CEST)

The change is visibile now Ad Huikeshoven (overleg) 12 apr 2020 09:15 (CEST)

Interface/styling

(In reply to " If you all have ideas or preferences, please feel free to share them.")

Current situation: plain links

Example: stylized with css

@Whatamidoing (WMF): This reply tool looks really promising! My idea of styling would be a light-colored (to make it less prominently visual) 'button', with a reply icon in front of the text (to make it easily recognizable and less easy to miss). The length of the button text would be less of an issue this way. The example shown here uses these css rules:

span.dt-init-replylink-buttons {
  margin-left: 0.5em;
  font-size: 70%;
}
span.dt-init-replylink-buttons > a {
  color: #6699ff;
  background-color: #ddeeff;
  border: 1px solid #ddeeff;
  border-radius: 8px;
  padding: 0px 4px 1px;
}
a.dt-init-replylink-reply::before {
  content: "";
  padding: 0 8px;
  margin: 0 -2px 0 -4px;
  background-color: #6699ff;
  mask: no-repeat center/80% url("//upload.wikimedia.org/wikipedia/commons/9/95/Ic_reply_48px.svg");
}

With kind regards — Mar(c). ^[O] 30 apr 2020 15:08 (CEST)

Awesome work – thank you!

@Ad Huikeshoven: What a great and helpful idea to create a single place to gather feedback. This will make it possible for us to respond more quickly to the feedback you all share. Thank you for taking the initiative to make this happen! PPelberg (WMF) (overleg) 9 apr 2020 00:40 (CEST)

Bericht zonder afzender

Bericht zonder afzender

Bericht zonder afzender met {{afz}}

Bericht zonder afzender – De voorgaande bijdrage werd geplaatst door Ad Huikeshoven (overleg · bijdragen)

Bericht zonder afzender met {{afz}} en tijdstempel

Bericht zonder afzender – De voorgaande bijdrage werd geplaatst door Ad Huikeshoven (overleg · bijdragen) 14 apr 2020 15:50 (CEST)

Bericht zonder afzender met {{afz}} en tijdstempel in sjabloon

Bericht zonder afzender – De voorgaande bijdrage werd geplaatst door Ad Huikeshoven (overleg · bijdragen) 14 apr 2020 15:50 (CEST)

Nog meer tests

Bericht met link naar kladblok ipv gebruikerspagina. Encycloon (overleg) 17 apr 2020 23:32 (CEST)

Bericht met link naar kladblok ipv overlegpagina. Encycloon (overleg) 17 apr 2020 23:32 (CEST)

Bericht met op beide plaatsen een link naar kladblok. Encycloon (overleg) 17 apr 2020 23:32 (CEST)

There is no link to your user page, talk page, or Special:Contributions in the last one, so there's no Reply button there. Whatamidoing (WMF) (overleg) 18 apr 2020 03:59 (CEST)

I see, so it doesn't work when someone uses redirects on both places (example). Encycloon (overleg) 18 apr 2020 12:31 (CEST)

Correct. Also, the MediaWiki software will consider that an invalid custom signature when the mw:New requirements for user signatures are finished (maybe six months from now?). Whatamidoing (WMF) (overleg) 20 apr 2020 20:14 (CEST)

RecentChanges

I have asked the product manager about getting a link in Speciaal:RecenteWijzigingen to a suitable page (e.g., this one, or maybe the help page that still needs to be written at MediaWiki.org). That way, if someone sees a problem with an edit, they'll be able to figure out what's going on. I think that adding a link to MediaWiki:Tag-discussiontools-reply (requires an interface admin, so pinging @Bdijkstra, Mbch331, Multichill:) would work, but there are several ways of going about it, and I'm not sure which one is best. Whatamidoing (WMF) (overleg) 18 apr 2020 04:03 (CEST)

Proposed changes

Here are some proposed changes. You can read more at mw:Talk pages project/replying#Version 2.0.

• 
  Overview
• 
  Visual editing
• 
  Wikitext editing

Please tell me what you like, what you don't like, and what you want to see first (or last). You can also post your comments at mw:Topic:Vju7lfcav875rt8r. Whatamidoing (WMF) (overleg) 4 mei 2020 19:32 (CEST)

What I like is the current process. We collect feedback, you respond. Developers are busy resolving known issues. I like the above proposals.

To but them to words. Currently the reply tool provides an input box to respond in source mode. The proposals add the option to respond in ´Visual´ mode, probably much like the current Visual Editor. That is okay with me. So far, none of my fellow community members on the Dutch Wikpedia has objected. So, please do proceed in iterative experimenting mode. As I see, while typing, there is already a preview (Voorvertoning), while typing in source mode.

Looking forward, one future move would be to switch from opt-in to opt-out? What is blocking such a switch now?

The tool is intended for junior editors. Junior editors will most likely just type plain text in the input box in source mode. User @Mar(c): is a senior editor. He tried to enter HTML code into the input box. Gödel proofed in the 1930's that no matter how advanced the reply tool, you can always find some source code that will break things or produce unexpected or unwanted output. Going that way would be catering the needs of senior editors, not of junior editors. A senior editor can edit the talk page without the reply tool. The syntax highlight bug is valid, but I won't give it a high priority. How likely will a junior editor input any source code different from plain text, and if they do, how likely would they enter anything that would break anything? Wouldn't the preview prevent entering any breaking source code? Ad Huikeshoven (overleg) 8 mei 2020 14:32 (CEST)

I think that the Editing team wants these upcoming changes to be used here before moving to opt-out. (If you all want it sooner, then let me know, but they're assuming – perhaps wrongly – that you don't want new folks using it while they're adding new/potentially buggy features.)

I want that Gödel citation. :-) Strictly speaking, the preview won't prevent broken code, but it will hopefully alert editors to the fact that something's wrong with what they've typed. That assumes that I'm paying attention to the preview. At least for myself, there are diffs proving that I don't always. Whatamidoing (WMF) (overleg) 8 mei 2020 20:17 (CEST)

The "Watch this page" feature has been added to the Reply tool already. I don't like it (IMO it's too big), but I might get used to it. What do you think? Whatamidoing (WMF) (overleg) 8 mei 2020 20:18 (CEST)

I also see 'Reactie op Whatamidoing (WMF)' prepopulated in the inputbox. I don't use watchpages. That makes me ignoring messages like 'Deze pagina volgen'/'Watch this page'. Other people might like it. Ad Huikeshoven (overleg) 8 mei 2020 20:28 (CEST)

I don't have any issues with the size of the Deze pagina volgen part. Mbch331 (overleg) 8 mei 2020 21:17 (CEST)

For the Gödel citation see en:Gödel's incompleteness theorems. Ad Huikeshoven (overleg) 8 mei 2020 20:50 (CEST)

The proposals look OK, a visual box to reply instead of the source function as it is now is OK, although I wonder if it is needed. Primarily it is a tool for discussion where the visual appearance is secondary. I don't object, but it should be easy for registered users to make a default choice. The wikicode that is relevant for discussions is links, internal and external, and simple templates like ping, and that should work in source mode, and be possible with visual mode.

I don't agree with Ad that this is mainly for junior editors, I consider myself senior, but will use this most of the time. If all works as it should I will probably only not use it with discussions about format or something where you want to give examples and that is not easy in a reply box. But I think those remains exceptions. On the other hand, his remark is valid, only senior editors would run into a bug like mentioned and are then also well capable to fix and go to normal source mode. Akoopal _overleg. 10 mei 2020 19:50 (CEST)

OP https://nl.wikipedia.beta.wmflabs.org/wiki/Overleg:Hoofdpagina?dtvisual=1 kun je de visuele modus van de reageerfunctie reeds testen. Dat werkt door daar dus ?dtvisual=1 aan de url toe te voegen. (Nu merk ik de link Share feedback about this feature op die verschijnt onder de voorvertoning.) Ad Huikeshoven (overleg) 11 mei 2020 09:09 (CEST)

I've been using it (as a volunteer) at enwiki on a couple of large pages, and I think I'll be using it more. There is a bit of "re-training my fingers" to do (sometimes I click the [Edit source] button without thinking), but I'm finding it useful.

Whenever the deployment train gets here (hopefully any minute now?), then you can try out the visual mode on this page by clicking https://nl.wikipedia.org/wiki/Overleg_Wikipedia:Discussietools?dtvisual=1 For me, the big advantage will be searching for a username (to ping someone). I have asked the devs to put the keyboard shortcuts into the wikitext mode, but that would require switching it (not visibly, but behind the scenes) to the 2017WTE, and I don't know whether they will agree. (My guess is "not soon", or at least not until people other than me ask for it.) Whatamidoing (WMF) (overleg) 14 mei 2020 23:02 (CEST)

The deployment train derailed. https://versions.toolforge.org has the status. We need Group 2 to match the others (or for Editing's devs to bypass the rest of the train; I don't know if they'll do that). Whatamidoing (WMF) (overleg) 18 mei 2020 21:14 (CEST)

Username completion in source mode.

First of all, I think the reply tool is a great addition/improvement to discussion pages – and like Akoopal said: for both junior and senior editors. I really love being able to type a reply without the need of loading the edit page (and having to search in the source where to put the reply, especially in longer discussions). Having the Visual and Source modes as tabs is nice; it makes switching between the two very easy. I prefer source mode, but with the tabs I might switch back and forth between the modes more often. The live preview is also nice, although it might get distracting at times. Some questions/remarks:

1. About Ad Huikeshoven's remark about catering the needs of senior editors: when I posted the button styling proposal (my first experience with the reply tool), I guess I was subconsciously assuming that any code I use (have been using, might use) in discussions, would (eventually) be supported by the reply tool. I still think that the reply tool is great for posting short replies as well as more complex responses containing 'advanced' wiki-markup. Is that what the developers have in mind? Or: to what extend will advanced markup be supported?
2. It looks like edit conflicts are handled well. Are there any plans for notifying the user about new edits that are made since the page loaded? Something between a simple notification when clicking the (save-the-)reply button, and an advanced live updating of "number of edits/new comments" (propably a colored number, near the reply button, visually similar to the 'your alerts' and 'your notices' ones) with some possibility to load those new comments without reloading the whole page. Those are two extremes I was thinking of, basically to have at least something for a quick and easy check for 'conflicting' additions to the discussion (when using the regular edit page, I can check that with 'Show changes').
3. When replying to a comment in an ordered/numbered list (#) or unordered/bullet list (*), the reply is added as an unordered list (#* or **, resp.), instead of an indentation (#: or *:) like when replying to an indented comment. Is this intentional? I expect indentation to be the preferred choice in most if not all cases (like replying to a vote in an ordered list of votes, or to an issue/remark in an unordered list like here). By the way: when replying to an ordered list item, the preview shows an ordered list, although it becomes a unordered one after saving.
4. I was thinking of a button/functionality "switch to regular edit page". When running into a situation the reply tool can't handle (or: can't perform to my wishes) – for example with 'too' advanced wiki-markup or when I'd like to change the position or indentation type/level (in case of 'conflicting' edits, or just for clarity) – it would be nice to be able to switch to the regular edit page, with the draft of the reply added in the source. Maybe I'm thinking 'too advanced' here again, but hey, it's just like saving the reply and clicking the 'edit section' button, only skipping the 'save' part.
5. I support the request for being able to edit the edit summary. According to phab:T249391 this has low priority (task will be revisited once work on v2.0 has been completed). That's fine, but I hope in the meantime the edit summary can be limited to just the autocomment part (i.e. /* section */). So without the text "Reactie", which might not always be the case (semi-related comments, or additions to own previous comments), plus it looks like user-added text which it actually isn't. We already have the tag Reply/Reageerfunctie, so i.m.o. there's no need to add anything to the summary.
6. I support Whatamidoing's request for keyboard shortcuts and username completion in source mode. I don't know why it would require any switching – it wasn't that hard to add username completion, see the captured video. ;-) Not as advanced as the one in the visual mode (it doesn't filter on additionally typed characters, and it only shows names of users who already posted on the page), more like a proof of concept. With two ways of pinging someone: '@' and selecting a name inserts the ping template (which shows as "@<name>:"), '!' and selecting a name inserts a regular link. I didn't look into keyboard shortcuts for styling yet.

With kind regards — Mar(c). ^[O] 25 mei 2020 03:05 (CEST)

Akoopal, Mar(c), Mbch331 de visuele modus kan nu ook op deze wiki uitgeprobeerd worden door ?dtvisual=1 aan de URL toe te voegen, zoals bijvoorbeeld https://nl.wikipedia.org/wiki/Overleg_Wikipedia:Discussietools?dtvisual=1 Ad Huikeshoven (overleg) 26 mei 2020 22:43 (CEST)

Mar(c), I'm going to number my notes:

1. Maybe – perhaps – someday, it will support almost everything. Right now, tables and some other uncommon (for talk pages) multi-line syntax will break the layout of the page. The main theme is whether the wikitext code has to be the first character on a line or on a single line. So, for example, Matma Rex tells me that you can add a gallery with one picture (with the code on a single line) but not a gallery with multiple pictures (which requires multiple lines of wikitext). Most of those could be solved by changing/extending wikitext. It will probably never support #REDIRECT syntax.
2. Edit conflicts are almost always auto-resolved. (They can't be resolved if the specific comment you were replying to is removed while you type your reply.) They are not detected until after you click the blue 'Reply' button. The team has talked about a note/warning afterwards. Maybe "There have been other changes to this page since you started typing your reply"?
3. Every wiki has a different idea about the ideal list formatting. (And that's a bug.)
4. I think that a "switch to regular editing" button might be useful. It's been mentioned before, but I don't know if there's a Phab task for it yet.
5. I'm not convinced that edit summaries are normally useful on talk pages. They almost always contain no information. My own at enwiki, before I stopped using them, tended to be "r" or "c" (for "reply" and "comment"). They feel pointless to me.
6. Obviously, I agree with you agreeing with me. ;-)

Can you try out the visual system here? Once we're convinced that it doesn't cause problems, we can ask the team to put it in the (same) Beta Feature.

Whatamidoing (WMF) (overleg) 27 mei 2020 18:39 (CEST)

Please also see https://www.mediawiki.org/wiki/Talk_pages_project/replying/prototype_testing#Reply_tool_version_2.0 The Editing team's designer is hoping that someone from the Dutch Wikipedia will tell her how it's working. Whatamidoing (WMF) (overleg) 27 mei 2020 18:43 (CEST)

Whatamidoing (WMF) Done: https://www.mediawiki.org/w/index.php?title=Topic:Vn76v83ev5b6bk7w&topic_postId=vn76v83ev998jo64&topic_revId=vn76v83ev998jo64&action=single-view (I have seen more feedback on that page, using the prepopulated question list, however, I got mine nicely formatted. (I switched to visual, back to source, removed the nowiki tags, and switched back to visual). Ad Huikeshoven (overleg) 28 mei 2020 09:44 (CEST)

Whatamidoing (WMF), thanks for the answers!

1. Yeah, I understand it's mainly the multiline syntax, and I guess block elements in general, being the pains in the ass for the Discussion Tools project (when advanced syntax is added in a reply, as well as when it's already somewhere in the discussion thread). It's nice to hear that the aim is to support most of the more advanced syntax (no, I wouldn't expect a "#REDIRECT [[Never Gonna Give You Up]]" to really work either, as in: redirecting this whole talk page ;-). Some additional questions: (a) does support for advanced syntax/functionality have some priority at this point of development, and (b) are tests and reports in that area wanted and/or useful at all, at this point? For example mine about syntaxhighlight, or some testing with galleries in comments (both visual and source mode, as well as switching between them). Note the discrepancy between the position of the reply tool ui on the page, and where the reply ends up after saving.
2. To be clear, my main point is that the reply tool lacks any feedback about new changes before the comment is actually published. Such a note/warning after clicking the blue 'Reply' button (but before actually publishing) would indeed be a nice starting point. We already have the 'comment-disappeared' error message (the publishing process is cancelled at that point); I can imagine a similar message, postponing the publishing process, saying "There have been other changes [..]" (your text) plus something like "Click 'Reply' again to post your comment, or you can reload the page first".
   Ultimately, something like a button for updating/injection of new comments would be great, comparable to a news site's live blog e.g. nos.nl (button "X nieuwe berichten tonen" at the top) or cnn.com (floating button "↑ X New Updates"). I'm aware that a Wiki talk page is a bit more complicated than a linear thread of news items, but – seeing that publishing a comment with the reply tool already uses some live update of the page (without reloading it), with the newly posted comment having the fancy fading background color – a button to update the page with new changes while the reply tool widget stays open, seems not to be a too far stretch.
3. The reply tool steers where and on which indentation level a comment is placed when a user replies to a specific comment/person, so comments will (more often than before) end up on the same indentation level. With longer comments, bullets add to the confusion about where someone's comment ends and another one's starts, especially when the comments consist of multiple paragraphs. See for example the stack of bullets under "Test nummers".
5. I'm a bit surprized here, because the wish to be able to edit the edit summary has been expressed a lot. On this project page alone (within the first three days of feedback): #1 (hinting at the hu-wiki feedback about it), #2 (prefering a visible textbox over a popup window), #3 (even as a deal-breaker), and #4 (the added value of a brief but powerful summary on busy talk pages). It might not be used a lot on talk pages, and my most used one is probably 're', but that doesn't mean it's useless (in case of multiple participants I'd like to add the name of the one I'm replying to; "re Whatamidoing" would have been the one for this reply). I.m.o. any discouragement of (or steering to not getting accustomed to) using the edit summary wouldn't be a good idea, since it is an important part of wiki editing. I hope you expressed 'just' your opinion and not a development decision; in other words that this feature request isn't 'under consideration' but 'planned to be implemented'?
   The other point: since (hopefully: as long as) we're not able to change the edit summary, I'd like to see any default summary like "Reactie" or "Reply" (which looks like it's added by the user) removed from the edit summary. We have the tags so it's superfluous, and i.m.o. it doesn't look very pro. I know I can edit it (or ask here on nl-wiki to override it locally), but I'd rather see the development team take this into consideration.

About 4 and 6: nice! (Also skipping 4 to check if 'advanced syntax' #<li value=".."> works. ;-) B.t.w. I'll take some of these points to the "design feedback" topic that you linked; I see 5, and to a lesser extent 3, being discussed there also.

I'm not fond of visual editing (in general), but to use some of its features and for testing (also out of curiosity about what the editor automagically changes in my wikitext) I'm switching between the two modes more often these days.

With kind regards — Mar(c). ^[O] 28 mei 2020 21:09 (CEST)

1. They're working on an RFC for multi-line comments (see phab:T230683).
2. I don't recall anyone talking about interrupting the publishing process to alert you to an edit conflict. That idea is now at phab:T254116.
3. I think this would be solved by the multi-line comment thing.
5. Yes, people say that they want it, but the requests "feel funny". I don't know quite how to explain it. You've heard, I assume, of the software customer who says, "It's just what I asked for, but not what I want"? It feels like that, somehow. When I look in RecentChanges, almost all of the edit summaries for replies look useless. If a descriptive edit summary is so important, then why don't people use them? I heard the same thing with Flow's design: I need an edit summary! Except after you use it for a little while, you stop even wondering where to put it. It just doesn't turn out to be important. And hopefully you don't have this problem here, but at enwiki (my home wiki), there have been many hundreds of complaints about people using the edit summary to make inappropriate statements – angry, hurtful, and, of course, 100% uneditable. I think that instead of adding an edit summary box, that it might be more helpful to copy the start of the message into the edit summary, or to implement phab:T54859's magic edit summaries.
   I've filed your idea of a 'blank' edit summary at phab:T254117. Feel free to edit/expand that brief description.
Whatamidoing (WMF) (overleg) 1 jun 2020 05:14 (CEST)

Ah, thanks for creating the phabricator tasks! I'll think about adding some short explanations here and there. New syntax for multiline list items sounds interesting, and would indeed solve some issues.

About edit summaries:

• Even when "almost all of the edit summaries for replies look useless" (which isn't my impression; might be different between enwiki and nlwiki?), it's still good practice to provide a summary for every edit. I didn't say a descriptive edit summary for a talk contribution is extremely important (indisputably there are much more important uses) —and that is why people tend to not using them— I meant to point out that edit summaries in general are an important part of wiki editing. "Most" people not using them for talk contributions doesn't imply they're useless. "Most" people not using them is i.m.o. not a strong argument for even more discouragement of using them. And Flow is, by design, quite different from regular talk and wiki pages; a possible uselessness of edit summaries in Flow (I don't have enough experience with Flow to agree or disagree with that) doesn't imply uselessness with regular talk pages.
• Of course people can abuse the edit summary with inappropriate statements, but summaries can be hidden, and persistent abusers can be blocked. I consider uncivilized behaviour (and the apparent inability to deal with it adequately) as a serious problem for WP, which has nothing to do with edit summaries specifically.
• Pre-populating the edit summary with the start of the message might be the worst idea; back when the length was limited to [what was it? 250 characters?], such summaries were already way too cluttering (on history pages etc.) and annoying (it's not a summary; only after reading the same thing twice, you realize you just read the same thing twice) – it has the characteristics of being spammy. Plus it undermines the whole 'abuse' argument: any inappropriate statement in the start of the comment would also be included in the (uneditable) edit summary.
• Magic summaries sound interesting, but I don't see this of much use for the reply tool – at least not for an uncustomizable edit summary. "Reply to [name]" would be very easy to distil from a comment when user [name] is mentioned/pinged in it, but i.m.o. magic summaries (in general) should be given as options the user can add to the summary, instead of being pre-filled in.
• These alternative options for a 'default' summary (using the start of the message, or some magic summary), combined with the inability to customize the edit summary, would be a deal-breaker for me to use the reply tool at all. It's strange behaviour for any software or tool to include uneditable text in a spot that's intended to be filled in by the user when the content of the edit itself is completely user-added. As opposed to e.g. revert technology and autoreplace tools, where pre-populated edit summaries contain useful information about the particular, highly 'automated' edit ("Undid revision [revid] by [user]", "[this and that changed] using [AWB/HotCat/toolX/scriptY]"). So yeah I feel very strong about the blank edit summary, even when it's customizable.

I'm a bit baffled by (what feels like) reluctance to implement something that is otherwise a default part of wiki editing, including editing talk pages (see also feedback comment #4 I linked above, pointing out the current unbalanced situation between [people] using the reply tool and [people] not using it: not even being able to edit the edit summary, versus getting asked [by design and by good practice] to do so). So it's far from some frivolous feature, it's explicitly asked for by numerous people and with good reasons, and it's relatively quite easy to implement. If 'preventing inappropriate statements' is the main reason, then there are other routes to take – like an extra right, an extra possibility within partial blocks, or if really necessary limiting any customization of edit summaries to some magic options (probably only talk space pages?), rather than 'disabling' it for only the ones using an otherwise great tool.

Anyway, I think that's enough words spent about "what I don't like", and what I'd like to see taken out of the freezer. ;-) With kind regards — Mar(c). ^[O] 1 jun 2020 18:05 (CEST)

Hi Mar(c), as I agree with the team that edit summaries are strange for talk pages, I still don't see the usefulness from them, apart from 'it is default wiki behaviour'. I myself would only type 're' there for reply, which is not really saying anything either. And I have seen cases where the edit summary was a bit more direct, maybe not vandalism, but it steered the discussion in a wrong direction where the talk itself wouldn't have done it. Can you give examples where on a talk page the summaries are useful? I agree fully with making the summary empty apart from the section heading, but to leave it it that. To be clear, I don't oppose having an editable edit summary, but don't see the need either and I think development time is better spend on other things. I also don't see a good workflow for it. With VE it is prompted when you save, with talk pages that is annoying likely and having an extra input field also looks strange to me. What might be acceptable is an extra button 'edit summary' but I doubt if it will be used. Akoopal _overleg. 2 jun 2020 11:51 (CEST)

Examples of edit summaries I use (see also here): adding the name of the one I'm replying to (e.g. "re Akoopal"), pinging someone who isn't mentioned in the comment itself, and short summaries or remarks like "toevoeging", "aanvulling", "opmerking", "betoog", "mee eens", "idd", "bedankt!", "top!", "goed idee!", "analyse", "conclusie", "vraagje", etc. These make history/contributions/etc. pages more useful than without an edit summary (or with a standard summary).

About the workflow: a prompt would be annoying indeed. An extra input field wouldn't look strange to me but I see the concern of "too much" – a collapsed field is an easy solution (e.g. next to the buttons, sliding sideways, or expanding/collapsing vertically like the wiki editor toolbars "Advanced"/"Special characters"/"Help"), remembering the collapsed/uncollapsed state like the last used visual/source mode is remembered. Development time is neglectable compared to about any feature of the reply tool.

With kind regards — Mar(c). ^[O] 2 jun 2020 14:11 (CEST)

When I enter {{infobox auteur}}

Overleghulpmiddelen/Archief 2
Portaal    Literatuur

, in the preview in source mode, the infobox is partially outside (below) the preview box and the last line starts outside (to the left) of the previewbox. Also a newline is inserted right before the first comma. Switching to visual mode scrambles the text, which doesn't get unscrambled after switching back to source mode. Also another newline is inserted, just before }}. Ad Huikeshoven (overleg) 3 jun 2020 12:13 (CEST)

That sounds like the "multiline comment" problem. If your wikitext is on different lines, and it can't have a : in front of each line, then it will be broken. Whatamidoing (WMF) (overleg) 9 jun 2020 02:29 (CEST)

V en C of B en I?

In de visuele modus geeft het menu de opties V en C met de keyboard shortcuts B en I voor vet en cursief, of bold en italic. Ik ben gewend dat ook bij een Nederlandstalige interface de menu opties B en I zijn. (Ik geef toe, ik werk (te)veel met Office.) Wat vinden jullie, de menu opties gelocaliseerd houden zoals ze nu zijn, of niet? Ad Huikeshoven (overleg) 4 jun 2020 21:33 (CEST)

Liever zo houden: in de brontekstmodus (buiten de reageerfunctie) wordt ook V en C gebruikt. Encycloon (overleg) 4 jun 2020 22:44 (CEST)

Last call for the visual mode

Is the newest addition good enough? The devs ask us whether the visual mode is satisfactory. I think it is satisfactory, but your opinion is more important. We have this week to decide. If it is good, then next Monday (15 June) they will put it in the regular wikitech:deployment train, and "version 2.0" will be turned on next Thursday (18 June) for everyone who already has the Beta Feature enabled.

You can try it out on this page: https://nl.wikipedia.org/wiki/Overleg_Wikipedia:Discussietools?dtvisual=1

Are there any significant problems? Is there anything you need, before the visual mode is available to you all the time, without having to type ?dtvisual=1 each time? Whatamidoing (WMF) (overleg) 9 jun 2020 02:34 (CEST)

cursor hopping around phab:T254549 is a blocker for deployment imho. Ad Huikeshoven (overleg) 9 jun 2020 10:25 (CEST)

I just tried to reproduce this and couldn't reproduce it using Firefox on Ubuntu (Desktop). Don't have a Windows PC at hand at the moment. Mbch331 (overleg) 9 jun 2020 10:44 (CEST)

@Ad Huikeshoven, does this still happen in mw:safemode? (Your comment about the shift key has reminded me of a bug in an enwiki gadget that had something to do with Google Translate.) Whatamidoing (WMF) (overleg) 9 jun 2020 17:55 (CEST)

@Ad Huikeshoven I also can't reproduce on either Firefox or Chrome on MacOS. Be aware this will just bring this function into 'beta' software, where you can expect some bugs or instability. Do you really think this should block broader testing, where you still can switch to source mode if needed? I think the broader testing is beneficial. Akoopal _overleg. 9 jun 2020 18:41 (CEST)

Just tried to reproduce it with Firefox on Windows 10 and no cursor hopping here either. So I think we can test it as a beta and see if other users can reproduce it. Mbch331 (overleg) 9 jun 2020 19:27 (CEST)

It looks like it doesn't happen in safemode @Whatamidoing (WMF). Removing all gadgets globally and locally (two in total) didn't resolve the issue, however. @Akoopal ok, I won't block moving to beta. I wanted to raise the issue of cursor hopping as serious. Ad Huikeshoven (overleg) 9 jun 2020 19:34 (CEST)

Gebruiker:Ad Huikeshoven/vector.js still has a script in it. Whatamidoing (WMF) (overleg) 11 jun 2020 00:35 (CEST)

TheAfter removing that one, and clearing cache, am I still able to get a cursor hopping around. I just have to copy an user name from recent changes and try to paste it in visual mode. Right after the copy when I hit the shift key, the cursor hops back. This still happens after turning off all extensions in Chrome. So, something specific happens while an user name copied from recent changes is on the clipboard in Windows/Chrome. Ad Huikeshoven (overleg) 11 jun 2020 08:45 (CEST)

When you copy a username, is it plain text or a link? (If it's a link, do other links have the same effect?) Whatamidoing (WMF) (overleg) 12 jun 2020 21:17 (CEST)

When I type now a @ in visual mode and select a name from the drop down list with the arrow keys and hit 'Tab', then w00t, the name appears! Yes, that works @Whatamidoing (WMF). And after entering the previous sentence I had to swith to source mode because after hitting shift the cursor hops to the left. This is on an Ubuntu laptop using Chromium. So I copied or pasted nothing this time. Ad Huikeshoven (overleg) 13 jun 2020 09:16 (CEST)

So much for that idea. Does this happen in any other editing surface on wiki? And is it only in the visual mode, or does the source mode (of v2.0, which I think is the same as the source mode for 1.0, but I'm not sure) have the same behavior? Whatamidoing (WMF) (overleg) 15 jun 2020 20:42 (CEST)

So far, only seen in visual mode of DiscussionTools @Whatamidoing (WMF). i will try ve. Ad Huikeshoven (overleg) 15 jun 2020 21:01 (CEST)

VE doesn't have username completion after typing @. Ad Huikeshoven (overleg) 15 jun 2020 21:03 (CEST)

Maybe try Flow on MediaWiki.org? It has the @ mention system. Does this happen when you add a regular link? Whatamidoing (WMF) (overleg) 15 jun 2020 22:11 (CEST)

It doesn't happen with Flow on mw. It has a different mention system. Flow inserts a FlowMention template. Here a link to a userpage is inserted after a plain @ symbol. Ad Huikeshoven (overleg) 16 jun 2020 08:49 (CEST)

Just a test to give the visual mode a try!

Bloemencorso Ciell 9 jun 2020 20:55 (CEST)

No problems for me, looks great! Ciell 9 jun 2020 20:56 (CEST)

Just noticed this is enabled now, I can see the choice Visual/Source without using the option. Akoopal _overleg. 17 jun 2020 21:19 (CEST)

@Akoopal yes, it is. Please let us know what you think about it. PPelberg (WMF) (overleg) 19 jun 2020 01:51 (CEST)

I noticed that if you use the visual mode, it does not preview the signature. But when I switched to source mode I could see that signing was not nessecary. Maybe there can be a fine print, or the signature can be added by default in the preview in VM as well? Ciell 20 jun 2020 21:20 (CEST)

Thank you for sharing this feedback, @Ciell. A question for you: what led you to "inspect" the comment you had written in the tool's source? What were you wanting to see/know?

For context: we have observed a few cases^[1] of people inserting ~~~~ when writing a comment in the tool's visual mode, not knowing the tool would add their signature automatically.

---

1. https://phabricator.wikimedia.org/T255738 PPelberg (WMF) (overleg) 23 jun 2020 02:19 (CEST)

Hi @PPelberg (WMF),

Why I inspect? Because I know we're in this trail group for the tool. :)

I noticed that the "normal" VE (the one we use for articles) shows a preview, that is why it is called the ''visual editor.'' But in the visual modus for the reply tool there is no "preview" of my text. I don't have to use wikicode, but when I do, the tool does not pick up and does not show the effect on my typed text. In the "source" modus, I do get a preview of my typed text. ~~~~ Ciell 25 jun 2020 17:44 (CEST)

Why I inspect? Because I know we're in this trail group for the tool. :)

That makes sense!

I don't have to use wikicode, but when I do, the tool does not pick up and does not show the effect on my typed text.

I see. Aside from the instance where you might instinctively type ~~~~ in the tool's visual mode to sign the comment you are writing, can you share when you would expect to use the visual mode to write in wikitext? PPelberg (WMF) (overleg) 26 jun 2020 01:46 (CEST)

Now I see the "Mention a user" icon in the visual mode top-right menu. I hadn't noticed that one before. Ad Huikeshoven (overleg) 26 jun 2020 10:36 (CEST)

@PPelberg (WMF) this is my text in Visual: no preview below the text-box: and this is the same in the Source mode: there is a preview below the text box.

I would have expected a kind of preview in the visual mode as well, that way I know I do not have to use the tildes to get a signature. Ciell 26 jun 2020 16:29 (CEST)

"I would have expected a kind of preview in the visual mode as well, that way I know I do not have to use the tildes to get a signature."

Understood – thank you for explaining this, @Ciell. We've come up with an initial approach for handling the case where someone using the tool's visual mode attempts to manually sign (read: types ~~~~) the comment they are writing.

If you're open to it, we'd value you trying what we've implemented and hearing what you think. Here is a link to a test wiki where you can freely experiment with it: https://patchdemo.wmflabs.org/wikis/3bb6e079ad2a5cc6ae32f1c72e4c371a/w/index.php/Talk:Main_Page

Note: The link above is not fully complete in so far as we will be enhancing it to make it clear to people the tool will automatically sign comments posted using it. More details can be found in the "Implementation details" section of this Phabricator task's description: T255738. PPelberg (WMF) (overleg) 3 jul 2020 20:14 (CEST)

Hi @PPelberg (WMF),

I think this might be a solution! Even when I use tildes in Visual mode, the sofware overwrites them ànd I get a preview. * thumbs up* Ciell 4 jul 2020 20:06 (CEST)