Talk:Talk pages project

About this board

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.

Do subscriptions expire?

18
Doug Weller (talkcontribs)

And if not, will a build up over time slow me down? Should there be a "list" where I can delete them? Doug Weller (talk) 07:41, 29 January 2022 (UTC)

MichaelMaggs (talkcontribs)

And a related question: what happens to a subscription when the pages gets archived? At that point I imagine it gets deleted to avoid old subs building up?

Whatamidoing (WMF) (talkcontribs)

At the moment, there's a hard limit of 5,000 subscriptions per user per wiki, and after that point (which nobody's come close to), you can't add any more.

A long list shouldn't slow you down.

When a conversation gets copied to a different page (e.g., by an archiving bot), the subscription transfers to the new page. This means that if someone adds a new comment to an archived discussion, you will still get notifications. However, the name of the old/original page is still displayed and linked in Special:TopicSubscriptions.

Doug Weller (talkcontribs)

So if I add 10 a day, in about a year and a half I'll have to stop. But I think I add more than 10 a day just by starting a new topic. What's the plan for that?

Whatamidoing (WMF) (talkcontribs)

Editing's devs' plan is to remove the hard limit. Whether they'll get agreement (e.g., from Ops) might still be an open question, but I think we still have a few months before it will become a problem for anyone.

Looking at your contribs last month, you used the New Discussions tool to create 130 sections, and you used the Reply tool about 450 times. Originally, automatic subscriptions were only enabled for those two tools (e.g., not for Twinkle), and I believe that's still the current situation.

I'd really like to know how well it's working for you. Is it a good idea? Would you recommend it to others? What kind of editor will it work best for?

Doug Weller (talkcontribs)

It's pretty good but I find it discourages me leaving edit summaries, which I predict it will do for others. When I do I feel the need to remove the word "reply" as it looks awkward. We need to do everything we can to encourage edit summaries. IMHO one reason to revert a dubious edit is lack of explanation for the edit. Agh, why wasn't I automatically logged in when replying? Refreshing logged me in.

Whatamidoing (WMF) (talkcontribs)

I remember you mentioning this concern at enwiki last month. I don't think that people revert signed talk-page comments due to a lack of explanation. They're pretty self-explanatory.

86.14.197.26 (talkcontribs)

Sorry, I wasn’t thinking, that’s articles of course.. So long as not encouraging people to leave edit summaries on talk pages doesn’t effect their leaving summaries on articles.

Doug Weller (talkcontribs)

Damn, happened again.

Tacsipacsi (talkcontribs)

I think the best way to make people’s article edit summary customs be independent from their talk page edit summary customs is actually what this project does: present a completely different UI that doesn’t even show the edit summary field by default—this reinforces that talk pages and articles are fundamentally different and should be used differently.

Doug Weller (talkcontribs)

Terrible idea. Edit summaries can still be important on talk pages.

Whatamidoing (WMF) (talkcontribs)

I agree that they can be important. In my experience, though, when you're posting a new comment (as opposed to, e.g., editing someone else's comment), they almost never are important.

DLynch (WMF) (talkcontribs)

For what it's worth, our intention around the 5,000 subscriptions limit is that it was added in case we were monumentally wrong about our estimate of how much data this feature would generate. E.g. If a lot of people had managed to hit the limit within a few weeks of usage, we'd have had to rethink our storage needs. But they haven't, and so I think our current plan is to remove the limit before anyone actually hits it. (Again, unless things change and make us reconsider that...)

Doug Weller (talkcontribs)

Thanks.

Xaosflux (talkcontribs)

@Whatamidoing (WMF) - did the 5000 limit ever get removed? If not is there a tracking task open to do so?

Doug Weller (talkcontribs)

And is it technically possible to build in a “delete after one year” or something similar?

Matma Rex (talkcontribs)

Yes, it has been removed in T294881.

It would be technically possible to make them expire and get deleted automatically, we have a task for it here: T278190. We also have one about making it easier to clear out your subscriptions manually: T292035. I don't know if we'll get around to working on these, though.

Reply to "Do subscriptions expire?"
Bluehill (talkcontribs)

To unsubscribe from Special:TopicSubscriptions, I must press the Cancel button, and then press the Cancel button again. And if I want to unsubscribe from multiple topics, I have to come back and repeat the process. This is very inconvenient for users. I wish I could cancel subscription without moving the page like Watchlist.

