This is somewhat similar to T240696: Make linebreak behaviour consistent regardless of indentation level, in that both issues result from the way that indentation is added for replies. I think it would be appropriate to give both tasks a shared parent task, perhaps titled something like "handle markup consistently in all comments to avoid unexpected behaviour".

This would actually be a problem even without the inline talk page editor, and the reason the template works at all is that it was never supposed to be used as part of a reply anyway. Aside from the section header being in the template, I think a lot of templates (e.g. WikiLove/barnstars) would suffer from this or similar issues – essentially, any template that contains line breaks, wikitext list items or wikitext tables wouldn't work as expected, although this wouldn't be considered a regression.

The two most obvious solutions, to me, would be to change the syntax on talk pages so that the generated preview is reliable (T230658/T230683) or to add the indentation before generating the preview. The latter would work in the short term but would be made redundant by the former.

On another note, it isn't currently possible to use a wikitext section header in a reply (well, at least, not without using templates to interfere with the addition of indentation). I assume in a later version of the editor the markup would probably be converted to an HTML section header, or a fake section header, to prevent comments from interfering with [edit] links and the table of contents?

Is there a use case for (intentionally) replying to any comment with a ==Level 2 section heading==?

Adding a new section pretty much means I'm not replying to you, at least in the conventions on the English-language wikis. For example, @Doc_James fairly often makes edits like https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Medicine&diff=930051648&oldid=930004247 which edit the last section on the page to start a new one, but nobody thinks that a reply to the previous comment, and I suspect that he wouldn't even do that if enwiki intalled the "add section" gadget that turns the [edit] link for the last section heading on the page into [edit] [add section].

Another point that @Whatamidoing-WMF raised: == Welcome == should not be visible within the preview [1].

@Esanders / @matmarex: is the above deserving of a separate ticket?

== Welcome == is visible in preview

More precisely, having == Welcome == visible in the preview is the correct preview of the wrong wikitext.

If you go to http://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats?action=submit (to force an old wikitext editor) and put this wikitext in:

:== Welcome! ==

and preview the page, you will get the same preview that the Reply tool shows. The problem is the input, not the preview, but the Reply tool's preview is correctly showing you that starting your reply with a ==Level 2 section heading== isn't going to produce the effect that you (presumably) wanted..

@ppelberg Eeeek! This Phab task is backwards.

The purpose of a preview is to show what the saved page will look like, given any arbitrary content. Within the scope of discussion, the saved page is by definition "correct". Any difference between the preview and the saved page is by definition a failure in the preview code.

The task you wrote says to change the rendered page to match the preview. That's logically backwards. Making random changes to how pages render is dangerous, potentially breaking an unknown number of existing pages. The {{welcome}} example is just a random example demonstrating that there is a flaw in the preview code. There are surely countless other cases that will not preview correctly. It would cause massive breakage if we opened a hundred or thousand Phab tasks trying to change page renders to match previews. The preview code needs to needs to work correctly for arbitrary/generic content.

In T241388#5762821, @Whatamidoing-WMF wrote:

Is there a use case for (intentionally) replying to any comment with a ==Level 2 section heading==?

Yes. In one particular case I recall, Cluebot goofed. It reverted a good edit by a new user. I reverted Cluebot, and I went to the new user's talk page. The only message there was the warning/notice posed by Cluebot. I replied to Cluebot's message explaining that Cluebot was wrong and that I had restored the edit. I followed that with a {{welcome}} section to aid the new user. There are of course endless other cases where someone would want to post a reply, and follow it with one or more new sections for related or unrelated topics.

This also shows the use case for having a manual signature in the middle (before the new section). This also shows the use case for changing or deleting the default-indentation-markup, which the tool currently hides from the user. There are many cases we want to change or delete the indentation, in particular colons (usually) should not appear in front of a ==section== or {{welcome}}.

The task you wrote says to change the rendered page to match the preview. That's logically backwards. Making random changes to how pages render is dangerous, potentially breaking an unknown number of existing pages.

Not really applicable in this case, because the task pertains to a prototype. Breaking changes won't affect readers. Additionally, the task description doesn't actually say how the expected result would be achieved; it would also be possible to change the behaviour of the editor so that it would publish different content to get the desired result (or, technically, it would also be possible to do so by changing the content of {{welcome}}).

There are of course endless other cases where someone would want to post a reply, and follow it with one or more new sections for related or unrelated topics.

