• no place for subtitles
• no place for additional controls which will be added later for control of embedding and subtitles

Wouldn't it have been possible to just make the box larger on page load, so that subtitles and controls could expand into the empty space?

Thanks for sending the email. I turned off Phabricator notifications some time ago so I didn't see that this was happening. It should be fixed now, since I've removed the temporary files and removed the lines of code in which they were being saved to disk.

This is about Minerva.

This might be related to T68722, but I'm not sure if this particular issue occurs only in Safari or in the app as well.

Are these pages marked in anyway that would let us know they are archived?

Has there been any progress on this issue? Within my watchlist, the distribution of edits seems to remain about the same as it was three months ago:

• A few users are labelling some of the images based on the wheelchair. (Those images form a minority of my uploads but the wheelchair still seems to be by far the most or only recognizable feature.)
• A few users are copying or translating the generic English caption.
• A few users appear to have a fairly poor command of English but are trying anyway, with mixed results (1, 2, 3, 4).
• The rest – including some of the former group – appear to be disseminating their own personal information (primarily names and locations), which could be problematic from a privacy perspective if it's not considered self-promotion.

I don't mean to suggest that someone would actually be using five tildes, because there's no clear application for it. Sometimes people type three or five tildes instead of four by mistake; I've seen it several times. It's often left uncorrected, I think especially in contexts where it's obvious who authored the comment.

if a comment ends in a group of tildes, the automatic signature should only be omitted if the group contains 5k−1 tildes where k is a positive integer

The reason I suggested it in this way is that implementing it in this specific way would have this result:

• Three or five tildes would result in the four-tilde signature being inserted automatically at the end of the comment (in addition to the three/five-tilde signature). The behaviour wouldn't change from the status quo for four tildes.
• For longer strings of tildes, if the string of tildes would result in a four-tilde signature being emitted, then a duplicate one would not be added. However, this is probably unnecessary.

@Izno Would it make more sense to have a blanket ban on all extension tags, rather than just TemplateStyles? I can't see <poem></poem> being useful in this context, for instance. Prohibiting magic words might also be appropriate. That said, the requirements seem to be primarily directed at making parsing easier, whereas the use of TemplateStyles probably wouldn't affect parsing in a meaningful way.

What about making the formatting the same as or similar to the section edit buttons (i.e. "[ reply ]" in Vector and most skins, "reply" with an icon to the left in Timeless)?

No, that's not what I meant. The magic word is not on the subpages (or on some of their parent pages, for that matter), which means that users will not be able to comment on those pages using the extension unless the magic word is added. At the same time, it may be inappropriate to add the magic word (e.g. because the edit button would create the wrong section header level).

As a direct UI comparison, SoundCloud and Spotify's websites display a horizontal bar along the bottom of the screen for audio player controls. Usability-wise, I think something like that (if possible with CSS) would be an improvement over the full screen overlay, which seems unnecessary.

Would it be significantly more difficult to replicate the functionality of the old player? I would consider this a regression, since it would no longer be possible to read and listen at the same time in the same window. (Even if it has to be in a pop-up overlay, it doesn't mean that the overlay has to cover 100% of the screen.)

What about discussion pages in project space that don't use __NEWSECTIONLINK__, such as subpages of project pages like Wikipedia:Articles for deletion? Would communities be expected to add the magic word to all of those pages (or templates on those pages)?

I would note that there are some rare cases where posting "empty comments" is actually done at the moment, such as WikiProjects' lists of users and situations like petitions and votes. It might not really make sense to use this tool to do that, but if the current use cases continue to exist, it may be necessary to allow empty comments to be posted.

But wouldn't a change of the rendering engine also fix T212085?

It might well, but this task has been largely dormant for almost three years. I think that task will probably be resolved some other way.

I don't think it makes sense to change the timestamp display upon hovering by default, since it could be difficult for users to discover this (particularly on mobile). I think it would be nice to have as an option, though. Similarly, I don't think the relative time should be the only string displayed by default, particularly if it isn't made clear whether the string is based on the current time or the time that the page was loaded.

You know, you could just display both...

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.