Doug Weller (talkcontribs)

There is also a limit of 5,000 subscriptions. Editors who edit a lot of pages that use this will hit it. How to undo old ones fast? Eg the earliest 3;000. And why can’t I make an edit summary here? ~~~~

Reply to "Special:TopicSubscriptions"

Link for specific reply highlighted

4
Summary by PPelberg (WMF)

T302011: Introduce permalinks on wikitext talk pages

Klein Muçi (talkcontribs)

If you follow the link in the email you get for a new reply, you get sent into the page with the discussion you are subscribed to and the new reply gets highlighted in blue.

Is there any way to get the same highlighting effect for different comments? Said differently, an anchor URL for individual comments of choice, the same logic that we follow when sharing links for specific sections on pages. If you share the very-long URL that makes such a process possible the other person will get that reply highlighted in the same way as you do, so I would assume that what I'm asking is technically possible. The only question is how do you get that URL for different comments in the discussion?

Matma Rex (talkcontribs)

Yes, you can find the anchor if you use the "Inspect" tool in your browser, and look for an element like <span data-mw-comment-start="" id="..."></span> near the beginning of each comment, then copy the id attribute from it.

There is a gadget that adds a "link" button next to "reply" to simplify this: https://meta.wikimedia.org/wiki/User:ESanders_(WMF)/commentlinks.js

We didn't add this feature to the normal reply tool because we feared cluttering up the page, but we're considering adding it as part of the talk page usability work.

Klein Muçi (talkcontribs)

Thanks a lot! This resolves my request.

I really hope you add that as a native feature. Does the link really have to be that long though?

Matma Rex (talkcontribs)

It doesn't really have to be. There are some ideas to improve the links in T302012 and related tasks.

Reply to "Link for specific reply highlighted"
Xaosflux (talkcontribs)

So, when using the quick reply tool, can TAB go to either the edit summary or the submit button, similar to if you are in the wikitext editor? Having it go to the next hyperlink on the page (for example in the preview) doesn't seem very helpful. Xaosflux (talk) 17:42, 6 June 2022 (UTC)

Xaosflux (talkcontribs)
Matma Rex (talkcontribs)

This idea was previously discussed in T271773. At the time it seemed like it wouldn't necessarily be intuitive, and could be particularly confusing for screen-reader users. In my own experience, in cases where I'd previously press Tab then Enter to submit a message, I just press Ctrl+Enter.

Xaosflux (talkcontribs)

Thanks for the note, I certainly find it more confusing for non-screen reading purposes - not sure of the utility of tabbing in "to" the preview content, but maybe someone will find it useful?

Reply to "reply-tool tabbing?"
Klein Muçi (talkcontribs)
Whatamidoing (WMF) (talkcontribs)

I'm pretty sure that one of the communities has something similar, built into the toolbar of the 2020 wikitext editor. It's mostly used by vandal fighters and RecentChanges patrollers to leave messages on new editors' talk pages. @Patrik L., is that a cswiki script/gadget?

Tacsipacsi (talkcontribs)

There is a gadget on huwiki that matches Whatamidoing’s description (maybe you remembered that, I think I’ve talked about it related to the preload support in New Topic Tool), but it’s different from what Klein Muçi is asking: warning.js can only start new topics, while this request is about adding replies to existing topics.

(Actually, warning.js doesn’t even have a notion of “topics”—it just has four modes (prepend—e.g. amboxes—, append—e.g. message templates—, comment out the rest—e.g. copyright violation notice—, and replace); if append mode is used and the content happens to include a topic header, it will result in a new topic.)

Klein Muçi (talkcontribs)

Maybe reading the other part of the aforementioned discussion will bring more clarity in what I'd be trying to achieve with the said function: https://en.wikipedia.org/wiki/Wikipedia:User_scripts/Requests#Script_that_adds_the_possibility_to_give_template-replies_with_1_button

