Change 637518 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] POC Show 'quote and reply' when selecting text within a comment

https://gerrit.wikimedia.org/r/637518

@Esanders - this is fantastic and right where we need to be thinking. I like this because the interaction brings the contributor into replying mode directly from reading mode.
A while back I made this exploration for fun to start tinkering with the idea of how we my treat quotes as visually distinct elements. Perhaps we can have some markup that styles it like that?

There are a few ways that the community has dealt with commenting. For example:

• https://en.wikipedia.org/wiki/Template:Talk_quote_inline
• https://en.wikipedia.org/wiki/Template:Talk_quote_block

Are there other examples? Is there anything we can learn from this work?

the community

The English Wikipedia community

There are versions of these template in other languages (at least 20). Some wikis will have templates which behave slightly differently, some will have none. As a result I would always be inclined to use some global syntax that will work on every wiki instead of trying to support local templates (the demo uses <blockquote> although this has almost no formatting, just an indent).

Is there anything we can learn from this work?

The ability to add the user/timestamp looks neat, and we can pull these automatically from the discussion parser...

Doing this without a template one could use syntax such as <blockquote cite="#commentid">, but this would require some processing either in JS or PHP to convert the comment ID to a nicely formatted (and linked?) username and timestamp.

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

http://patchdemo.wmflabs.org/wikis/402bdf54eadd38949a1a7c7dc064f82b/w/

I can mock up how the quote would look if it had a username and timestamp.

In T266821#6589478, @iamjessklein wrote:

@Esanders - this is fantastic...

+ 1, @iamjessklein. I think this is wonderful [i], @Esanders.

Ed, as it relates to the implementation, can you experiment with implementing this such that the "quote tool tip" only becomes available once a Reply Tool is already open? Details in "Revisions to experiment with" below.

Here's what I have in mind and the reasons why...

Revisions to experiment with:

• CHANGE "quote tool tip" to only appear when text is highlighted while a Reply Tool widget is open.
• CHANGE the "quote tool tip" copy from Quote and Reply to Quote text

Thinking

• While I think there is value in exploring ways for making it easier for people to go from "reading" to "participating" as Jess mentions in T266821#6589478 [ii], to start, I'd like for us to experiment with this kind of interaction in a context (read: when a Reply Tool widget is already open) where we have more confidence what a person is intending to (read: respond).

i. As I currently think about it, a core value of a conversation, and by extension talk page interactions, is developing shared understandings. I wonder whether citing (read: quoting) a specific part of what another person can increase the likelihood people will form said "shared understandings" by way of it being unambiguous what exactly another person is responding to. It's for these reasons, I think this is a wonderful step.
ii. "...the interaction brings the contributor into replying mode directly from reading mode."

The styling of blockquote is being discussed at T265947.

There may end up being a divergence between blockquote on articles and blockquote in discussions. There would be a few way to achieve this:

• Load an additional stylesheet on DiscussionTools-enabled pages
  • Downsides: You might get the "wrong" styling on pages where it is ambiguous if a discussion is taking place (e.g. Project pages)
• Add an extra attribute to <blockquote>, e.g. <blockquote class="talk">
  • Downsides: More cluttered syntax in source mode, especially vs {{tq|...}}
• Use an existing template, e.g. {{tq}}
  • Downsides: Much more complex to implement, as each wiki has different implementations. Harder to edit in visual mode, as templates can't be edited inline.

For this first iteration, let's use the styling that they are using on articles for consistency. If we see it's not working for us that's an easy fix (if we go the stylesheet route) for future.

While experimenting, I remembered that we can't do multi-line quoting at the moment, due to the limitations of indentation syntax.

In T266821#6629122, @Esanders wrote:

While experimenting, I remembered that we can't do multi-line quoting at the moment, due to the limitations of indentation syntax.

In discussions there aren’t any real paragraphs anyway, only line breaks, so as long as no line-start-only syntax (e.g. list) is present, the quote can be inlined with <br>s:

:Lorem ipsum
:Dolor sit amet [[User:Example]] ~~~~~
...
::Example said: <blockquote>Lorem ipsum<br>Dolor sit</blockquote> ~~~~

This would be very difficult to support, especially in visual mode. This should either wait for proper multi-line comment syntax, or we should limit this to single line selections (which is probably the most common case).

@Esanders shared the following potential approaches for coping with multi-line constraint:

• Only surface "Quote" tootlip when someone selects a single line of text
• Suppress "Quote" tooltip when Reply Tool widget is in visual mode
• Prevent people from adding extra lines within blockquotes in the tool's visual mode

In T266821#6630916, @ppelberg wrote:

• Suppress "Quote" tooltip when Reply Tool widget is in visual mode

Why? I think this kind of defeats the purpose of this feature. The inability to quote multi-line comments is inconvenient, but probably affects few users. However, this feature is much more important for visual mode than for source mode: source mode is probably mostly used by senior contributors who may prefer the quote templates they know how to use and customize, but these can’t be used in visual mode and are out of question for junior contributors who don’t know about them.