Talk:Talk pages project/Replying/2019

The team would value any thoughts and/or questions you about this project: Replying to specific comments.

Version 2.0 questions

The page says Version 2.0 would likely include the following "enhancements"

• A way to easily understand who the author of a post/comment is
• A way to easily differentiate between different replies and comments on the page
• A way to intuitively know how to reply to a specific post/comment

It is unclear and mysterious what is being proposed here, and why. Aren't these already addressed by signature and formatting and reply buttons in version 1.0? Alsee (talk) 19:20, 17 November 2019 (UTC)

I assume this just means adding formatting (or displaying extra/different HTML) to clearly indicate usernames, separations between comments and the reply button. In the phase 1 mockup the reply button is basically the same as the one in reply-link. Jc86035 (talk) 15:36, 27 November 2019 (UTC)

Thank you for chiming in here, @Jc86035.

@Alsee, what @Jc86035 describes here accurately describes our intention.

I'll add: at this moment, it is difficult for us to say which of these interventions we will pursue or what they could look like considering knowing the answers to these questions depends on knowing how Junior Contributors experience version 1.0. PPelberg (WMF) (talk) 21:27, 27 November 2019 (UTC)

I use Enterprisey's reply link on enwiki. It works great (when it does). Guarapiranga (talk) 01:59, 3 December 2019 (UTC)

Thank you for adding your thoughts here, @Guarapiranga – @Enterprisey and their reply link has inspired many parts of this project!

Some people have been sharing the gadgets and templates they use most frequently on talk pages in another thread; it seems like your comment would fit right in there, so I've included a link to it here. PPelberg (WMF) (talk) 03:25, 5 December 2019 (UTC)

Previewing a reply

T238177
Prototype

What do you find valuable about being able to preview the content of a reply you are drafting before posting it to a talk page?

---

Context for this question: The team is thinking through how the initial workflow for "previewing" the reply you are composing might work as part of this new dedicated workflow for replying to specific comments. For reference, the way User:Thnidu articulates why they value previews has been instructive: "...a large part of their value for me is spotting errors of execution as well as errors of intention." [1] PPelberg (WMF) (talk) 19:48, 5 December 2019 (UTC)

Most significantly it shows whether wikitext renders as desired.

It strips away all of the markup characters, making it easier to review the displayed-text.

A final subtle point, the preview mode displays the content with the exact font and spacing and styling and surrounding environment as the read mode. The visual change somehow shifts the brain (or at least my brain) into read-mode. It may just be a psychological effect, but psychological effects can be real effects. In edit mode I'm fiddling with the details - the preview forces my brain to read it in a stream as if someone else wrote it. My brain knows it can't directly alter the preview text area. The various visual cues contribute to the effect. It makes it easier to catch spelling errors, unclear grammar, and the general quality of my communication, even if there was no markup and the preview made no substantive change in the stream of characters displayed. When I post without previewing, sometimes I find that my message was technically fine but the communication quality could and should have been better. Alsee (talk) 21:11, 5 December 2019 (UTC)

I would agree with all of Alsee's points here, although I typically only use the preview function on longer comments. Jc86035 (talk) 15:11, 6 December 2019 (UTC)

you won't believe the amount of time I created an invalid link and caught it while previewing. Or an accidental line break, or pinged the wrong user or .. endless. The preview is better human readable and it is easier to review the effect of any wikitext/html syntax you have written. —TheDJ (Not WMF) (talk • contribs) 16:46, 10 December 2019 (UTC)

Alsee summarized it very well.

I'd add that I love the preview on the prototype.

• It's much more convenient, than switching between visual and wikitext in Flow.
  • No need to search for the button that switches between visual and wikitext...
• It's fast enough (similar to discourse preview).
• Does not take up more place than necessary (in discourse it kinda does). —Aron Man.🍂 edits🌾 05:34, 12 December 2019 (UTC)

These responses are helpful – thanks y'all. I want to make sure I'm understanding what has been mentioned so far and then follow up with a few other questions.

Points raised so far

1) Previews help "me" to know whether the wikitext I wrote is rendering properly. Said another way: my text is formatted in the way "I've" intended it to (e.g. as @TheDJ mentioned: links, line breaks, etc.).

2) Previews help "me" to know how the content I've composed will be displayed to people who might be reading the page in "read mode."

Follow up question