If you see my current last answer there, you'll see that I do mention 1 specific list of templates I'd like to be able to use with a function like this. We're talking about templates such as "done", "read", "agree", etc. This is no news with me because ever since the reply tool was first introduced I've asked for the ability to vote and thank with it. (I'd still like it if for the thanking function the native "thank this user" function was used and for voting we had an overall better interface that also allowed for better "vote counting".) This is in the same waters. Generally I do enjoy templated answers and I think they're a great "solution" to "one-liners". This isn't as much related to warnings and vandal fighting as it is to organizing everyday wikiwork. Actually the whole inspiration behind this came because I was thinking of asking for a script that gave me a button on a press of which I could quickly add a reply on the lines of "I've seen this request and I'll answer shortly." because Wikipedia has no "seen/read; online/offline" function. (That's a good thing I believe.) There I saw the {{Read}} template and with it the whole list I mention above. This is when I started thinking that most of them would also be pretty useful in everyday work in many wikis, hence the user script request and this discussion here.

The scalability problem I mention comes because I imagine that if such a tool would be made possible as a native function, it would also force each wiki to first import all those templates, that is, unless we are willing to make those templates also ingrained in the function itself somehow.

Whatamidoing (WMF) (talkcontribs)

It sounds like you want the original vision for Flow.

Klein Muçi (talkcontribs)

Could be. Don't really know in what that vision consisted of. :P

Reply to "Templated answers"

Bengali language project issue

4
This post was hidden by MdsShakil (history)
MdsShakil (talkcontribs)

Discussion tools in Bengali language project contains ertra -- before automatic signed. As far i saw this things was not in other projects. Where is it coming from and why? @Whatamidoing (WMF):

Matma Rex (talkcontribs)
MdsShakil (talkcontribs)

Thanks for your help. That's now fixed in translatewiki

MediaWiki message delivery (talkcontribs)

Read this in another languageSubscription list for this multilingual newsletter

New editors were more successful with this new tool.

The New topic tool helps editors create new ==Sections== on discussion pages. New editors are more successful with this new tool. You can read the report. Soon, the Editing team will offer this to all editors at the 20 Wikipedias that participated in the test. You will be able to turn it off at Special:Preferences#mw-prefsection-editing-discussion.

Whatamidoing (WMF) 18:43, 2 May 2022 (UTC)

Reply to "Editing news 2022 #1"

Line-item selection for the beta feature

12
Theleekycauldron (talkcontribs)

I want the reply-tool and new section creator, but the section subscription is just a headache... can i have the option to disable it?

Matma Rex (talkcontribs)
PPelberg (WMF) (talkcontribs)

...the section subscription is just a headache

hi @Theleekycauldron: are you able to share a bit more about your experience with the section subscription feature? I'm curious to learn what's causing you to want to disable it in case there are aspects of the feature we ought to consider revising...

Theleekycauldron (talkcontribs)

@PPelberg (WMF): it's just that it keeps showing up whenever I use the double-click to try and copy the whole of a section heading. then I gotta delete it, and since I do a lot of manual copy/paste work, it's a hassle.

PPelberg (WMF) (talkcontribs)

Ah, I see! Can you share what browser you are using? And even better, a screen recording of you experiencing the issue you are describing above?


...I ask the above as I seem to be able to double click section headings without the [edit] or [subscribe] links being selected.

Theleekycauldron (talkcontribs)

I've uploaded a video here; i use google chrome 100.0.4896.75, as you can see

Tacsipacsi (talkcontribs)

Thanks, that’s really useful! I can reproduce it with Chromium 90.0.4430.212 (but not with Firefox 91.8.0esr), even on w:Bay of Winds, which has absolutely nothing to do with DiscussionTools (on this page, of course only [edit] gets unnecessarily copied, as there’s no subscribe link). Disabling topic subscriptions can reduce the number of characters you need to delete after copying, but the bug doesn’t seem to be specific to DiscussionTools.

Whatamidoing (WMF) (talkcontribs)

Leeky, I don't see anything at that link.

I wonder if this could be solved with CSS (for all the [buttons]). Perhaps there's some way to mark them as not worth copying, or as being separate?

Theleekycauldron (talkcontribs)

the video contained some identifying information, so I removed it. I could upload another, if you'd like?

Whatamidoing (WMF) (talkcontribs)

No, I don't think I need that. I'm glad that you removed the file with identifying information.

Tacsipacsi (talkcontribs)

I wonder if this could be solved with CSS (for all the [buttons]). Perhaps there's some way to mark them as not worth copying, or as being separate?

