Seems to me that this may be better done by a javascript component that the communities can embed onto the index page template by means of a script rather than by putting it into the proofread page code.

Someone should be able to write an api call that iterates through the Page: and Index: namespace page. Accordingly, I would think that this might be better to be put into the Wikisource queue rather than sitting with proofread page.

As one who edits the Page: ns a lot, I am not certain that I see a lot of benefit in watching all those tens of thousands of pages.

In T100233#1669887, @Billinghurst wrote:

Seems to me that this may be better done by a javascript component that the communities can embed onto the index page template by means of a script rather than by putting it into the proofread page code.

I'd tend to agree offhand but, assuming the reporter is looking to monitor any changes to existing Page:s as well as the creation of previously non-existing new Page:s at once, it seems like the list of pages to be added is a mirror of the pages detected & linked to by <pagelist /> so there is a chance the PR extension is relevant here.

Someone should be able to write an api call that iterates through the Page: and Index: namespace page. Accordingly, I would think that this might be better to be put into the Wikisource queue rather than sitting with proofread page.

Again, if monitoring both existing and yet-to-be created Page:s is the overall goal here - all we really need is a way to output a list with a constant "basepagename" (Page:Foo.djvu) and the entire Page: range (1 to 3) ... ex.

Page:Foo.djvu/1
Page:Foo.djvu/2
Page:Foo.djvu/3

... to manually (raw) add to one's watchlist

As one who edits the Page: ns a lot, I am not certain that I see a lot of benefit in watching all those tens of thousands of pages.

Agreed. If someone just want to insure nobody messes with their last edit, they should be adding to their watchlist upon save. Or they can manually (raw) add a list of only existing pages by ripping from outputs like this.

Definitely agree with GOIII that if someone wanted to watch all subsidiary
pages of an index, it should be done by JavaScript. (low use function)

That said ...

Seems more pertinent to have a proxy watch through/relationship with
"special:related links" and have a name space filter capability.

Eg. For index:ggg.djvu, show me changes on linked pages in Page: ns (as
they will only be subsidiaries.)

That has universal wiki application, though significant change to watch
lists. As it has a broader audience, though with special application, it
may make a good GSOC project.

In T100233#1845746, @Billinghurst wrote:

...

Seems more pertinent to have a proxy watch through/relationship with "special:related links" and have a name space filter capability.

Eg. For index:ggg.djvu, show me changes on linked pages in Page: ns (as they will only be subsidiaries.)

That has universal wiki application, though significant change to watch lists. As it has a broader audience, though with special application, it may make a good GSOC project.

Well wait a second... the only reason I kept throwing in the ''assumption the reporter intends to watch both existing and yet-to-be-created" was because I assumed that monitoring would be perpetual (for ever and ever). That would need to be handled by some "notification" type of list/system instead of watchlist

Throw away that assumption and lets say the reporter just intends to monitor a work while its the PotM (e.g. a monitoring range only extending 30 days or so from the "last change), one [I would think] would use the form on Special- Recent Changes Linked to accomplish that. See this month's PotM changelist for example. [update: that too seems to be limited to the last 500 changes max regardless of the number of days set]

So the nuance between with or without "assumption" cases is the current period of time limits. Currently most anything generated by a query via a Special: page form is probably limited by 'report count' if not by a max ~30 days view back while the original reporter "seems" to want be able to monitor the same but without date range if need be.

Otherwise, I agree with Billinghurst that -- be it watchlist based or notification listed, this idea probably better off being developed as a local, per-User script and/or aided by off-core tools if need be.

@Ninovolador of course you can just scoop the pages from the index page (edit mode or page information) and paste them into place through special:editwatchlist.raw and you can even do redlinks