For "2)", can you identify any patterns among the times when you find this kind of preview necessary? Does it depend on the size of the edit (per Jc86035's point above)? The type of edit? The namespace in which you are editing?

...I ask the above curious about whether a "full page" previewing should be considered a requirement for the replying workflow and if so, when. PPelberg (WMF) (talk) 02:06, 19 December 2019 (UTC)

can you identify any patterns among the times when you find this kind of preview necessary?

The following patterns are the most common (and repetitive... sigh) mistakes I make editing wikitext:

1. After editing markdown I forget that a linebreak is not a linebreak in the end result.
2. Syntax errors: one apostrophe less, one curly brace less, etc.
3. When making multi-level lists (ordered or unordered or mixed), it's hard to get the numbering and indentation right without a preview.
4. Templates: did I use the right parameter name? If it renders, then it's ok.

I'd say the complexity of the wikitext (different markups, templates used) is the primary concern. Longer edits give more opportunity to be complex, but length in itself is not usually an issue. I'm not sure about the namespace... maybe having a preview, thus avoiding some mistakes is more important in high-visibility discussions. —Aron Man.🍂 edits🌾 22:03, 19 December 2019 (UTC)

Indentation syntax

What wikitext should the reply tool use for the indentations it will automatically generate? Does the tool use whatever indentation syntax is used on the page the tool is currently being used on? Does it use : in all cases? Something else? If you have thoughts, the team would value your thoughts in this discussion.

---

Context for this question: When bullets are used for indentations (e.g. on ru.wiki), multi-line comments will render on the page as if they are separate comments. This situation can be avoided if contributors manually insert <br> tags as has been done here. Assuming there will be contributors using the reply tool who will not know or think to manually insert <br> tags, what can be done to make sure their multi-line comments are posted to pages in a way that is legible to others? PPelberg (WMF) (talk) 19:49, 5 December 2019 (UTC)

@Jc86035, with these two priors conversations in mind [1] [2], I wonder if you have any thoughts to add here...

By the way, please feel no obligation to respond.

---

1. https://en.wikipedia.org/wiki/Wikipedia:Talk_pages_consultation_2019/Phase_1#Straw_poll:_changing_indentation
2. https://www.mediawiki.org/w/index.php?title=Talk%3ATalk%20pages%20project/Updates#c-Jc86035-2019-11-06T11%3A20%3A00.000Z-PPelberg_%28WMF%29-2019-11-06T01%3A08%3A00.000Z PPelberg (WMF) (talk) 21:00, 5 December 2019 (UTC)

I don't know if I have a good answer, but I hope this is at least somewhat helpful.

My original suggestion was to copy the markup string for each new line, but you raise an important point. That would create a broken result when the last character is * or #.

We normally handle this with human intelligence. It may be challenging to come up with a good automated solution. Using <br> will usually work, but that would become rather annoying when someone tries to include indentation, a bullet list, or a number list, in the middle of their comment.

My tentative suggestion is that when the initial indent string ends in : to copy the indent string for each new line. When that string ends in * or # you'll probably have to use <br> instead. In general the user needs to be able to modify/fix the automated markup. Alsee (talk) 21:47, 5 December 2019 (UTC)

If memory serves, @Jeblad has spent some time thinking about some of these problems. Whatamidoing (WMF) (talk) 06:24, 6 December 2019 (UTC)

If a div, or any element that can be set as a block element through the display css property, is injected in a list, then following list items can be rendered as before. If that div is created as wiki markup, then you must keep using the rules for existing markup, otherwise you will run into problems.

In particular, adding smartness by keeping previous indentation are more or less doomed to fail. It creates problem because it breaks the expectation for what the user is supposed to write. Don't change the expectations about existing markup, that will create huge problems. (You are inside a list, and the communities has abused the list metaphor, so the communities should expect it to break.)

There are less problems with adding a tag function, that will wrap up the complete post, no matter if the post has multiple parts. You must armour the content to avoid further parsing of the content. The reason why you must armour the post is that the parser has no idea where the newlines goes, and will try to restart the list. You get the same problem with a table inside a list.

The core problem is that you need to know where the post begins, and where it ends. As long as both beginning and end is within the same block it is quite easy. If it is in two different blocks it is not so easy. Then you must start inspecting previous revision(s), and things start to get ugly really fast. You can backtrack and find the beginning of a post by looking for previous toolbars, signatures, and changes of indentation, but this is error prone.

It is possible to avoid the whole problem by neglecting one of beginning or end, thus you can't properly delimit the post. The best is probably to neglect the beginning, and add a toolbar (thanks·reply-to) at the end. That is you add a toolbar after the signature, and that toolbar has the reply-to link (or button, or whatever you want to use). Note that this function must (or should) be provided the timestamp or a revision id. (Actually it could be done as a signature function, so to add even more functionality.)

You should probably inject the post (no matter how it is formatted) directly after the post where you clicked on the reply-to link, but note that if you use a tag function and track who you reply to it isn't really necessary.

A slightly smart solution could be to add a special character sequence that says “here starts the post” and running all the way up to and including the signature, but then someone insists to add a reply in the middle of someone else's post. That often happen with a multipart post, unless we add code to stop it. If that has a beginning-of-post marker then the text can be parsed recursively. It is although nothing more than a involved tag function with a new syntax, so better avoided, but it is a possibility.

For those situations where you need to make a reply to a faq or similar, there can be a parser function that creates an anonymous reply link. That should be able to take a direction mark that says whether a post is added above or below the parser function. (This parser function can be the same as the one that creates the toolbar for individual posts, you somply does not reply to a single post.)

Note about timestamp in toolbar: The timestamp makes it possible to link to a specific post. Usually the timestamp is good enough, but sometimes you must use the revision id. You could also use timestamp and username (or user id) but that can also fail. I would guess timestamp is good enough for user added posts, and that the system could inject revision ids when it observes collisions. Jeblad (talk) 13:23, 7 December 2019 (UTC)

There's a live test page for the first version of the software at the VisualEditor test wiki. It might help with visualizing how the finished software would actually look and work.

One of the main reasons I suggested making the new markup compatible with list item syntax was to ease the transition between the existing discussion conventions and the new markup. You could perhaps mitigate this by providing a tool/checkbox for users to try to convert old discussions to the new syntax (or by having the software attempt to do this automatically when a new comment is posted in an old discussion), but I don't know if either of these would be disruptive.

Adding the post immediately after the parent comment would probably be unexpected behaviour, since this would reverse the expected sort order of replies (i.e. in the case where there are multiple replies to a single comment, the replies would be ordered in reverse chronological order instead of in chronological order). I think it could make sense to have both a reply button after the comment and a reply button after any existing replies (especially if there are already e.g. 10 or more replies), with both buttons resulting in the addition of the input form in the location where the comment would be posted (i.e. after the existing replies).

Allowing people to "reply" to a parser function would probably be useful, especially where the top comment is typically separated from the rest of the discussion (e.g. deletion discussions).

Would it not be better for the system to consistently inject revision IDs? This could reduce the complexity of using the data on the page (although I imagine it could still be problematic if users copy comments/discussions between different wikis). Jc86035 (talk) 15:13, 7 December 2019 (UTC)

I followed some of these threads for a short time, so my knowledge of all discussions are only partial.

(Sorry, it is slightly incoherent, it is four in the morning.)

The page you link to gives the usual wikitag soup I really-really dislike. Adding a reply-link and and doing the posting on visual page helps, but keeping the wikitag soup as bad as it is without cleaning up is less so. Given that this is what many advocates (even if it makes me puke – it really does) then really good solutions are lost, it is more a question of what can be salvaged from the chaos.

(rant: The wikisoup creates a master language that rises some editors above the plain readers. The plain readers that don't control the language of the master race will then feel intimidated. It can be said in many ways, but by creating distance between one group and another group we are creating a deep hierarchy. With wikicode we do it with technical means, but the end result is the same – someone will be intimidated.)

There are at least two different types of replies; one on the main thread which I would simply call “reply”, and one on a specific post which I would call “reply-to”. The first one would be the plain anonymous parser function, while the second would have some kind of id. When I was playing around with a gadget to do this I found that the timestamp was usually sufficient. At enwiki you would probably find that this will create ambiguity, so you can instead use username-timestamp for an id. If even that creates ambiguity you can add the revision, like username-timestamp-revision. Fun thing is, if you give an empty id the system might fill in the id to make it sufficient, or you might create something like "my-amazing-idea". I don't know whether it should be an id or a name attribute, that has some implications. It is somewhat easier to use a counter, like VisualEditor does for references, but a situation might emerge where the whole page is archived, and what would the value of counter then be as there are no old values.

For those cases where the reply is a single part it can be inserted as before. If the reply is multipart, or it is a reply to a specific user, then the easiest solution is to wrap it in a tag function (<post>Here goes the post</post>), armour the output, and use the same indentation +1 given the post for the reply. If you don't do that you run into all kinds of problems. If users insists on writing multi part posts manually with all kinds of made up weirdness, then simply avoid doing anything with it. Add some niceties to the tag function like “thank” link, and people will start using it by themselves.

If the reply is on the main thread, ie. created from a “reply” and not any “reply-to”, then add it in whatever indentation +1. This type of post can use the username and timestamp if the post is signed, but those should be normalized. They can be put back in as stylised signatures, but they should be on a format that can be easily parsed. Here you could use magic names as URN, and do some tricks to parse the timestamp as an URN, but some devs insists on removing the magic names. Trying to parse the insane tag soup for signatures as it is now is probably pretty much stupid… Use a parser function for name and timestamp.

In a multipart post with a post tag function add the user name and timestamp as attributes in the head.

I believe replies should be ordered ascending chronological in the main thread, but a reply-to should be descending chronological on the actual post. Now Flow use ascending chronological on reply-to, but this gives the wrong impression. If I do a reply-to on Whatamidoing [1] I will get a post below this one, which is wrong in my opinion. The reason why it is so is said to be enforcing a flow towards a consensus, but quite frankly I doubt that idea work at all. Usually there aren't that many replies to a single post, the most I have seen is a handful.

In my test at the linked page I got a post inserted on a very weird place, and without any way of telling who I responded to. That is really-really weird. If I reply to someone I would expect the reply to be to this person and not some other stranger. This type of reply are often creating harsh disputes on nowiki. “Do you talk to me? I didn't say so and so!”

One way to get a pretty nice and simple solution is to name the person you do a reply to, that is the same that the post tag function will do, but you might do it as {{reply-to:username|timestamp}} or if you insist on adding new wikisyntax @username-timestamp|. The final vbar is modelled after table syntax. Note that it is a bit awkward to reply to two posts at once. This form of lead-in could be given some special formatting, and then strengthen the readers mental model of this is the beginning of the post. A toolbar after the signature will likewise strengthen the readers mental model of this is the end of the post. It is slightly odd that you end with as much wikicode this way as a tag parser function, but users will probably feel it is more “wikiesque”.

If you make it clear who you reply to, you can add posts at the same indentation level. As it is rather important to avoid deep indentations due to readability, it is important to clarify who you reply to.

Now, assume a callback is registered on the block holding reply-to information, and the user hovers on that block, then the linked post can be highlighted with a marker along the edge. This is pretty simple, but you must have the linkage information, that is at least a timestamp. That will make it a lot easier for the reader to figure out who is replying to whom. Just dumping some text on the page, with or without added VE editing help, will not be very useful. That is my main concern with the linked page, it does not enhance readability, it only enhance editability (yummy).

It is likely that users will ask for a parser function like {{reply-to:username|timestamp}} pretty fast if it becomes easy to point to other posts. In this case they will use it inside their reply, and then they will need some easy way to copy-paste such templates. They will probably just copy the reply-to link and try to paste it inside the edit window.

(The gadget I experimented with was motivated on how to do such highlighting with a special link. It is possible to do this to some limited degree with signatures as the only hint of targets, and a callback run at load time. It simply traversed the parents until list items was found and then added formatted ids. When a fragment link hit the post, then it got a green border.)

Another typical copy-paste is inserting text from the replied post. Other systems usually dumps the whole post inside the window at the cursor position, or at the beginning, or at the end. I'm not sure what's best. Perhaps the user should be allowed to drag-n-drop from the page.

I tend to believe there are several filter and sort orders. You should be able to mute some discussions to be able to figure out what goes on in a discussion of special interest. Assume you have some indentation, who has replied to this specific post? That is much harder to do than to describe, and I don't know if it is possible with a free form wikipage.

Lastly; sometimes you need to know whether someone agree or disagree with a statement. It is quite similar to a “thank”, but would log an active yes or no. This is the easy use case. The more difficult use case is quite involved. I started to write a description for User:Jeblad/subjective voting (in lack of a better name) but it is darn hard to get it right.

Last II: A discussion thread should usually start with a well-defined post, and if that is wrapped in a post tag function, the the spawned div could use a class that transforms the following lists so they have lines on the side. Those line will make it easier to visually see who replies to whom, and may make it unnecessary to identify which post you reply to. This seems to work up to some number of indentations, and then it becomes hard to follow. It is especially the long lines that are troublesome when they run off the screen.

It easier for users that writes the replies manually when they don't have to track who they reply to, but it also makes it possible for users that refuses to follow etiquette to seriously mess up the threads. I could give examples, but then I would probably create a similar chaos in this thread. ;)

The fundamental clause is that you have one canonical definition of a thread, and if someone break that it very quickly gets really messy. Ie. someone decides to outdent to margin even if they reply to someone that has indented. In this case the previous replied post must be stated explicitly, but then if someone later will reply to the original post they to must state that explicitly. It is messy.

Last III: I wonder if it should be visually different whether you reply to a post or you discuss a topic. It could be easier if the users clearly discuss a topic on the leftmost branch, and replies to posts on the other branches. That could streamline the flow somewhat, but I don't know how that should be done. It is probably not sufficient to just name the links differently, somehow the users must want to make discussion on topic focused.

Wild idea; What if posts are detached from the left branch after votes. They stay to the left, gets a little greyed, but not on the branch, and people can reply to them. That little gap could be sufficient for people to stay focused on the thread, as they don't want to get sidetracked. A simple vote on whether the posts is helpful, and only helpful posts stay on the branch. Perhaps it works… Could be trolled easily though, so need some limitations. Jeblad (talk) 03:08, 8 December 2019 (UTC)

Adding a reply-link and and doing the posting on visual page helps, but keeping the wikitag soup as bad as it is without cleaning up is less so.

I have assumed that they would want to change the output HTML at some point (i.e. new syntax). However, it does seem logical that for an early beta version with only a few people using it, they might want users to be able to participate in real discussions on live wikis, which would necessitate using the existing list item syntax.

Usually there aren't that many replies to a single post, the most I have seen is a handful.

If you go to w:en:Wikipedia:Village pump (policy) or w:en:Wikipedia:Administrators' noticeboard/Incidents at pretty much any time, there will be several discussions with lots of bullet point replies to a top-level post (typically a proposal or RfC of some sort). This is the norm for most deletion discussions and votes as well. For the biggest discussions there might be hundreds of replies to the parent comment. I have assumed that the new software will typically follow this structuring approach by default (after all, enwiki does form about 30 to 40 percent of the user base), although allowing the comments to be re-sorted (in read mode, not edit mode) seems like a good idea and could prevent usability issues.

Assume you have some indentation, who has replied to this specific post? That is much harder to do than to describe, and I don't know if it is possible with a free form wikipage.

Presumably it would be possible to tell by tracing back from each reply to the previous appropriately nested comment? Nevertheless, I think you could probably do it otherwise by adding metadata to the comment output (e.g. part of the signature, part of the comment wrapper, etc.). If each comment has a unique ID (e.g. the first revision ID, randomly generated ID, ...) then you would be able to generate anchors and so on, which could work even without changing indentation (e.g. if the anchor/metadata are an extension tag within the signature), but this would rely on users choosing to use the extension and/or choosing to add the metadata manually. Unless you're describing another problem entirely. Jc86035 (talk) 14:12, 8 December 2019 (UTC)

On reply to a single post

You may have many replies from users discussing the main topic (ie. leftmost branch), but there are usually very few that replies to a specific post (ie. branch to the right). The way we discuss now at the wiki projects are a mess, and it is very difficult to figure out who is replying to whom.

On post ids

The ids must be unique for the whole page, not just a section, and as soon as a part of the page is archived it become difficult to figure out what is the correct index. You could use random identifiers, but then you will get collisions. You could use digests from the individual posts, but then random changes could (would) render the digest unusable. The best workaround I know is to use locality sensitive hashing (LSH) but how should a random user be able to create something like that. Everything some user must do manually will create problems. Jeblad-demo (talk) 18:57, 8 December 2019 (UTC)

Even if it's a mess, the main problem I would see with unilaterally changing it is that users would expect the current sorting system to remain in some form, and changing how comments are nested by default would be considered an unnecessary and disruptive change. The WMF developers already tried to change it in Flow. I don't know if they'll want to try to change it again, and there's no one clear or objective "better" method to do it. (There's also no guarantee that changing the nesting structure would make it less confusing to navigate a large discussion.)

Would w:en:universally unique identifiers not be sufficient? Even in a system where collisions would regularly be produced, presumably the system could retain a full index of IDs and force another ID to be generated if a new ID does indeed clash (although I don't know how computationally intensive this would be). If the signature generates the ID then a user commenting manually wouldn't have to worry about it. Jc86035 (talk) 19:19, 8 December 2019 (UTC)

An UUID is just some way to write a very large number, it does not solve anything by itself. When the number is very large, the chance for a collision gets very small, but it does not go away, and you still must track all numbers you have used so far. It is possible to do tracking in the page-props table, but you should probably create a new table. The right way to do this would be to use globally unique ids, because you don't know where someone might move the thread.

Then you have the problem the user face when (s)he must write that pesky number manually. It is easier to write an identifier consisting of a user name and a timestamp. Jeblad (talk) 21:11, 9 December 2019 (UTC)

If you were to include the unique IDs in the UUID (in addition to random bits), it would probably help to reduce the likelihood of generating collisions. I don't really know how this would work in practice, though.

If the issue is writing the unique ID when making a reply, I've assumed that users would either reply automatically, copy and paste the ID (from elsewhere in the page source) or simply omit the ID altogether. If the reply is located at the correct place on the page then the parent comment can be inferred, so it would presumably only be an issue if the users have broken the formatting. Jc86035 (talk) 14:53, 10 December 2019 (UTC)

Interestingly, Flow/Architecture#IDs indicates that SD already uses the UUID approach. Presumably comments are simply infrequent enough that including the date and time is enough to make collisions impossible. Jc86035 (talk) 02:29, 16 December 2019 (UTC)

As long as you want to reply to an on-page post the problem dwindle down to copy-paste in most cases. The real problem is the entry of the posts' id, because the user has no interest in adding an id to his own post. For others to reply to that post they must know the id.

You might get around the problem with changing the timestamp into a composite date-time-random string. It is somewhat similar to a UUID, they come in several flavors, and this one is human readable. This works on a single page, but if a thread is moved, then it is not necessarily unique. That's why I believe a signature should be a packed user-date-time-random or a user-revision composite string of some kind, and transformed into a more readable form during parsing.

The move of a post will happen as part of the archive process, even if there are no plans for moving threads to other pages. Jeblad (talk) 11:48, 16 December 2019 (UTC)

In re inserting the revision id into the edit, @Catrope tells me that it's "pretty much impossible" and referred me to https://phabricator.wikimedia.org/T14694#177118 and related ancient requests.

Something about needing to re-architect MediaWiki from the ground up, I think it was. It shouldn't take him too long to make the impossible become commonplace, right? ;-) Whatamidoing (WMF) (talk) 22:27, 27 December 2019 (UTC)

It is right that you can't easily use the revision, but it is possible – it is all about how and when you want to use the revision. The revision can be lazy-updated if necessary, but it can also be injected on save. This although creates unnecessary complex code.

(I guess the discussion arose because I wrote “If even that creates ambiguity you can add the revision, like username-timestamp-revision.” That is somewhat confusing and unnecessary, and I should have left it out.)

Most of the time you just want user and timestamp, and it is good enough, but that is also hard enough because the users are free to chose whatever format they want. (I.e. it would create a fragile system.) If you only have the timestamp, then several users might save within the same timeframe, so you want to add the user, and you want the composite in a form that makes it identifiable. If the user is named then a collision only happen if the user saves several replies in fast succession, we use a one-minute resolution on the shown timestamp, or several replies on the same save operation. Save in fast succession can be solved by increasing the shown time resolution, save within the same save operation can be solved by adding a counter.

A signature can either be created as a tag-function, a parser-function, a special link, or a template. If a template is chosen, then you need to track that, which is a bit pesky. Users don't expect parser-functions, so using that would be bad. I would say it is best to use a tag-function for a signature, but people often seems to dislike tag-functions. It could be best to use a signature-link and add a timestamp. The actual link could call the users chosen signature on render instead of save, thus it would visually be the same as today, but in wikitext it would be different. Jeblad (talk) 02:43, 28 December 2019 (UTC)

> The actual link could call the users chosen signature on render instead of save, thus it would visually be the same as today, but in wikitext it would be different.

I wonder what effect that would have on renamed accounts. Whatamidoing (WMF) (talk) 17:55, 30 December 2019 (UTC)

Just keep a redirect. The same problem arise, and is solved, at Wikidata. Jeblad (talk) 19:57, 30 December 2019 (UTC)

Then the redirect would automagically show the new name? Most editors would probably appreciate that. Whatamidoing (WMF) (talk) 01:20, 31 December 2019 (UTC)

I think I said this before somewhere else, but it is a very bad idea to replace save-based-signatures with render-based-signatures. Consider this:

1. Someone sets their signature to something interesting, perhaps impersonating WMF-Legal for example.
2. They post a message, using that deceptive signature.
3. They wait for the target person or persons to read the message, with the deceptive signature.
4. They change their signature back to normal.
5. They purge the page... the deceptive signature vanishes.
6. There now is no log and no evidence anywhere of the malicious actions. Alsee (talk) 07:14, 31 December 2019 (UTC)

Logging changed signatures pose no real problem, and should be done anyhow. It is not done now, but that is a failure and not a feature. (Point 1 would show up in the history anyhow, so the point is somewhat moot, but just assume it work for this discussion.)

If anyone insists, then use a user id. It doesn't change much, but you avoid protecting the redirects.

(Note that falsified signatures is a bit more complex, and isn't solved by the present signature. In fact falsified signatures can't be solved at all without somehow wrapping the posted text and adding a real cryptographic signature for the wrapped text. That would make it near impossible for users to add the signature manually in wikitext.) Jeblad (talk) 15:26, 31 December 2019 (UTC)

> That would make it near impossible for users to add the signature manually in wikitext.

Which would be a problem for people sending (current version of) MassMessages, because we don't really want those signed by the bot. (There are solutions and alternatives, such as Extension:Newsletter.) Whatamidoing (WMF) (talk) 02:56, 2 January 2020 (UTC)

Not sure, but I don't think it would be a problem to sign a message as someone other than the user sending the message. It is a slightly different problem than the plain “reply-to”, but could be done by a tag function (<post>Here goes the post</post>) were a detached signature is added as an attribute. It would create a bit messy wikitext, it would not be easily edited, but it could work. The current version of MassMessages could be slightly changed, and then it would add the detached signature without the user doing any additional editing. Jeblad (talk) 11:54, 2 January 2020 (UTC)

Short version:

Make a tag multipart and wrap it around posts with newlines. This tag will be generally useful, for example for tables inside lists. The lists will only see a single blob, and there are no newlines to mess it up.

Hover for replies: Traverse upwards from block with timestamp until nearest list, and then go up to sibling item. This will be the containing list item for the reply unless someone try to make a mess.

Hover for topics: Parent of list is mw-content, only highlight item.

Hover effects can be done with selectors in CSS, possibly with a single line representing a branch.

Add ids (username-timestamp) to posts so they can be highlighted with a link. This should only higlight a post, not the replies.

Make it possible to copy-paste a reply-to link. Jeblad (talk) 04:59, 8 December 2019 (UTC)

I've explained possibly more of my reasoning than might be necessary, as I don't really know how specific I need to be and what issues I can refer to without explaining them. You might want to read the last parts of the comment first.

I think another common formatting for multiline bullet point comments is to follow * with : (obviously incorrect but renders passably). It's not clear to me what the semantically correct syntax for multiline comments would be (‎<br> is not ideal, and obviously neither are list items). I believe it would be correct to use ‎<p> to separate each paragraph, but in practice this is very rarely done; I have done this, but only when writing a level 1 * comment. (Within this comment, "level n comment" refers to a comment with n indentation levels; a level 0 comment would usually be the first comment in a thread.) Because the conventions themselves are semantically incorrect, users who actually try to write semantically correct comments are by definition not following said conventions.

It might be preferable to introduce an entirely new syntax for comments written with the new interface while still allowing users to write comments with the old syntax, although how this would work in practice would likely be mostly dependent on the costs and constraints of building a more complex system than would be functionally necessary. (This would make it the software's task to format those comments in a semantically correct way.) It's not clear to me if this is actually going to happen, but I think having new syntax would be a prerequisite of allowing users to make multiline comments, since it would probably reduce the technical complexity of saving multiline comments while still allowing them to be edited (and without discarding the original input). (phab:T230683 and phab:T230658 seem to be the main related tasks, although only the latter is currently under the OWC2020 umbrella.)

For the versions of the software before any new syntax is introduced (if any), I think it could be appropriate to use : automatically; even considering the wide variations in how contributors use indents, "use : in most discussions" is a fairly widely-followed convention that has been the norm since about 2002. However, if replying to a level 0 comment, I would follow whatever list item syntax has been used for the last level 1 comment. (Enterprisey's reply-link would be a good model for this sort of approach.) This won't be perfect – in some discussions there may not even be any machine-readable indication that the software is supposed to indent the first reply using * – but I think it should work in most cases. If this were to be kept around indefinitely, then it would probably be necessary to introduce a better guessing mechanism (e.g. partly based on whether the page title matches a community-defined list of title formats). For multiline comments, I would probably have the software insert ‎<p> for all multiline comments (in spite of this not being a particularly common convention), since this would be semantically appropriate and would be appropriate for all list types, but contributors could potentially dislike this behaviour. (I imagine that it would be understandable while the software is in beta.)

This approach would still result in some broken list formatting; for example, although my understanding is that * should only be used for level 1 comments, some experienced users tend to use it in other places, and some experienced users will indent with :* or :: following a level 1 * instead of using the correct *:. (I would argue that ** would also be incorrect, but some might disagree.) MediaWiki discussion markup usage is in this way similar to natural language, in that the grammatical conventions can easily be ignored, can change over time and can vary between communities. Because of this, I think it would probably be futile to try to make the software produce list item syntax, or at least it likely would be without changing the behaviour of the existing syntax on discussion pages. (I also suggested in phase 1 that an extension tag or some other marker/syntax could be used to indicate the discussion type, similar to the meaning expressed by the usage difference between :, * and #; clearly defining this sort of difference would presumably be an improvement over not doing so, and this and other software changes could potentially enable other feature possibilities like CSS customizations for different discussion types and semi-structured polls.)

Perhaps it would be a foregone conclusion that versions of the software published after the introduction of new syntax should always output the new syntax, even if the new syntax can be mixed with list item syntax. This could potentially make it difficult for users using the older editors to make comments, so it could be beneficial to keep the new syntax at least somewhat similar to the current syntax. Obviously, what the syntax would actually look like is still up in the air, but presumably it would minimally be able to handle multiline comments and most/all current elements of wikitext formatting.

Tracked in Phabricator
Task T239978

As a side note, it may be impossible to surface the software in some cases if it can only be accessed from the "reply" button (particularly if the location of the button is entirely dependent on the location of the comment being replied to). For example, in an RfA support or oppose section, there is no level 0 comment to reply to, so the user will be unable to post a vote; additionally, a single reply button would be insufficient to allow the posting of level 1 comments/votes in all of the support, oppose, neutral and discussion subsections. (The same would happen in many RfCs, and possibly AfDs. In extremely long discussions, users also tend to insert level 3 or 4 headers as "arbitrary breaks" so as to be able to more easily navigate through the page, and this could also prevent the interface from being surfaced correctly due to the top-level comment being in a previous subsection.) I don't know if this has been noted as an issue anywhere else, but I've filed a Phabricator task for it.

In conclusion:

• I think it is almost necessary to introduce new syntax for indentation (and/or to change the behaviour of list item syntax where it is used for indentation in discussions), so that the software's output can be guaranteed to be correct. Although this could seem unnecessarily complicated, a number of factors – such as the lack of multiline list item syntax, the semantic incorrectness and inaccessibility inherent to the use of definition lists, the inconsistencies in discussion syntax conventions between and even within wiki communities, and the frequent misuse of list item syntax by many contributors – make this complexity justifiable. (In pre-release versions of the software, I think it would be acceptable to temporarily use the existing list item syntax for indentation.)
• I think the features possible within the current discussion conventions should nevertheless be retained as fully as is practical within the new software and syntax, primarily to avoid reducing contributors' ability to communicate with each other, but also to preserve some flexibility in structure and formatting that might otherwise be lost. This includes (but is not limited to) multiline comments, wikitext formatting, structural flexibility, and the meaning expressed by the differences between the list types used for indentation. I think it would also be beneficial for those features to be expanded, even if they aren't directly related to the main goals of the talk pages project.
• For any versions of the software which automatically indent using list item syntax, I would prefer a ‎<p>-based approach to multiline comments. However, I think it would be preferable to disable this behaviour before the software is enabled by default.
• I think users who are unable to (or choose not to) use the new software should ideally still be able to participate in discussions without significant difficulty, so the new syntax should be intuitive and/or similar to current list item syntax.
• I think it would be premature to widely deploy the software before new syntax is ready (and/or the parsing of list item syntax on discussion pages is changed). Introducing relevant syntax changes first could make it easier for the software to work well regardless of differences between wikis' discussion formatting conventions, and could potentially reduce the development work needed to make early versions of the software work without said syntax changes. Jc86035 (talk) 10:25, 6 December 2019 (UTC)

If not as supported (simple : indenting), give up and throw people into old style section editing for an initial version, until you get a syntax defined. It's the easiest solution. —TheDJ (Not WMF) (talk • contribs) 16:44, 10 December 2019 (UTC)

+1, initially using the source editor as a fallback would clearly be a lot more feasible than handling lots of edge cases. Jc86035 (talk) 17:04, 10 December 2019 (UTC)

Prototype testing report

First, I'm not saying the full page needs to be in the edit box. However the product concept should be somewhat more closely derived from the current editor. The community essentially asked for three quality-of-life improvements over the current talk system:

1. We don't want to have to count and type the indent markup. Put it in the box for us.
2. We don't want to have to type ~~~~. Auto-add it on the end. Displaying this is less important than displaying the indent-markup, but it should be visible at the bottom right for consistency and simplicity of concept.
3. Insert that blob at the correct place in the page.

Don't take radical leaps away from that. Hiding the indent markup breaks my ability to control that markup. Faking the indent markup is breaking the previews. Running things through VE's parser is a fundamental design flaw. It's breaking previews and it's breaking the content itself. Alsee (talk) 14:29, 10 December 2019 (UTC)

(For the purposes of this discussion I'm going to ignore the fact that Parsoid exists, because discussing it here will not be productive by most meaningful measures.)

The summary of the proposed product direction that was used in the phase 2 consultation questions:

The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.

I analyzed the English Wikipedia responses to the summary in July. There was near-unanimous support of the summary's stated goals from the users whose accounts were created in 2007 or later (i.e. users who signed up in the last 13 years), though the users who joined before were clearly somewhat more ambivalent. Overall, more than three quarters of the respondents stated their support without voicing any concerns (although it is notable that some of them made their support conditional on their workflows not being disrupted and supported the changes primarily because of the benefit to new users; and a few opposed because they found the direction insufficiently ambitious).

The other community discussion summaries on the linked page indicate a similar distribution of responses, with most respondents supporting the statement and agreeing with the specifics.

Furthermore, the respondents were clearly supportive of the initiative as a way to make talk pages easier to use for inexperienced users; it follows that if the main goal is to improve talk pages for new contributors, the specific technical quality-of-life improvements that the community wants should not even be the main focus of the talk pages project to begin with.

So, in a nutshell, I would disagree with your comment's framing of the direction of the talk pages project, and would also disagree with the conclusion that the primary aims should be to make small and incremental improvements for the benefit of experienced users.

Regarding your specific concerns:

Hiding the indent markup breaks my ability to control that markup.

They're not taking the source editor away.

And from my experience using reply-link, automatic indentation is sufficient in most cases, so it's not clear what would normally be worth controlling. Even in the case where you would be expected to choose between : and *, typically this is dependent on what the previous users have used unless you're writing the first reply in a discussion. This is not even the first beta version yet; it wouldn't make sense to expect that edge case to be dealt with before everything else.

Faking the indent markup is breaking the previews.

Again, I think it is unrealistic to expect a prototype of unreleased software to work very well. The code for previewing, as far as I can tell, did not even exist until last week. Jc86035 (talk) 17:01, 10 December 2019 (UTC)

@Jc86035: I would disagree... improvements for the benefit of experienced users.

I protest you and everyone else who slanderously frames opponents as some sort of selfish villains just because we disagree on how to best help new users.

The community is deeply protective of our on ramp for new users, and I expect community consensus will kill any product believed to damage that new user experience.

The Foundation had wonderful-sounding theories on how to help new users. Unfortunately those theories failed in practice. I believe community consensus has a better understanding of the process of turning new users into experienced users.

The new interface shouldn't be trying to hide the fact that we're a wiki. We're explicitly keeping talk pages as wiki pages, we explicitly plan to continue making some of our edits to the page the same way we do now. The new interface eases the most routine class of talk edits. If a new user is to become an experienced user, we expect that they are going to edit the talk page with the full page wikitext editor at some point. The new interface should be 'convenient training wheels', so the new user feels comfortable and familiar when they do click the full-page-edit. That means the new interface should look and feel sort of like a streamlined standard wikitext edit.

We help turn new users into experienced users with things like ensuring that previews are accurate. We help turn new users into experienced users with things like showing the indentation markup, so the new user can see it and learn how it works and control it. We help turn new users into experienced users by ensuring that the software does not randomly mangle what they type in. The Foundation likes to cite "broken markup" as an reason for mangling the user's work. That is not a valid excuse. New users are expected to experiment and they are expected to enter strange markup. If a user types in "broken markup" then that is what you save, character-for-character. That's how people learn on a wiki.

We might disagree on some points, but can we agree to kill the experienced-users-are-selfish-villains framing? Alsee (talk) 19:48, 11 December 2019 (UTC)

Many of the experienced users in the consultation supported the direction specifically (and in some cases only) because of the focus on making talk pages better for new users. This, I would think, clearly shows a lack of self-interest in their decision-making; I'm not trying to villainize experienced users, and the data wouldn't be able to support that sort of judgement anyway.

Furthermore, the overall results of phase 2 of the consultation (as aforementioned) indicate that community consensus is more or less in favour of the approach that was proposed then, which explicitly mentions the introduction of a WYSIWYG editor. The present consensus is, then, to support the Editing team's direction (unless a different consensus is found by some future consultation or RfC). "Consensus", when invoked, should be an accurate reflection of the opinions of community members, and is not supposed to be a cudgel to get the developers to acquiesce to demands (and to be pedantic, it is nominally useless here per w:en:WP:CONEXCEPT).

The new interface should be 'convenient training wheels', so the new user feels comfortable and familiar when they do click the full-page-edit.

Talk pages do not have to be forced into being training wheels; it's arguable that they shouldn't be, and doing so may come at the cost of making communication harder. Moreover, definition lists and signatures are almost never used in articles, so forcing users to handle them in order to communicate has questionable utility (even if the aim is to familiarize users with wikitext). As I understand it, the new interface will have a wikitext option, so those using it would still be able to write comments in wikitext.

Talk pages, as I'm sure you're by now aware, were more or less an ad hoc solution, targeted towards an audience that was very different to both present-day new contributors and present-day experienced contributors. If the interface can be modified without breaking advanced workflows and such, then there is no practical reason to keep forcing that onto new users indefinitely, especially since there is little evidence that it actually helps them learn wikitext syntax.

If a user types in "broken markup" then that is what you save, character-for-character. That's how people learn on a wiki.

A wiki is a public environment. While you might not have been dissuaded by going through this sort of experience, some people might not like their mistakes to be recorded publicly forever. Forcing users to learn by trial and error (which is probably what usually happens) is a recipe for frustration.

And I would note that even experienced users routinely use incorrect syntax on talk pages. This suggests that users wouldn't necessarily learn from making mistakes on a talk page, since they might not realize their mistake to begin with. Jc86035 (talk) 16:31, 12 December 2019 (UTC)

unless a different consensus is found by some future consultation or RfC

A new RFC may be necessary to clarify or make explicit some issues, but doubt the underlying consensus would really be any different.

There was a consensus to keep Talk pages and improve them for both new and experienced users. A number of ways of doing so were identified.

Converting a "direction" into a product requires filling in a lot of details. If the editing team declares "everything will be comic sans font" as part of their direction, obviously you cannot claim consensus for the editing team's direction.

There was nothing remotely resembling consensus for a VE default. For example on DeWiki a few people suggested a VE default - however it dies there to explicit and implicit opposition. On EnWiki a few people suggested eliminating the Foundation's restriction banning VE from some namespaces, and I do not recall any opposition to that idea. However that does not remotely equal support for reversing the default. VE is explicitly the secondary editor, and if the Foundation's ban on VE is lifted then VE remains the secondary editor.

During the consultation phase the Foundation did a really good job working to listen to the community. During this phase, it's starting to seem like there's disinterest in hearing from the community. The Foundation should welcome or even collaborate on any RFC for more clarity and information.

experienced users routinely use incorrect syntax on talk pages

There are good reasons HTML pages need "correct syntax". Those reasons do not apply on a wiki. The syntax is therefore not incorrect.

For example:

• ''' bold '' bold-italics ''' italics ''
• <b> bold <i> bold-italics </b> italics </i>

Both of those are correct wiki syntax. On a wiki, users are expected to use all sorts of random syntax. It is the job of the wiki parser to accept any syntax, and jump through the proper hoops to convert that into HTML-correct syntax.

On a wiki, the only "incorrect syntax" is syntax that didn't produce the desired result. Alsee (talk) 08:43, 14 December 2019 (UTC)

Could you clarify what you refer to by "VE"? Does this encompass the source editing mode (i.e. the 2017 wikitext editor) as well or just the WYSIWYG portion?

The syntax is therefore not incorrect.

You can't just define "incorrect" out of existence and say that there's nothing wrong with misnesting HTML and forcing the parser to guess what it means. Words have meanings. Obviously, the editor still allows you to save the page, but that doesn't mean that you haven't introduced any syntactical errors; Special:LintErrors exists specifically because it is considered desirable to correct syntactical errors (strictly speaking, this is primarily because of the transition away from HTML Tidy, but the page is still maintained even though the transition has already occurred). Jc86035 (talk) 15:18, 14 December 2019 (UTC)

Could you clarify what you refer to by "VE"? Does this encompass the source editing mode (i.e. the 2017 wikitext editor) as well or just the WYSIWYG portion?

Given consensus that wikitext is primary and consensus against 2017editor, I expect no one will be interested whether wikitext-inside-VE does or does not fall within a wikilawyer definition of "VE". The result is the same regardless.

Regarding syntax, what I wrote would have been misnested if I were writing HTML. But I wasn't. I was writing wikitext. Wikitext does not require it to be nested. Therefore it was not misnested.

The point of wikitext is that editors aren't expected to have any HTML programming training. Wikitext must be more accepting and more intuitive. Wikitext resembles and copies some things from HTML, but anyone who attempts to force "HTML-correctness" on wikitext is sabotaging new users. Alsee (talk) 13:45, 15 December 2019 (UTC)

The result is the same regardless.

Is it necessarily possible to apply the 2017WTE consensus here? That consensus was for the use of the editor in article space, where the considerations and applications for the software are substantially different to the ones for this project. It is not very likely that FA-length replies are going to be written regularly, and new users would presumably be less likely to run into issues with loading time and such. Other users have noted that the editor has improved since then.

Additionally, the editor within Structured Discussions (the one we have been using on this page) is actually a separate editor to both modes of Extension:VisualEditor (per Editor). Considering that the editors have clearly diverged in some ways despite both being based on Parsoid, I think it is important to make the distinction. It is not clear to me whether the Editing team would use either editor's code.

That said, I personally would want there to be an option to use a ‎<textarea>-based version of this editor, primarily because some users may not want to or may be unable to use JS/VE, but may still want the ability to reply inline. Presumably, this would mean leaving the prototype's edit box in the software in some form. However, this could come with disadvantages; e.g. the team would be forced to maintain two largely redundant versions of a number of things (e.g. previewing, formatting toolbar).

Wikitext does not require it to be nested.

Citation needed? I think this is somewhat of an apples-to-oranges comparison, because HTML has a formal specification (by design) and wikitext doesn't (probably not by design). Additionally, wikitext is first rendered server-side (and so displays largely the same for all end users), whereas HTML isn't (and so browsers differ in what HTML they are willing to render and/or how they render it). I think it would be more helpful to refer to something more specific than "requiring" something, because what this means in relation to the two formats is not really the same, and this reduces the meaningfulness of the verb in this context.

HTML's formal specification does not prevent website owners from serving invalid or incorrect HTML. Obviously, making the XML structure incorrect will cause most browsers to throw an error, and in that specific case wikitext is somewhat more lenient because the parser needs to fix misnesting so that the generated HTML doesn't contain XML errors. Nevertheless, I would be wary of interpreting this as an open invitation to let users misnest wikitext wherever they want. There isn't really any evidence that the intention of this particular feature (that is, the parser's fixing of misnesting) is for wikitext to be "more accepting and more intuitive", even if wikitext is "designed to be easier to use and learn than HTML", because it seems to primarily serve a much more pragmatic function (that is, to allow browsers to render the generated HTML at all).

On the other hand, both MediaWiki and web browsers allow authors to use deprecated tags and introduce all sorts of semantic errors (e.g. block inside inline) and whatnot. In this case, the MediaWiki parser typically just doesn't do anything, and the errors end up in the generated HTML as well. This category is what I was mainly referring to by "routinely use incorrect syntax" (e.g. misuse of list items).

Within the set of wikitext errors that the parser attempts to fix, there is the set of errors that the parser does not fix "correctly". As such, I think it wouldn't be acceptable to expect users to rely on the parser to fix errors.

From this, I think both of these approaches could logically follow:

1. A wikitext editor should highlight and attempt to suggest fixes for (or autofix) all errors that the parser would attempt to fix. This would tell the user that something is wrong with their code, whereas the rendered HTML might not communicate that.
2. A wikitext editor should not attempt to suggest fixes for (or autofix) any errors, even if it highlights detected errors. Doing so would encourage the user to rely on the software, even though its fixes might not be correct.

Obviously, the second approach is much easier to implement, even if users could benefit from the first. In practice, the Structured Discussions source mode is the only source code editor that doesn't use the second approach. (2017WTE also seems to use the second approach; upon limited testing it appears that it doesn't actually do any autofixing, or at least the SD editor is a lot more aggressive with wikitext.)

The SD editor also doesn't really use the first approach; it makes some unnecessary fixes like removing spaces after bullet points. I think this might be a design limitation rather than something intentional; both editors include the spaces if the bullet points are created in visual mode, but SD will confusingly proceed to remove the spaces if you switch modes or save the comment even though the editor introduced them in the first place. Given that 2017WTE does not seem to use the same approach (as far as I'm aware), I don't think it would be appropriate to assume that the new inline editor would also be problematic in this way; if another attempt is made to follow the first approach, I would hope that it doesn't have the issues that the SD editor's implementation has.

----This leaves some questions that remain to be answered:

• Will the textarea editor remain in the software, or will it be replaced? Is it too soon to say?
• How much code/features will the new WYSIWYG editor draw from (a) the VisualEditor extension and (b) the Structured Discussions extension?
• If the new WYSIWYG editor has a "source mode" like VisualEditor, will that source mode take any particular approach towards syntax highlighting, error highlighting, error autofixing, or similar?

@PPelberg (WMF), would the team be able to answer any of those questions at this point in time? Jc86035 (talk) 03:11, 16 December 2019 (UTC)

Thank you for these clear questions, @Jc86035 – I'm working on gathering answers here.

Also, I appreciate how you acknowledged how definitive answers about implementation questions get harder to provide, the further into the future we are talking about.

PPelberg (WMF) (talk) 18:49, 18 December 2019 (UTC)

Okay, I've added some responses below.

===Will the textarea editor remain in the software, or will it be replaced? Is it too soon to say?===

It's too soon to say for certain. With this said, we have talked about, and explored, using the 2017 wikitext editor as the editing interface for the wikitext text input mode in the future. Although, we have not made any decisions about this yet and before doing so, we would need to, at a minimum, talk about it on-wiki and conduct user testing. And by "explored" I mean we have started documenting and investigating issues with the 2017Wikitext Editor with the intention of figuring out whether it is a tool we could all rely on in the future.

Note: I started to type out a fresh response to this question, then I thought, "I think it's okay to copy over what was written here: Talk:Talk pages project/2019#h-Please_don't_let_Visual_Editor_endanger_this_project.-2019-11-24T10:50:00.000Z."

===How much code/features will the new WYSIWYG editor draw from (a) the VisualEditor extension and (b) the Structured Discussions extension?===

Our current plan is to use VE as the basis for the WYSIWG editor we are planning to release as part of version 2.0.

===If the new WYSIWYG editor has a "source mode" like VisualEditor, will that source mode take any particular approach towards syntax highlighting, error highlighting, error autofixing, or similar?===

Good question. We have not yet formed an opinion about whether things like, "syntax highlighting, error highlighting and error autofixing" would be included in a future version of the "source mode."

Our current approach to providing contributors with feedback they can use to identify "errors of execution and intention" (which it seems like the tactics talked about here are related to) is to show contributors a real-time preview of the comment they are composing (see: T238177).

It seems like you've thought about this topic quite a bit, so if there is anything beyond what you've mentioned above (e.g. the two different approaches), we'd be keen to hear it.

On the topic of previews, what's currently on the prototype is our initial approach. We are very much still gathering feedback on it: Talk:Talk pages project/Replying/2019#h-Previewing_a_reply-2019-12-05T19:48:00.000Z.

...please let me know if anything about the above could be made more clear or if any new questions come to mind. PPelberg (WMF) (talk) 01:56, 20 December 2019 (UTC)

The wikitext parser actively transforms a variety of non-nested constructs into nested-HTML. It is implausible to suggest that the pattern of non-nested language behavior is accidental.

Regardless of original intent, one of our top priorities is to design for and accommodate users with zero programming or HTML knowledge. They don't know what syntax is, don't know what nesting is, don't know what DOM scopes are, and it would be harmful to expose them to those issues. It is important that wikitext work in an intuitive way insofar as we can. If someone types a non-nested <small>^{(Note: see xyz)</small>} we don't want to bother them with nesting. It is visible and intuitive that small and sup were opened, it is visible and intuitive that small and sup were closed. It's a good thing that the wikitext parser does not expect nested syntax. Another example, if someone writes:

<b>Bold list heading

* My first list item is still bold</b>

* The rest of my list is not bold

Again, we don't expect the user to know anything about HTML. We don't expect them to know that the * is converted into HTML list tags. They have no idea anything is nested at all. They don't want to know anything is nested. Non-programmers will parse it in more of a string-matching approach. The <b> string turns on bolding, and the </b> string turns off bolding. Everything in between is bold. Easy peasy. It is a good thing that the parser does not expect or implement nested syntax there.

The non-nested syntax is the clearly superior definition for the language. I know why the programmers prefer nesting. But we're a wiki, the users come first. We pay the programmers build what the users need, even if some aspects of the language design are less convenient for the programmers. Breaking that aspect of the language, for a purely internal programming agenda, would be harmful. Alsee (talk) 15:53, 17 December 2019 (UTC)

Regardless of original intent, one of our top priorities is to design for and accommodate users with zero programming or HTML knowledge.

Even if it works (well, outside the version of Parsoid that Structured Discussions uses, anyway), is it necessarily superior? The current implementation can break as soon as background styling, padding, margins or borders are involved (including e.g. ‎<pre>), and in some cases it's impossible to represent that well in HTML. Encouraging the use of misnested HTML – as opposed to encouraging users to fix it – would mislead users into thinking that it's always appropriate and will always work. Are there any use cases where intentionally keeping the misnested tags would actually be better than nesting them correctly?

That said, in practice a lot of "misnested" tags (that is, the ones shown in Special:LintErrors) seem to come from the non-misnested use of block-level elements inside inline elements, which Remex doesn't like (it splits up the inline element so that it's inside all the block elements). VE-Parsoid actually differs here, because it doesn't seem to care about the block/inline distinction (or at least the preview function of 2017WTE doesn't), whereas Remex and SD-Parsoid do. Jc86035 (talk) 02:12, 18 December 2019 (UTC)

I don't understand why it seems to be so difficult to communicate this concept.

Let's imagine there are two wikis. Wikiwiki and HTMLwiki.

On Wikiwiki a new user sees various kinds of markup, with the simple concept that everything between tag-pairs is affected by that pair. Something like <small> means "turn on small style" and </small> means "turn off small style". The language deliberately does not care about nesting, insofar as possible. The language aims for "things do what they look like they do".

On HTMLwiki people either need to already have training in HTML and programming concepts, nesting and DOM scopes, or they are effectively forced to learn it. I'm a programmer, I understand stuff like nesting, but not everyone is mentally-built to think like a programmer. Let's look at a specific and grotesque example:

On Wikiwiki, everything between a tag pair is affected by that pair. Easy peasy.

On HTMLwiki sometimes the end tag is mysteriously ignored, spilling the markup down the entire page. A user points to several pages with different scenarios where this happens.[2][3] Two simplified real world example cases are basically as follows:

 ::::<small>comment1

::::</small>comment2
The rest of the page, several entire sections, are all in small font.

and

<s>::::first line

 ::::last line</s>

The rest of the page, several entire sections, are all in strikethrough.

Those examples will confuse the hell out of new users. Those examples will confuse the hell out of experienced editors. Those examples will probably confuse the hell out of even a mediawiki developer, until they go digging and figure out what the heck is going on. Everything works fine up to three indentation, but at four-or-more indentation those pages break.

The user reporting the issue points out that everything used to work fine, there's nothing visibly wrong on either of the pages, the tags are balanced, and asks why is the pages are suddenly broken? The answer is, and I quote:

This behavior appears to be the result of the HTML5 "adoption agency algorithm", implemented by Remex:

https://www.w3.org/TR/html5/syntax.html#adoption-agency-algorithm (large page).

Specifically, this part:

If outer loop counter is greater than or equal to eight, then abort these steps.

Four colons :::: generate eight tags <dl><dd><dl><dd><dl><dd><dl><dd>.

No one but a programmer can understand the link supplied in that explanation, no one but a programmer can realistically follow the explanation for why the close-tag didn't work. And even an HTML expert would be hard pressed to provide an understandable explanation for why it was changed to do that. Everything used to work fine, but now four-or-more indentation sometimes breaks the page. It was broken in pursuit of a purely internal agenda. I hope anyone can understand that this kind of wiki-behavior will only confuse and drive away users, and this kind of rationale will only confuse and drive away users. The point of a wiki, the point of wikitext, is to be understandable and usable by average people who don't want to learn strange and obscure HTML rules. The point of wikitext is to NOT be HTML. Alsee (talk) 13:57, 18 December 2019 (UTC)

Thank you for mentioning those specific examples here. I had no idea that this was part of the problem you were talking about. (At this point, this isn't really directly related to the original subject of this thread, so apologies if I've ended up sidetracking this discussion.)

Considering that the earlier Phabricator task was declined and the later one was merged into it, the clearest options to me would be to either increase (or remove) the limit, or do nothing. Changing the behaviour now would have the side effect of potentially breaking wikitext that has been written since the RemexHtml transition, would take RemexHtml out of compliance with the HTML5 standard, and would require more effort on the part of the developers than doing nothing. I think I would agree that the algorithm (as specified) doesn't really seem suited to the specific task of fixing wikitext misnesting, mainly because of the unusually low numerical limits, but there are still good reasons to keep Remex as it is. (I also don't know how easy it would be to get a +2 on such a change, since Remex was most likely stabilized a while ago.)

If there isn't anything to be done, there isn't much of a point in discussing this particular part of the issue here. If you think there's a case for reopening phab:T199057, then... well, this isn't really the place either.

On Wikiwiki, everything between a tag pair is affected by that pair.

Obviously this is supposed to be a comparison between parser.php+Tidy and parser.php+Remex, so I think it would be best not to oversimplify and claim that Tidy was able to do this perfectly.

For Tidy (as well as Remex, in most of these cases), the claim that misnested markup will always work isn't true for many combinations of misnested tag pairs (notably those involving pre, nowiki, ref, noinclude, includeonly, onlyinclude, and some extension tags), isn't true for many misnested combinations involving wikimarkup (particularly combinations of wikimarkup and XML), and generally isn't true for misnested combinations involving templates or magic words. (Tidy also breaks certain combinations of XML with wikimarkup even with correct nesting.) It follows: this behaviour was already somewhat inconsistent to begin with, so is it necessary to keep the behaviour precisely as inconsistent as it used to be?

(Incidentally, I couldn't find any wikis with Tidy still enabled, so I couldn't actually test these. I'm fairly confident in this being accurate, but it would be nice if these things could be tested without having to bother with installing MediaWiki locally.)

It was broken in pursuit of a purely internal agenda.

My understanding of the situation is that HTML4 Tidy had to be replaced anyway because it was no longer maintained, and this particular issue came up because Remex (which was written specifically as a Tidy replacement) exactly follows the parsing algorithm in the HTML5 specification, which can be somewhat problematic for the reasons you've mentioned.

It's definitely clear that there is a strong internal developmental agenda – that is, aiming at replacing the current wikitext parser with Parsoid – but there seem to be clear benefits from transitioning to Parsoid, although I think it would be fair to state that most experienced contributors wouldn't directly benefit much from the change. I don't think the existence of an agenda in itself is particularly problematic, although I haven't really followed discussions on Parsoid closely.

The point of a wiki, the point of wikitext, is to be understandable and usable by average people who don't want to learn strange and obscure HTML rules.

I don't think it has really succeeded in doing that, even if it's better than HTML. Even aside from the difficulty of learning all of the markup, wikitext still has its own idiosyncrasies, such as the impossibility of nesting ‎<ref> tags without using a parser function. Obviously, the development of VE is primarily a consequence of the perception that wikitext was not sufficiently accessible.

----

As for what Parsoid actually means for this project, I think the situation may be clearer once the team posts answers to the questions I asked in my second-last comment.

If it were up to me, I might not go as far as to automatically mess with the input to the source editor; extending the linter or adding tracking categories would probably be better for handling markup errors (and might encourage users to fix the errors in the first place). I think following the 2017WTE behaviour would make a lot more sense than following the SD behaviour, but at this early stage both could still be possible.

It's also been suggested to "armour" comments so that unbalanced markup doesn't spill into the rest of the page, which could be possible with a magic word that forces each comment to be parsed separately. Jc86035 (talk) 00:53, 19 December 2019 (UTC)

The 'problem I am talking about' is that the Foundation has been making user-hostile changes to wikitext, and they plan to continue making user-hostile changes. (If "user hostile" is objectionable, you can read it as "less user friendly".)

I very carefully read and re-read your post trying to Identify what arguments you were presenting. It looks like you start with superficial reasons, leading up to what appears to be the main argument. This is what I came up with:

• You do not appear to dispute that these changes make the wiki less user-friendly.
• You cite that the original wikitext was not "able to do this perfectly". I hope we can agree that doesn't support making the imperfect-thing worse.
• You argue "Changing the behaviour now would have the side effect of potentially breaking wikitext that has been written". The Foundation has broken millions of pages, and plans to break millions more. Your argument doesn't support what they're doing, it argues against it.
• You argue Tidy had to be replaced because it was no longer maintained. That is a circular argument. They deprecated Tidy as a result of their strategy to redefine wikitext.
• The remainder of your post presents what appears to be the actual argument. You don't quite say it this way.... but it appears you're arguing that we should make wikitext worse because you think people should use Visual Editor instead. It reminds me of something a staff member wrote in an Office Hours meeting about Visual Editor, discussing Visual Editor's abysmal acceptance figures:[4]

[15:06:32] <James_F> So, as you can see, adoption isn't as high as we'd want and we're looking to make VisualEditor better so that more people choose to use it over wikitext.

[15:06:52] <James_F> (The alternative of course would be to make wikitext worse, but that wouldn't be very ethical. ;-)) Alsee (talk) 11:02, 19 December 2019 (UTC)

Cancelling a reply

I see that in the current prototype, when you have an editor open, all other reply buttons become grey and disabled. While I understand the technical reason for this (avoiding self edit conflict), perhaps an idea, is to have the grayed out links behave as a cancel as well. When you click them, have the UI go "To reply here, you have to cancel and reply you started elsewhere on this page but have not yet finished." Take me there-button, cancel other changes-button. —TheDJ (Not WMF) (talk • contribs) 16:51, 10 December 2019 (UTC)

@TheDJ, thank you for taking a look at the prototype and great spot RE the disabled reply links.

Question: what did you think when you saw the disabled reply links? Was it something curious you noticed? Were they confusing? Something else?

In the meantime, some context about why reply links are disabled and what we have planned to improve the experience...

Why are reply links currently disabled when a text input is open?

The current version of the prototype does not have auto-save implemented.

This means, if a contributor was to:

1. Compose a reply in "Text input A"
2. Compose a reply in "Text input B"
3. Post the reply they drafted in "Text input B"
4. The comment they composed in "Text input A" would be discarded

In the time between now and when auto-saving is implemented, reply links are disabled when one text input is open so as to avoid a situation where a contributor's unposted draft(s) are unintentionally discarded.

What do we have planned to improve the experience?

In time, we plan to have a more robust auto-save implemented (see: See: T240257#5729386) which will enable contributors to compose multiple comments in parallel and eliminate the need for reply links being disabled.

cc @Iamjessklein

PPelberg (WMF) (talk) 02:19, 12 December 2019 (UTC)

> what did you think when you saw the disabled reply links?

I figured: "i guess i can't use this right now. Maybe i have one open already... BUT WHERE on this huge page. scroll, scroll, scroll" —TheDJ (Not WMF) (talk • contribs) 08:49, 12 December 2019 (UTC)

Thank you for clarifying this. Would you say the below [1] accurately describes what you encountered?

Context for my question: I'm trying to figure out whether what we're talking about in this thread is deserving of a separate ticket or whether the below adequately captures it.

---

1. "In long threads the reply textbox is a long way from the comment it is replying to (and the “Reply” button)...how should we handle/display the page when a lot of text means that there is a big gap between the original comment to which someone is attempting to reply, and the place where the reply will go? Where should the affordance for replying go? At the end of the original comment or the place where the reply will end up?" Source: T235923 PPelberg (WMF) (talk) 01:42, 19 December 2019 (UTC)

Question: what did you think when you saw the disabled reply links?

I was surprised. It's unusual, eg. on reddit you can edit multiple answers, however I find that confusing (sometimes I forget how many replies I started...), so it's better to edit only one reply.

Actually I was most surprised, when I scrolled away and forgot where I clicked reply... had to scroll through the page to find it :D

An improvement that I suggest is to keep the editbox (it's parent div.oo-ui-inputWidget) on-screen, when it is scrolled out of the viewport with css position:fixed; bottom:0; (on bottom) or position:fixed; top:0; (on top), and add a button that scrolls the edited reply back to the center of the screen. —Aron Man.🍂 edits🌾 06:13, 12 December 2019 (UTC)

Thank you for adding your thoughts in here. Now to the approach you proposed:

...keep the edit box...on-screen, when it is scrolled out of the viewport...

This seems like it could be an effective way of making sure the text input is easily accessible regardless of where "you" are on the page.

Do you think this question is an adequate way of representing the issue? PPelberg (WMF) (talk) 01:47, 19 December 2019 (UTC)

"Do you think this question is an adequate way of representing the issue?"

I think this approach of keeping the edit box onscreen solves both problems, therefore it would be one task to implement it. However the two reports describe two different paths to get to a similar, confusing situation:

1. Replying to a comment that has too many replies (ca. 10 replies usually don't fit on the screen)
2. Replying to a comment and scrolling away at least one screen, while editing.

I think these use-cases should be investigated separately: the circumstances are somewhat different and it's possible the solution to each will differ in details. In case 1) I imagine clicking "reply" could automatically start moderate-paced scrolling to the end of the thread, where the new comment will be edited. In case 2) the user clicking a "return to edited comment" button would do the same.

Tl;dr: I think there is one solution to two related, but different problems. To properly address both, I think the two questions should be kept separate, while clarifying that a common solution will be implemented. —Aron Man.🍂 edits🌾 21:43, 19 December 2019 (UTC)

Thank you for clarifying! I think I've represented the scenario you are highlighting in Phabricator [1]. Although, please tell me if this is not the case.

---

1. https://phabricator.wikimedia.org/T235923#5761782 PPelberg (WMF) (talk) 00:05, 24 December 2019 (UTC)

Exactly! Thank you. —Aron Man.🍂 edits🌾 01:34, 24 December 2019 (UTC)

We created a new ticket where we will think about this issue among others related to it: https://phabricator.wikimedia.org/T254208 PPelberg (WMF) (talk) 00:51, 2 June 2020 (UTC)

On the one hand, it's probably good to make people focus. It can be helpful to finish the first thought before starting the second reply.

On the other hand, when I'm reading a l-o-n-g diff on an active page, I can open multiple sections in different tabs, so I can reply to all the things in turn, without needing to lose my place in the diff. I can't use the quick reply tool to do that, because it doesn't open in a tab. Whatamidoing (WMF) (talk) 04:46, 13 December 2019 (UTC)

This is a good use case to mention. It's documented in Phabricator here for our team to consider addressing in a future iteration: T235923#5761825. PPelberg (WMF) (talk) 01:00, 24 December 2019 (UTC)

Usability test: Version 1.0 prototype

The issues that have surfaced in this thread can be found in Phabricator here:

• T241388: When inserting {{welcome}} reply preview is different to saved content
• T241391: Unable to respond to specific comments
• T241393: Abandon changes dialog appears unexpectedly
• T241396: Unable to publish changes to an outdated beta.wmflabs.org talk page
• T241193: Replies with <gallery>...</gallery> tags do not render in preview properly
• T239861: Bug: Not able to post comment on beta
• T242466: Why does posting a new comment delete </span> from a previous one?

===Usability test overview===

The team has an early prototype that is ready for testing: https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats

In an effort to identify opportunities for improvement, the team has developed a usability test we would value you participating in: Version 1.0 prototype test

If you would like to participate, the details of the test can be found here: Usability test instructions

While we would like to reserve this thread for people participating in the "Version 1.0 prototype test" to share their experiences, please continue to use other threads on this page to share your feedback as @TheDJ, @Aron Manning, and @Jc86035 have been doing.

===Feedback questions===

After completing the test, please share your answers to the questions below (source) as replies to this post.

1. Do you think that you completed the Task above correctly?
2. Was there anything painful or not obvious about this experience?
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
4. What other additional comments, concerns, or ideas would you like to make known?
5. How do you typically use talk pages (across namespaces)?
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?

Note: The team will be monitoring this thread going forward and will begin responding to comments on Wednesday, 18-Dec. PPelberg (WMF) (talk) 02:02, 14 December 2019 (UTC)

I was asked to test this tool a while back by @Whatamidoing (WMF): a while ago. I have been unable to submit anything through the tool because of an

Error contacting the Parsoid/RESTBase server (HTTP 500)

I will however state that a problem that I've observed before is still there: not closing wikitext will transfer the formatting over to the signature. I have not tried working with indentation on this tool.

I am using a similar tool, Enterprisey's reply-link.js on Wikipedia, which not only does previews (albeit not live), but can also close edit requests while replying. One downside the tool I use has is that it does not always work well with excessively long discussion pages. If this tool gets past that I think it might be a good contender against reply-link.js. Tenryuu (talk) 15:57, 13 April 2020 (UTC)

I've got the same (HTTP 500) error, so I was unable to finish the tasks in the test.

I have some comments about the usability of the form:

- First, I love the concept, we've been waiting it for years, and the current design seems simple and functional. Well done.

- I'm uncertain about the placement for the "Reply" link after the date. It's OK that it's the last thing in the paragraph, but it seems too separate from the name of the user you're replying to. I think it would help if the link had a tooltip that stated "Reply to [username]", to reinforce what comment are you replying to.

- Most important:

I'm a seasoned Wikipedia user who understands the indent rules for talk pages, and yet I got surprised at the placement of the reply box. When replying to comment "This contribution is not indented ... --Honischboy (talk) 20:25, 8 April 2020 (UTC)", the input interface is opened at the bottom of the section. Even though I understand the placement rules for comments in Wikipedia Talk pages, my gut reaction was to expect the input box right where the "Reply" link is placed. This is exacerbated in the "New section" below the page, where replying to "signed edit 105.187.36.38 (talk) 06:08, 21 January 2020 (UTC)" makes the previous comment dissapear because of the long scroll down.

The interface really needs some visual reinforcement for explaining why the reply is placed so far away. I have two alternatives that I think would work for this:

a) After opening the reply text box, put a black line on the left margin of the "<dl>" tag which contains all the previous replies to the same comment. This would visually connect the new comment and the comment you're replying to. (I have my regular Wikipedia CSS template at talk pages set to this style, and works great for following indentation).

b) Do the same before opening the box, e.g. show a black left margin when hovering over the Reply link. Then, open the reply box right below the original comment (so that it won't jump and you can still read the original comment you're replying to), and meanwhile show a placeholder box at the end of the line, where the comment will be placed by indent rules when you press the final Reply button.

Opiton b) would be my preferred solution, as it reduces surprise when opening the intrface and lets you see the contex. Diego Moya (talk) 16:50, 13 April 2020 (UTC)

Is your black line meant to do something similar to the blue lines that the French Wikipedia uses (see https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion for an example)? Whatamidoing (WMF) (talk) 19:40, 13 April 2020 (UTC)

Yes, but only the left margin, not the bands of alternate colors in French Wikipedia. The resulting style is much more lightweight, but still shows indentation quite clearly.

Diego Moya (talk) 12:00, 14 April 2020 (UTC)

Found another bug: When you start a reply and you turn out to not be logged in, it will tell you so, which is good. If you then login via another tab, so as not to disrupt your message-in-progress, when you come back and do anything in the editing field, it knows you've logged in and will change the IP address in the sig to your username. However, when you try to save the message, it will not let you, giving a farcical error of "You are no longer logged out, so the action could not be completed." So, something about the login-detection routines is incomplete.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:14, 18 April 2020 (UTC)

Other issues: Just from skimming the page, I can see two major problems:

1. Syntax is being misparsed, such that tables in comments are breaking.
2. Syntax is probably being miswritten, if not misparsed, such that after a while new threads are indented to the right and should not be (it's probably due to an unclosed element in a previous post). Using modern markup (e.g. turning every comment into a div or an "article" in the HTML 5 sense) would probably help ameliorate this; even if it doesn't trigger browsers into re-parsing properly, it should allow the MW parser, with a minimal upgrade, to detect and fix such issues on-the-fly.

That said, the main disappointment to me is that this opportunity is not (yet?) being taken to undo the terrible mistake made in WP's early days, of abusing list markup for comment indentation and bulleting. Both : (the dd element, which auto-generates an invalid dl element lacking a dt), and * (an li that auto-generates a ul) wikimarkup a the start of a new line (and when not wrapped in "don't parse this" markup like ‎<nowiki> and ‎<pre>) need to be re-parsed on the fly – on talk pages, not in articles – into divs that use CSS to do visual indentation or apply visual, non-list bullets, instead of manufacturing invalid, mangled list markup. A Phab ticket has been open about this problem for over a decade (ported over from the pre-Phabricator ticket tracker), and the main MW devs are obviously never going to do anything about it, so it's up to the community to fix it with better tools than they will provide us.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:23, 18 April 2020 (UTC)

This is a side effect of communities not wanting Flow and having chosen small incremental steps based on wiki text. When you build something on quicksand, you should not expect it to be able to turn into flat concrete any time soon.

Can’t have cake and eat it.

also, please provide diffs. —TheDJ (Not WMF) (talk • contribs) 11:45, 19 April 2020 (UTC)

Diffs of what? The page is short, and if you want to look at the table breakage and page indentation breakage, it's right there in the page; rather hard to miss. I didn't do any edits that resulted in either problem, and have not dug through others' comments to try to identify exactly which edits resulted in the errors.

Anyway, I get what you are saying about incremental changes, but at some point this issue (of abusing list markup and making mangled lists) has to be addressed in an actual increment, instead of the buck being passed forever. Maybe now isn't the time to take that step, but it needs to happen eventually, so I will bring it up at every appropriate opportunity of a step being taken to see if it can be that step.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:23, 20 April 2020 (UTC)

I experimented on the page before trying to follow the instructions. The breakage was so severe that it became difficult to follow through on the test instructions.

The first thing I tested and found was that posting a comment can corrupt existing content on the page. It appears the content is being round-tripped through Parsoid.

Next I found that the preview is inaccurate. A template rendered with different indentation in preview than it did when the comment was saved. I suspect that indentation markup isn't being actually being generated and integrated as part of the comment-content, and trying to fake it can't handle the general case correctly.

I posted assorted test-content... I'm not sure what part was responsible but it became impossible to reply to certain comments. The reply button would work and I could type a reply and I could click save, but replies to those particular comments would not actually save. I was able to reply elsewhere.

The instructions asked me to fix my comment. I don't know if that was supposed to be done via the new interface - I didn't notice any way to do so. Therefore I tried editing the page as normal. The 2017editor came up, but it would not allow me to edit. I tried multiple times and different parts of the page. The 2017editor was broken and just wouldn't let me type or change anything on the page. All menu items to the left of 'help' were grayed out and non-functioning. I had to edit the URL to force the wikitext editor to load. The real wikitext editor worked fine, and I was able to 'fix' my comment.

Cancelling worked, and page history worked fine. Alsee (talk) 15:29, 15 December 2019 (UTC)

Thank you for trying the prototype, @Alsee. A few clarifying questions:

posting a comment can corrupt existing content on the page

This is unexpected. Do you recall if this is the comment that caused said corruption? Also, what kind of corruption did you experience?

...I found that the preview is inaccurate. A template rendered with different indentation in preview than it did when the comment was saved.

Are you able to share the contents of the comment you posted that led to the preview differing from what ended up being saved to the page? If you're able to track down a link to the diff itself, that would be even better.

The reply button would work and I could type a reply and I could click save, but replies to those particular comments would not actually save. I was able to reply elsewhere.

Hmm. Are the comments you were not able to reply to, comments 10.0.3.1 16:30, 10 December 2019 and 192.168.122.1 02:50, 12 December 2019? If so, it seems I'm experiencing the same behavior you are reporting [1].

Therefore I tried editing the page as normal. The 2017editor came up, but it would not allow me to edit. I tried multiple times and different parts of the page. The 2017editor was broken and just wouldn't let me type or change anything on the page

Interesting – do you remember what steps you took that led to the 2017editor appearing?

---

1. Actual behavior:

i) Click "Reply"

ii) Compose reply in text input

iii) Type command + enter

iv) Loading animation is overlaid atop text input + draft reply

v) Text input disappears