They already have user-select: none, which is a hint that they’re not worth copying. However, per the spec, browsers are only required not to select such text, copying it is not forbidden. Making selection and copy behavior consistent is just a best practice recommended by the spec, and Chrome seems to ignore it. I think the best we can do here is to ask Chrome developers to follow the best practices.

Theleekycauldron (talkcontribs)
Reply to "Line-item selection for the beta feature"

Reply tool does not allow edit summaries

25
Doug Weller (talkcontribs)

I think this is a big mistake. Edit summaries are IMHO still part of communication and can be very useful. Doug Weller (talk) 12:09, 22 December 2021 (UTC)

Tacsipacsi (talkcontribs)

It does allow them. Edit summaries are less useful on talk pages, though, so the summary field is hidden in the Advanced drawer in order not to distract inexperienced users. (You can change the summary even in the new discussion tool, which is not possible in the classic editor.)

Doug Weller (talkcontribs)

Thanks.I believe it should be the default, at least on enwiki we encourage people to use edit summaries, and in requests for Administration Admins have had their lack of edit summaries mentioned. And I can see no reason at all why Talk pages project/Replying#What it is doesn't mention this. Sure, it's in [[Talk pages project/Feature summary]] but I'd prefer not to have to click to another page to find out what it does, although I'm happy for the screen shots to be on another page. I see I have to sign for myself on this page. Doug Weller (talk) 14:39, 22 December 2021 (UTC)

Yaron Koren (talkcontribs)

I disagree with this - I don't see the point of putting in an edit summary on a talk page edit; if it conveys any actual information, that means that people trying to follow the conversation on a talk page now need to read the page history as well - more work for everyone. If potential admins on Wikipedia get points deducted for not writing talk page edit summaries, that seems like a problem on Wikipedia.

Doug Weller (talkcontribs)

For people using watchlists to keep track of articles and talk pages, edit summaries are extremely useful. And of course we want to encourage their use elsewhere, and this doesn't help. So far as I can see, you haven't edited much and your edits are on projects associated with the encyclopedia, so you don't seem to have much experience, oe none, on something like en.wiki. So you'll have little or no experience of watchlists. I don't mean to be rude, but I'd prefer to here from people with a lot of experience editing on their own language wikipedia. They are more likely to know what will be useful. Doug Weller (talk) 17:03, 22 December 2021 (UTC)

Thryduulf (talkcontribs)

On watchlists edit summaries can tell you whether you need to read the whole comment or not (e,g, is it a strand of discussion you are following? is someone replying to you?, just correcting a typo, etc), in page histories they can help you find the particular comment you are looking for. This is especially true when talk pages are being used for complex discussions, where article content is being drafted or other things other than just simple discussion. So they should always be available to enter and never hidden. For example for this comment I would (if I could) summarise it as "agree with Doug", which is much easier for someone to parse in histories and watchlists than the first however many characters of my comment, which will probably leave someone reading it little wiser about my comment. Thryduulf (talk) 17:29, 22 December 2021 (UTC)

Nick Moyes (talkcontribs)

Aargh- I’ve just looked at the so-called edit summaries of edits to this very page. Incomprehensible!

Doug Weller (talkcontribs)

It's worse. If I start a new topic on an editor's talk page to give them a Discretionary sanctions alert, it just publishes it without the warning that I should be checking various places to make sure they don't already have one. Doug Weller (talk) 13:55, 23 December 2021 (UTC)

Enterprisey (talkcontribs)

