CCing Reedy and Odder.

For the floating page-number links it's an issue in the PageNumbers.js script of en.wikisource.

For the source tab, it's because Proofread Page try to add it only in ns0. A solution is maybe to make Proofread Page add it to all content namespaces, excepts Page: and Index: ones. But there may be some unwanted side effects.

(In reply to Tpt from comment #2)

For the floating page-number links it's an issue in the PageNumbers.js
script of en.wikisource.

I'm pretty sure we've circumvented the floating page-number issue in the period since this bug was first identified by modifying the local en.WS PageNumbers.js file just like you recommended but it came at the expense of removing the feature from working in the Project ns sandbox. In short - they "work" in the Translation namespace but it's probably not the most elegant fix possible.

For the source tab, it's because Proofread Page try to add it only in ns0. A
solution is maybe to make Proofread Page add it to all content namespaces,
excepts Page: and Index: ones. But there may be some unwanted side effects.

Maybe the "refactoring" changed this state of affairs in the interim? It seems that that the ns-0 generation of the 'source' tab comes from 'ext.proofreadpage.article.js' in the line...

$( '#ca-nstab-main' ).after( '<li id="ca-proofread-source"><span>' + mw.config.get( 'proofreadpage_source_href' ) + '</span></li>' );

... the '#ca-nstab-main' being the key. Wouldn't ...

$( '#ca-nstab-translation' ).after( '<li id="ca-proofread-source"><span>' + mw.config.get( 'proofreadpage_source_href' ) + '</span></li>' );

... achieve the same tab generation but limited to just the translation namespace?

In T53980#587475, @Tpt wrote:

A solution is maybe to make Proofread Page add it to all content namespaces, excepts Page: and Index: ones. But there may be some unwanted side effects.

Would it make sense to add it anywhere a <pages /> element is used? e.g. have that insert some marker, and then have the JS insert the Source tab based on the presence of that marker?

@Samwilson Yes, everywhere the element is used it should generate the source tab, the page numbers along the left side, and any other elements that it generates in mainspace.

Are there other elements other than those two?

@Samwilson not sure. I know it generates a grey highlight under the text transcluded from a single page when you hover over the page number. There may be other functionalities that I am not aware of.

Ok, a couple of things here…

First, as @Tpt said in the 2013 comment, the page number links and grey background highlight on hover are provided by the Wikisource-local javascript MediaWiki:PageNumbers.js. It's entirely independent of ProofreadPage and needs to be handled separately (if only we had any Interface Admins…). All those bits of the task description can be ignored (I'll edit the task description shortly if I have sufficient permissions).

Second, the actual problem in ProofreadPage can't be fixed in ext.proofreadpage.article.js as @GOIII suggested in 2014. The javascript depends on ProofreadPage exposing a proofreadpage_source_href config variable to mw.util, which ProofreadPage doesn't do in the Translation: namespace.

So the fix has to happen in ProofreadPage proper (in PHP code). If the risk is merely that ProofreadPage exposes proofreadpage_source_href in various weird content namespaces, I think that's probably an acceptable risk. You won't even get a "Source" tab by default outside ns:0 because that's added by the javascript that triggers off a known namespace name (#ca-nstab-main vs. #ca-nstab-translation). We'll need to actively turn on display of it (by modifying that selector) for anything to happen. If concern about that is the stumbling block I say “Go for it!”.

If concern about that is the stumbling block I say “Go for it!”.

Agreed.

This is worked around at enWS with Javascript: https://en.wikisource.org/wiki/MediaWiki%3AGadget-site-source-links.js

This is presumably very nearly T239033, since if the extension can add a "Source" link for a mainspace page user of <pages/>, it can do it in any other namespace?

This is presumably very nearly T239033, since if the extension can add a "Source" link for a mainspace page user of <pages/>, it can do it in any other namespace?

Yes, there is nothing on MediaWiki core side that prevent adding the "Source" link in other namespaces than ns0. The filter on ns0 is done here

Boldly adding this task to Thai-Sites because Thai Wikisource also has this problem (eg. https://th.wikisource.org/wiki/งานแปล:ย่อรายวันสำหรับประธานาธิบดี_26_กุมภาพันธ์_ค.ศ._1974).

Feel free to remove the tag if this is deemed inappropriate.

Change 841998 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/extensions/ProofreadPage@master] Add ability to configure Book namespaces on a per wiki basis

