Other previously discussed possibilities, I think, would include

• allowing this to be enabled or disabled for pages with a certain prefix (e.g. all subpages of Wikipedia:Articles for deletion)
• recognizing discussions automatically (e.g. by detecting signatures on every page with the default content model regardless of namespace)
• using the magic word to indicate a discussion type (e.g. #::::-format indentation, or the future equivalent if the syntax changes, for votes) and/or other metadata

I've mentioned this a few times elsewhere, but I thought it would be clearer if this were proposed as a discrete task.

@Whatamidoing-WMF, I think it would help if you were to provide an example of a page on which this happens, since I think this is already supposed to be handled for the case in which all of the existing comments are correctly parsed.

In T241391#5833068, @Alsee wrote:

[...] a comment begins on the line after a signature, and it runs to the end of the next signature. Any markup or change of indentation in between is irrelevant.

In T230683#5792294, @ssastry wrote:

So, in the interest of reducing the number of proposals to evaluate, I would pool them all in one class of proposals and distinguish them in terms of whether they propose custom syntax only for talk-page-list items, all-list-items, or reuse syntax from other uses. And perhaps other concerns specific to the proposals (ex: <<dd> has other issues).

Might it be useful to test on a Project-namespace discussion page as well, such as w:en:Wikipedia:Help desk?

This would also be an issue with certain CJK Unicode characters, since their rendering and stroke order may vary between languages.

How many levels of indentation does the tool need to support

For what it's worth, {{outdent}} on the English Wikipedia has a default of 10. I've almost never seen it used at 5 levels. I think for 1.0 it would be acceptable to never outdent, particularly since the existing outdent templates are not consistent across wikis. (In future versions it might make sense to introduce a parser function or CSS class to avoid having to rely on templates.)

In T239978#5795952, @ppelberg wrote:

As part of this work, we'd value knowing what about the existing workflows stands out to you. More specifically, we are curious to know:

• What issues/point of frustration do you encounter when creating a new discussion section and when adding a new comment in an existing section without any comments? What about these workflows do you think could be improved?

This is a comparison table of the various proposals and existing constructs that I'm currently aware of, with a focus on the syntax differences. (n is the nesting level; ⏎ indicates a line break; the "Compatible?" column indicates whether the proposal would allow mixing of old and new syntax.) There (understandably) aren't a lot of editors putting out fully realized proposals, so I've had to guess how Wnt and Jeblad's proposals would have worked syntax-wise.

: Hi, I'm power user one! I've been editing for decades, never gonna change my markup.

On the other hand, it's nominally acceptable to correct people's formatting errors, though it's not clear what the actual community reaction would be if people started fixing talk page nesting all the time. It would have to happen at some point depending on the syntax, since there would be tens of thousands of ongoing discussions at the point in time that the syntax is introduced, but it would probably be somewhat messy unless the implementation's unusually smooth.

Although in implementation I'd suggest handling it more like you'd probably handle any of the above proposals: collect the lines in the block, parse them, then inject them into the nested structure.

Is it really appropriate to keep using definition lists for comment nesting? As @stjn notes in this topic, it's semantically incorrect to do so. If new syntax is introduced, it just doesn't make sense to me to keep using definition lists for nesting in discussions. Perhaps it could be justified from a usability POV, but it otherwise seems short-sighted.

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 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.

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".

Regarding the RfC example, if there is any sort of markup change (e.g. T230683), it's possible that comments could become more clearly delineated (both on the rendered page and in the wikitext source). In the case where the end of the comment is marked only by the signature, the code example would continue to work; but in the case where the end of the comment is marked by something else, it's very possible that the software would inadvertently include the section headers inside the comment (and possibly other things; e.g., if the user chooses not to sign the long explanation, they might not want that inside their comment either).

This appears to be more or less the same issue as in T188143: VisualEditor does not like TemplateStyles; the <style>...</style> tags are gone and only <span about="#mwt1"> </span> tags are left.

Considering T240696: Make linebreak behaviour consistent regardless of indentation level, the output behaviour for comments would presumably have to change with the introduction of new markup (i.e. multiline list item syntax / multiline comment syntax), since it would no longer be necessary to prefix characters to each line of the output. This would presumably make it easier to introduce new syntax at some point before introducing actions 2 and 3 (or any other action in which a top-level comment is added).

Does the editor currently output any comments without indentation? Currently it can only be used through the “reply” button, so there will always be a parent comment, and so under this behaviour it would always prefix at least one indent.

What happens if the parent comment is deleted or moved? Will the reply be discarded? Or is it expected that the user will only be drafting one comment at any given time?

We divert one of our experienced high-wage-value workers to make this edit.... instead of doing whatever other work they would have done.

I would disagree with two of the assumptions here:

• That Wikipedia editors won't decide to spend more time editing because of such concerns being raised. Contributors typically don't spend 100% of their free time editing, and hypothetically an increase in the number of such valid concerns could encourage a contributor to spend some more time fixing those issues.
• That editors would need to be diverted to resolve the issue. Some editors specifically find value in helping new users (e.g. regulars at the help desk), so it's possible that they would actively seek out such comments on talk pages (e.g. by filtering recent changes to find such comments).

It seems sort of inevitable that if a tool is made easier to use there will be more unproductive things done with it (simply because it will be easier). Perhaps it would be better to, e.g.,

• measure if such edits are being successfully reverted;
• consider methods of actively reducing the rate of such edits.

Why is it preferable to save raw HTML? Wouldn't it be better, from the perspective that wikitext should be as readable and compact as possible, to, say, use a parser function or extension tag (e.g. at start and end, or within the signature) that results in the same HTML being inserted into the page? Doing so would also allow for the parser function/extension tag to be modified without changes to the wikitext (making comments from v1 and v2 of DiscussionTools forward-compatible), and could potentially allow for substituted (i.e. fake) comments to be distinguishable from real comments in some way.

Is the current plan to eventually allow tables to be used without any additional syntactical/formatting difficulty (i.e. would it definitely be possible by version 3)? If so, would changes to the parsing of talk pages be made in the first version?

In T235923#5658799, @matmarex wrote:

In T235923#5639667, @Jc86035 wrote:

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think you're describing just putting the table non-indented after the list item? Which would be a solution to our problem, I guess, but it isn't a great solution. It's not possible to actually indent a table, as far as I know, unless you use HTML syntax for either the list or the table (which is another not-great solution).

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think the easiest way to avoid the transclusion problem, while still using such a parser function, would be to insert the complete HTML of the signature into a parameter of the parser function (or to include it before/after the parser function) and add any other necessary user/revision data in other parameters upon page save. While this would introduce redundancy, it would presumably be easier to implement without breaking certain things; e.g. if the user ID is included as a separate parameter, the new talk page interface could link to the user's current userpage regardless of what username is stored in the signature. (I imagine this could cause issues if talk page discussions were imported between wikis, though...)

Thanks for the link. I hadn't noticed that task.

The syntax that I suggested back in February (during the phase 1 consultation) was:

>4*
[arbitrary wikitext] ~~~~

The number(s) would indicate the indentation level, and the list item after the number(s) would indicate some sort of comment styling (as opposed to being directly analogous to the current list item markers). Use of the new syntax would perhaps be optional (i.e. >4* could be omitted in place of **** or :::*). The metadata would be provided entirely by attributes within an extension tag in the signature (as proposed in T230653).

More or less, an experienced user is going to want to be able to save this sort of comment through any of the available editing interfaces, regardless of the level that the comment is nested at, using the syntax that they learned years ago (or something very close to that).

How is the syntax to get into the page source? Is it going to be saved directly or is something like an extension tag going to generate the HTML?

"Junior contributor" and "senior contributor" strike me as terms that will be confusing and/or have unintended implications (e.g. that users with 500+ edits are unambiguously regarded as having higher seniority), especially since this seems to be the first time they've been used in a MediaWiki context. While I think it does make sense to use the terms, it would probably be worth explicitly defining their meanings whenever they're used (or, alternately, replacing them with more common and/or less ambiguous terms like "experienced contributor").

Would this be generated by an extension tag or parser function, or would that HTML be directly saved into the page by the editor? The former approach would presumably be cleaner in terms of the wikitext source code.

While I am a Flow user and have it enabled on my Wikidata talk page, I do have some reservations about using VE directly without any alternative. I think it's likely that users will complain that there is no non-JS option (see e.g. VE vs. 2010 editor; Old Reddit vs. New Reddit). Furthermore, considering the relatively troubled history of VE, I imagine that it will inevitably face extra scrutiny from experienced users, and it would be disappointing to see this also get stuck in beta indefinitely.

I think it's possible that the inline "reply" button might not be visible enough, since it just looks like a normal link enclosed in parentheses. Perhaps it could be given different formatting to allow it to be distinguished more easily?

This seems like something that could be easily broken by signature customization and possibly page formatting. I imagine matching signature output would work reasonably well if users are cooperative, but that may not always be the case, and it would be preferable to avoid things that don't work with what is currently allowed.

Could you be more specific about what this would entail? (I'm assuming based on your title that you're requesting something different to that proposed in the linked proposal, as the proposal is for archival being requested automatically as soon as an edit is made.)

• It's already possible to archive individual URLs to the Wayback Machine using e.g. Firefox/Chrome extensions (or, of course, the Internet Archive website). Since equivalent functionality already exists outside of MediaWiki/gadgets/user scripts, this would only provide additional functionality for mobile users.
• On the other hand, there is likely a use case for archiving all of the external links in an article; in addition to being less tedious than the former approach, additional functionality (e.g. screenshots, recursive archival) could be accomplished through use of the new Wayback Machine Save Page Now software and its API. It's possible it could be done using a gadget or user script, but I'm not sure if it would be fine from a security standpoint.

@Isarra I'm not sure if there's already a ticket for this, but GeoHack coordinates are misaligned again for me (possibly because of the recent change to where the language links are displayed). It looks like this is because the position is now set based on the top of the prose, so the coordinates usually end up floating above the infobox area. I also have the XTools gadget turned on, which adds additional vertical space between the h1 line and the start of the prose.

Safari 12.1.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

Firefox 68.0.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

There's four-sevenths of a second between each beat, and I don't think the delay exceeds that.

I've reported this in the librsvg issue tracker.

I've checked all of the Wikivoyages' logos. Two of the logos (el, uk) seem to be raster-only; should they be redrawn/vectorized as SVGs?

@LadyofShalott remarks on Wikipedia:Village pump (miscellaneous) on enwiki that the survey keeps reappearing even though she has already responded to the survey.

I don't think it is. Only one of the issues in the search has been updated in the past six months, and it seems to be completely unrelated.

Other examples of this problem (probably simpler examples, in fact, since there's only one mask in each image) are File:BSicon uetkKRZ3+lto.svg and File:BSicon evKRZ3+1o.svg. In the original revisions of both images, attributes on a <g/> element result in the opacity of a <path/> element being inadvertently reduced.

See also T209243: Protection of classes of Wikidata items based on attributes of their statements; it might be more practical to (either additionally or alternately) allow protection of classes of statements (e.g. based on property). This would be somewhat similar to how MusicBrainz requires 7-day review periods for all edits to certain types of data.

Is there an existing procedure for reflecting the page moves and deletions that will occur during the period that Wikidata is read-only?