vi) Highlight appears atop talk page

⚠️ vii) Reply has not been posted to talk page PPelberg (WMF) (talk) 00:54, 19 December 2019 (UTC)

@PPelberg (WMF) the diff you linked was indeed an example of corruption. Specifically:

• The (first) comment of 14:10, 15 December 2019. Contains the word red, in red style. The red style ends before the signature. Note: The wikitext used is a deliberate test case - if various corruption issues exist, that particular test case generally reveals it in a most dramatic fashion.
• The next edit, during the same minute worked normally. I would guess it didn't affect the first edit because it replies in a different section.
• The edit of 14:13, 15 December 2019 deleted the </span> from the first edit in the sequence, resulting in the red-styling spilling down to the end of the section.

The inaccurate preview edit contains a random assortment of test content. The welcome template previews as indented, but the saved version is not indented. I am just guessing, but something in that comment might be the cause of the inability to reply to the comments of 16:30, 10 December 2019 and 02:50, 12 December 2019.

I don't think I did anything special to get the 2017editor. All I recall is clicking the full page edit button.

I just did a bit more testing and I just ran into a new issue. I saved a comment. I do *not* have any reply-box open. All reply links are blue. However when I try to leave the page I get the warning popup Changes you made may not be saved. Leave/Cancel. It seems that the page thinks I still have a reply-box open. I don't know why. I now select leave option, so I can continue with my next test.

