We are using diff for that long

Who is "we"? Wikimedia wikis don't use GNU diff but wikidiff2.

Two questions:

1. Is this task about any pages (as StructuredDiscussions on talk/discussion pages offers watching a specific section / topic, so technology already exists but outside of the MediaWiki core), or rather about articles in the main namespace as described in T2738#1098527 ?

2. Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team--ARCHIVED working on technology that might overcome this?:

In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

This is about standard wikitext pages

Question still open:
Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team--ARCHIVED ( @ssastry? @cscott? @Legoktm? or someone else?) working on technology that might overcome this?:

In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

I already answered this question:

In T2738#34571, @Nemo_bis wrote:

I think there are multiple degrees of complexity / steps possible here.
The simplest/crudest way possible is probably

1. add a "watch" / "unwatch" button next to the "edit" button of each section, which stores the header text as is in the user's watchlist,
2. let users edit that text match freely in Special:EditWatchlist,
3. show in Special:Watchlist only the edits whose summary matches that section text, similar to how we filter by minor/bot/etc. edit.

Of course this would cover only a subset of the cases, but potentially a significant one. Anyone bothers to search in Google Scholar or whatever if there's some relevant past research on section editing?

search in Google Scholar or whatever if there's some relevant past research on section editing?

I found nothing. Perhaps someone else might have better luck.

In T2738#2361293, @Aklapper wrote:

Question still open:
Is the situation described by Brion twelve years ago in T2738#34503 still the current status or is the Parsing-Team--ARCHIVED ( @ssastry? @cscott? @Legoktm? or someone else?) working on technology that might overcome this?:

In T2738#34503, brion wrote:

Sorry, but this is not practical; sections don't have a consistent identity which could be watched reliably.

Yes, his comment is still true (there's a bug about stable ids for sections somewhere) but I think Nemo's implementation suggestion is probably the best way to go forward for now.

In T2738#2682136, @Legoktm wrote:

Yes, his comment is still true (there's a bug about stable ids for sections somewhere) but I think Nemo's implementation suggestion is probably the best way to go forward for now.

I think the UI for the basic version is rather straightforward (more controls and assorted improvements can be done later). Is the next step to propose a possible DB schema? Are there other potentially controversial aspects or blockers?

Maybe want to check how frequent edit summaries satisfy/don't satisfy the criteria in T2738#34571 so that we know how robust that fix is.

In T2738#2682441, @Nemo_bis wrote:

I think the UI for the basic version is rather straightforward (more controls and assorted improvements can be done later). Is the next step to propose a possible DB schema? Are there other potentially controversial or blocking?

Probably. It needs coordination with the other planned schema changes to watchlist (@Addshore?). We would also need some kind of index on rev_comment. I don't know how expensive or problematic that would be. It could also be implemented like the category watchlist stuff was potentionally?

I know this has been open for ages, but would it be feasible for a tag (the same as existing tags, or a different sort so they also contain the section name) to be auto-associated with an edit if said edit is made by clicking a section edit link? Then the "watch a section" functionality wouldn't have to rely on parsing, and could filter out all edits that have an unrelated tag. Regex matching could also be possible with such an implementation (e.g. if someone wants to be notified about Tech News without publicly announcing their subscription).

Such a filter would also catch edits made in sections with the same name and edits to the whole page (i.e. edits without tags), but it would filter out the majority of unrelated edits.

(Obviously there would be issues with templates being used in section names and section names being changed, but those things already break current edit summaries.)

Oh, this is basically the same as T2738#34571. Adding a tag would allow some auto-filtering (e.g. removal of templates), though.

I wish this request was given higher priority. It would really be extremely useful.

This will also let users watch specific sections in talk pages.

This was one of the top results of the Talk Page Consultation. I think(?) the team put section watchlisting on the to-do list.

Is it possible to add this feature in the mobile app?

@Jeour3: Hi, please ask in a support forum for the mobile app (as this ticket is about the MediaWiki software running on websites). Thanks a lot! :)

I've also been working on https://en.wikipedia.org/wiki/User:Enterprisey/section-watchlist, which is relevant to this task. It's not that stable right now (and down most of the time), but it seems pretty promising. My approach was use the recent changes events stream to get revision IDs, and then parse diffs to figure out what happened to each section.

Please see https://www.mediawiki.org/wiki/Talk_pages_project/Notifications and especially the discussion at https://www.mediawiki.org/wiki/Topic:W3c084ihivgkm9vt especially if you have specific use cases or examples to share.

Hi what's the status on this? Is it still being worked on?

@Jeour3: The status is below the task title ("Open"), and in the "Assigned To" field ("None").

DiscussionTools now allows users to subscribe to sections which uses the notifications mechanism, which is usually the dominant use case for watching sections.