Talk:Talk pages project/2020

This page is for discussing the Talk pages project. The software interface on this page is Structured Discussions ("Flow"), which is not part of the Talk pages project.

Indentation style

As far as I can see, current prototype of the project still uses wrong syntax for making the threading work. If WMF will develop a script (although I would prefer an extension, since not everyone has JS enabled), please make sure to use the right syntax (***) instead of the wrong one (:::).

As noted on MDN, description list syntax is not intended to be used as a list without bullets, it is intended for entirely different purposes, even if a lot of our users neglect that on forums. Using wrong syntax makes the accessibility and semantics of our pages worse. stjn^[ru] 14:31, 9 January 2020 (UTC)

What if the MediaWiki parser is modified so that in the talk pages only it interprets ::: in a more sensible (semantic) way, while keeping the visual output identical?

Granted, this idea seems to go beyond the scope of this project, but it is somewhat related and I would love to hear why it's insane. Sophivorus (talk) 18:51, 2 April 2020 (UTC)

In theory this could be possible, and it could only make sense to interpret such formatting as indentation rather than as definition lists.

However, the relevant Phabricator task (previously the Bugzilla bug) has been open since January 2006. I don't expect that issue to be resolved in this way. MediaWiki is fragile, and the WMF rarely allocates its limited resources to fixing these sorts of difficult problems. Jc86035 (talk) 07:52, 3 April 2020 (UTC)

In the category of complications, if wikitext markup means something different on different pages, then it'd be hard to discuss content that uses that markup, such as w:en:Disease#Terminology. So either you have to give up on discussing that content 'correctly', or you have to have some system for saying that the other namespaces' rules apply to this one bit of the talk page but not to the rest of it, which adds more complication to MediaWiki.

I think that we can safely predict that no such changes will happen during the next two years (i.e., until the old parser has been removed, and Parsoid is used on all pages). Whatamidoing (WMF) (talk) 21:59, 3 April 2020 (UTC)

AFAIK "*" is only used on Russian wikis for indentation. Many wikis have always used ":". Stryn (talk) 14:39, 9 January 2020 (UTC)

I think in most projects it is, mostly, inconsistent (with different users using both), while in some others, like French Wikipedia, they do prefer :. In the recent years English Wikipedia might’ve adopted : through using tools like Enterprisey’s reply-link, but it’s not uniform either. The same is with more widespread usage of * in Russian wikis due to Convenient Discussions script. stjn^[ru] 15:50, 9 January 2020 (UTC)