I just tried the full page edit button again. It's still giving me the 2017editor. I still can't edit the page.

I just went to the first version of the page, to get away from the test content that I added to the page. I clicked edit. I am still getting the 2017editor. I still cant edit. It appears that the 2017editor issue is unrelated to any of my test content, as my test-content is not present on the page.

P.S. You said content corruption was unexpected. I did expect it. In my post to you on November 28 I asked:

Is it going to use VE's parser, parsoid, for saving as indicated in Phab task T238218?

That phab task says "Our current approach for saving wikitext replies via Parsoid". Running the wikitext through Parsoid was the source of corruption in Flow. The fix is to not send the content through Parsoid. The page is a text string, the new comment (with indentation and signature) is a another text string, just insert one string into the other without looping through Parsoid. Alsee (talk) 03:22, 19 December 2019 (UTC)

These links and added details are helpful – thank you, @Alsee. Comments below...

...diff you linked was indeed an example of corruption.

It seems like the markup "spilling" we're seeing here is related to, if not caused by, the issue raised here ("If outer loop counter is greater than or equal to eight, then abort these steps.").

With this said, Edit 3 in the corruption-causing-sequence seems to have been made using full page editing rather than the prototype...do you recall what steps you took that might have caused the `</span>` tag to be deleted, and as a result, the red text styling to be applied to the rest of the section?