https://gerrit.wikimedia.org/r/841998

Although @Soda has added a great patch above to make the namespaces configurable, I still wonder if we wouldn't be better off getting rid of the namespace restriction all together and just displaying the source tab on every page that uses the <pages /> parser tag? That way we don't have to keep track of namespace IDs at all for this.

It sounds like one of the main issues with doing that might be on talk pages, where multiple different Index pages might be linked (for examples etc.), but actually I think this is highlighting an existing problem with how we handle linking to multiple sources. For example, a top-level page for a work might want to display the tables of contents from multiple volumes with something like this (where each volume has its ToC on page 5):

<pages index="Book, vol 1.pdf" include="5" />
<pages index="Book, vol 2.pdf" include="5" />

That works correctly as far as the output goes, but the Source tab only links to the first Index page.

It might be nicer to make the source tab into a dropdown in this case, and list all Index pages.

It sounds like one of the main issues with doing that might be on talk pages, where multiple different Index pages might be linked (for examples etc.), but actually I think this is highlighting an existing problem with how we handle linking to multiple sources. For example, a top-level page for a work might want to display the tables of contents from multiple volumes with something like this (where each volume has its ToC on page 5):

Yes, a dropdown would definitely make sense in this case. But there is also the question of the proofreading process widget. Should we have one per "index" or a single one that merges all the indexes?

Then, as @Soda said in Gerrit, there is the question of the appearance of the source link in namespaces like "author", "wikisource"... I am not sure all communities are going to like the "source" tab to appear there. Having a NS whitelist seems like a safe way to avoid this debate but I'm maybe a bit too conservative here.

Yes, okay. :-) Maybe I'm just overcomplicating this! The issues of multiple Indexes are probably separate to this, and if y'all are happy with the new config var then so am I.

Change 841998 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Add ability to configure Book namespaces on a per wiki basis

https://gerrit.wikimedia.org/r/841998

Change 843230 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[mediawiki/extensions/ProofreadPage@master] Source link should also use wgProofreadPageBookNamespaces

https://gerrit.wikimedia.org/r/843230

Change 843230 merged by jenkins-bot:

[mediawiki/extensions/ProofreadPage@master] Source link should also use wgProofreadPageBookNamespaces

https://gerrit.wikimedia.org/r/843230

Change 843593 had a related patch set uploaded (by Sohom Datta; author: Sohom Datta):

[operations/mediawiki-config@master] Enable source links on Translation ns on enwikisource and thwikisource

https://gerrit.wikimedia.org/r/843593

Change 843593 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable source links on Translation ns on enwikisource and thwikisource

https://gerrit.wikimedia.org/r/843593

Mentioned in SAL (#wikimedia-operations) [2022-10-24T08:05:04Z] <ladsgroup@deploy1002> Finished scap: Backport for [[gerrit:843593|Enable source links on Translation ns on enwikisource and thwikisource (T53980)]] (duration: 09m 18s)

9 yers since it has been reported; very exciting pace of fixing this problem...

Waited for long to be enabled on Wikisource. Since it is happening, would love to see it deploy on Bengali Wikisource too. Example - https://bn.wikisource.org/s/crl

Change 849672 had a related patch set uploaded (by Bodhisattwa; author: Bodhisattwa):

[operations/mediawiki-config@master] Enable source links on Translation ns on bnwikisource

https://gerrit.wikimedia.org/r/849672

Change 849672 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable source links on Translation ns on bnwikisource

https://gerrit.wikimedia.org/r/849672

Mentioned in SAL (#wikimedia-operations) [2022-10-27T13:06:19Z] <lucaswerkmeister-wmde@deploy1002> Started scap: Backport for [[gerrit:849672|Enable source links on Translation ns on bnwikisource (T53980)]]

Mentioned in SAL (#wikimedia-operations) [2022-10-27T13:06:38Z] <lucaswerkmeister-wmde@deploy1002> lucaswerkmeister-wmde and bodhisattwa: Backport for [[gerrit:849672|Enable source links on Translation ns on bnwikisource (T53980)]] synced to the testservers: mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-10-27T13:12:02Z] <lucaswerkmeister-wmde@deploy1002> Finished scap: Backport for [[gerrit:849672|Enable source links on Translation ns on bnwikisource (T53980)]] (duration: 05m 40s)

@Bodhisattwa Changes should be live on bnwikisource :)