On the English Wikipedia, the convention I've generally seen is that * and # are used mainly for "votes" (e.g. RFCs, RFA), and : is generally used for everything else. *'''Support'''. ~~~~ is a fairly common construction even in more informal discussions.

Although the guidelines recommend not mixing indentation styles, I think it's more common to use *:: than ***, and more common to use #:: than ###. Jc86035 (talk) 16:03, 9 January 2020 (UTC)

Editors cannot be faulted for using DL-DD tags to indent, that's the html generator's choice. I think the wikitext syntax (':') and usage is appropriate and the generator should use a different element (maybe '<div class="ind">' with 18 chars compared to the 8 chars of '<dl><dd>'). Or alternatively each comment should be properly marked up with a tag like <post>. There's another topic here that discusses that possibility (I still have to allocate the time to read that though...).

I do occasionally use '*' on enwiki depending on context to separate two long (10 line) comments with the significantly noticeable bullet. As a hack, basically, to make the conversation more readable. Sometimes I'd prefer if enwiki would follow the ruwiki practice of using bullets '***' to mark comments.

As a sidenote: These issues are all the result of using a technology (wikipages) not suitable for the purpose of discussions... —Aron Man.🍂 edits🌾 19:14, 9 January 2020 (UTC)

I think the relevant Phabricator tasks are phab:T230683 and phab:T230658.

Since introducing altogether new markup constructs has been floated by the developers working on this, it seems somewhat likely that that will actually happen; and if new markup is introduced, then reusing any list item syntax to format discussions (as opposed to introducing separate multi-line syntax for list items and discussions) could seem somewhat short-sighted.

As phab:T241388 and phab:T240696 demonstrate, there are some issues with using any of the current list item markup for automatic nesting, because it makes it impossible to use markup consistently (especially with anything involving line breaks). This isn't really an issue in the current software, since it's only possible to write replies, but it will become more apparent if it becomes possible to create new sections and new syntax hasn't been introduced. Jc86035 (talk) 14:42, 9 January 2020 (UTC)

Using specific markup such as <post> for each comment would make it possible to separate comments with eg. a border. The reason to use '***' is to mark this separation. Without that need the "debate" whether to use ':::' or '***' would be rendered unnecessary. Parsing and tooling would be more reliable too.

The price of these benefits is the need to write the comment opening and closing tags if editing the raw page source. —Aron Man.🍂 edits🌾 19:29, 9 January 2020 (UTC)

Hello, I'm not sure how I got notified of this, however, * produces what is called a bullet point. It is used to sign that you have a particular point to make in the particular writing. As for common usage... it can depend which area you are posting in. The most recognisable example is DYK. Bullet points are often used more than anything else in DYK.

Although it may be used numerically more often in votes, the reason for that is, when each post is not indented, which is most commonplace in a list of votes, each bullet point makes scanning and counting through the votes much easier as the eye drifts from bullet point to bullet point to easily see the start of each vote which would otherwise be lost in a wall of indiscriminate looking text. The standard is to use a bullet point accompanied with a word in BOLD text, making each start line very visible and easy to scan.

For discussion purposes, the use of bullet points is easy. It is supposed to be used when making a list of individual points. Often a post will start of with some text introducing the list or other point of discussion, then a list of bulleted points, then some more text to conclude and sign off, and variations on that theme. It's not a Wikipedia theme. It's just adopted by Wikipedia from common formats, i.e. mainly text-book formatting.

Then # produces numbered lists, similar to bulleted points, applications are obvious.

Using (***) or (:::) cannot be uniform in each case because there is a purpose to (***). Forcing one or the other will not improve presentation of text and is unlikely to be accepted, at least on the en.wiki, where most people, although they will use these codes in various ways, will have a good idea of why these tools are useful. It would be like enforcing a spellchecker. You'd come up with no spelling mistakes, but then I couldn't post a word or lettering which is not in the dictionary. How am I supposed to discuss algebra in that case?

In my experience ":::*" is the standard way used to indent with a bullet point (as opposed to "*:::"). The only problem with mixing indentation styles is that posters do not undrstand how to make the length match. If the last post was ":::*" and I indented with "::::" which means another ":" added, the text will not indent. I must add one for the "*" also, and then the text will appear indented.

I may think the reply scheme as linked on the beta bluster is going to be an improvement for several reasons, and support it on strong terms should they be required. However, as someone who types rapidly with about four fingers, I make a lot of errors, which I usually catch as soon as they are made, before posting, but I think I need to be able to edit my text quite easily. I'd like to see the section edit button stay there. I would suggest with both the reply and section edit available in that style, the reply will become the standard used button except for correcting errors. In fact, I'd suggest have an edit button beside the reply button, and a section edit button in this format. I suspect motivation behind removing the edit button may include such things as entering many replies at one time, which can make review of postings difficult. With this new proposed format, I expect that behaviour would become frowned on because it would be much easier to use the reply button.

Sorry for the length, as the old joke goes, I didn't have time to write less.! RTG (talk) 17:01, 9 January 2020 (UTC)

Well, "::*", ":::*", is not read properly by screen readers. It's supposed to be "*", "*:", "*::", "*:::", etc.Each further indent is supposed have a single character added, the character being ":", "*", or "#". Arthur Rubin ^en.Wiki (talk^en.Wiki) 19:34, 9 January 2020 (UTC)

This seems more sensible, and yet, I have noticed this quite specifically because when I indent, I copy the one above having seen discussions before which talk about broken indentation and often having made a post of mixed format only to find the text is not indented. A similar phenomenon occurs on redirects. The standard redirect call is "#REDIRECT" ... yet the system does not require capitals. "#redirect" is fine. (If you'll forgive sharing a pun, according to internet etiquette, this means editors like the page to scream at them when they are making a redirect, but not when they are doing other things...) RTG (talk) 19:45, 9 January 2020 (UTC)

See in the above post, for instance, I needed a couple more commas to make it readable... Need an edit button of some sort. RTG (talk) 17:02, 9 January 2020 (UTC)

Okay I see on this page there are edit buttons (however they didn't work for me and crashed loading:- "An error occurred. The error message received was: http" was the full error text) RTG (talk) 17:04, 9 January 2020 (UTC)

I edited it to put some character formatting on Arthur's comment. I hope that helps.

It sounds like, speaking very generally, ruwiki is mostly getting valid HTML, and everyone else is mostly not (except, e.g., at enwiki's AFDs, which also use lots of bulleted lists).

It's possible to specify list formatting in your reply, but if it's "standard" at a given wiki, perhaps they should consider a way to make the local convention be the default. Whatamidoing (WMF) (talk) 21:01, 16 January 2020 (UTC)

Spanish Wikipedia uses almost exclusively ::: for indentation. Using *** is common when voting, like in the English Wikipedia, but most votes are done on pages that are not in any talk namespace but in the project namespace. Sophivorus (talk) 16:00, 10 February 2020 (UTC)

Edit board description

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Edit description (at the top of the right sidebar) does not work without login, it was of course only a quick plausibility test with a wikilink to the phab page. You need not logged-in beta-testers. 84.46.53.192 (talk) 14:42, 19 January 2020 (UTC)

Yes; that is the correct and intended behaviour. Clump (talk) 14:44, 19 January 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Share a story about starting a new discussion

More information about the work being done to improve the workflow for starting a new discussion can be found on the project page here: Talk pages project/New discussion.

Please tell us a story about starting a new discussion. What worked? What didn't? What was most memorable? Whatamidoing (WMF) (talk) 04:15, 4 March 2020 (UTC)

I could tell stories about talk page discussions I've started but it's more about how the discussion went than the starting it. These days it's easy enough to start a discussion, in my mind, in both a flow and non-flow talk environment so there's not a lot that is memorable about starting the discussion itself for me. To the extent I have a story it was nervousness about putting my thoughts out there and what would or wouldn't happen. Barkeep49 (talk) 15:56, 4 March 2020 (UTC)

Can you say more about your "nervousness"? JKlein (WMF) (talk) 15:03, 5 March 2020 (UTC)

There was one time I started and AFD discussion and a time traveler from 2040 showed up to insult me Praxidicae (talk) 16:13, 4 March 2020 (UTC)

Oooh, a hand-typed forged datestamp! I haven't seen one of those for a while. Whatamidoing (WMF) (talk) 19:11, 4 March 2020 (UTC)

If you start a new section on a talk page, what's your workflow? Do you use the "+" or "New section" buttons at the top? Do you edit the last section and hand-type the ==Section heading== underneath (and hopefully remember to change the section heading in the edit summary, which my wiki-friends often don't)? Do you hand-edit the URL to add ?action=edit&section=new? Whatamidoing (WMF) (talk) 19:14, 4 March 2020 (UTC)

I almost always do == to start == and occasionally will do new section. Often, like on m:SRG, I'll just edit the section above so as not to have to load the whole page and add my own section below the last. Praxidicae (talk) 00:44, 5 March 2020 (UTC)

In this scenario, do you approach it as editing the full page? JKlein (WMF) (talk) 15:07, 5 March 2020 (UTC)

I know the Foundation loves this "story" approach, but this topic seems so basic that I'm having a hard time answering in the requested format. I'm not sure what they're really looking for, but I'll try to run through it anyway.

Starting a discussion is an almost trivial step more than just posting a comment. There are two methods, the +Start_new_section button and the standard EDIT button.

• The +new_section button only allows starting a new discussion at the bottom of the page, which is the standard case. You fill in the subject box, write your comment in the edit box, and sign. Simple.
• The standard EDIT button lets you comment anywhere on the page, and to make a new discussion you merely start your comment with a subject heading. Normally it's a level two ==Subject_heading==, but in some cases you need a ===level_three=== or ====level_four==== heading. The Discussions Tools probably shouldn't try to address use cases other than a standard level 2 heading at the bottom of the page. The other cases are somewhat uncommon and trying to address those cases would make the UI more complicated.

And a question in return: Is the team's design concept that the wikitext EDIT button is for "power users"? And that "non-power-users" won't be using the wikitext EDIT button?

----

By the way, welcome to the product as liaison @Whatamidoing (WMF). As liaison, I was wondering whether it occurred to you to inform the product team that there is a significant community situation brewing in regard to this product? As you are aware, I am in the process of installing a new English Village Pump page for the explicit purpose of organizing the community to address issues with the WMF. And as you are presumably aware, I wrote that my first order of community-business on the new page would likely be to deal with this product.

To help you put the pieces together, before you arrived I made all reasonable efforts to warn that this product has serious design problems. My warnings were ignored. The project manager has stated that he has no intention of fixing the problems. When it became clear that further efforts to discuss the issue would also be ignored, I concluded that repetition would be an unproductive waste of my time and a waste of staff time. I have learned to avoid wasting staff time in that fashion. I have found it is far more productive to move discussions to the community at that point. I intend to propose the product be banned from deployment unless the design flaws are fixed. Alsee (talk) 21:23, 4 March 2020 (UTC)

Alsee I've seen you reference a couple of times the fatal flaws (here and in a phab ticket) but haven't quite figured out what those are after a (minimal) amount of digging. Could you tell me (perhaps at EN as it's a bit off topic here) what those are in your mind? Barkeep49 (talk) 16:01, 7 March 2020 (UTC)

I'm not sure how much of the technicals you're familiar with, so I'll give some background. Back in 2011 the Foundation published a strategy to eliminate wikitext. Talk pages would be replaced with chatboards (Flow). Article pages would dump wikitext and save everything as HTML. Because wikitext was to be eliminated, they built a Visual-type editor with no ability to edit wikitext or wikipages. VisualEditor can only edit HTML. They couldn't immediately eliminate wikitext, so they built a temporary hack to get VisualEditor to work on wikipages. They built something called Parsoid. It goes like this:

1. Parsoid translates the wikitext page into a variation of HTML (HTML/RDFa).
2. VisualEditor edits HTML/RDFa.
3. Parsoid translates the HTML/RDFa back into wikitext.
4. The wikitext is saved.

This is why the early versions of VisualEditor screwed up the wikitext so often, the translation steps. VisualEditor itself actually worked well, but the double translation through Parsoid would cause all sorts of messes in the saved wikitext. The developers put a huge amount of work over the years into various methods for hiding and avoiding those problems.

The Foundation is so obsessed with the VisualEditor strategy that they're still trying to eliminate our wikitext engine and replace everything with VisualEditor's Parsoid engine. When you use the new Discussion Tools to reply, what it does is run part of the existing page content, and the new comment, through Parsoid translating it into HTML/RDFa. That step is utterly pointless, because we're not about to edit it in VisualEditor. Then they run the content through Parsoid a second time, trying to reconstruct the original content. Then they save the reconstructed content. That's dumb, because the reconstructed content is sometimes damaged. They have the original undamaged content, they could simply save the original undamaged content.

The double-translation process is so insanely complicated that it's essentially impossible to predict all of the cases where it will damage the wikitext. One example is that replies containing a table get damaged. Part of the table markup gets lost and it spews raw table markup onto the page. Posting a new comment can also break existing content on the page. (Note: I can't post the example in Flow because Flow has the same problem, Flow screws it up even worse.). You can see the example in this diff. The comment of 08:33, 31 December 2019 contains a /span tag. A few days later the reply of 20:01, 5 January 2020 causes damage to the old comment. The reply shouldn't touch anything in the old comment, but old /span tag vanishes. That causes the red color style to spill out turning the timestamp red and turning the ==welcome== red. In other cases it could cause markup to spill down the entire page messing up every section below it. Alsee (talk) 10:48, 8 March 2020 (UTC)

I'm not sure what's implied by "story". Are we supposed to report something unusual from the usual way we start a new discussion? J. N. Squire (talk) 13:10, 6 March 2020 (UTC)

All of the above, @J. N. Squire! Your usual method, your favorite method, what you remember from the first time you started a new section, the strangest method you ever saw, whatever you want. Whatamidoing (WMF) (talk) 18:49, 6 March 2020 (UTC)

Update

The "Start a new discussion" project page has been published: Talk pages project/New discussion. It contains information about the goals of this work and the questions we are still trying to answer. PPelberg (WMF) (talk) 05:06, 3 April 2020 (UTC)

I know the Foundation loves this "story" approach, but this topic seems so basic that I'm having a hard time answering in the requested format.

This throws me out of kilter, too. I’m good at learning concepts but not remembering anecdotes. “Tell me a story” might suit some people, but I find it alienating.

@Alsee@Whatamidoing (WMF)@J. N. Squire Pelagic (talk) 20:14, 2 June 2020 (UTC)

Summary of the first feedback on the Hungarian Wikipedia

This is the list of the initial feedback people at the Hungarian Wikipedia have shared. Thank you, @Samat for pulling all this information together...

1. T245890: extend the tool to the non-talk pages
2. T249391: enable people to customize the edit summary that accompanies their reply
3. T249072: add a tool of special characters to the forthcoming Reply tool's toolbar.
4. T249579: it can be difficult to understand how comments relate to one another; this is especially difficult in longer conversations.
5. [[Talk:Talk pages project/2020#h-Summary_of_the_first_feedback_on_the_Hungarian_Wikipedia-2020-04-05T16:35:00.000Z|T249579]]: it can be difficult to tell comments apart from one another.
6. T249578: it can be difficult to notice the "Reply" link.
7. T249886: enable people to use the "Reply" tool to post a comment that is not indented.
8. T249889: enable people to sign a (complex, multi-line or formatted) comment in the new line
9. T245225: enable people to edit or modify an already published comment.
10. T232601: enable people to ping or notify the editor whose comment is answered.
11. Resolved: when composing a long comment, the text is jumping/jiggling quickly.
12. T240257: Replying tool cannot restore the inserted text in the event of browser crash/OS restart/accidental closed tab etc.
13. T249577: the tool does not always appear on longer talk pages (multiple times).
14. T234403: enable people to change between the source code and graphical interface during editing.

Hi!

Thank you for your work for this tool!

I try to summarize the comments and suggestions of the beta testers on the Hungarian Wikipedia.

1. Editors expressed a request to extend the tool to the non-talk pages (discussion pages in the Project namespace, in our case) = T245890
2. Request for an option for edit summary = T249391
3. Request for a tool of special characters (similar which is used in the wikitext editor now) = T249072
4. For longer conversations (especially with several participants) it is practically impossible to find out for which comment somebody answered --> indicate this information (on the planned visual surface?)
5. For longer or formatted comments it is not easy to see where is the end of one comment and where the next one starts --> boxes or clear visual separation would be useful (actually, Flow/SD works well here in this sense)
6. Highlight the Reply link to find it, it looks like part of the signature many times (button style?)
7. Option for fitting the text to the left without indentation (it is quite commonly used)
8. Option to sign a (complex, multi-line or formatted) comment in the new line.
9. Option to edit or modify an already published comment.
10. Option to ping or notify the editor whose comment is answered
11. If the answer is longer than the place in the pre-formatted text box, the text is jumping/jiggling quickly as the scroll bar appears and disappears (apparently, this bug was resolved since the box becomes resized with longer text now)
12. Unlike in case of the normal wikitext editor, this one cannot restore the inserted text in the event of browser crash/OS restart/accidental closed tab etc.
13. There is a reported case, where the tool does not always appears on longer talk pages (multiple times). This is now under investigation in order to make it reproducible.
14. As soon as we have the graphical interface for the tool, an option to change between the source code and graphical interface during editing.

You can find most of the comments here (in Hungarian), and one of the testing of the tool here.

Please feel free to ask questions if you need details or explanation about the issues above.

Please feel free to start Phabricator tickets for these issues or indicate the ticket where it exists already.

Samat (talk) 16:35, 5 April 2020 (UTC)

Samat, you had another finding on my talk page: considering that the concept of this solution is indentation, using manual indentation (aka colon) in the beginning of the very first line of any reply must not be allowed (unless there is any other visual aid besides indentation to understand at a quick glance what comment is replied with a new comment). Pasztilla (talk) 16:53, 5 April 2020 (UTC)

I hope that point 4) will be implemented, and then we do not have to think on how can we avoid hacking the system (which is very easy now). (Manual indentation can be useful in some cases, if it does not mislead the conversation.) Samat (talk) 18:43, 5 April 2020 (UTC)

About point #4, is the difficulty that you reply to someone (and you know whom you're replying to, because you know which Reply button you clicked), but I (reading everything later) can't figure it out? Whatamidoing (WMF) (talk) 22:57, 6 April 2020 (UTC)

Exactly. I know that you already saw: already in Pasztilla's test, it is not easy to find out this in case of the bottom comments. We have much longer conversations on discussion pages, where you need to scroll, and even if you have a ruler in your hand, it is not easy :) If somebody uses a formatted paragraph or lists for example, it is already not easy to understand even if they are close to each others.

I understand, that this is a clean solution for the software, but humans don't typically follow algorithms :) I haven't made research on this topic, but I believe that we tend to add comments and replies below each others without indentations, and if somebody would reply to an earlier comment in the middle of a conversation, they use indentation and insert the reply just below the actual comment. That way the directly connected conversations stay closer to each others, and easier to follow for others read them later. Samat (talk) 21:35, 7 April 2020 (UTC)

I can say, that quite much the same how this surface works right now. Samat (talk) 21:36, 7 April 2020 (UTC)

@Samat it is wonderful to see all of the feedback in one place – thank you for bringing everyone's feedback together!

I, like @Whatamidoing (WMF), have a few follow up questions. I am going to post these questions in separate posts below*.

Before this, I've done two things:

1. Added the Phabricator tickets you've linked (thank you) to this discussion thread's "Summary."
2. Added responses to some of the feedback you shared below.

Comments on feedback

9. Option to edit or modify an already published comment.

This is functionality we've started working on in task:T245225. Although, we are not able to share a specific date for if/when this will be enabled. More details about the status of this work can be found here: T242562#5977993.

11. If the answer is longer than the place in the pre-formatted text box, the text is jumping/jiggling quickly as the scroll bar appears and disappears

We're glad to hear this is no longer an issue. Although, if you or others notice this happening, please let us know.

12. Unlike in case of the normal wikitext editor, this one cannot restore the inserted text in the event of browser crash/OS restart/accidental closed tab etc.

We are investigating this. See: task:T240257.

13. There is a reported case, where the tool does not always appears on longer talk pages (multiple times). This is now under investigation in order to make it reproducible.

We are investigating this. See: task:T249577 PPelberg (WMF) (talk) 00:34, 7 April 2020 (UTC)

13. There is a reported case, where the tool does not always appears on longer talk pages (multiple times). This is now under investigation in order to make it reproducible.

We are investigating this. See: task:T249577

@Samat I think we have resolved the issue above. I'm going to comment in the original thread [i] to be sure.

---

i. https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Konzult%C3%A1ci%C3%B3_a_vitalapokr%C3%B3l_%C3%A9s_a_k%C3%B6z%C3%B6ss%C3%A9gi_kommunik%C3%A1ci%C3%B3r%C3%B3l&type=revision&diff=22444702&oldid=22433317&diffmode=source PPelberg (WMF) (talk) 00:49, 10 April 2020 (UTC)

1. Editors expressed a request to extend the tool to the non-talk pages (discussion pages in the Project namespace, in our case) = T245890

@Samat: what do you think about using the presence of __NEWSECTIONLINK_as the signal for whether people can use the Reply tool on pages outside of talk namespaces on hu.wiki?

I ask considering there seems to be a relatively small number of pages on hu.wiki using __NEWSECTIONLINK__. See: Speciális:Keresés. PPelberg (WMF) (talk) 00:46, 7 April 2020 (UTC)

I am not completely sure yet. I've checked the pages where we use this magic word now, and majority of them are not real discussion pages. If the decision will be, that the __NEWSECTIONLINK__ is connected to the Reply tool, we need to reconsider how we use it and clean up the wiki before we introduce this feature.

(Thank you very much for organizing and summarizing our comments, and for working on them! I will continue answering the questions tomorrow: I need to sleep a little bit before...) Samat (talk) 21:52, 7 April 2020 (UTC)

This makes sense. I think it will be best for us to continue this conversation on the ticket where the conversation about__NEWSECTIONLINK__ being implemented is happening.

As such, I've coped the comment above over to said ticket: T245890#6038413.

(Sounds great and you bet ^ _^ ) PPelberg (WMF) (talk) 00:44, 8 April 2020 (UTC)

hey @Samat – quick update: the Reply tool should now be available on pages that contain the following wikitext: __NEWSECTIONLINK_

PPelberg (WMF) (talk) 18:40, 17 April 2020 (UTC)

4. For longer conversations (especially with several participants) it is practically impossible to find out for which comment somebody answered --> indicate this information (on the planned visual surface?)

5. For longer or formatted comments it is not easy to see where is the end of one comment and where the next one starts --> boxes or clear visual separation would be useful (actually, Flow/SD works well here in this sense).

@Samat: are you able to ask the person/people who shared this feedback (@Pasztilla, maybe it was you?) for a link to the talk page(s)/conversation that inspired this thought.

I've written how I am understanding their feedback below and I want to be doubly sure we (this person/these people) are thinking about this similarly!

What I am understanding "4." and "5." above to mean:

A) It can be difficult to understand how comments relate to one another; this is especially difficult in longer conversations..

B) It can be difficult to tell comments apart from one another. PPelberg (WMF) (talk) 00:56, 7 April 2020 (UTC)

It was a conclusion of the quick test we made together with Pasztilla on his discussion page.

4 or A) tries to describe the situation, when the comment and reply to that comment are in a larger distance, and it is difficult to find out the relation or connection.

5 or B) tries to describe the situation, when the following comments have formatted text and/or links, and they look like as one comment.

Did you mean the same?

Point 4. is more critical: on community discussion pages one section can be several pages long, and if somebody answers to the first person, their answer will be sooo far, that nobody can find out that it is an answer for the first person. I think (and others have the same opinion), that type of indentation is not the right approach, see my explanation in my answer to Whatamidoing above. And we didn't try out yet what happens after 100 replies in a conversations (if the indentation should be wider than the page itself). I think the logic what Flow/Structured discussions use here is more suitable for the wiki environment. Samat (talk) 21:33, 8 April 2020 (UTC)

4 or A) tries to describe the situation, when the comment and reply to that comment are in a larger distance, and it is difficult to find out the relation or connection.

Understood! I suspect this is an issue we will address when we begin working on visual improvements to talk pages. In the meantime, I've represented what you've reported on this ticket where we are gathering information: T249579.

Please let me know if you think the ticket could be made more clear.

5 or B) tries to describe the situation, when the following comments have formatted text and/or links, and they look like as one comment.

Are you able to share an example of the kind of comments you have in mind? I didn't see, what looked like the kind of comment you were describing on Pasztilla's discussion page. In the meantime, I've added this issue to that same ticket where we are gathering information about the visual improvements we will explore later in this project: T249579.

PPelberg (WMF) (talk) 01:12, 10 April 2020 (UTC)

7. Option for fitting the text to the left without indentation (it is quite commonly used)

@Samat: this sounds like [1] people are requesting the ability to start a "new" discussion thread within an existing section by posting a comment that is not indented at all...am I understanding this correctly? And if so, are you able to describe the scenario(s) when functionality like this would be useful? Even better if you are able to share links to specific conversations where people are posting comments within existing discussions that are not indented.

1. https://hu.wikipedia.org/w/index.php?title=Wikip%C3%A9dia%3AKonzult%C3%A1ci%C3%B3_a_vitalapokr%C3%B3l_%C3%A9s_a_k%C3%B6z%C3%B6ss%C3%A9gi_kommunik%C3%A1ci%C3%B3r%C3%B3l&type=revision&diff=22425422&oldid=22425327 PPelberg (WMF) (talk) 01:04, 7 April 2020 (UTC)

Yes, this is what Pasztilla mentioned in that comment. The situation is, when somebody would like to say something about the topic (described in the section title), but their comment is not a direct reply to anybody.

More generally, there are two basic types of usage of indentation in the wikitext conversations: one is always reply with one more semicolon (more indentation), and the other, which never (or rarely) uses and answers without any indentation. I personally use a mix of these two approaches :) Samat (talk) 21:48, 8 April 2020 (UTC)

Thank you for clarifying this, @Samat. This is clear to me know. I've created a ticket for this issue which you can see here: T249886. I've also updated the conversation "Summary" to include this ticket. PPelberg (WMF) (talk) 23:41, 9 April 2020 (UTC)

8. Option to sign a (complex, multi-line or formatted) comment in the new line.

@Samat: is the "example" below what you understand people to be requesting? If so, why do you think people might be requesting this functionality? If they are easy to locate, it would be great to see a link to a conversation where people are posting comments in this way.

Example

: The first line of my comment.

: The second line of my comment.

: The third line of my comment.

: The fourth line of my comment.

: PPelberg (WMF) (talk) 01:10, 7 April 2020 (UTC) (reply) PPelberg (WMF) (talk) 01:09, 7 April 2020 (UTC)

Exactly. For example I use that formatting quite often, see for example the actual sections on the News village pump:

• development of the discussion pages
• editathon about the Roma culture
• new blog posts in the Hungarian Wikipedia Magazine.

I choose this type of formatting if the comment is longer, has more paragraphs or a list. In this case, it is closed visually better and it makes very clear that this is a block of comment, if the signature is in a new line. For example, if I signed it at the end of the last element of the list, it would look like I answered the previous paragraph (where somebody forgot the signature) because of the indentation. Samat (talk) 22:05, 8 April 2020 (UTC)

The links you shared made what you were describing abundantly clear...thank you for sharing them, @Samat.

I've created a ticket for this issue (T249889) and added it to the "Summary" above.

---

A separate, but related question: have you gotten feedback from other people that adding your signature on a separate line helps them read your comments more easily? If so, do you recall what they've said? Please don't worry if nothing comes to mind. PPelberg (WMF) (talk) 00:09, 10 April 2020 (UTC)

I've posted a "work around" method for achieving this in a comment at phab:T249889. It was inspired by seeing this edit. Whatamidoing (WMF) (talk) 19:14, 17 April 2020 (UTC)

I posted another workaround at the same phab ticket.

Like Samat, I will usually sign on a new line if I'm making a multi-para comment, and same-line if single paragraph. I feel it's more readable but haven't received any feedback for or against. Pelagic (talk) 18:35, 11 May 2020 (UTC)

Or I thought I did. My comment there seems to have disappeared.

Maybe I somehow closed/lost the tab without hitting Submit? Pelagic (talk) 19:02, 11 May 2020 (UTC)

10. Option to ping or notify the editor whose comment is answered.

@Samat: this seems to be one of the the comments where this feedback surfaced...are you able to figure out which of the following people are requesting?

1. An easier to way notify someone else (e.g. by @ mentioning them)
2. An easier way to be notified when someone else responds to you
3. Both of the above? Something else entirely?

PPelberg (WMF) (talk) 01:13, 7 April 2020 (UTC)

Option 1. Several editors asked if the answered person (whom reply link was clicked on) receives a notification. Pagony suggested here that that person should be automatically (without using @ or similar) notified, but I don't think it is a good idea, because it would result in extreme noise. But an easy option for that (like @ here) would be useful, indeed.

Note: Pagony also requested in the linked comment an option for choosing if the answer arrives the replied person's talk page or stays on the original talk page. I left this request out from the list above, because I think this does not fit to the direction of this development. Samat (talk) 22:16, 8 April 2020 (UTC)

I agree that automated pinging would raise the noise level, and we rather would need to serve existing user behaviors for such cases: 1) direct ping in the reply (already possible with the tool), 2) ping in the edit summary (would be possible by enabling edit summary option). Pasztilla (talk) 04:38, 9 April 2020 (UTC)

Thank you for filling in the details here, @Samat and @Pasztilla.

Introducing an easier way to notify someone specific (read: ping or @ mention) is a feature we are planning to introduce in Version 2.0 of the Reply tool.

In fact, the design of this functionality is something we are actively talking about here. If either of you (or anyone else!) has thoughts to share, we would value you sharing them in this conversation. You can also follow our work implementing this functionality in this task: T232601.

Now, on the topic of being notified when someone responds to you...

I think we would need to do more research before we implementing a feature that makes it so people are automatically notified anytime someone responds to something they have said. And this is research we plan to do as part of our effort to make it easier for people to stay up-to-date about conversations that are relevant to them. We are tracking this work in this task: T233447.

On this broader topic of notifications...

@Samat / @Pasztilla: how do you typically find out someone is requesting your input? Updates on your watchlist? Echo notifications? Something else? PPelberg (WMF) (talk) 00:32, 10 April 2020 (UTC)

One more suggestion came into my mind: an option for Thank a comment (without using the Page history) would be very useful. It is often used to indicate that we read the comment, if we do not want to answer it. Or just for traditionally saying thank you for it :)

I missed out several positive comments about the new Reply tool. I wanted to share with you what are the suggestions and requests, but positive feedback is feedback as well. For example it handles well the edit conflicts or the unnecessary empty lines. Or the preview is accurate and works smoothly. It is not the case that it received only negative comments :) Samat (talk) 22:15, 8 April 2020 (UTC)

...an option for Thank a comment (without using the Page history) would be very useful. It is often used to indicate that we read the comment, if we do not want to answer it. Or just for traditionally saying thank you for it :)

I'm glad you raised this idea, @Samat! This is something we've been wanting to explore and you saying something about it is the prompt I needed to file a task: T249893. PPelberg (WMF) (talk) 01:53, 10 April 2020 (UTC)

I missed out several positive comments about the new Reply tool. I wanted to share with you what are the suggestions and requests, but positive feedback is feedback as well.

I appreciate you saying this, @Samat – I will pass it on to the rest of the team who will be glad to hear it ^ _ ^

Thank you again for the work you're doing to inspire people to share their feedback and bring it to us here. PPelberg (WMF) (talk) 01:56, 10 April 2020 (UTC)

Editing news 2020 #1 – Discussion tools

Read this in another language • Subscription list for this multilingual newsletter

The Editing team has been working on the talk pages project. The goal of the talk pages project is to help contributors communicate on wiki more easily. This project is the result of the Talk pages consultation 2019.

The team is building a new tool for replying to comments now. This early version can sign and indent comments automatically. Please test the new Reply tool.

• On 31 March 2020, the new reply tool was offered as a Beta Feature editors at four Wikipedias: Arabic, Dutch, French, and Hungarian. If your community also wants early access to the new tool, contact User:Whatamidoing (WMF).
• The team is planning some upcoming changes. Please review the proposed design and share your thoughts on the talk page. The team will test features such as:
  • an easy way to mention another editor ("pinging"),
  • a rich-text visual editing option, and
  • other features identified through user testing or recommended by editors.

To hear more about Editing Team updates, please add your name to the "Get involved" section of the project page. You can also watch <figure-inline></figure-inline> these pages: the main project page, Updates, Replying, and User testing.

– PPelberg (WMF) (talk) & Whatamidoing (WMF) (talk)

19:05, 8 April 2020 (UTC)

MediaWiki message delivery (talk) 19:05, 8 April 2020 (UTC)

If you're watching this page, remember that we want your ideas about that second screenshot. See Talk pages project/replying#Version 2.0 for more information. Whatamidoing (WMF) (talk) 19:16, 17 April 2020 (UTC)

Chinese Wikipedia decides to join the trial stage of new talk page design

T251075: Enable DiscussionTools as a beta feature on zhwiki

Two weeks ago, I raised a discussion: will Chinese Wikipedia want to join the trial stage of new talk page design? According to the today's result, most users agree to join this test. We wish that Chinese Wikipedia can join the next trial stage. Thanks. Taiwania Justo (talk) 01:57, 23 April 2020 (UTC)

@Taiwania Justo, we are thrilled to see zh.wiki organize as quickly as you all have to request DiscussionTools be enabled on your wiki.

Although, before we can deploy these tools to more wikis, our team needs to finalize our strategy for how we will increase the number of wikis we are partnering with while continuing to be responsive to feedback.

You can expect more details from us about the "strategy" I mentioned above before the end of next week (8-May).

Also, here is the Phabricator ticket @VulpesVulpes825 created about the idea you raised: T251075. PPelberg (WMF) (talk) 20:48, 27 April 2020 (UTC)

• 
  Caption1
• 
  Caption2

• 
  Caption1
• 
  Caption2

• File:! Header text !! Header text !! Header text

</gallery> </gallery>== Where does the tool work ==

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I would like to better understand where will the tool work after the foreseen changes. I am making some statements. Could you please confirm, make it more precise or explain why are they false?

1. The Reply tool will be available on all pages in the namespaces defined by the wgExtraSignatureNamespaces parameter in the InitialiseSettings.php
2. The Reply tool will be available on pages using the __NEWSECTIONLINK__ magic word, independently from in which namespace they are.
3. According to these settings the wgExtraSignatureNamespaces defines only the Project (=Wikipedia) namespace for the Hungarian Wikipedia (there is no Help namespace). Will this be the case after deployment?
4. The Reply link will appear only after a single line (paragraph) which contains a linked username or a linked user talk page AND a full time stamp, not necessary at the end of the comment (see my test). Samat (talk) 13:40, 1 May 2020 (UTC)

I don't understand completely the algorithm in point 4. yet, because the Reply link appears if I link a user talk page using the localized names "User vita" or "Szerkesztővita", but does not appear if I use the original "talk_page" or "talk page" characters in the link. Samat (talk) 13:44, 1 May 2020 (UTC)

1. This is the new approch, yes. See T249036.
2. Currently, the tool will be available in 3 different ways. If the URL parameter ?dtenable=1 is detected or if the namespace is in $wgExtraSignatureNamespaces or if the magic word __NEWSECTIONLINK__ is detected, independently from the namespace.
3. I do not understand the question.
4. These are the conditions, yes. I do not see any test with the original name of the namespaces. I am not a developer of the extension, but it should work. Lofhi (talk) 18:07, 1 May 2020 (UTC)

Thank you, your answers are very useful!

3. I think I understand the code part, which means that only the Project (=Wikipédia) namespace is under the wgExtraSignatureNamespaces now, in case of the Hungarian Wikipedia. The question was more if there will be any change of the definition in the InitialiseSettings.php (in my understanding, the settings will not be changed, I just wanted to be sure).

4. The mentioned examples are in the first two lines of the last group of test replies. Samat (talk) 21:00, 1 May 2020 (UTC)

I don't think it matters. I said that if the namespace is in $wgExtraSignatureNamespaces the tool is activated because they are checking if the namespace of the page you are editing is in the array $wgExtraSignatureNamespaces. default impacts all the wikis when the site configuration object per wiki is created. The absence of the namespace help on this edition of Wikipedia should not be a problem.

On your examples, there is a word between the user (talk) page and the date. I think it's on purpose. Lofhi (talk) 23:56, 1 May 2020 (UTC)

Only for the "example": yes, the included Text is on purpose there, but it doesn't have any effect on the tool (as I tested already before in the same section). Samat (talk) 17:28, 3 May 2020 (UTC)

1, 2: What Lofhi wrote is correct.

3: We're not planning to change which namespaces are included in wgExtraSignatureNamespaces, if that's what you're asking.

4: Yes, that's how it works. Both the English and the localised namespace names should work. On your testing page, it looks like some of the signatures don't get the "Reply" link because the timestamp is in the wrong format, e.g. missing the "1." after the "május" (it must be exactly the format generated by typing tildes). You can use the ?dtdebug=1 parameter to figure out how the tool is interpreting a discussion, it will highlight the detected signatures and comments, for example: https://hu.wikipedia.org/wiki/Szerkesztővita:Samat?dtdebug=1#Text_test Matma Rex (talk) 16:32, 4 May 2020 (UTC)

Thank you, @Matma Rex All my questions are answered now.

About 4: I didn't realize that I copied a line without the day (that was part of my earlier test, some lines above). The debug feature is quite cool! :) Samat (talk) 19:41, 4 May 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

DiscussionTools vs. Replying tool

What is the difference between the expressions in the title?

From some messages I have the impression, that the tool which shows the Replying tool/Reply link is different from the DiscussionTools. Are the DiscussionTools broader toolsets, a different tool or just name of the extension with the Replying tool (1.0, 2.0 etc.)? Samat (talk) 16:09, 1 May 2020 (UTC)

Meanwhile, I've found the page Extension:DiscussionTools and a sentence on the Talk pages project/replying: "The replying feature is implemented via the DiscussionTools extension." But any further explanation is welcomed :) Samat (talk) 17:20, 1 May 2020 (UTC)

DiscussionTools is a new feature. One of the tools of this feature is the Replying tool. Lofhi (talk) 17:35, 1 May 2020 (UTC)

Thank you Lofhi! What other tools/features are (or are planned) part of the DiscussionTools beside the Replying tool? Samat (talk) 18:04, 1 May 2020 (UTC)

They are currently working on allowing you to edit your own comments, I think they're adding adding a ping-user menu item, and I expect they will add support for starting a new discussion(section).

More broadly, there is also a request to be able to watchlist sections (rather than watching the full page), and I think they are considering working on an archiving system. However I don't believe either of those ideas has any formal status at this point. Alsee (talk) 23:12, 1 May 2020 (UTC)

They are very useful information! This means for me, that the Replying tools expression covers only the Reply button and its functionality, but if we talk about the extra features around the input field are already only part of the DiscussionTools. Naming is important if we would like to talk about the same things :)

I thought, the planned Watch this page option is about watching the whole page, but if it is about watching the specific section only, it makes sense for me. Samat (talk) 08:33, 2 May 2020 (UTC)

The Watch this page option is a whole-page watch.

Section-watchlisting is only an idea/request at this time. Alsee (talk) 18:53, 3 May 2020 (UTC)

There's talk of adding new markup to better indicate the start &/or end of comments. Either something specifically for comments, or a general mechanism for nesting multiple block-level elements into wikitext that would normally finish at a line-break. (I'd like both, but that's a separate conversation.) Pelagic (talk) 21:52, 18 May 2020 (UTC)

For the time being, another tool is under development. No official name, but we can name it like "New discussion tool". Lofhi (talk) 18:11, 1 May 2020 (UTC)

[OP Samat closed the topic, so forgive me for re-opening.]

From what's been said above, I'd say that for clarity we should use the term Discussion Tools only for features that get rolled into the extension of the same name. Other talk page changes probably deserve a different umbrella term(s).

Likely to be part of DT:

• Reply
• @-mention
• Edit comment in-place

Maybe?

• New topic/subject
• Changes to wikitext markup for start/end of comment Pelagic (talk) 21:22, 18 May 2020 (UTC)

Timestamping messages

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Why are posts timestamped with ambiguous timestamps such as "yesterday" and a "a month ago" and not with what wikipedians are accustomed to, for example "19:02, 11 May 2020" ?

(edit summary: I don't know if this is the correct place to ask such questions?) Ottawahitech (talk) 21:27, 12 May 2020 (UTC)

You're talking about this interface (which is Flow)? They did some user research, and relative time stamps are less likely to be misunderstood. (It makes sense. I've replied to a "11 May" message on wiki, and only later noticed that it was from 11 May in a different year.) The Talk pages project itself won't change the format of the date stamp. Whatamidoing (WMF) (talk) 23:14, 12 May 2020 (UTC)

Sorry, but I have to disagree. Look at older posts like this one. Almost everything is marked as being written "4 months ago", like it was all written the same second, by the same person, or a spam bot, or a database field was accidentally destroyed. I find this hilarious. Was a response written a minute later? A day? A week? I can't tell. Yes, I know I can hover to get a timestamp, but this is not helpful. It especially doesn't allow me to compare the timestamps of multiple posts, as I can only see 1 at a time.

Sorry for picking this up, as it is indeed unrelated to what your team currently does. But I feel it's worth mentioning to avoid repeating the same mistake. Thiemo Kreuz (WMDE) 06:48, 13 May 2020 (UTC)

I agree with Thiemo Kreuz. The same day it might be helpful to see "2 minutes" ago, but the next day it already becomes troublesome to know the time difference between the replies because it says "yesterday" and not the actual date and time. Smile4ever (talk) 09:07, 13 May 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Supported wikimarkup

The Discussiontool Reply tool support some wikimarkup, but not all. Where can I find a list of supported wikimarkup? Which markups will not or never be supported? Ad Huikeshoven (talk) 12:52, 15 May 2020 (UTC)

Are you more concerned about content already on the page (which will cause the Reply tool to disappear), or about content inserted via the Reply tool? Whatamidoing (WMF) (talk) 19:18, 18 May 2020 (UTC)

About what can and cannot be inserted in the text field via the Reply tool. Ad Huikeshoven (talk) 07:43, 19 May 2020 (UTC)

As a general rule:

• Things that fit on one line of wikitext will work – including bold/italic, links, and most HTML tags
• Things where the syntax requires line breaks will not work – including tables, parser tags like <gallery>, headings
• Also, despite requiring line breaks, lists will work

We haven't documented the details since it's difficult to document them clearly, these are very arbitrary limitations caused by the fact that comments on talk pages are written using list syntax. We could document that you can have a gallery with one image but not two, or that you can have a table only if the previous comment was indented without a bullet point (yes, this is really true), but you'd go crazy reading that documentation.

We have some ideas about introducing multi-line list item syntax to wikitext, which would allow all wikitext in comments, but we haven't had much time to work on it yet. Matma Rex (talk) 17:44, 19 May 2020 (UTC)

Let me think. The limitation is because wiki text doesn't have multi-line item syntax, so it is not a limitation caused by the reply-tool. Stated otherwise, if in source mode the syntax won't work when the first line starts with * or #, it won't work in the reply-tool. Or, if someone wants to input wiki text that has to start at the first position of a line, they can't use the reply tool. (And frankly, that wouldn't make sense to me to do either). This is an expectation and perception issue. People wrongly perceive the left border of the textfield of the reply tool as the start of a line in wiki source mode, which it isn't. Could there be away to overcome this perception issue and set expectation correctly? For example showing the :, * and # on the first line to the left and outside the textfield that are going to be inserted by the reply tool? Ad Huikeshoven (talk) 06:26, 20 May 2020 (UTC)

This is a possible solution however we are hesitant to clutter the interface this early on. We will soon have wikitext and visual modes, and the assumption is that the wikitext mode will be used by people who are familiar with the limitations of indented comments on talk pages. In the visual mode we are able to control which features are available to the user (e.g. we can hide the tool for inserting tables). Furthermore the live-preview allows users to experiment with what "works" at the moment. It may also be possible to provide a documentation link in addition to our current "feedback" link.

As Whatamidoing states below, our long term ideal solution is to be able to create a multi-line context in wikitext: T246960 ESanders (WMF) (talk) 11:24, 21 May 2020 (UTC)

But it might be nicer to make it actually work, instead of setting an expectation (for experienced editors) that it shouldn't work. Whatamidoing (WMF) (talk) 20:40, 20 May 2020 (UTC)

As @Ad Huikeshoven said the solution is to show the indentation markup, and to allow the user to change or delete it if necessary. That allows all markup, just like the Edit button does. Alsee (talk) 00:11, 21 May 2020 (UTC)

@Alsee, thanks for your suggestion. I didn't suggest to allow the user to change or delete the indentation markup. However, I am willing to support an opt-in only reply-tool variant which will show an unindented textfield for input prepolated with editable indentation markup. That would suit your needs. As long as that doesn't happen you can use source mode to add for example a table in a reply. You know how to do that. You don't need the reply tool for that. Ad Huikeshoven (talk) 10:20, 23 May 2020 (UTC)

New talk pages tools on the Konkani Wiktionary

We, the Konkani Wiktionary community, would like to have the new talk page tools on the Konkani Wiktionary. Specifically, some users have been interested in the reply link. I have posted a message on the community discussion page regarding this.

To give you some background, the Konkani community working on the Konkani Wikipedia have found it difficult to handle the syntax of Wikitext discussion pages. This is probably one of the factors that has led to most of our discussion being held off-Wiki (on WhatsApp). The Discoverer (talk) 08:22, 23 May 2020 (UTC)

Pinging @Whatamidoing (WMF) The Discoverer (talk) 09:58, 28 May 2020 (UTC)

Thanks for the note. I've put it on the list for the team to consider. Whatamidoing (WMF) (talk) 02:24, 1 June 2020 (UTC)

Editing news 2020 #2

Read this in another language • Subscription list for this multilingual newsletter

This issue of the Editing newsletter includes information the Talk pages project, an effort to help contributors communicate on wiki more easily.

• Reply tool: This is available as a Beta Feature at the four partner wikis (Arabic, Dutch, French, and Hungarian Wikipedias). The Beta Feature is called "Discussion tools". The Beta Feature will get new features soon. The new features include writing comments in a new visual editing mode and pinging other users by typing @. You can test the new features on the Beta Cluster now. Some other wikis will have a chance to try the Beta Feature in the coming months.
• New requirements for user signatures: Soon, users will not be able to save invalid custom signatures in Special:Preferences. This will reduce signature spoofing, prevent page corruption, and make new talk page tools more reliable. Most editors will not be affected.
• New discussion tool: The Editing team is beginning work on a simpler process for starting new discussions. You can see the initial design on the project page.
• Research on the use of talk pages: The Editing team worked with the Wikimedia research team to study how talk pages help editors improve articles. We learned that new editors who use talk pages make more edits to the main namespace than new editors who don't use talk pages.

– Whatamidoing (WMF) (talk)

20:29, 17 June 2020 (UTC)

MediaWiki message delivery (talk) 20:29, 17 June 2020 (UTC)

Managing old discussions

Hello Editing team, I have seen that two of the areas the talk pages project is focussed on are:

• Replying to specific comments
• Starting a new discussion

Based on our experience in the Konkani community, these are important aspects of talk pages where those uncomfortable with Wiki-syntax usually struggle.

I would like to highlight another important area that I have noticed: managing old posts. Eventually, high-use talk pages become very long, and it is desirable to have some kind of archiving system like the bots on the English Wikipedia, or an unlimited scroll with loading-on-demand like Structured Discussions has. For a small community like ours, not having a lot of technical skill to implement bots, it would be ideal if such a system were built into Wikimedia. Have you considered this aspect as part of the task pages project? The Discoverer (talk) 11:47, 18 June 2020 (UTC)

pinging @Whatamidoing (WMF) The Discoverer (talk) 11:48, 18 June 2020 (UTC)

Hello, and thank you for your note.

Archiving was discussed in the consultation last year (see Talk pages consultation 2019/Phase 1 report#Archiving for a summary). The bot-based approach to archiving is complicated because it makes it hard to find previous discussions. But, of course, keeping everything on the page, especially since most wikis don't follow the modern internet convention of top-posting, leads to very long pages. This is particularly bad for editors using smartphones, who have to load and scroll through the whole page to reach the most recent discussion. Loading on demand works best with top-posting.

I agree with you that some archiving ought to be handled automatically. The Editing team is thinking about the possibility of improving some aspects of this situation. Unfortunately, I do not think that a real solution will be implemented during the next year. Whatamidoing (WMF) (talk) 16:48, 18 June 2020 (UTC)

Hello Whatamidong, thanks for your reply. I was a bit disappointed to know that a solution is not on the horizon. It appears that we will have to look at implementing a bot-based system for the newly-launched Konkani Wiktionary.

You mentioned that "most wikis don't follow the modern internet convention of top-posting". Do any Wikimedia wikis use top-posting for discussion pages (apart from Flow boards)? Is this possible or feasible?

In my previous comment, I meant to say "it would be ideal if such a system were built into MediaWiki". The Discoverer (talk) 19:16, 18 June 2020 (UTC)

@The Discoverer: , can you elaborate on what the exact problem is with very long Talk pages? Is it that scrolling through the page to find the right discussion is cumbersome or takes a long time, or that the page takes a long time to load in areas of slow internet speed, or something else? If it's a scroll problem, there might be a solution involving rolling up/collapsing the sections by default. Mathglot (talk) 18:38, 12 July 2020 (UTC)

@Mathglot, navigating and handling a long page is the issue felt first, when a page already has around 50 discussions. At this stage, the page size tends to be around 100kB. Loading time would probably come into play at a later stage, or if there are a lot of images, which usually doesn't happen on discussion pages.

I guess if the sections are collapsed by default and you reach around 100 discussions, it would still mean quite a bit of scrolling.

I think it would be great if either an archival system, or a loading-on-demand system (like Flow) were built into MediaWiki. The Discoverer (talk) 08:57, 13 July 2020 (UTC)

@User:The Discoverer, as a practical matter, I use w:Template:Skip to bottom on my Wikipedia user talk page. That would work on mobile view as well, I believe. Still not a solution for long-loading pages, but should get you to the most recent discussion quickly. I added gom:सांचो:Skip to bottom

but you might need to tweak it for your environment. Mathglot (talk) 19:26, 21 July 2020 (UTC)

@Mathglot, thanks for that. I will add the template to gomwiktionary too. It does not seem to work in mobile view, though.

In an earlier comment you mentioned tere might be a solution involving rolling up/collapsing the sections by default. The Discoverer (talk) 04:38, 22 July 2020 (UTC)

User:The Discoverer, are you comfortable altering the gom Template, to add the text "Skip to TOC" and "Skip to bottom" in Konkani? If not, if you paste the words below, I will add them for you. "TOC" is an abbreviation for "Table of Contents" in English. If an analogous abbreviation exists in Konkani, that would be preferable; otherwise, the translation of "Skip to Table of Contents / Skip to bottom" would be best. Mathglot (talk) 20:32, 22 July 2020 (UTC)

Thanks @Mathglot. I think I can handle localising the template. Since the Konkani community use the interface in the Latin and Devanagari scripts, I intend to make use of MediaWiki messages so that users can see the text of the template in their preferred script. I'll ask you for help if I get stuck. The Discoverer (talk) 10:16, 23 July 2020 (UTC)

Check this out.. the user sees the template contents in his/her own interface language :)

Template:skip_to_bottom?uselang=gom-deva

Template:skip_to_bottom?uselang=gom-latn

Template:skip_to_bottom?uselang=en The Discoverer (talk) 09:44, 25 July 2020 (UTC)

I believe it's by design; not sure if it has to do with the "float" properties of that Template, but if I get enough time, I could probably figure it out.

As WaId commented below, they are rolled up on mobile view by default. Rolling them up by default in desktop view would, I believe, be a software change, although possibly it could be done by a bit of javascript that would look for your H2 sections on your talk page, and use the Before property to add a collapse bottom template (for the previous section), a blank line, and a collapse top (for that section) right under the header, and then you could stick that in your w:Special:MyPage/common.js. However, only you would see it that way, everyone else would see it expanded. You could add it to the gom-sitewide common.js, I believe, if there was Community support for that, and then everyone would see it that way. Mathglot (talk) 06:12, 22 July 2020 (UTC)

The w:en:WP:TEAHOUSE originally used top-posting, but has since switched to bottom posting. I believe that conforming to the typical (Wikipedia) style was a significant factor in that decision. In Wikipedia's early days, neither top-posting nor bottom-posting were used. If you're interested in a bit of history, then Talk pages consultation 2019/Discussion tools in the past might be worth reading. I think we have done some of everything over the years. Whatamidoing (WMF) (talk) 19:53, 16 July 2020 (UTC)

The mobile platform collapses sections. See https://en.m.wikipedia.org/wiki/Wikipedia_talk:Village_pump_(technical) (a talk page) for an idea of what that looks like. Whatamidoing (WMF) (talk) 19:55, 16 July 2020 (UTC)

@Whatamidoing (WMF), thanks for your replies. The Discussion tools history page made for interesting reading. I used to be unhappy about the fact that our Konkani Wikimedians community does most of our discussion off-wiki, on WhatsApp. I was surprised to learn that initially, for the big Wikipedias too, most conversations were off-wiki. So this may be a normal path of progress for communities.

The Konkani Wikipedia community adopted Flow as the default discussion system, and we are quite comfortable with it. Sadly, when the Konkani Wiktionary was approved in March this year, our request to have Flow set up was declined. The Discoverer (talk) 16:03, 21 July 2020 (UTC)

They're not approving any new Flow installations. The system has many advantages, but it really needs some serious work. Have you tried out Help:DiscussionTools#Reply tool? I've left a link on one of your talk pages with a link that I think will work for you. Whatamidoing (WMF) (talk) 18:57, 21 July 2020 (UTC)

Thanks, @Whatamidoing (WMF). Yes, I had tried the reply tool, and I think that it will be useful for us. The link that you left worked for me. I wasn't aware that the Reply tool had already been deployed to projects. This means that we can request for it to be enabled on all discussion pages on our project, doesn't it? The Discoverer (talk) 05:20, 22 July 2020 (UTC)

It's still under development. The Konkani Wiktionary is already on their list to wikis to consider for the next round. The approved groups will get the Reply tool as a Beta Feature. I can add the Konkani Wikipedia to the list if you would like.

I am hoping that they will make some decisions in early August about that list. (It has taken longer than I expected.) Right now, I think it mostly depends upon Analytics' needs. They want to do some A/B testing on the next group. Whatamidoing (WMF) (talk) 18:53, 24 July 2020 (UTC)

Thanks, @Whatamidoing (WMF). On the Konkani Wikipedia, Flow is the standard content model for discussion pages, and there are very few Wikitext discussion pages, so the utilisation of the Reply Tool on the Konkani Wikipedia will be low. We can still add Konkani Wikipedia to the list so that the editors see the same thing on both projects, especially since I've heard that Flow might eventually get uninstalled. The Discoverer (talk) 04:40, 25 July 2020 (UTC)

Editing news 2020 #3

Read this in another language • Subscription list for this multilingual newsletter

Seven years ago this month, the Editing team offered the visual editor to most Wikipedia editors. Since then, editors have achieved many milestones:

• More than 50 million edits have been made using the visual editor on desktop.
• More than 2 million new articles have been created in the visual editor. More than 600,000 of these new articles were created during 2019.
• The visual editor is increasingly popular. The proportion of all edits made using the visual editor has increased every year since its introduction.
• In 2019, 35% of the edits by newcomers (logged-in editors with ≤99 edits) used the visual editor. This percentage has increased every year.
• Almost 5 million edits on the mobile site have been made with the visual editor. Most of these edits have been made since the Editing team started improving the mobile visual editor in 2018.
• On 17 November 2019, the first edit from outer space was made in the mobile visual editor. 🚀 👩‍🚀
• Editors have made more than 7 million edits in the 2017 wikitext editor, including starting 600,000 new articles in it. The 2017 wikitext editor is VisualEditor's built-in wikitext mode. You can enable it in your preferences.

Whatamidoing (WMF) (talk)

12:48, 9 July 2020 (UTC)

MediaWiki message delivery (talk) 12:48, 9 July 2020 (UTC)

"Fixed width" is a different project

Just a heads-up to anyone who might find a different appearance on their talk pages:

As announced at w:fr:Wikipédia:Le Bistro/2 juillet 2020, the Reading/Web/Desktop Improvements project is planning to implement a fixed width screen size. This kind of change always takes a few days to get used to, and there's some research behind it, but if it's just not working for you, then @SGrabarczuk (WMF) has promised me that there will be a way to opt out of this via preferences. If you have questions, suggestions for a different default width, etc., then please go to mw:Talk:Reading/Web/Desktop Improvements. Whatamidoing (WMF) (talk) 20:01, 16 July 2020 (UTC)

To be clear, this is only going to be enabled by default for certain "early adopter" wikis: Basque/French/Hebrew/Persian Wikipedias, French Wiktionary, and Portuguese Wikiversity. the wub "?!" 22:23, 16 July 2020 (UTC)

That's right. A link to opt-out easily will also be available in the sidebar, and this will be useful for the communities of the abovementioned wikis. For the vast majority of wikis, one will be able to opt-in individually via preferences. SGrabarczuk (WMF) (talk) 00:45, 17 July 2020 (UTC)

Probably better to call it max-width rather than fixed-width. Anyone who remembers the bad old days of truly fixed width web pages that you had to scroll from side to side as you read across the lines on a small screen would have a conniption if they thought MediaWiki was going down that route. Pelagic (talk) 16:26, 24 July 2020 (UTC)

Automatic ping template

I use wikitext editor. When I want to ping someone, I can copy his name form discussion above.

With this reply tool I don't see source. Problem is, when somebody have different username than appears in his signature e.g. [[User:John Walker|Johnnie Walker]], in that case user doesn't receive ping on his account.

It would be fine, if there is possibility to include ping template on the beginning with prefilled name of author of previous post. JAn Dudík (talk) 11:17, 7 August 2020 (UTC)

In the visual mode, if you type the @ symbol, then it opens a list of everyone who has already commented in this discussion. (If the person you want hasn't joined the discussion, then you start typing the username, and it will let search for the user page.) Have you tried this? Whatamidoing (WMF) (talk) 00:01, 8 August 2020 (UTC)

Good to know, it works :-) JAn Dudík (talk) 17:06, 11 August 2020 (UTC)

indentation problem after list

When I reply to post which have format

Some text

• list
• list
• list

the reply have same intendation as list lines.

[1]

Probably not easy to solve, but I report it. JAn Dudík (talk) 08:09, 25 August 2020 (UTC)

JAn Dudík, yes, that's why I never end with a list item; even if it's only my signature on the line below it. What I do in practice, when the person I'm replying to does that, is just add an extra level of indent in my reply. Problem solved. Mathglot (talk) 00:41, 27 August 2020 (UTC)

They used to use the last line (so the * in this example, resulting in ** or *: for the reply), and people complained that it should use the first line. Now they use the first line (the un-indented plain text, resulting in : for the reply), and people complain that it should be the old way.

There is no single "correct" way to do it, and editors have different personal preferences. I think they're going to have to pick one, knowing that it will be m:The Wrong Version. Whatamidoing (WMF) (talk) 15:32, 25 August 2020 (UTC)

Editing news 2020 #4

Read this in another language • Subscription list for this multilingual newsletter

Reply tool

The Reply tool has been available as a Beta Feature at the Arabic, Dutch, French and Hungarian Wikipedias since 31 March 2020. The first analysis showed positive results.

• More than 300 editors used the Reply tool at these four Wikipedias. They posted more than 7,400 replies during the study period.
• Of the people who posted a comment with the Reply tool, about 70% of them used the tool multiple times. About 60% of them used it on multiple days.
• Comments from Wikipedia editors are positive. One said, أعتقد أن الأداة تقدم فائدة ملحوظة؛ فهي تختصر الوقت لتقديم رد بدلًا من التنقل بالفأرة إلى وصلة تعديل القسم أو الصفحة، التي تكون بعيدة عن التعليق الأخير في الغالب، ويصل المساهم لصندوق التعديل بسرعة باستخدام الأداة. ("I think the tool has a significant impact; it saves time to reply while the classic way is to move with a mouse to the Edit link to edit the section or the page which is generally far away from the comment. And the user reaches to the edit box so quickly to use the Reply tool.")[2]

The Editing team released the Reply tool as a Beta Feature at eight other Wikipedias in early August. Those Wikipedias are in the Chinese, Czech, Georgian, Serbian, Sorani Kurdish, Swedish, Catalan, and Korean languages. If you would like to use the Reply tool at your wiki, please tell User talk:Whatamidoing (WMF).

The Reply tool is still in active development. Per request from the Dutch Wikipedia and other editors, you will be able to customize the edit summary. (The default edit summary is "Reply".) A "ping" feature is available in the Reply tool's visual editing mode. This feature searches for usernames. Per request from the Arabic Wikipedia, each wiki will be able to set its own preferred symbol for pinging editors. Per request from editors at the Japanese and Hungarian Wikipedias, each wiki can define a preferred signature prefix in the page MediaWiki:Discussiontools-signature-prefix. For example, some languages omit spaces before signatures. Other communities want to add a dash or a non-breaking space.

New requirements for user signatures

• The new requirements for custom user signatures began on 6 July 2020. If you try to create a custom signature that does not meet the requirements, you will get an error message.
• Existing custom signatures that do not meet the new requirements will be unaffected temporarily. Eventually, all custom signatures will need to meet the new requirements. You can check your signature and see lists of active editors whose custom signatures need to be corrected. Volunteers have been contacting editors who need to change their custom signatures. If you need to change your custom signature, then please read the help page.

Next: New discussion tool

Next, the team will be working on a tool for quickly and easily starting a new discussion section to a talk page. To follow the development of this new tool, please put the New Discussion Tool project page on your watchlist.

Whatamidoing (WMF) (talk)

15:11, 31 August 2020 (UTC)

MediaWiki message delivery (talk) 15:11, 31 August 2020 (UTC)

> Per request from the Arabic Wikipedia, each wiki will be able to set its own preferred symbol for pinging editors.

> some languages omit spaces before signatures

Thanks for posting these notes, I think I'll make corresponding changes to Convenient Discussions as well. Jack who built the house (talk) 15:42, 31 August 2020 (UTC)

You're welcome. Arabic prefers an arrow on the right ("front") side of the name, like this: aaa◀️. I would not be surprised if other right-to-left languages felt that the @ symbol was a little awkward. Whatamidoing (WMF) (talk) 01:53, 2 September 2020 (UTC)

Title of tab with reply draft

In browser I have usually many tabs open. The tab of wiki where I am editing can be recognized by title starting with Edit… But when using reply tool or Flow, is hard to recognize, which tab is the correct. When I want to search and copy something from other page, I must search, which tab is the right one.

If there is some way how to change title or design of actually edited tab, it would be useful. JAn Dudík (talk) 06:43, 4 September 2020 (UTC)

When editing in Wikipedia, I also often have more than 6 tabs open and often visually lose the tab on which the answer was started in the Reply tool or the edit started in the Visual editor, because out of habit I am looking for the tab with "Editing" in the title. I have to manually drag the tab to the beginning so that it becomes the first and I can easily find it. Some kind of marker in the header for a page in an editing state would be helpful.

Sometimes I have to open two versions of a page to view different parts of a long discussion. Sometimes I don't send messages instantly and they stay in the editing state for tens of minutes, at this time other pages open and many pages accumulate with a similar beginning of the namespace in the tabs. And if I scroll to other comments, for example to the beginning of a long thread, so that the edited place is outside the visible area in the browser, then when I return to this tab it looks like a usual inactive page - it takes time. Sunpriat 08:45, 4 September 2020 (UTC)

@JAn Dudík and @Sunpriat, thank you for saying something about this. What might you expect the tab in which you have the Reply Tool open to say?

In the meantime, here is a task for this work: T262066. PPelberg (WMF) (talk) 16:10, 4 September 2020 (UTC)

It will be recognizable as it was before "Editing: Title" or "Reply: Title" or status label "[reply] Title". Sunpriat 17:27, 4 September 2020 (UTC)

@Sunpriat: to confirm, "title" in the example shared above would be the title of the talk page? The heading of the section within which you are replying? Something else? PPelberg (WMF) (talk) 00:24, 5 September 2020 (UTC)

If there are a lot of tabs, I better remember the name of the page and less well remember the name of the section in it. Out of habit and by analogy with editing wiki-text, I would look for the text of the Tab title (as it was before editing) in the following words.

The section title is a good question. The section names in the tab, as in this topic, we saw only in Structured Discussions and this text is naturally understandable and even convenient. Not everyone has seen Structured Discussions on Wikipedia, for many it will be a new experience with titles. The title of the tab will be unique and will not look like the tabs next to it - this is interesting, but even so the title should be "reply: section - page title - wikipedia" to see the title of the page in the pop-up hint when you hover over the tab. Sunpriat 01:45, 5 September 2020 (UTC)

This seems like the kind of question that @TheDJ would know something about. Whatamidoing (WMF) (talk) 18:05, 18 September 2020 (UTC)

It is definitely necessary, for example, at the end of the title, to add the full word "reply" or "edit". Now browsers, when the user writes text in the address bar, show hints and, in particular, show suitable names of open tabs. This ability of browsers to find a tab is worth using. Sunpriat 21:20, 30 January 2021 (UTC)

Timestamps

Please fix the timestamps so that they display in the same format as set in my preferences. — GhostInTheMachine ^{talk to me} 19:37, 12 September 2020 (UTC)

What timestamps? Matěj Suchánek (talk) 13:13, 13 September 2020 (UTC)

Timestamps displayed on these posts.

Your question is marked as “an hour ago” which is itself a problem, since it was only 40 something minutes ago, but the time itself displays as 2:13pm which is not how my preference is set. It should be in 24 hour format as 14:13. — GhostInTheMachine ^{talk to me} 14:03, 13 September 2020 (UTC)

This is probably out of the scope of "Talk pages project". Fix for this in the Structured discussions project (a.k.a. Flow) is less likely to happen, given that the project isn't being developed anymore. Matěj Suchánek (talk) 14:20, 13 September 2020 (UTC)

Reply box does not appear

The tool has just been deploited on Vietnamese wikipedia, and after I've turned the feature on on the beta feature preference, I tried replying to some comments. After clicking into the reply button, that button disappeared but the reply box was nowhere to be found, and also all the other reply button turned into gray. What's wrong? Please help me.

Edit 1: Okay, it seems that other users in my wiki can still use the feature... but after I changed the browser the problem is still there.

Edit 2: After further testing I realized that the problem only appears if I click the reply button of the lastest comment. It'll be fine if it's not the lastest comment. What's wrong though? Bluetpp (talk) 01:26, 18 September 2020 (UTC)

There could be something wrong with your interface customization. Try Help:Locating broken scripts. Matěj Suchánek (talk) 07:05, 18 September 2020 (UTC)

@Matěj Suchánek Okay, I tried purging, nothing changed. but I tried adding "?safemode=1" and voila, the reply box appears.

I follow the guide and there's indeed an issues on the "Console" tab but I cannot find the "Debugger" tab. Help me... Bluetpp (talk) 08:06, 18 September 2020 (UTC)

You probably don't need the debugger (if you want it, search the internet for how to find it in your browser), the console should tell you enough (especially with debug=1). Note that the console will also likely show some warnings but you are looking for "errors". Matěj Suchánek (talk) 08:36, 18 September 2020 (UTC)

I don't understand a single things in this image, can you please help me and take a look at it? I see that it has 2 errors... Bluetpp (talk) 09:03, 18 September 2020 (UTC)

Twinkle[module] is not a function points me to vi:MediaWiki:Gadget-Twinkle.js. It's quite worrying a project-wide gadget breaks, you should probably contact users who ported it to your wiki and tell them about this problem.

Cannot read property 'style' of null points to vi:MediaWiki:Gadget-AVIM.js, again a project-wide gadget. It's possible it needs be updated to work with DiscussionTools. Matěj Suchánek (talk) 09:48, 18 September 2020 (UTC)

Bluetpp, would you please check this idea, by going to https://vi.wikipedia.org/wiki/Đặc_biệt:Tùy_ch%E1%BB%8Dn#mw-prefsection-gadgets and turning off Twinkle? (I use AVIM at viwiki, and the Reply tool works for me there, so I think AVIM is not the cause of the problem.) Please try turning off Twinkle, check for the Reply tool on a few pages, and then let me know whether it made a difference. (And then turn Twinkle back on, if you want to.) Whatamidoing (WMF) (talk) 18:01, 18 September 2020 (UTC)

We were able to post with Twinkle enabled: diff. ESanders (WMF) (talk) 18:16, 18 September 2020 (UTC)

@Whatamidoing (WMF) Hi, I'm the one asking you to exploit the tool in viwiki. So I've turned off Twinkle but it doesn't fix anything.

In [[:vi:Wikipedia:Thảo_luận#[TH%C3%94NG%20B%C3%81O]%20T%C3%ADnh%20n%C4%83ng%20beta%20m%E1%BB%9Bi:%20C%C3%B4ng%20c%E1%BB%A5%20th%E1%BA%A3o%20lu%E1%BA%ADn|this]] talk topic, somebody points out that if he replies to other comment first (not the lastest and with the deepest indent one) and then not refresh the page, he can then reply to the lastest comment.

@Matěj Suchánek Thanks, I'll try doing what you told and I'll update later. Bluetpp (talk) 05:27, 19 September 2020 (UTC)

Did you try on your second account?

Important: open the console before you click reply button and see what error messages income.

Probably another gadget is problem. wargo (talk) 08:09, 19 September 2020 (UTC)

@Wargo Okay, I did what you told, used 2nd account, open the console before clicking reply button. Here it is: Bluetpp (talk) 02:29, 20 September 2020 (UTC)

I can reproduce this problem after enabling the gadget "Tin nhắn theo giờ địa phương" (Comments in local time) on https://vi.wikipedia.org/wiki/Đặc_biệt:Tùy_chọn#mw-prefsection-gadgets. Matma Rex (talk) 20:06, 21 September 2020 (UTC)

@Matma Rex Yes! After turning the "comments in local time" off, it's back to normal! So what can I do? This is a massive bug isn't it? Bluetpp (talk) 01:13, 22 September 2020 (UTC)

This gadget adds time tag. I think it will be easy to implement recognization of this. Maybe normal timestamp should also have these tags? ;) wargo (talk) 08:03, 22 September 2020 (UTC)

@Bluetpp we appreciate you making us aware of this issue and thank you, @Matěj Suchánek and @Wargo for helping us all identify the cause(s) of it.

The editing engineering team investigated this issue today and has come to think the following: it is possible for the Reply Tool to be enhanced so it can be compatible with the "Tin nhắn theo giờ địa phương" (Comments in local time) gadget @Matma Rex linked to above.

Said "enhancement" is described in this task: phab:T252555. However, it is likely this enhancement will not reach Vietnamese Wikipedia, and subsequently resolve the issue being discussed here, for a few weeks.

This means that in the meantime, you'll need to disable the "Tin nhắn theo giờ địa phương" (Comments in local time) gadget in order to use the Reply Tool (not ideal, we know :/ )

Please let us know if anything above prompts new thoughts or questions and thank you again for working with @Matěj Suchánek and @Wargo to figure out what was causing this issue. PPelberg (WMF) (talk) 19:44, 22 September 2020 (UTC)

@Portal18 and @ネイ, I'm tagging you both here because I wanted you to be aware that we think the issue you were discussing here [i] will also be resolved by the fix we are implementing as part of phab:T252555.

---

i. Talk:Talk pages project/Replying/2020/09#h-Cannot_use_with_"Change_UTC-based_times_and_dates,_such_as_those_used_in_signatu-2020-09-19T12:24:00.000Z: Cannot use with "Change UTC-based times and dates, such as those used in signatures" Gadget PPelberg (WMF) (talk) 19:48, 22 September 2020 (UTC)

Correct indentation when replying _within_ a discussion thread?

Tracked in Phabricator
Task T251350

Hi! I notice that indendation goes one notch when replying to a discussion post. This is the same regardless if you put your reply at the bottom of the discussion or _within_ the discussion. In the latter case the indendation is the same as the earlier reply below, which makes telling the two posts apart. Would it be possibly to develop some sort of fix to this? Paracel63 (talk) 07:30, 25 September 2020 (UTC)

This is a reply to the first post — GhostInTheMachine ^{talk to me} 07:47, 1 October 2020 (UTC)

This is my third post, replying to my first post. — GhostInTheMachine ^{talk to me} 07:48, 1 October 2020 (UTC)

This is my fourth post, replying to my third post — GhostInTheMachine ^{talk to me} 07:49, 1 October 2020 (UTC)

And this is a reply to my first reply — GhostInTheMachine ^{talk to me} 07:48, 1 October 2020 (UTC)

This is my fifth post, replying to my second post — GhostInTheMachine ^{talk to me} 07:51, 1 October 2020 (UTC)

... which reported a failure due to timeout, but did post. :-( — GhostInTheMachine ^{talk to me} 07:53, 1 October 2020 (UTC)

5B -- Replying to reply to reply 5 — GhostInTheMachine ^{talk to me} 12:56, 1 October 2020 (UTC)

5D -- replying to 5B

5B should probably be indented twice — GhostInTheMachine ^{talk to me} 12:58, 1 October 2020 (UTC)

5C replying directly to 5 — GhostInTheMachine ^{talk to me} 12:57, 1 October 2020 (UTC)

This is my fifth post, replying to my second post — GhostInTheMachine ^{talk to me} 07:51, 1 October 2020 (UTC)

This is my fifth post, replying to my second post — GhostInTheMachine ^{talk to me} 07:52, 1 October 2020 (UTC)

@GhostInTheMachine, this page uses Structured Discussions (aka Flow). It's the default that this community chose a few years ago. The Talk pages project isn't about Flow. Whatamidoing (WMF) (talk) 16:25, 7 October 2020 (UTC)

Please could you point me to an overview of Flow vs. Structured Discussions post-Flow vs. Current developments vs. Plans for the future. — GhostInTheMachine ^{talk to me} 18:00, 7 October 2020 (UTC)

What we're typing in now is Structured Discussions (=the parts of Flow that actually got built). Current work is on the Reply tool, which you can test by clicking on https://en.wikipedia.org/wiki/Wikipedia_talk:Talk_pages_project?dtenable=1 and looking for the [reply] buttons at the end of each line. Plans for the future include Talk pages project/New discussion, and (we all hope) maybe even section watchlisting ("Imagine a world in which you can watchlist only a single section of WP:ANI"). Whatamidoing (WMF) (talk) 18:28, 7 October 2020 (UTC)

If you click reply on some message it will create one more step of ident under message you click "reply". If you want at identation at the same level as last message, click reply button on parent message. By clicking reply you are telling your message is releated to post you clicked and next identation tells it. If this doesn't happen this way, give link to example of discussion where it happens and with example of messages you want to reply. wargo (talk) 09:28, 25 September 2020 (UTC)

Thanks for the your reply, pointing to the general behaviour of the tool. What I was looking at was a way of making the indentation _two_ notches to the right, not one. That behaviour would mimick the normal behaviour when you reply manually within a thread, letting people know that your posting and the posting below are not directly related. Maybe comparing time stamps could implement such a behaviour? All the best. Paracel63 (talk) 09:35, 25 September 2020 (UTC)

Just to be clear of what I'm talking about. It's about replying to a posting _inside_ an ongoing thread (between the postings), _not_ below all the previous postings of this thread. Paracel63 (talk) 09:38, 25 September 2020 (UTC)

You will need to provide an example. The only behavior I can see for this is, if not non-standard, then at least unusual and generally unnecessary. Izno (talk) 11:23, 25 September 2020 (UTC)

OK. Within the "modern" reply technique used on this very discussion page, such a behaviour is unnecessary, as the posting starts with the signature. When replying in the "traditional" discussion format (standard at my native sv:wp), any posting starts with plain text. A multi-paragraph reply inside a thread is distinguished by its indent, not by indent plus a starting signature. This make replies with the same indent harder to differentiate. You can see double indent being used when replying "within" in this thread (https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen#Fortsatt_diskussion) and in this thread (https://sv.wikipedia.org/wiki/Wikipedia:Bybrunnen#Stubb_och_noter). All the best. Paracel63 (talk) 12:26, 1 October 2020 (UTC)

@Wargo: @Izno: Another example (https://sv.wikipedia.org/wiki/Wikipedia:Ans%C3%B6kan_om_administrativ_beh%C3%B6righet#Jan_Arvid_G%C3%B6tesson), by Janders, at 27 September 2020 kl. 15.37. All the best. Paracel63 (talk) 09:39, 2 October 2020 (UTC)

Some people like this style, and others don't. I've seen disputes at the English Wikipedia in which editors claim that their preference is the "correct" style. One style (the "double-indent") makes it easier to see which words were posted by which editor; the other style (the "same level") makes it easier to see which comment the second person was replying to.

If you are interested in the general subject of making it easier to see threading, then you might want to look at the pale blue lines on https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion It doesn't separate comments at the same indentation level, but it does mark some things. Also, be on the lookout for a technical request for comment in a few weeks. If they settle on a style for wrapping complex content/solving some w:en:WP:LISTGAP problems, it might be easier to visually mark separate comments in the future. Whatamidoing (WMF) (talk) 16:31, 7 October 2020 (UTC)

Thanks for the links and tips. I see that the replying tool I was referring to does not seem to put the reply after a posting inside a thread but at the end of the whole thread. So this behaviour defeats the purpose of posting inside a thread using this "gadget". So I'll return to replying manually, as all the other posters at sv:wp seem to do. All the best. Paracel63 (talk) 20:14, 7 October 2020 (UTC)

@Paracel63, can you give me a diff of the reply ending up in the wrong place? Was this at the Swedish Wikipedia? Whatamidoing (WMF) (talk) 17:58, 12 October 2020 (UTC)

Hi! Here I produced a test thread on my user discussion page at sv:wp. Yes, the problems are happening at sv:wp. The postings are being numbered in the order they were posted; "efter X" means they are produced through clicking at [ svara ] at the end of that specific posting.

Results: #5 was placed after #4 (and not after #1); #6 was placed after #4 (and not after #3); #7 was (correctly!) placed after #4; #8 was placed after #6 (and not after #2; diff). So 3 out of 4 nested replies were not properly placed. It really seems like the tool does not identify the postings in the right chronological order. Paracel63 (talk) 07:31, 13 October 2020 (UTC)

{{ping|Whatamidoing (WMF)}} Ping! Paracel63 (talk) 07:32, 13 October 2020 (UTC)

Yes, I've seen that. It places replies according to the list structure, rather than according to chronological order. This means that when you reply to comment #4, it places the comment in the first available sub-list space under comment #4, which happens to be immediately under it. Comment #5, which is a reply to comment #1, goes in the first available sub-list space under comment #1, which is even with comment #2 and at the end.

It might make more sense if you think of the discussion as being a real list or outline:

1. Things I want for school
   1. Food
      1. Apples
      2. Oranges
   2. Clothing
      1. Comfortable shoes
   3. Computers
      1. Phone
      2. Laptop

If you were "replying" to "Things I want", you'd expect that to be #4 on the level with (and immediately after) #3 "Computers". But if you're "replying' to "Food", you want the list to put "Chocolate" after "Oranges", not after "Laptop".

If they built a strict chronological system, then you couldn't use the Reply tool to inject a comment into the middle of a long discussion, because your comment would always end up at the end of the section.

As a workaround, you can click the "Reply" button for a different comment, to get the placement where you want it to be. For example, if you want your comment at the end, then click the reply button for the last comment. Whatamidoing (WMF) (talk) 00:06, 14 October 2020 (UTC)

Yes, you're correct. My reasoning was only consistent with my (original) wish to have a nested reply with enhanced indent and placed directly below the post being replied to. I totally agree that the indexing system is a good way of organising discussions with this tool, if others do not agree to my modus operandi. All the best. :-) Paracel63 (talk) 08:02, 14 October 2020 (UTC)

I do still wish that the devs could figure out some sort of magic system that will put my replies where I think they belong. In the meantime, I think we're going to be stuck with the normal editor for that. Whatamidoing (WMF) (talk) 20:45, 14 October 2020 (UTC)

Indentation

Bonjour. Quand une réponse est faite au même niveau qu'une réponse précédente, l'indentation ne correspond pas aux recommandations de fr:wp:Aide:Indentation#La réponse de même niveau sans séparation.

Par exemple la discussion fictive suivante :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

: Bonjour {{ping|Utilisateur1}}, ça va bien? --Utilisateur2, 1 janvier 2001 00:03

:: {{ping|Utilisateur2}} très bien merci. --Utilisateur1, 1 janvier 2001 00:05

:Bonjour {{ping|Utilisateur1}}. --Utilisateur3, 1 janvier 2001 00:07

donne le rendu suivant :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

Bonjour @Utilisateur1: , ça va bien? --Utilisateur2, 1 janvier 2001 00:03

@Utilisateur2: très bien merci. --Utilisateur1, 1 janvier 2001 00:05

Bonjour @Utilisateur1: . --Utilisateur3, 1 janvier 2001 00:07

Admettons un hypothétique Utilisateur4 qui désire répondre à Utilisateur1, Outil de réponse indente sa réponse comme si son message était dans la continuité de celui d'Utilisateur3, alors qu'il devrait y avoir un marqueur de séparation de niveau inférieur.

Code actuel généré avec Outil de réponse :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

: Bonjour {{ping|Utilisateur1}}, ça va bien? --Utilisateur2, 1 janvier 2001 00:03

:: {{ping|Utilisateur2}} très bien merci. --Utilisateur1, 1 janvier 2001 00:05

:Bonjour {{ping|Utilisateur1}}. --Utilisateur3, 1 janvier 2001 00:07

:Salut {{ping|Utilisateur1}}. --Utilisateur4, 1 janvier 2001 00:09

Rendu actuel :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

Bonjour @Utilisateur1: , ça va bien? --Utilisateur2, 1 janvier 2001 00:03

@Utilisateur2: très bien merci. --Utilisateur1, 1 janvier 2001 00:05

Bonjour @Utilisateur1: . --Utilisateur3, 1 janvier 2001 00:07

Salut @Utilisateur1: . --Utilisateur4, 1 janvier 2001 00:09

Or, le code idéal selon la page d'aide serait le suivant :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

: Bonjour {{ping|Utilisateur1}}, ça va bien? --Utilisateur2, 1 janvier 2001 00:03

:: {{ping|Utilisateur2}} très bien merci. --Utilisateur1, 1 janvier 2001 00:05

:Bonjour {{ping|Utilisateur1}}. --Utilisateur3, 1 janvier 2001 00:07

:Salut {{ping|Utilisateur1}}. --Utilisateur4, 1 janvier 2001 00:09

Avec un rendu comme celui-ci :

Bonjour tout le monde! --Utilisateur1, 1 janvier 2001 00:01

Bonjour @Utilisateur1: , ça va bien? --Utilisateur2, 1 janvier 2001 00:03

@Utilisateur2: très bien merci. --Utilisateur1, 1 janvier 2001 00:05

Bonjour @Utilisateur1: . --Utilisateur3, 1 janvier 2001 00:07

Salut @Utilisateur1: . --Utilisateur4, 1 janvier 2001 00:09

---

Systématiquement, quand je publie des réponses de même niveau que le message précédent, Outil de réponse fait un amalgame visuel et je dois intervenir avec le code pour rétablir l'indentation.

Est-ce que c'est possible d'ajuster le module afin qu'il ajoute une ligne comportant une indentation d'un cran inférieur avant de formuler une réponse de même niveau, pour permettre de séparer visuellement les réponses de même niveau? Webfil (talk) 19:03, 15 October 2020 (UTC)

(Originally posted on wpfr Flow discussion page. Trizek, I believe this is the better place to discuss this issue?) Webfil (talk) 19:06, 15 October 2020 (UTC)

[reply] appears near signatures broadly

Turns out that "[reply]" thing is programmed to be near signatures, isn't it? If that's the case, it also appears in signatures that don't make messages but rather signatures indicating especially attendance planning. For example, meta:Strategy/Wikimedia movement/2018-20/Transition/Global Conversations has "[reply]" near signatures lacking messages, inviting possible vandalism or something like that. George Ho (talk) 19:35, 28 October 2020 (UTC)

It detects most signatures that are followed by a timestamp. I haven't seen anyone replying in inappropriate places yet. I suppose that someone might think it's a way to send a w:Personal message to the people listed there. If you are concerned about it, then removing any or all of the timestamp will make the signatures undetectable. Whatamidoing (WMF) (talk) 18:18, 29 October 2020 (UTC)

Not concerned for now. We'll wait for diffs then. I just opted-in the beta feature. George Ho (talk) 20:11, 29 October 2020 (UTC)

One workaround is to add __nosectionedit__ to the page, that deactivates Discussion tools for a page. You would then probably want to add an explicit link in the text of that section, directly to section-edit that section:

https://meta.wikimedia.org/w/index.php?title=Strategy/Wikimedia_movement/2018-20/Transition/Global_Conversations&action=edit&section=2 Alsee (talk) 23:21, 29 October 2020 (UTC)

__nosectionedit__ doesn't work properly, but __TOC__ still does. George Ho (talk) 19:49, 30 October 2020 (UTC)

Valid is __NOEDITSECTION__ wargo (talk) 09:06, 4 November 2020 (UTC)

It probably disabled the "[reply]" tool, but it also disabled editing a section. I reverted the insertion. George Ho (talk) 09:10, 4 November 2020 (UTC)

For an update, the list of attendees have been moved to a subpage. I added the code, but turns out I was incorrect about the tool disabling "[reply]". Instead, the DiscussionTool is still there, but seems that Phab crew has been working on disabling the tool in some or many pages. George Ho (talk) 10:16, 9 November 2020 (UTC)

hi @George Ho! We appreciate trying the Reply Tool and sharing this feedback.

It sounds like over the past couple of weeks you've encountered a couple cases where [ reply ] links are appearing in places you don't expect.

In response, I thought it might be helpful to share two things:

1. What determines where [ reply ] links appear
2. How we are thinking about making sure [ reply ] links appear just where people expect them to

More details about both of these things below...

What determines where [ reply ] links appear

[ reply ] links will appear on pages in talk namespace and pages in namespaces which have been configured to show the 'add signature' tool ($wgExtraSignatureNamespaces). For most Wikimedia wikis this is the project and help namespaces.

On Meta, the main namespace has been configured to enable the 'add signature' tool, this explains why you are seeing Reply Links on both of the pages you shared links to:

• https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2018-20/Transition/Global_Conversations/Attendees
• https://meta.wikimedia.org/wiki/Strategy/Wikimedia%20movement/2018-20/Transition/Global%20Conversations

You can read more about the logic that determines how/where reply links appear on the DiscussionTools help page here: Help:DiscussionTools.

How we are thinking about making sure [ reply ] links appear just where people expect them to?

We are currently gathering cases where [ reply ] links are appearing in places people do not expect so we can determine what might be a sustainable way for accommodating all of them.

The ticket where this "gathering" will happen is: phab:T249293.

Note: last week I aded the cases you shared here to that ticket. See: phab:T249293#6604678. PPelberg (WMF) (talk) 20:27, 11 November 2020 (UTC)

Not available?

I activated this beta feature at wiki.pt, but apparently not only it shows a message saying it not available in my talk page (though it still shows the "reply" link/button normally), but it rendered it extremely slow. I've stopped trying it, consequently. DarwIn (talk) 17:29, 30 October 2020 (UTC)

I'm sorry the tool doesn't seem to be working as expected for you, @DarwIn – thank you for letting us know as much.

...it shows a message saying it not available in my talk page (though it still shows the "reply" link/button normally)

Just to be sure: can you confirm this is the page where you experienced the above?

If so, then I too am seeing the following dialog when I click a [ reply ] link on that page: The "reply" link cannot be used to reply to this comment. To reply, please use the full page editor by clicking "Edit".

I suspect one of the reasons given on the Why can't I reply to this comment?#The "reply" link cannot be used to reply to this comment explains this behavior. We will look more closely next week to know exactly what's causing this.

...it rendered it extremely slow.

This is unexpected. Are you able to share a rough estimate of how long "slow" might have been in this case? PPelberg (WMF) (talk) 18:38, 30 October 2020 (UTC)

Hey! I missed your replies for some time - sorry, this has been a complicated month. :P

Yes, this is the page. DarwIn (talk) 08:45, 28 November 2020 (UTC)

Also, is the slowness consistent (all pages always, or a particular page always), or intermittent? Whatamidoing (WMF) (talk) 18:59, 30 October 2020 (UTC)

Replying doesn't work on your talk page because of unclosed tags in the template at the top (which are also causing the text on the entire page to be light grey – I'm not sure if that is intentional).

The page is definitely slower to load with the reply tool enabled. For me, it takes about 2.5s without and about 4s with (testing while logged out, using the dtenable=1 parameter). Matma Rex (talk) 19:33, 30 October 2020 (UTC)

It's not intentional, I'll try to clean it up, as well as some of the stuff which is currently cluttering it DarwIn (talk) 08:46, 28 November 2020 (UTC)

Once or twice was Reply tool very slow for me too. Patrik L. (talk) 21:44, 30 October 2020 (UTC)

We're planning to work on the slow loading in T267404. Matma Rex (talk) 17:17, 6 November 2020 (UTC)

Thank you very much for your replies, please tell if there is some improvement. Every day that passes I hate more the old talk system, and definitely would like to migrate to this one, if possible. DarwIn (talk) 08:47, 28 November 2020 (UTC)

We're planning to work on the slow loading in T267404.

@DarwIn, the work @Matma Rex mentioned above is now complete. This means, you should see some improvements in how quickly pages where the Reply Tool is accessible load. If you have a chance to test this out, we'd be curious to know if you notice any changes. PPelberg (WMF) (talk) 03:08, 30 January 2021 (UTC)

No outdenting?

T265750: Make it easy to "outdent" by changing the colons/list level

This tool seems to be intended for those wanting to indent their replies automatically, doesn't it. What about outdenting, which is used whenever indention would make further replies less readable? I guess the tool doesn't do that, does it?

If I want to outdent, then I have to either click "[reply]" next to the OP or click "edit" and then go to the very bottom of the thread. Then I must use {{Outdent }} for better readability, especially for larger replies. Are there other ways for me to outdent? George Ho (talk) 08:57, 13 November 2020 (UTC)

hi @George Ho – I've posted a couple of comments in response to the points you've raised below.

This tool seems to be intended for those wanting to indent their replies automatically, doesn't it.

This is correct.

What about outdenting, which is used whenever indention would make further replies less readable? I guess the tool doesn't do that, does it?

The tool does not offer a way to adjust the indentation level of comments published with it. I wonder if you'd be interested in another conversation that is happening about outdenting on the Reply Tool's talk page: Talk:Talk pages project/Replying/2020/09#h-Adding_outdent_option?-2020-09-12T19:29:00.000Z.

If I want to outdent, then I have to either click "[reply]" next to the OP or click "edit" and then go to the very bottom of the thread. Then I must use {{outdent}} for better readability, especially for larger replies. Are there other ways for me to outdent?

This is correct; to adjust the indentation level of a comment posted with the Reply Tool, you'll need to do that in the talk page's full page source editing mode. PPelberg (WMF) (talk) 00:09, 21 November 2020 (UTC)

Lack of spaces around message

Current behaviour:

:message.--signature

I expect it to generate more readable:

: message. --signature

Information tokens should be visually separated. AS (talk) 00:04, 25 November 2020 (UTC)

I agree ("Sparse is better than dense." --Zen of Python) though this behavior maybe comes from Parsoid, that seems to favor dense rather than sparse wikitext. :-( Sophivorus (talk) 00:58, 5 December 2020 (UTC)

Which wiki are you editing at? This is configurable per wiki, because different languages have different conventions. Whatamidoing (WMF) (talk) 19:19, 8 December 2020 (UTC)

ukwiki AS (talk) 20:05, 8 December 2020 (UTC)

So if it's set per wiki, than I suppose I have to ask local community if that's a preferable convention and fill a ticket in Phabricator? AS (talk) 20:08, 8 December 2020 (UTC)

Yes, you need local community agreement. No, you don't need to file a ticket in Phabricator. Any Interface administrator can do this. At ukwiki, the list is https://uk.wikipedia.org/wiki/Спеціальна:Список_користувачів?group=interface-admin Whatamidoing (WMF) (talk) 19:42, 6 January 2021 (UTC)

More details please :) I don't see such system message mentioned on Extension:StructuredDiscussions AS (talk) 21:00, 6 January 2021 (UTC)

The "signature prefix" is defined in MediaWiki:Discussiontools-signature-prefix (e.g., at w:uk:MediaWiki:Discussiontools-signature-prefix for ukwiki). It looks like it has already been fixed. Whatamidoing (WMF) (talk) 23:50, 6 January 2021 (UTC)

I see, thanks. Is there a possibility to also add space between indentation marks and message? AS (talk) 00:12, 7 January 2021 (UTC)

Do you want the wikitext to look like ::: Message. --Signature instead of :::Message. --Signature  ? If so, that is not possible. Whatamidoing (WMF) (talk) 00:20, 7 January 2021 (UTC)

Hyphens

This tool automatically adds a "--" before my signature. But I've changed my signature, which now preforms a space " " and two U+2014 em dashes "——" before me username. So now when I reply someone, there's a very strange "-- ——username" (Example). I hope the tool can allow us to choose whether to add hyphens or not. Thanks. 魔琴 (talk) 13:27, 9 December 2020 (UTC)

The prefix is an override on zh.wp: zh:MediaWiki:Discussiontools-signature-prefix. Matma Rex (talk) 18:18, 9 December 2020 (UTC)

But I can't edit it... and even if I do, it will make everyone on zh.wp have the same changes, wouldn't it? 魔琴 (talk) 22:18, 9 December 2020 (UTC)

So, can it? 魔琴 (talk) 15:32, 17 December 2020 (UTC)

@羊羊32521 To clarify, administrators of zh.wp decided that every signature must have "--" before it on that wiki, by creating that page. There is nothing we can do about it. Please talk to them and ask for that page to be changed or removed. Matma Rex (talk) 17:53, 17 December 2020 (UTC)

But if it was changed/removed, it will apply to every user's signature, which is not what I want. 魔琴 (talk) 15:46, 22 December 2020 (UTC)

I understand but I can't change this. Please talk to Shizhao, who created that override. (@Shizhao) Matma Rex (talk) 09:58, 23 December 2020 (UTC)

Unique topic headings

Can you think of discussion pages where the topic headings on them are styled in unique ways? If so, can you please share a link to them in this thread?

For context: this question came up during one of our team meetings and I thought it would be neat to experiment with asking a lightweight question...the kind of question not tied to any immediate decision or plan. PPelberg (WMF) (talk) 23:16, 10 December 2020 (UTC)

@Dyolf77 (WMF), @Patriccck and @Tacsipacsi, I am cc'ing you all in case an example comes to mind. Please know this question is not urgent :) PPelberg (WMF) (talk) 23:18, 10 December 2020 (UTC)

We're looking for things like https://it.wikipedia.org/wiki/Wikipedia:Bar/2020_12_15 or maybe the table at the top of https://zh.wikipedia.org/wiki/Wikipedia:互助客栈/其他 Whatamidoing (WMF) (talk) 19:38, 6 January 2021 (UTC)

Thanks button

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Hi! Wouldn't it be nice to add a [thank] button next to the [reply] button, to thank users for their messages? The relevant edit to thank could be found based on the timestamp. This would avoid clutter by unnecessary "Thank you" messages and would increase thank you notifications, thus spreading wikilove.

If this is not the best place to post it, or if it's been suggested already, I apologize and would appreciate a link to the relevant place. Cheers! Sophivorus (talk) 15:36, 17 December 2020 (UTC)

We too support the idea of adding the ability for people to "Thank" someone for the comment they left on a talk pages! Here is the task where we are collecting the thinking around this idea: T249893.

And this talk page is a great place to post ideas :) We hope you will continue to share any other ideas you have for how talk pages might be improved, as they occur to you. PPelberg (WMF) (talk) 16:25, 17 December 2020 (UTC)

Great idea! Patrik L. (talk) 17:58, 17 December 2020 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Button to [edit] your own comment

Tracked in Phabricator
Task T245225

Hi! After I publish a reply, I often notice some error or way I can improve it. It would be nice to have an [edit] button appear next to my reply after I publish, so I don't have to edit the entire page.

Yes, I know that's why previews exist, and I try to use them, but years go by and the same thing keeps happening. Maybe it's my type of personality, or something psychological about having just published that makes me want to triple-check, but in any case I'm sure I'm not the only one. StackOverflow, for instance, has a similar feature, where you can easily edit your own comment for a few minutes after publishing. Sophivorus (talk) 12:57, 31 December 2020 (UTC)

Thanks for voicing this. It's true, even Slack has a hot key shortcut so that you can quickly get in there and edit. Out of curiosity, do you have the same instinct when editing article or other kinds of pages or is this an experience unique to Talk Pages? JKlein (WMF) (talk) 16:04, 6 January 2021 (UTC)

It does happen to me also on other pages... Sophivorus (talk) 11:53, 7 January 2021 (UTC)

Thanks, as you can see, @WhatamIdoing has added the Phabricator Task to this topic T245225 if you'd like to follow it's progress.

I agree that this would be a nice feature and am glad that you brought it up. JKlein (WMF) (talk) 13:59, 7 January 2021 (UTC)