(I ask the above in an effort to figure out how we ought to categorize this issue)

The inaccurate preview edit contains a random assortment of test content. The welcome template previews as indented, but the saved version is not indented.

Good spot. Here is the Phabricator task we will use to investigate this issue: T241388

...something in that comment might be the cause of the inability to reply to the comments of 16:30, 10 December 2019 and 02:50, 12 December 2019.

This is curious. Here is the Phabricator task we will use to investigate this issue: T241391

I don't think I did anything special to get the 2017editor. All I recall is clicking the full page edit button.

Thank you for the details here. I'm seeing the 2017 wikitext editor after clicking the full page edit button as well. We're investigating why the beta wiki is configured to have this editor as the primary wikitext editor.

...ran into a new issue. I saved a comment. I do *not* have any reply-box open. All reply links are blue. However when I try to leave the page I get the warning popup Changes you made may not be saved. Leave/Cancel. It seems that the page thinks I still have a reply-box open.

We've been able to reproduce this issue. Here is the Phabricator task we will use to investigate this issue: T241393

I just tried the full page edit button again. It's still giving me the 2017editor. I still can't edit the page.

Are you able to successfully save an edit to the current version of the talk page when using full page editing?

...I wonder if the issue you encountered (not being able to edit a previous version of the talk page) has  to do with how the Beta Cluster is configured.