I usually avoid doing this, but this is obviously a fairly common use case (although the workflow could be improved, and editors often don't use the correct section header in their edit summaries when doing this). I'll modify the description of T239978 to reflect this; although I'd already mentioned adding new sections, it might turn out that users would dislike having to do the listed things one at a time.

In T241388#5761786, @Jc86035 wrote:

The two most obvious solutions, to me, would be to change the syntax on talk pages so that the generated preview is reliable.

@Jc86035, are you able to expand on the "reliable" point a bit more? What do you think would make the preview more "reliable" than it currently is?

For context, our current thinking is as follows. Contributors ought to be able to depend on the preview (T238177) to:

1. Help them know whether the wikitext they wrote is rendering properly. Said another way: contributors can depend on the preview to identify when an action they've taken has an unexpected result.
   • e.g. invalid link, accidental line break, etc. (see: Topic:Vcehezaiyl3znf0d).

2. Help them to know when the software does something unexpected.
   • e.g. == Welcome == not saving to the page in a way contributors might expect (see: T241388#5762825) or the content of a reply affecting other parts of the talk page (see: Topic:Vcwvt3bq03o5gv8h).

A related point: today, we started thinking about what might be a good way to measure the impact of the current previewing implementation. One idea that came to mind that I think is relevant here is whether the current approach to previewing causes an increase in the number of syntax errors being introduced on/to talk pages.

On another note, it isn't currently possible to use a wikitext section header in a reply (well, at least, not without using templates to interfere with the addition of indentation).

Good spot – thank you for raising this. I've added this issue/question to the description of this task: T235923 [1]

In T241388#5766187, @Alsee wrote:

Any difference between the preview and the saved page is by definition a failure in the preview code.

@Alsee, our aim is to minimize the number of instances where there is a, "...difference between the preview and the saved page..." The approach we have in mind right now is as follows:

• Short-term: document and fix cases (e.g. the point you raised here) where the content of a reply can corrupt the rest of the talk page. I should say: for each case, we will need to understood the issue and assign it an appropriate level of priority before committing to resolving it.
• Longer-term: introduce new wikitext syntax to encapsulate comments and ensure their contents do not impact the rest of the talk page. See: T230683

1. We are using T235923 to track all of the issues/unresolved questions we will need to address, or decide not to address, before the first release of v1.0 of the replying workflow to the "target wikis."

In T241388#5779747, @ppelberg wrote:

@Jc86035, are you able to expand on the "reliable" point a bit more? What do you think would make the preview more "reliable" than it currently is?

The main solution I was probably thinking of was more or less T230683: New syntax for multiline list items / talk page comments. This would resolve a number of issues, primarily revolving around treating markup consistently (e.g. T240696), so I still think this would be the best option.

@ppelberg will determine when this should be prioritized as well as the use cases.

Thank you for weighing in on this ticket y'all.

Two issues seem to have emerged in the discussion thus far:

1. The new replying workflow's support for templates that contain line breaks and
2. The new replying workflow's support for creating new sections

A couple updates on our plans for addressing them:

1. Support for templates that contain line breaks

Version 1.0 of the new replying workflow (T235923) will not support templates that contain line breaks. In the longer term, per the point @Jc86035 raised in T241388#5761786, we plan to introduce new syntax for multiline list items (T230683) which should enable the software to support this functionality.

• Thinking: we are assuming contributors will not expect the new replying workflow to support templates that contain line breaks considering the existing, full talk page editing, workflow does not support this functionality either. Furthermore, if contributors do attempt to use templates that contain line breaks, we are assuming the real-time preview (T238177) will communicate to them this functionality is not [yet] supported. If these assumptions end up not being true (read: contributors are attempting to use the new replying workflow to post templates that contain line breaks), we will consider addressing this behavior even before the new syntax is available which depends on a soon-to-be started RfC.

2. The new replying workflow's support for creating new sections
Version 1.0 of the new replying workflow (T235923) will not support creating new sections. We created T243044 to host the conversation about potentially revising this approach in the future.

• Thinking: While we appreciate there are instances where contributors using the current, full talk page editing, add new sections in conjunction with replying in another conversation, the new Replying workflow is specifically designed to support instances where contributors are adding new content in an existing conversation (read: section). This inherently means there will some use cases the new Replying workflow will not support. Now, the meta question of: "Where and what is the specific boundary between the workflows the new replying workflow will and will not support?" is likely a question whose answer will emerge, over time, through incremental decisions like these.
• Note: T233446 is prioritized to make the workflow for starting new discussion easier.

I'm moving this to the backlog considering:

• This ticket is not resolved and
• We do not have any near-term plans – at this moment – to work on it