User talk:IndentBot: Difference between revisions
→Deleting useful hard spaces that are not rendered.: adding a blank line after a paragraph without any prefixing characters isn't an issue; unfortunately, removing blank lines between list items is the best workaround to avoid extraneous voice output from screen readers |
|||
Line 42: | Line 42: | ||
:::{{U|Notacardoor}}, yes, this relates to spaces (returns) in the default text editor to easily distinguish comments/responses - just as you added a space after my initial comment and I have added one now. See also the link I provided. I don't think that the approach at [[MOS:INDENTGAP]] is necessarily the right way to do things in such a case, since the spaces (returns) are placed between sections of prose that will often have different indent levels (though a second response by a second editor will have the same indent level as the first response by the first responding editor. I would think that the solution is simple. Unless there are multiple such lines in series, leave them alone (leave one). Regards, [[User:Cinderella157|Cinderella157]] ([[User talk:Cinderella157|talk]]) 00:38, 17 May 2022 (UTC) |
:::{{U|Notacardoor}}, yes, this relates to spaces (returns) in the default text editor to easily distinguish comments/responses - just as you added a space after my initial comment and I have added one now. See also the link I provided. I don't think that the approach at [[MOS:INDENTGAP]] is necessarily the right way to do things in such a case, since the spaces (returns) are placed between sections of prose that will often have different indent levels (though a second response by a second editor will have the same indent level as the first response by the first responding editor. I would think that the solution is simple. Unless there are multiple such lines in series, leave them alone (leave one). Regards, [[User:Cinderella157|Cinderella157]] ([[User talk:Cinderella157|talk]]) 00:38, 17 May 2022 (UTC) |
||
::::Regarding {{tq|just as you added a space after my initial comment}}: there isn't an issue with blank lines after a paragraph without any prefixing characters (<code>:</code>, <code>*</code>, or <code>#</code>), since there is no current list in progress that would get interrupted by a blank line. The problem with leaving a blank line between list items (that is, between paragraphs with prefixing characters) is that this will cause all lists in progress (one for each prefixed character) to be closed, and then new lists started, and screen readers will announce all of them. (See [[User:Isaacl/On wikitext list markup]] for a little more detail.) I appreciate that editors can find it inconvenient. Unfortunately, it's the best workaround we have at present to avoid what can be a lot of extraneous voice output. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 05:19, 18 May 2022 (UTC) |
Revision as of 05:19, 18 May 2022
Archives (Index) |
This page is archived by ClueBot III.
|
To report an issue or make a request, comment, or suggestion, add a new section at the bottom of the page.
Suggested use
I understand why you're trying to do this, but I'm not sure I 100% support the use of this bot on discussion pages or user talk pages, where people are "creative" enough in the way they mess up indentation that a bot might not be able to know what was intended, or who is responding to what. But I think I might have a less controversial use. WP:AIV consists of individual reports of vandals, which all start with a bullet, followed by indents that are often incorrect or random uses of colons and bullets. I think the bot would be much more able to understand what it needs to do in this environment, than it would in a more free-form discussion. Are you allowed to run your bot at AIV without further approval? If so, I'd like to be safe and mention this at WT:AIV before you do anything. If not, then nevermind. --Floquenbeam (talk) 21:40, 7 January 2022 (UTC)
- @Floquenbeam The bot already no longer edits user talks. Currently, the bot is doing short trials. The expected behavior is for there to be no noticeable visual difference (you can verify this by opening two tabs side-by-side of the before and after), except that non-final bullet points may be hidden. Winston (talk) 21:48, 7 January 2022 (UTC)
- I continue to be astounded at the fractured logic being employed around this bot. If it can't be trusted at user talk pages, it can't be trusted anywhere. There's no difference between the different spaces. EEng 00:27, 8 January 2022 (UTC)
- Are you allowed to do short trials at WP:AIV? It seems like a less steep learning curve for the bot (if it needs one), as the types of potential errors seems smaller. I ask because of a thread at ANI (Wikipedia:Administrators' noticeboard/Incidents#My talk page message re AIV), where someone with a screen reader commented that indenting at AIV is usually a mess. --Floquenbeam (talk) 21:52, 7 January 2022 (UTC)
- The bot is actually currently in a trial (see the BRFA) of 200 edits, which I am doing in chunks. The bot doesn't focus on specific pages. Instead, it watches recent changes and works on discussion pages, including those in the WP namespace. So WP:AIV can be edited. However, it also has some criteria which probably prevents it from editing WP:AIV very often. It must detect several (currently 5) signatures, and it also will not make an edit until at least (currently) 15 minutes after the most recent edit, to prevent getting in the way of particularly busy discussions. Winston (talk) 22:07, 7 January 2022 (UTC)
- OK, thanks. Perhaps it is something we can revisit someday. --Floquenbeam (talk) 22:10, 7 January 2022 (UTC)
- can you also extend trials to subpages of Template:Did you know nominations? DYK's indenting tends to be a little bit of a mess... theleekycauldron (talk • contribs) (she/they) 05:00, 5 May 2022 (UTC)
- OK, thanks. Perhaps it is something we can revisit someday. --Floquenbeam (talk) 22:10, 7 January 2022 (UTC)
- The bot is actually currently in a trial (see the BRFA) of 200 edits, which I am doing in chunks. The bot doesn't focus on specific pages. Instead, it watches recent changes and works on discussion pages, including those in the WP namespace. So WP:AIV can be edited. However, it also has some criteria which probably prevents it from editing WP:AIV very often. It must detect several (currently 5) signatures, and it also will not make an edit until at least (currently) 15 minutes after the most recent edit, to prevent getting in the way of particularly busy discussions. Winston (talk) 22:07, 7 January 2022 (UTC)
test pause
test Notacardoor (talk) 09:34, 5 May 2022 (UTC) test done Notacardoor (talk) 09:40, 5 May 2022 (UTC)
Thanks
A quick note to say thanks for creating this bot. I've spent too much time over the years cleaning up bad indentations and trying to explain how the system works to others. I'm very glad to see this bot come along. Mike Christie (talk - contribs - library) 11:04, 7 May 2022 (UTC)
Deleting useful hard spaces that are not rendered.
Per this edit, the bot is deleting returns deliberately added to facilitate editing in the edit interface. The returns do not render and are therefore not "white space". It does not appear to me that these are productive or useful edits being made by the bot. Cinderella157 (talk) 05:36, 16 May 2022 (UTC)
- @Cinderella157 Hello, the returns are rendered but are very difficult to notice in some browsers since the extra spacing is partially suppressed (MOS:LISTGAP has an example). In any case, the edits are not about the visual spacing but rather the HTML output. See WP:BULLET for how the HTML changes.
- When you say you are adding the extra returns to facilitate editing, do you mean that the extra spacing in the wikitext helps you quickly differentiate comments/responses? Would the first approach at MOS:INDENTGAP achieve the same effect? For example, If so, I might have the bot do that instead of deleting the returns. Notacardoor (talk) 19:18, 16 May 2022 (UTC)
: Hello. : : Helloooooooooo.
- Notacardoor, yes, this relates to spaces (returns) in the default text editor to easily distinguish comments/responses - just as you added a space after my initial comment and I have added one now. See also the link I provided. I don't think that the approach at MOS:INDENTGAP is necessarily the right way to do things in such a case, since the spaces (returns) are placed between sections of prose that will often have different indent levels (though a second response by a second editor will have the same indent level as the first response by the first responding editor. I would think that the solution is simple. Unless there are multiple such lines in series, leave them alone (leave one). Regards, Cinderella157 (talk) 00:38, 17 May 2022 (UTC)
- Regarding
just as you added a space after my initial comment
: there isn't an issue with blank lines after a paragraph without any prefixing characters (:
,*
, or#
), since there is no current list in progress that would get interrupted by a blank line. The problem with leaving a blank line between list items (that is, between paragraphs with prefixing characters) is that this will cause all lists in progress (one for each prefixed character) to be closed, and then new lists started, and screen readers will announce all of them. (See User:Isaacl/On wikitext list markup for a little more detail.) I appreciate that editors can find it inconvenient. Unfortunately, it's the best workaround we have at present to avoid what can be a lot of extraneous voice output. isaacl (talk) 05:19, 18 May 2022 (UTC)
- Regarding
- Notacardoor, yes, this relates to spaces (returns) in the default text editor to easily distinguish comments/responses - just as you added a space after my initial comment and I have added one now. See also the link I provided. I don't think that the approach at MOS:INDENTGAP is necessarily the right way to do things in such a case, since the spaces (returns) are placed between sections of prose that will often have different indent levels (though a second response by a second editor will have the same indent level as the first response by the first responding editor. I would think that the solution is simple. Unless there are multiple such lines in series, leave them alone (leave one). Regards, Cinderella157 (talk) 00:38, 17 May 2022 (UTC)