Either way, here is a task to make sure this issue is documented, regardless of its relationship to the replying prototype: T241396 PPelberg (WMF) (talk) 20:08, 24 December 2019 (UTC)

It seems like the markup "spilling" we're seeing here is related to, if not caused by, the issue raised here

Not related.

The issue raised in that link is that the Foundation changed the parser so that it would incomprehensibly ignore existing markup in some circumstances. The markup spills, but page source is unchanged.

The issue here is that the prototype deleted </span> from an old comment while it was adding a new one.

Edit 3 in the corruption-causing-sequence seems to have been made using full page editing rather than the prototype.

Nope. I definitely used the prototype. I just tested it again with the same result. All of these replies were made with the prototype:

• Reply-1: I posted "Red test", with only the word "red" is in red. It does not spill past the word red.
• Reply-2: I replied elsewhere in the same section. That worked fine, no unusual effects.
• Reply-3: Posted as a reply to Reply-1. This did cause a side effect, corrupting the existing content of Reply-1. It deleted the </span>, as happened before.
• I returned to an older version of the page, so that Reply-1 was undamaged. Reply-4: Posted as a reply to the parent of Reply-1. This reply also corrupted Reply-1.

I've left the page with several comments with the word "red" in red. Assuming they don't all get mucked up by someone else, you can try replying to them.

Are you able to successfully save an edit to the current version of the talk page

The 2017editor still won't let me edit. I can only edit if I manually modify the URL to get the normal wikitext editor. Alsee (talk) 08:52, 31 December 2019 (UTC)

Thanks for your patience here, @Alsee – some more information and two follow up questions below...

Nope. I definitely used the prototype. I just tested it again with the same result. All of these replies were made with the prototype:

Ok, we see what's happening here now. Thank you for elaborating on this. We were able to reproduce the corruption you initially described.

This is a case where the Parsoid is unexpectedly changing existing wikitext that's been written to the page.

Two resulting questions:

1. In what situations have you found yourself using this wikitext on talk pages?
2. Are you able to share links to the talk pages where you/others are using this syntax?

In the meantime, it seems like the following syntax constructions would have the same output as the problematic string and be Parsoid-compatible:

a) {{#if:x|<span style="color:red; font-weight: bold">|<span style="font-weight: bold">}}red</span> test.

b) <span style="{{#if:x|color:red;|}} font-weight: bold">red</span></nowiki> test.

While the alternative syntax above may work when posting new comments to a talk page, we appreciate there could be instances where this syntax already exists on some talk pages. In which case, using the new replying workflow, as it's currently implemented, could negatively affect those pages.

Like mentioned above, if you're able to share links to where this syntax is being used, we can reassess whether the new reply tool's incompatibility with this specific string is something we need to prioritize fixing.

In summary, considering there is Parsoid-compatible syntax that achieves the same output as the problematic string and we have yet to find examples where this string is being used in practice, this is not an issue we plan to prioritize fixing at this time. But again, we are keen to see examples where this kind of syntax is used so we can potentially change the priority.

More meta: we appreciate you raising this concern and would value you continuing to share examples of unexpected behavior with links to where you see them occurring. PPelberg (WMF) (talk) 00:54, 18 January 2020 (UTC)

@PPelberg (WMF): I tried to use the prototype, but ran into some problems...

When loading the talk page I get a console error:

Failed to load resource: the server responded with a status of 503 ()
VM36:203 RESTBase load failed: error

Then when I write a reply and click the "Reply" button, nothing happens. Tried it multiple times with the same results. Using Chrome on a Mac. The basic problem is that https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Talk%3ACats/407862?redirect=false&stash=true returns a server error.

Another problem I noticed is that using <gallery> tags doesn't work right in the preview. Instead of getting a gallery, it shows a bullet list instead. Kaldari (talk) 23:13, 19 December 2019 (UTC)

When loading the talk page I get a console error:and Then when I write a reply and click the "Reply" button, nothing happens.

Oh, thank you for raising this and including these details. I've added them to this Phab task: T239861.

I will reply to this comment once this issue is resolved.

Another problem I noticed is that using <gallery> tags doesn't work right in the preview. Instead of getting a gallery, it shows a bullet list instead.

Good spot. Hmm, this seems to be working properly on the prototype server, but not on ...beta.wmflabs.org. Here is the task to figure out why this is so: T241193

PPelberg (WMF) (talk) 01:05, 20 December 2019 (UTC)

The prototype is now working normally. The issue raised in T239861 has since been resolved. PPelberg (WMF) (talk) 05:51, 24 December 2019 (UTC)

1. Yes, I think I was able to complete the tasks correctly.
2. I would have expected to be able to edit the comment inline. Additionally, the reply buttons didn't appear upon saving the page with the new wikitext editor, and I had to reload the page to perform step 8; the text box didn't appear when clicking "Reply" after going back to the "Read" tab from the "New section" tab (also with the new wikitext editor); and Firefox gave me the "data you have entered may not be saved" warning on closing the page after saving a comment.
3. It's already a little better in that less effort is required to post comments, and newcomers wouldn't be required to learn wikitext for basic text-only replies. However, the markup issues and inability to e.g. make a new section make it less usable in general due to the limited applications for which the editor can be used.
4. For fun, I decided to post this comment:

   __NOTOC__ __NOEDITSECTION__ __INDEX__ {{DISPLAYTITLE:cats}}{{Infobox person|name=Wikipedia|image=Wikipedia's W.svg|birth_date       ={{birth date and age|2001|01|15}}}}
   {|
   |Lorem ipsum
   |}
   

   Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning. It also appears that the formatting has resulted in: "list gap"; the entire page from that point being indented four times (including the sections below); the infobox being in a different list to the next three lines (it is indented four times, whereas the other text is indented eight times); the failure of the wikitext table formatting; and the disappearance of the {|. I think some of these are probably due to pre-existing bugs. (Infoboxes usually use HTML tables and not wikitext tables, so the infobox was not affected by the indentation.)

   Surprisingly, the preview was visually completely accurate, although it wouldn't have been if the infobox wasn't right-aligned (due to the superfluous indentation of the next two lines).

5. I'm not sure what the question really means, and it would help if it were more specific.

   Aside from making comments (you know, like a normal person), I don't use the banner templates much; I would say I most commonly use them for the links to deletion discussions and GA/FA discussions, as well as the dates that articles were promoted to or demoted to GA and FA. (The discussions have usually already concluded, so this is mainly out of interest than because it makes me more productive or anything.)

   However, I generally use non-talk-namespace discussion pages as much as talk pages; I typically use Project-namespace discussion pages more than all talk pages on the English Wikipedia and Wikidata, and vice versa for Commons, Meta-Wiki and MediaWiki-wiki. Out of the talk namespaces, on Wikipedia it's usually User talk, Wikipedia talk and Template talk, and more occasionally Talk and Module talk; on Wikidata it's usually User talk, Property talk, Wikidata talk and more occasionally Talk; and on the others it's usually Talk and occasionally User talk.

6. I would say I currently use talk pages weekly and non-talk-namespace discussion pages weekly-ish, but in the past it would have been daily for both for various periods. Jc86035 (talk) 01:48, 24 December 2019 (UTC)

We appreciate you taking the time to try out the prototype and share your thorough feedback. I hope the time it's taken us to reply here does not signal the opposite.

Now, getting into the points you raised, a few comments and questions...

I would have expected to be able to edit the comment inline.

This is reasonable expectation. Currently, we are planning for this functionality to be included in v1.1. For context, the scope of this release is being defined in this ticket:T236916.

...the reply buttons didn't appear upon saving the page with the new wikitext editor...

This issue should now be resolved now that the new wikitext editor is no longer enabled on the prototype. If you are still not seeing the "Reply" links after saving an edit using full page editing, please let us know.

...the text box didn't appear when clicking "Reply" after going back to the "Read" tab from the "New section" tab (also with the new wikitext editor)...

Are you able to try this once more and see if the issue persists and if it does, let us know? ...I think this should now be resolved.

Firefox gave me the "data you have entered may not be saved" warning on closing the page after saving a comment.

Good spot. This seems to be happening to others as well. Here is the task where the work to resolve this issue is happening: T241393.

...the markup issues and inability to e.g. make a new section make it less usable in general due to the limited applications for which the editor can be used.

Markup issues: are you referring to the issues raised in "4." here?

New sections: How and when the reply workflow supports the creation of == new sections == is something the team plans to discuss before v1.0's release. In the meantime, I saw you've expressed some thoughts around this on Phabricator (T241388#5766816). Tho, I wonder in what situations you notice yourself posting a reply and creating a new section in one edit?

Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning.

Can you expand on this a bit more? My assumption is that magic words, like __NOTOC__ __NOEDITSECTION__ __INDEX__ should work on talk pages and so it's expected that they would work if posted to the page using the new replying workflow. Although, I suspect you're aware of something I'm not...

...you can expect a response about the remaining points you raised [1] next week; I just wanted to make sure we got a start on these before any more time passes. Thank you for your patience and continuing help with all of this work.

---

1. Remaining issues to talk about:

a) Formatting resulting in a "list gap"

b) The content of a reply affecting the indentation of other content on the page

c) An infobox being indented at a different level of depth than the rest of the content the infobox was posted with

d) Inability to embed a table in a comment PPelberg (WMF) (talk) 02:54, 11 January 2020 (UTC)

By "markup issues", as well as the issues I mentioned specifically, I was also referring to the other markup inconsistencies between the inline editor and the usual wikitext enviroment, mainly those caused by the automatic addition of list items.

I don't add new sections as well as comments very often. I think it'd nevertheless be worth preserving at least some of the more complicated workflows that are currently used, simply because it would provide a better user experience. (If users have to use the source editor as a fallback often, they might as well just use it all the time.) A number of user scripts, such as Twinkle, XfDCloser and VisualFileChange, exist specifically to make it easier to perform such workflows on talk pages, and it would make a lot of sense for the inline UI to be able to make similarly complex workflows easier (although these would have to be limited to generic workflows – such as the ones I mentioned in this Phabricator task – or generic workflow templates, similar to the existing preload feature). Aside from the utility of adding such workflows, one of the reasons I've mentioned these a lot at this stage is that the automatic nesting and signature would prevent users from doing these things, and it's possible that they wouldn't expect it to be a problem.

In Structured Discussions, you would expect magic words like NOINDEX and categories to have no effect. As Jeblad noted in this discussion, it would probably be beneficial to make the new discussion formatting work like that if it were feasible (i.e. by parsing comments specially). I think it makes sense, because previously there was basically no control over the structure of talk pages, whereas with this project at least some of that structure will have to be defined as a prerequisite for the software to actually work. Since the opportunity arises to modify that structure (if new markup is to be introduced), it would be appropriate to make it difficult for users to inadvertently break that structure (and other parts of the talk page) within the inline editor. Jc86035 (talk) 17:21, 12 January 2020 (UTC)

I'm sorry it's taken this long to get back to you @Jc86035..

I'm going to respond in a series of separate comments to make these responses both easier to read and discuss... PPelberg (WMF) (talk) 01:36, 15 February 2020 (UTC)

By "markup issues", as well as the issues I mentioned specifically, I was also referring to the other markup inconsistencies between the inline editor and the usual wikitext environment, mainly those caused by the automatic addition of list items.

This context is helpful. Thank you. A quick update on how we're thinking about the replying workflow's inline editor…

For now, we are assuming the real-time preview will be sufficient in helping contributors understand what markup the replying workflow does and does not support.

In the longer-term, we hope to introduce new wikitext syntax that will expand the range of markup capable of being embedded in list items, and by extension, comments posted using the new replying workflow.

I know you've been actively involved these conversations [1]. I'm sharing this detail here in case it is news to someone reading this thread.

1. https://phabricator.wikimedia.org/T230683 PPelberg (WMF) (talk) 01:38, 15 February 2020 (UTC)

I think it'd nevertheless be worth preserving at least some of the more complicated workflows that are currently used, simply because it would provide a better user experience. (If users have to use the source editor as a fallback often, they might as well just use it all the time.)

This is a great point. I've added the scripts you shared to the thread we have going [2] about gadgets and templates that are used on talk pages. This way, if/when we explore adding shortcuts to the workflow, we have a list of popular tools in one place.

To the potential you raised about contributors being more likely to use full page editing all the time if they find many of their common workflows are not supported by the new replying tool...I think this is a great thing to mention.

Our thinking: once the feature gets deployed on live wikis, it will be important for us to do three things:

1. Keep track of instances when the workflow does not support what contributors expect it to
2. Understand how common and important these workflows are and
3. Determine whether adding support for them needs to be prioritized.

Please let me know if the above does not address the concern you are raising fully. I appreciate this is a point you've mentioned a few times which leads me to think you might be seeing something I am not...

2. https://www.mediawiki.org/wiki/Talk%3ATalk%20pages%20project/Updates#h-Update%3A_15-October-2019-2019-10-15T22%3A06%3A00.000Z PPelberg (WMF) (talk) 01:39, 15 February 2020 (UTC)

I think that makes sense as an approach. Would you track this by measuring when users exit the inline editor and use a different editor instead, by analyzing all discussion page edits made by users who have the extension enabled, or by some other method? Jc86035 (talk) 13:24, 15 February 2020 (UTC)

Good question. In an effort to understand the extent to which the new replying tool is not meeting contributors' expectations, we are planning to start by looking at the percentage of contributors who start drafting a comment and who end up actively abandon it before posting (e.g. click "Cancel").

It would be nice for us to be able to answer a question like the one you entered here (phrased below [1] in a slightly different way), but I'm not yet certain whether we're capable of measuring it or not.

---

1. What percent of edits made using Replying feature are "immediately" followed by a non-DiscussionTools edits to the same page by the same person?

PPelberg (WMF) (talk) 22:42, 6 March 2020 (UTC)

In Structured Discussions, you would expect magic words like NOINDEX and categories to have no effect.

Ah! I think the point you are making is connecting with me now. Can you please let me know if how I'm understanding this point matches up with yours?

My understanding: As it's currently implemented, the replying workflow could lead contributors to think their ability to affect the talk page is limited to the text they are inserting into the page. This could lead contributors to be surprised when text they enter in a reply affects the rest of the page. PPelberg (WMF) (talk) 01:39, 15 February 2020 (UTC)

Yes, that's what I meant. It's probably not a massive concern, though; my mention of this was primarily influenced by Jeblad's reasoning for "armouring the output" (that is, sandboxing each individual comment using an extension tag). Jc86035 (talk) 13:27, 15 February 2020 (UTC)

They're talking about that. It'll require a technical RFC, though. Keep an eye out for something about "multi-line comments", hopefully later this month. Whatamidoing (WMF) (talk) 21:53, 18 February 2020 (UTC)

Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning. It also appears that the formatting has resulted in: "list gap"; the entire page from that point being indented four times (including the sections below); the infobox being in a different list to the next three lines (it is indented four times, whereas the other text is indented eight times); the failure of the wikitext table formatting; and the disappearance of the {|. I think some of these are probably due to pre-existing bugs. (Infoboxes usually use HTML tables and not wikitext tables, so the infobox was not affected by the indentation.)

List gap: Are you able to share what lines of a reply containing this text [3] become separated by a list gap

Issues with table formatting (page corruption and disappearance of `{|`)

This behavior seems to fall into the category of "preexisting bugs" you alluded to, but please tell me if you see it otherwise.

Here's what we're understanding to be happening...

When someone attempts to post a table inside of a list item (read: comment), the rest of the content of the page gets incorporated into that table.

Right now, we are not planning to address this issue for the following reason:

We are assuming contributors attempting to add a table inside of their comment will:

1. See the real-time preview of the comment they have drafted
2. Notice the table markup they have entered does not render/display in the way they intended it to
3. Not post a comment containing a table

With this said, our assumptions could be incorrect. For example, rather than not posting the comment, contributors might assume the preview is broken and post their comment anyway.

If this happens frequently, we would need to come up with a more effective way for the feature to communicate to people the kinds of markup it can and cannot support.

Infobox being in a different list item

This behavior also seems to fall into the category of "preexisting bugs" you alluded to and for the reasons mentioned in the "table formatting" issue. Although, please tell me if there is something I am missing.

---

3. Talk:Talk pages project/Replying/2019#h-Usability_test:_Version_1.0_prototype-2019-12-14T02:02:00.000Z PPelberg (WMF) (talk) 01:50, 15 February 2020 (UTC)

It looks like the list gap was caused by the unclosed {|. Jc86035 (talk) 13:31, 15 February 2020 (UTC)

It looks like the list gap was caused by the unclosed {|.

Meaning, that in posting a comment using the new Replying tool (let's call it "Comment A") on a talk page that contains a table, "Comment A" will strip the table's closing table tag ( |}) resulting in a list gap?

PPelberg (WMF) (talk) 22:54, 6 March 2020 (UTC)

Yes, but it happens mainly because the closing tag isn't recognized due to being preceded by colons. I think. It's probably related to how tables within definition lists are parsed specially. (In terms of this project, I don't think it'll end up being especially relevant unless the table-within-a-list parsing is modified as a result of the introduction of multiline list item syntax.) Jc86035 (talk) 16:12, 7 March 2020 (UTC)

Do you think that you completed the Task above correctly? - Yes.

Was there anything painful or not obvious about this experience? - My message dont appear on a page

I pressed Reply on first message and entered this text:

----# first

# second

** second unnumbered

#* second numbered

no list

----All just dissapear.

PS. Any reply on a first message makes text simply dissapear. No traces in history too.

Igel B TyMaHe (talk) 11:51, 24 December 2019 (UTC)

Well, there is a bug. I can't close the discussion page after the reply publishing, the browser claims I'm in the middle of the edit. IKhitron (talk) 12:43, 24 December 2019 (UTC)

hi @IKhitron – we appreciate you trying the prototype and sharing the issue you encountered. We have it documented in Phabricator here: T241393.

The "abandon edit" warning issue aside, how did you find the rest of your experience trying the prototype? Were there other tasks listed in the "Test instructions" section you found behaved in unexpected ways? PPelberg (WMF) (talk) 20:29, 24 December 2019 (UTC)

Thanks. Didn't do it yet. Maybe later. Just played and compared with the original one, the CD. IKhitron (talk) 20:53, 24 December 2019 (UTC)

1. Do you think that you completed the Tasks above correctly?
   1. All but the editing one. See below.
2. Was there anything painful or not obvious about this experience?
   1. Not to an experienced Wikipedia editor, but I think newer users coming from other platforms may find it unintuitive to have to click "edit" in the section header or on the page to edit comments. Compare Youtube, Facebook, etc. where "edit" for that comment is next to said comment. In this particular interface, I'd imagine, for example: [my comment] [my username] (talk) [timestamp] (UTC) (reply | edit)
   2. Also, for some reason, when I visit the page on the same browser session I used to edit, I see my comments, as expected. But if I open a different browser session (Guest on Chrome, for example), none of my comments appear. The bug also occurs when opening the page on a different browser (Firefox 72.0.2 (64-bit), Private mode). I use Chrome 80.0.3987.149 (Official Build) (64-bit) on Windows 10. Yes, I did press Ctrl+F5 to clear the cache. My comments still did not appear only appeared on the tab in the same browser session.
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
   1. I've used reply-link on en-wiki, I think it's called? This is better in that replying to a high level comment seems to place your reply in the right place.
4. What other additional comments, concerns, or ideas would you like to make known?
   1. Some edits have the tag "source" in addition to "reply". What does that mean?
5. How do you typically use talk pages (across namespaces)?
   1. To collaborate with other editors. Mostly I perform Gnomish tasks like editing banners, archiving old discussions.
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?
   1. Weekly? I've participated more often this week, but if distributed evenly, probably weekly. Rotideypoc41352 (talk) 20:03, 25 March 2020 (UTC)

Thank you for taking the time to try the prototype and share your feedback, @Rotideypoc41352. We're glad to hear the Replying tool posted your comment to the page in the place you expected it to.

As to some of the comments you raised...

I think newer users coming from other platforms may find it unintuitive to have to click "edit" in the section header or on the page to edit comments. Compare Youtube, Facebook, etc. where "edit" for that comment is next to said comment. In this particular interface, I'd imagine, for example: [my comment] [my username] (talk) [timestamp] (UTC) (reply | edit)

This is a great point and the workflow you are describing is one we've started work on; you can see a mockup here.

So you're aware, we have not yet set a date when this functionality will be deployed.

...when I visit the page on the same browser session I used to edit, I see my comments, as expected. But if I open a different browser session (Guest on Chrome, for example), none of my comments appear

Comments you posted appearing in one browser and not another is certainly unexpected. To be sure, are the comments you are expecting to see in the second link comments posted using the following IP address: 104.33.84.249?

If yes, then I think it is expected for you not to be able to see the comments you posted as 104.33.84.249 in this second link.

Reason being: that second link is showing an old version of the talk page as edited by Catgirllover4ever at 17:24, 24 March 2020, 12 hours before the first edit by 104.33.84.249 was posted to the talk page.

Please let me know if you think the above does not explain what you are experiencing.

Some edits have the tag "source" in addition to "reply". What does that mean?

"source" refers to the fact that the reply was posted using the "source" or wikitext input mode. This additional change tag will become more useful in the near-term future when there is a second `visual` or rich text input mode.

You can see [and share your feedback about] the proposed designs here: Talk pages project/replying#Version 2.0.

PPelberg (WMF) (talk) 23:45, 26 March 2020 (UTC)

I just want to note that I see my comments now! Not sure what was going on before this. Just in case: still using Chrome 80.0.3987.149 (Official Build) (64-bit) on Windows 10. Thanks again! Rotideypoc41352 (talk) 01:07, 1 April 2020 (UTC)

Thank you for following up about this, @Rotideypoc41352 – I'm glad to hear your comments are appearing as you expect them to.

And what timing: I was just moving "look into the issue user:Rotiedeypoc41352 reported" to my to-do list for tomorrow... PPelberg (WMF) (talk) 01:35, 1 April 2020 (UTC)

are the comments you are expecting to see in the second link comments posted using the following IP address: 104.33.84.249?

The second link is an illustration of what I see when I go to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Dogs. I expect to see what's in the first link, but I don't. No idea what's happening, as clearly the edit history shows my comments.

Thank you again for your time and patience. Stay well! Rotideypoc41352 (talk) 04:52, 27 March 2020 (UTC)

Before doing my edits I cleared the section and left only the first commet because some unusual insertions made it not working anymore.

Answers:

1. I've used the normal editor to edit my comment in step 6. Was that right?
2. No
   • It's fine but there's the same issue as in the already existing reply feature on mobile: Comments are signed using ~~~~ and not --~~~~ but the second one is the signature used by the normal editor.
   • The yellow highlighting should appear behind and not in fornt of the text. Because it appeares in front of the text, the text can't be read well (but the highlighting disappeares immediately this is just a minor issue.
3. Users can get confused because replys are auto-signed but new sections have to be signet manually
4. Currently only to write complaints or information to new users or bad gus. Most times I'm adding a new section with a template (that is substituted and often includes an automatic signature) but sometimes I also have to reply.
5. I don't know. FF-11 (talk) 20:46, 8 April 2020 (UTC)

1. Do you think that you completed the Tasks above correctly?

No, I wasn't able to edit the comment. Also my Edits seem overblown by bytes. Though it seems I'm not the only one with this problem.

2. Was there anything painful or not obvious about this experience?

No, the UI is quite nice. Although the generated code is still using DL, DD, DT-Tags instead of proper paragraphs.

3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?

It's definitively faster. I like it. AND the biggest plus: nobody will ever miss their signature again, this alone is awesome!

4. What other additional comments, concerns, or ideas would you like to make known?

Proper HTML-formatting would be nice, though I think this is not in the scope of this project.

5. How do you typically use talk pages (across namespaces)?

Quite heavily to discuss all sorts of things. Though the process is normally pretty painful. But that is the communities' fault.

6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?

When I'm working in one of the projects (which I didn't do for the last couple of months) at least once a day I would estimate. Could be more.

Regards --~ 94.217.145.185 (talk) 20:51, 8 April 2020 (UTC)

1. Do you think that you completed the Tasks above correctly?
   • I think so, but probably given that I was an experienced Wikipedia/wikiHow editor with knowledge of the MW software.
2. Was there anything painful or not obvious about this experience?
   • I could not find the "Edit" button next to my reply, so I had to go into the source code to edit my reply.
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
   • It seems very similar to wikiHow's commenting feature, except it was more structured.
4. What other additional comments, concerns, or ideas would you like to make known?
   • I think this is important because new editors may have a difficult time with talk pages, but at the same time, we want a smooth transition from "Posting comments aimlessly on talk pages" to "Being able to post within a discussion properly without missing signatures or indentation".
5. How do you typically use talk pages (across namespaces)?
   • Not that often, but I still raise issues on the talk pages of articles and on other user's talk pages.
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?
   • Daily to weekly, sometimes monthly. Aasim 21:41, 8 April 2020 (UTC)

Hello, when i was not logged in, there is parsoid err: "Error contacting the Parsoid/RESTBase server (HTTP 500)" - and i think, its not very good. :) --~ Frettie (talk) 05:39, 9 April 2020 (UTC)

@Frettie I think you are not supposed to see this yet, when you are not logged in.. How did you enable it ? —TheDJ (Not WMF) (talk • contribs) 08:02, 9 April 2020 (UTC)

@TheDJ Open that beta wiki page. :) Frettie (talk) 08:21, 9 April 2020 (UTC)

Frettie, can you try again? The servers were having some problems yesterday. Whatamidoing (WMF) (talk) 19:02, 9 April 2020 (UTC)

Hello, I just got the same error message as Frettie, while not logged in. I could edit the page normally though. GrandEscogriffe (talk) 20:39, 9 April 2020 (UTC)

@Whatamidoing (WMF) yes, its ok! Frettie (talk) 22:04, 9 April 2020 (UTC)

My IP seems to have went 'bonk' on the test server. I still have no idea why I'm assigned a private-use IP Address that is subsequently autoblocked (JonelleMaier71) by an edit filter. My IP is static, and yet seems to be something completely different on this specific wiki.

Considering most might be using these bogon IPs, I think this is just a case of weird range-blocking. ToxiBoi (talk) 08:19, 14 April 2020 (UTC)

I am not able to complete the test. What I attempted to post was the following, and the first part of it has much to do with why it failed (the second part reports another problem, in sig processing):

For some reason, I cannot create an account here. No matter what VPN I come in from, I get a bogus message stating 'Autoblocked because your IP address was recently used by "JonelleMaier71".' (And this beta box doesn't seem to be hooked into the SUL system.) Anyway, this is meta:User:SMcCandlish.

PS: It is weird that this automatically adds a sig. I hope that it's smart enough to detect when people add ~~~~ (as I'm about to test), and not double the sig when that happens. In typing it out, this system appears to recognize ~~~ (username only), then add the complete sig after it; and recognize ~~~~ (normal sig) without doubling the sig; but fail to recognize ~~~~~ (date only) at all. It treats ~~~~~ as if it were ~~~~ preceded by a stray, meaningless ~ character. Anyway, I do like the live preview. It has a bit of latency, and it might be worse on a heavily populated server like en.wikipedia, but we'll see.

When I attempted to post this, I got another bogus error stating "Your IP address has been blocked automatically, because it was used by a blocked user." I switched to yet another VPN node, same crap. I tried servers as far apart as Los Angeles and Latvia. So, that's pretty broken.

PS: I also found that the link w:en:User:SMcCandlish would not work, and had to change it to meta:User:SMcCandlish. I doubt that has anything to do with this software and is a server config issue.
 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:38, 14 April 2020 (UTC)

I too am unable to create an account, I keep getting the same message as everyone above "Autoblocked because your IP address was recently used by "JonelleMaier71" (although the name was different yesterday), I did message PPelberg yesterday who also seemed confused by it,

I've deleted all wiki(p)(m)edia cookies however unfortunately that had no effect so unless this is fixed then I'm unable to test this feature, Thanks, Regards, ~ Davey2010 (talk) 13:26, 14 April 2020 (UTC)

@ToxiBoi, @SMcCandlish, and @Davey2010 first off: thank you for being patient with us and sharing the issue y'all are encountering.

I can think of better things to experience than being asked to try out a prototype only to find out that there was a bug preventing you from doing so.

With this said, I hope we will have this issue resolved soon. Here is the task where work on this issue will happen: T250245.

In the meantime, could you please have a quick read through the steps below to ensure they match up with what you experienced?

Steps to reproduce issue:

1. Go to en.wikipedia.beta.wmflabs.org
2. Click the Create account link to the left of the Log in in link in the top right corner of the window
3. Enter a username, password, etc
4. Click Create your account
5. ❗️Receive the following message: Autoblocked because your IP address was recently used by (a username that seems to vary day-by-day) PPelberg (WMF) (talk) 01:57, 15 April 2020 (UTC)

That sounds about right. I just tried it again, and this time got a different error (at the same point, after clicking "Create your account"):

Database locked

The Wikipedia database is temporarily in read-only mode for the following reason:

The database is read-only until replication lag decreases.

[misc. additional boilerplate here]

I'm not sure if that's progress (i.e., I'm not sure if this kind of error would be triggered before or after the previously reported one).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:45, 15 April 2020 (UTC)

Never mind. It apparently "mostly worked". I went back to try again (sometimes these database-lock errors last less than a minute), and it actually already had me logged in. So, it apparently queued the registration form submission then resubmitted it for me as soon as the db lock cleared.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:48, 15 April 2020 (UTC)

Woosh! Thank you for letting us know, @SMcCandlish – I'm glad to hear you were able to create an account. Curious to hear what you think of the prototype if/when you have an opportunity to try it out... PPelberg (WMF) (talk) 01:11, 16 April 2020 (UTC)

My first situation was a little different, as I was posting a comment in Reply and the error message appeared in the box above. However, I can confirm those steps were accurate the second time around.

It seems to be fine now, I just created an account and it gave me a survey. ToxiBoi (talk) 05:31, 15 April 2020 (UTC)

It seems to be fine now, I just created an account and it gave me a survey.

Excellent – thank you for being patient with us and letting me know things are working on your end, @ToxiBoi. PPelberg (WMF) (talk) 01:12, 16 April 2020 (UTC)

Success!! - Account creation worked! :),

My only other problem is that for whatever reason someone took my username - Is there any possible way I can have it given their only contribs are creating a userpage and talkpage ?,

My account over there is "Davey2010EN" but would rather have just "Davey2010" if at all possible,

Thanks PPelberg and those at Phab for kindly getting this issue fixed :), Thanks, Kind Regards, Davey2010 Davey2010 (talk) 10:44, 15 April 2020 (UTC)