As I remarked on enwiki (don't want to split the conversation), edit summaries on discussion pages are not generally used (edit: usefully) on enwiki, so I don't see the need for a change in this area. (The discretionary sanctions thing is unrelated and at https://phabricator.wikimedia.org/T298263 for any onlookers; I see Doug Weller has already commented.)

Thryduulf (talkcontribs)

"edit summaries on discussion pages are not generally used on enwiki," eh!? Edit summaries are almost always used on every page on enwiki and have been for well over a decade. Thryduulf (talk) 10:16, 25 December 2021 (UTC)

Enterprisey (talkcontribs)

I spoke imprecisely: edit summaries on discussion pages are not usually used to convey anything interesting on enwiki besides the single words "reply" or "comment", and most of the remainder is people saying their bolded !vote in a discussion ("sup", "opp").

Doug Weller (talkcontribs)

It's good to encourage their use. I certainly use them when I want to make sure that a point I am making is seen in the history of the discussion page. Doug Weller (talk) 11:08, 25 December 2021 (UTC)

Thryduulf (talkcontribs)

even "reply" and "comment" can be useful, summaries like "reply to ..." and "comment re ..." even more so when you are browsing the page history or see it in your watchlist.

Nick Moyes (talkcontribs)

I quite like 'reply' as the default edit summary on any talk page. It makes my life easy. But there are innumerable times when I need to do much, much more, including pinging another editor, or explaining why I'm making the reply I'm making in just a couple of key words.

Enterprisey (talkcontribs)

As I proposed on IRC, when the reply includes a ping, automatically making the edit summary "reply to ..." (or "reply (pinged ...)", to be 100% accurate), sounds like it would be a positive move. Nick, for your use cases, I would certainly expect them to provide an option to always show the edit summary box, as I did with reply-link.

Whatamidoing (WMF) (talkcontribs)

Once you open the "Advanced" drawer, it stays open until you close it. It's a sticky pref that will follow you from page to page (but not, I think, from wiki to wiki) forever.

Nick Moyes (talkcontribs)

I didn't know that; I'll give it a try. Thank you, WAID.

Doug Weller (talkcontribs)

One of the most important uses of reply on a discussion page is when that's a user talk page and you are commenting on policy/guidelines violations and vandalism - it gives a clear trail in the talk page history. I think it should be the default, not "Advanced'. Doug Weller (talk) 11:20, 26 December 2021 (UTC)

Doug Weller (talkcontribs)

When you reply, it indents to the right. Does this continue ad nauseam?

Thryduulf (talkcontribs)

A way to control the indent has definitely been identified as a missing feature of the reply link.

86.14.197.26 (talkcontribs)
Doug Weller (talkcontribs)

We’ll that caught me by surprise, I assumed I was logged in as I’m logged in elsewhere. But why the hell does my IP still show up when I edit it? Doug Weller (talk) 19:11, 29 December 2021 (UTC)

Doug Weller (talkcontribs)

I think edit summaries are also very important, at least on enwiki, at noticeboards.

Beland (talkcontribs)

I never put manual edit summaries for talk pages unless archiving or doing something outside a section (like putting a map-requested template), and I never read them when participating in a conversation. Looking through talk page histories, it seems that's how most editors operate. The auto-generated edit summaries just track which section is being commented on, and that's useful when archiving or tracking down unsigned comments. But beyond knowing the topic of conversation, I don't see the point. If it's important to know what the editor did in that edit, it's easy to read the diff. Otherwise, the implied action is "I commented on the topic of this section".

That said, I'm not sure it's worth hiding the edit summary box, when it's not that tall, and can be easily ignored. At the vary least, instead of "Advanced", maybe the text hiding it should say "Show edit summary/watchlist options" so editors new and old would be able to find those things more easily.

Doug Weller (talkcontribs)

I use them quite a bit on user talk pages, especially with problematic editors. I think that helps other editors who have the user on their watch list. I agree there is no advantage to hiding the edit summary box - I see only disadvantage.

Reply to "Reply tool does not allow edit summaries"

New topics should be at top of page

21
HopelessNightOwl (talkcontribs)

Currenly, new topics get added below older topics. It would be optimal if this was reversed.

Alexis Jazz (talkcontribs)

Hi @HopelessNightOwl. I found your question very interesting, so I decided to do it. Go to w:User:Alexis Jazz/Bawl#How to install and copy/paste the mw.loader line to m:Special:MyPage/global.js. Go to a talk page and press a blue speech balloon. Open the settings (gear icon) and enable "Reverse section order (newest threads first)". Scroll down and save. Reload the page. Please do let me know if this has the desired effect for you, and thank you for the inspiration to add this feature!

Doug Weller (talkcontribs)

Definitely not. A couple of decades of expecting new topics to be at the bottom can't be easily reversed, nor should it be.

The wub (talkcontribs)

The longstanding convention on Wikimedia sites is for new topics to be posted at the bottom, and I doubt that's going to change. However maybe it could be a config setting for other sites that want it?

Whatamidoing (WMF) (talkcontribs)

Top-posting is the longstanding convention on the internet.

To understand the bottom-posting preference on the older Wikipedias, it's helpful to know what we started with. Back in the day – see nostalgia:Neutral point of view for an example – there were no talk pages at all. Discussion (and policies and everything else) happened in the mainspace articles, because that was the only option. Later, most discussion was moved to a subpage like nostalgia:Spacetime/Talk.

At the time, it was common to have a discussion and then replace the discussion with a summary of the decision ("Alice and Bob agreed that this article should include information about elephants").

In this model, bottom-posting makes a lot of sense. The top of the talk page/section works like a FAQ, and active discussions are at the end of the page. You can read the past decisions before you join the new discussions.

However, in 2022, it has two drawbacks that will be significant to some:

  • It's inconvenient on a mobile device, especially when the page is long.
  • It's not what newcomers expect.
Doug Weller (talkcontribs)

Ah, mobiles. I can see that problem. Could do there be a fix, eg something at the top of the page to click to tale you to the bottom?

GhostInTheMachine (talkcontribs)

Perhaps a Table of Contents (with date of first post / date of latest post) would help?

Whatamidoing (WMF) (talkcontribs)

HopelessNightOwl, I would be very interested in hearing what problems you have encountered with bottom-posting, or what problems you think could be solved by top-posting.

PerfektesChaos (talkcontribs)

If some users are using AddNewSection as for the last two decades they will add at bottom, and if this tool starts to add sections on top if users are utilizing DT you will get an interesting structure within the page. Even more, those who are reading top sections only will never guess that there are recent topics on bottom, while those who acquired bottom sections will fly over top sections.

There are also multi-threaded talk pages, like Nominated for Deletion per Day in German Wikipedia at de:WP:LKH, where new entries are supposed to be added to the end, with the first proposal of the day in first position. Note the blue buttons. Later proposals might be related to the ones mentioned before.

Whatamidoing (WMF) (talkcontribs)

I think it would make sense for &section=new to post in the same part of the page, regardless of which tool you are using.

PerfektesChaos (talkcontribs)

That would require new syntax to mark selectively such classical talk pages which shall follow the reverse sequence.

  • A parser function or page switch is required to identify such pages for DiscussionTool.
  • The AddNewSection functionality needs to be extended for that mode, best by automatic recognition of the first switch to avoid incongruent behaviour and requiring additional manual efforts to change all implementations on all such pages.

Please see German Village Pump and explain the effect on those headlines and TOC.

Whatamidoing (WMF) (talkcontribs)

I don't think it would require new syntax. I think you would just have a moment of temporary but confusing transition. Perhaps you would schedule it for midnight on New Year's. Before then, you would have the old bottom-posting method of:

29 December–30 December–31 December, and then starting in January, you would have:

1 January––30 December–31 December, followed by:

2 January–1 January–31 December, and finally:

3 January–2 January–1 January.

Of course, it would be confusing if someone said that my page is special and must use the old style forever, because now you have to figure out which pages get which style, but a wholesale, complete switch for all pages would produce only temporary challenges (especially on high-traffic pages).

PerfektesChaos (talkcontribs)

Did you ever try in a project of 10,000 active users with 10,000s of portals, local projects, request pages to convince them to change a two decades old method on all community pages?

  • And necessarily on all article discussions, user talks, and template discussons?
  • With 10 unresolved issues present on X-day in chronological order, but section 11 and more on top now?
  • German Wikipedia has about 10,000,000 non-empty talk pages which are affected by your transition event, which mostly have more than one section and will need to be re-ordered. How long will a bot run take if server load does not permit more than one edit per 10 seconds per Wiki? I guess they are busy for several years. No X-day, not really.

Another interesting effect with classic order: Until after midnight some sections may be archived by bot and deleted, or somebody might insert a sub-section somewhere above, the &action=edit&section=42 in URL will edit always the same section for answering.

  • With on-top-AddNewSection the offered link to &section=42 becomes invalid and confusing half an hour later, since that is now &section=43. If you did not rebuild the entire page in your browser immediately before you answer, your village pump contribution will answer the wrong question. Oh, sorry, now it is &section=44 on saving, since between beginning and terminating typing a new issue became &section=1.
  • Hope at least everybody recognizes that just answering in the wrong section.

If ever introduced, this may be used on a few pages within the Wiki which are prepared and announced to follow the New Order. And this will need a software marker to be detected by both AddNewSection and DT to distinguish between sequence request and set by bot after re-ordering the previous content. And since you cannot change an entire large project with all talk pages by turnkey from one minute to the other you will need to support both methods simultaneously for a longer migration period.

Whatamidoing (WMF) (talkcontribs)

> Did you ever try in a project of 10,000 active users with 10,000s of portals, local projects, request pages to convince them to change a two decades old method on all community pages?

Yes, and so far it seems to be going pretty well. ;-) But I think you mean: Did I ever try to restructure millions of wikitext pages? The answer to that is "no".

I'm not sure that it would be necessary to restructure the pages. Yes, the old discussions would be in a different order. But high-traffic pages will sort themselves out via archiving, and I don't think it will matter for low-traffic pages. If you go to a page with three sections, and they are in the order of "3 – 1 – 2", it's still just three sections. You can still find everything on the page, even if the sections are not in order. It doesn't really matter if an article's talk page follows the order of "Book – Marriage – Links" or "Links – Book – Marriage".

Doug Weller (talkcontribs)

It appears from the post at the top that it's possible to do this through a script, so it should be possible to make it a choice? I think you overestimate archiving as not all article talk pages are archived and I've seen some very long ones.

PerfektesChaos (talkcontribs)

On a few highly frequented and archived pages it might be possible to reorder the appearance of independent sections via JavaScript.

  • However, the physical order needs to be constant, especially the section numbering and the effect of &section=new.

I recall more sophisticated and controversial discussions over weeks looking like that:

== Some topic ==
=== Severe objections ===
=== Other viewpoint ===
=== Reset this discussion and make a new starting point ===
=== Conclusions ===
=== Straw poll ===
=== Follow-up ===
== Some other topic ==

If ever, sorting on top is the exception on some pages requesting that, but should not become standard behaviour on all talk pages from one day to the other, without migration of unarchived dozens of sections within a page, and re-education of some 10,000 wikipedians used to the other way.

Alexis Jazz (talkcontribs)

@PerfektesChaos, there's no reason for the end user to care if the physical order is oldest first, newest first, diagonally or inscribed on cucumbers. There is no "physical" order anyway, it's all virtual. :-) My script option does four things: reverse all H1 sections, reverse all H2 sections without leaving their H1, make the new section form appear at the top instead of the bottom, collapse the TOC. The latter because if you enable this you probably want to minimize scrolling/start reading as quickly as possible. When a thread is posted the form is replaced with the preview, so the preview also shows correctly. H3/H4/etc sections and individual comments keep their original order exactly for the reason you stated. An individual Twitter thread is also oldest-first so this isn't out of the ordinary. It should help with the excessive scrolling issue on mobile devices in most cases, though some extremely long H2 sections are known to exist, luckily they are fairly uncommon.

GhostInTheMachine (talkcontribs)

"New to the top" is only at all valid if the ordering is implemented as a display option for the user. If the page showed a up/down button and allowed the time flow to be revered, then that might be acceptable. The posts would also need to show a valid timestamp as part of their heading so that a user could tell which way up everything was

Alexis Jazz (talkcontribs)

@GhostInTheMachine, I'm not entirely sure what you mean. In case of my script, there is no up/down button, it's an option in its preferences. As a matter of fact, once the reversal is complete it currently can't be undone without reloading the page. What do you mean with the "heading of the posts"?

Whatamidoing (WMF) (talkcontribs)

I don't think that Ghost meant to write quite so absolute a statement. Presumably he'd have no objections at all if a community chose to top-post on some or all of their pages. The English Wikipedia top-posts their AFD entries, and I'm sure that Ghost wouldn't want to change that just for the sake of making every AFD entry for each given day be posted in chronological order (example: the entry for Jabaco was posted at 01:39, 16 March 2022 (UTC) and is correctly above the entry for "Commit Media", which was posted 18 minutes earlier).

GhostInTheMachine (talkcontribs)

I cannot remember discussing this with Whatamidoing.

Reply to "New topics should be at top of page"
Return to "Talk pages project" page.