verszil wrote:

Wikisource mobile Page View

Attached:

Not sure about the best software component either - tentatively moving from ProofreadPage to MobileFrontend.

I believe it should be handle by Proofread Page as it's Proofread Page related features but as long as Mobile Frontend is not merged into core, it's more easy to add mobile related features into Mobile Frontend. than in other extensions.

What needs to happen here is Proofread extension should add its own module to mobile that adds this feature. (alternatively if the javascript that does this is small you may want to test the code you've written on desktop and attempt to enable the same code you use on desktop)

We now have full RL support so it should be as simple as:

$wgResourceModules['mobile.proofreadpage'] = array(
'scripts' => array(

		'mobile.js',

),
'position' => 'top',
'targets' => array( 'mobile' ), // or array( 'mobile', 'desktop' ) if you want to use same module
'mobileTargets' => array( 'stable', 'beta', 'alpha' ),
);

MobileFrontend currently adds any modules that have been set to target mobile and set a mobileTargets

I'd suggest enabling it on the beta site of wikisource first and spend some time testing it before switching it on on stable.
This is as simple as setting:
'mobileTargets' => array( 'beta', 'alpha' ),

Word of warning:
The mobile environment may be missing parts of the mw library so be careful what you use!

Hello. This seems to have languished for years; clearly, Wikisource contributors lack the technical know-how to fix this along the lines @Jdlrobson suggested. Or perhaps @Tpt just hasn't noticed this?

This seems like a fairly serious usability flaw for our readers, so it seems to me some priority should be given to it. I would like to request at least re-triaging this, and ideally finding the right developer to fix this. My understanding is that it should take too long for a person familiar with these components (RL etc.)

@Ijon I would suggest the community wishlist; Google Summer of code; the grants process as a way to bring attention to Wikisource mobile improvements as well as talking to people like @JKatzWMF about Wikisource and the reasons they do not get attention.

I think the problem we have here is that there is no set of developers that are familiar with both Wikisource and mobile. I tried a while back to get Wikisource working locally but without much luck. Thus the challenge here is dedicating some time for both ramp up and enhancements, at which point it would make a lot of sense to dedicate a long stretch of time to the work similar to how WMF just did for the maps extension.

(I don't think Wikisource work fits under any existing team at WMF right now)

I congratulate anyone who even tries to proofread in the Page: ns on a mobile device. I cannot even imagine wishing to attempt it.

Thank you, @Jdlrobson, for the forthright comments!

May I indeed request @JKatzWMF to offer a plan for fixing this? This is the main workflow for Wikisource contributors, albeit on the less-used channel of mobile. I understand there is currently, as a matter of fact, no team formally tasked with supporting Wikisource, but I suggest that we do need to unbreak this, even at the cost of some one-time investment, as @Jdlrobson explains, of ramping up (providing a Vagrant or whatever).

If there's someone more appropriate to triage this, I hope @Aklapper can help draw their attention.

@Ijon thanks for pushing on this. I agree with the severity fo the issue, given how broke it is. I'm also moved by how rapidly wikisource traffic on mobile seems to be growing despite such a frustrating experience. See "Asia traffic, below over the last 2 years:

Given their current workload and godlike ability to attract complicated "interrupt work", I am very reluctant to involve the reading-web team on this. That being said, I am talking with others in product about who could work on it. I set a reminder to myself to follow back here in a week, but if you don't hear from me by next Wed, I wont consider it rude for you to remind at me either here or elsewhere.

@Niharika, can you talk to Sam about this? Maybe CommTech can do an investigation.

Sure, we can discuss this but I cannot promise anything. :)

In T47955#520443, @Jdlrobson wrote:

What needs to happen here is Proofread extension should add its own module to mobile that adds this feature. (alternatively if the javascript that does this is small you may want to test the code you've written on desktop and attempt to enable the same code you use on desktop)

We now have full RL support so it should be as simple as:

$wgResourceModules['mobile.proofreadpage'] = array(
'scripts' => array(

		'mobile.js',

),
'position' => 'top',
'targets' => array( 'mobile' ), // or array( 'mobile', 'desktop' ) if you want to use same module
'mobileTargets' => array( 'stable', 'beta', 'alpha' ),
);

MobileFrontend currently adds any modules that have been set to target mobile and set a mobileTargets

I'd suggest enabling it on the beta site of wikisource first and spend some time testing it before switching it on on stable.
This is as simple as setting:
'mobileTargets' => array( 'beta', 'alpha' ),

Word of warning:
The mobile environment may be missing parts of the mw library so be careful what you use!

@Jdlrobson You reckon any of this is still accurate?

@Niharika I don't think anyone of it applies anymore.

Looking at it now, the root of the problem, is that Minerva doesn't have the same menus as Vector.
e.g
This menu doesn't exist in Minerva:

At minimum this PHP code needs to be made to cooperate with Minerva. Without a design, I'd propose prepending and appending the links after the content would be a good start - as it can lend itself to most designs later.

That should be sufficient to get this functional.
For some reason, those links do not work without JavaScript (but that's a larger problem), so the corresponding JS would also need updating...

I'm not sure what the JS does but the code inside the JavaScript needs to be Minerva specific (this bit should be easy). This looks easy given there is already special handling for other skins.

The code also should then be set to mobile target:
https://github.com/wikimedia/mediawiki-extensions-ProofreadPage/blob/46e52885f08b7289a1566106ffb72d9f5f3e329c/extension.json#L121
(again easy given oojs-ui.styles.icons-movement is already working on mobile)

This all looks pretty mechanical to me. I would guess once the extension is setup locally for 2 engineers (and provided there isn't any hidden complexity that will be discovered while looking into this), at most this would take a few hours. If if takes longer you'll have an even better definition of the problem here.

This looks like it's working now (without JS, even):

Yeh looks like it. But logged in users only...

https://en.m.wikisource.beta.wmflabs.org/wiki/Page:The_Climber_(Benson).djvu/6

I'd suggest Wikisource's make the following configuration change to make it show for anonymous users too:

$wgMinervaTalkAtTop = [
                                "base" => true,
                                "loggedin": true
];

Change 741097 had a related patch set uploaded (by Inductiveload; author: Inductiveload):

[operations/mediawiki-config@master] enwikisource: enable anonymous talk page mobile tabs

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

Backlink to (just-started) community discussion: https://en.wikisource.org/wiki/Wikisource:Scriptorium#Enable_mobile_talk_page_tabs_(and_page_NS_prev/next/index)_for_anonymous_users

Change 741097 merged by jenkins-bot:

[operations/mediawiki-config@master] enwikisource: enable anonymous talk page mobile tabs

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

Mentioned in SAL (#wikimedia-operations) [2021-12-01T12:10:05Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: c8ab29b2feb47d611873cf0465b2a2dd5eac0ad2: enwikisource: enable anonymous talk page mobile tabs (T47955) (duration: 00m 56s)

Anything left do do here?