Success!! - Account creation worked! :),

^ _ ^

We have people like @Hashar and @Krenair to thank for this speedy fix...

Is there any possible way I can have it given their only contribs are creating a userpage and talkpage ?,

This I do not know. My instinct would be to one of two things:

1. File a task in Phabricator that describes the change you would like to see made. I'd also recommend tagging "Beta-Cluster-Infrastructure".
2. Start a discussion on the Beta Cluster talk page.

PPelberg (WMF) (talk) 01:18, 16 April 2020 (UTC)

Hi @PPelberg (WMF), Done :),

Many thanks again for yours and everyone elses help here it's greatly appreciated,

Once I know the outcome to my query I'll try this feature either way but in the meantime apologies for the delay on my part, In all fairness I wasn't to know I'd be account creation blocked and then I also didn't know someone would take my username so I guess it's one those things annoyingly but yeah sorry for any delays on my part, Anyway many thanks again :), Thanks, Davey2010 (talk) 10:27, 16 April 2020 (UTC)

I'm one massive idiot!, Apparently I created the account back in 2014 (or it was unified) .... if it was the former then I have no recollection of it but yeah I'm in!, Thanks Davey2010 (talk) 10:38, 16 April 2020 (UTC)

Whenever I try and reply to a comment I keep getting "Error contacting the Parsoid/RESTBase server (HTTP 500)" however I'm able to create new sections with no problems, Thanks Davey2010 (talk) 10:59, 16 April 2020 (UTC)

I'm sorry that you've encountered so many problems with the Beta Cluster. "HTTP 500" errors are basically never your fault or a problem that you can solve. They've got it working again. Whatamidoing (WMF) (talk) 01:45, 18 April 2020 (UTC)

Hi @Whatamidoing (WMF), Unfortunately I'm still getting the same error, I give up trying!,

As general feedback I like the reply feature a lot (Obviously couldn't use it but clicking a button and replying is a lot better and much more easier than having to use Wiki markup -

(Don't mind wiki markup but personally I do prefer this feature and it also means I can reply and not have to worry about indents which I still mess up on a daily basis lol)

My only suggestion which I don't think applies here but I'd like to see the feature updated so that when you create a new section it sort of has the same box etc etc and it signs the post for you,

Overall personally I think this feature is a major improvement to what we have and whilst I didn't get to actually use it it looks easy and simple to use, Major improvement for the newbs and major improvement for us normies too :),

Thanks,

Regards, Davey2010 (talk) 12:56, 18 April 2020 (UTC)

@JKlein (WMF) is looking at ways to improve the start-a-new-discussion feature at Talk pages project/New discussion (please put that page on your watchlist, if you're interested). I can't remember off hand whether she's already put automatic signing on her list, but I'm sure she'll be interested in knowing that you recommend it. Whatamidoing (WMF) (talk) 19:12, 20 April 2020 (UTC)