Talk:Talk pages project

Jump to navigation Jump to search

About this board

Share a story about starting a new discussion

15
Summary by PPelberg (WMF)

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.

Whatamidoing (WMF) (talkcontribs)

Please tell us a story about starting a new discussion. What worked? What didn't? What was most memorable?

Barkeep49 (talkcontribs)

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.

JKlein (WMF) (talkcontribs)

Can you say more about your "nervousness"?

Praxidicae (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

Oooh, a hand-typed forged datestamp! I haven't seen one of those for a while.

Whatamidoing (WMF) (talkcontribs)

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?

Praxidicae (talkcontribs)

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.

JKlein (WMF) (talkcontribs)

In this scenario, do you approach it as editing the full page?

Alsee (talkcontribs)

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.

Barkeep49 (talkcontribs)

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?

Alsee (talkcontribs)

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.

J. N. Squire (talkcontribs)

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?

Whatamidoing (WMF) (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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.

Pelagic (talkcontribs)

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

Reply to "Share a story about starting a new discussion"

New talk pages tools on the Konkani Wiktionary

3
The Discoverer (talkcontribs)

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 (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

Thanks for the note. I've put it on the list for the team to consider.

Reply to "New talk pages tools on the Konkani Wiktionary"
Ad Huikeshoven (talkcontribs)

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?

Whatamidoing (WMF) (talkcontribs)

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?

Ad Huikeshoven (talkcontribs)

About what can and cannot be inserted in the text field via the Reply tool.

Matma Rex (talkcontribs)

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.

Ad Huikeshoven (talkcontribs)

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?

ESanders (WMF) (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

But it might be nicer to make it actually work, instead of setting an expectation (for experienced editors) that it shouldn't work.

Alsee (talkcontribs)

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.

Ad Huikeshoven (talkcontribs)

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

Reply to "Supported wikimarkup"

DiscussionTools vs. Replying tool

10
Samat (talkcontribs)

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 (talkcontribs)
Lofhi (talkcontribs)

DiscussionTools is a new feature. One of the tools of this feature is the Replying tool.

Samat (talkcontribs)

Thank you Lofhi! What other tools/features are (or are planned) part of the DiscussionTools beside the Replying tool?

Alsee (talkcontribs)

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.

Samat (talkcontribs)

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.

Alsee (talkcontribs)

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

Section-watchlisting is only an idea/request at this time.

Pelagic (talkcontribs)

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

Lofhi (talkcontribs)

For the time being, another tool is under development. No official name, but we can name it like "New discussion tool".

Pelagic (talkcontribs)

[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
Reply to "DiscussionTools vs. Replying tool"

Timestamping messages

4
Summary by Jdforrester (WMF)

Off-topic.

Ottawahitech (talkcontribs)

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?)

Whatamidoing (WMF) (talkcontribs)

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.

Thiemo Kreuz (WMDE) (talkcontribs)

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.

Smile4ever (talkcontribs)

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.

Summary of the first feedback on the Hungarian Wikipedia

32
Summary by PPelberg (WMF)

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. task T245890: extend the tool to the non-talk pages
  2. task T249391: enable people to customize the edit summary that accompanies their reply
  3. task T249072: add a tool of special characters to the forthcoming Reply tool's toolbar.
  4. task T249579: it can be difficult to understand how comments relate to one another; this is especially difficult in longer conversations.
  5. task T249579: it can be difficult to tell comments apart from one another.
  6. task T249578: it can be difficult to notice the "Reply" link.
  7. task T249886: enable people to use the "Reply" tool to post a comment that is not indented.
  8. task T249889: enable people to sign a (complex, multi-line or formatted) comment in the new line
  9. task T245225: enable people to edit or modify an already published comment.
  10. task 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. task T240257: Replying tool cannot restore the inserted text in the event of browser crash/OS restart/accidental closed tab etc.
  13. task T249577: the tool does not always appear on longer talk pages (multiple times).
  14. task T234403: enable people to change between the source code and graphical interface during editing.
Samat (talkcontribs)

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.


Pasztilla (talkcontribs)

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

Samat (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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?

Samat (talkcontribs)

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 (talkcontribs)

I can say, that quite much the same how this surface works right now.

PPelberg (WMF) (talkcontribs)

@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) (talkcontribs)

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) (talkcontribs)

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.

Samat (talkcontribs)

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

PPelberg (WMF) (talkcontribs)

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) (talkcontribs)

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


PPelberg (WMF) (talkcontribs)

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.

Samat (talkcontribs)

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.

PPelberg (WMF) (talkcontribs)

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) (talkcontribs)

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

Samat (talkcontribs)

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 :)

PPelberg (WMF) (talkcontribs)

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) (talkcontribs)

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)

Samat (talkcontribs)

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

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.

PPelberg (WMF) (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

I've posted a "work around" method for achieving this in a comment at phab:T249889. It was inspired by seeing this edit.

Pelagic (talkcontribs)

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 (talkcontribs)

Or I thought I did. My comment there seems to have disappeared. Maybe I somehow closed/lost the tab without hitting Submit?