Isn't this intentional? See T311607. The limited width preference doesn't override any page specific behaviour.

@Jdlrobson Thanks for pointing this out T311607. @ovasileva There is a very bold thesis "A majority of sources in Wikisource are not intended to be read as a traditional article."
It's very interesting because..., for example, in pl ws 99.99% of articles in main NS is intended to be read as traditional article(!)
It's a pity that all this happens "outside" the editors of non-English Wikisource. Maybe we could have a chance to propose that this be an option??? rather than completely depriving us of this functionality.
Its very sad...

This is configurable so can be changed at any time with community consensus:
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L7127

In T323185#8409855, @Jdlrobson wrote:

This is configurable so can be changed at any time with community consensus:
https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L7127

What community do you mean? pl ws or all ws?

Was there a consensus by making this configuration for all ws different from the default?

Z.

I did some investigation and it looks like the existing requirements came from T300563 (community discussion: https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements/Archive4#Not_at_all_suitable_for_Wikisource_users and https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements/Archive2#Wikisource)

It sounds to me like most of the discussion was about the edit mode of the page (and at the time the max width preference was shared between edit and view mode).

What community do you mean? pl ws or all ws?

Either is possible. I guess ideally all the Wikisource projects would be consistent, but the setting can be configured as needed if say Polish Wikisource disagree with French Wikisource. Hope this is helpful!

In T323185#8411503, @Jdlrobson wrote:

I did some investigation and it looks like the existing requirements came from T300563 (community discussion: https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements/Archive4#Not_at_all_suitable_for_Wikisource_users and https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements/Archive2#Wikisource)

It sounds to me like most of the discussion was about the edit mode of the page (and at the time the max width preference was shared between edit and view mode).

All of these discussions were about excluding the Page namespace (and editing there with proofread extension) (not editing a page in Main NS). Excluding the Page namespace is done here. And we agree with that.

What is unclear is the source of the idea to exclude the Main NS we are talking about here. This is completely incomprehensible to me. And this (exclusion om Main NS) really looks like a misunderstanding.

What community do you mean? pl ws or all ws?

Either is possible. I guess ideally all the Wikisource projects would be consistent, but the setting can be configured as needed if say Polish Wikisource disagree with French Wikisource. Hope this is helpful!

I'll be back here in a few days with pl ws community decision regarding main NS.

Per some discussions that we had with @sgrabarczuk during the Wikisource Triage Meetings, certain Wikisources (fr.wikisource for example, at https://fr.wikisource.org/wiki/Mod%C3%A8les_de_lettres_sur_diff%C3%A9rents_sujets/R%C3%A9ponses_%C3%A0_des_lettres_de_demande or the en.wikisource Layout 2/4) do already restrict the viewing size, and shrinking the viewport further can/might cause problems.

Additionally pages that have multi-columned books, for example research journals, might cause issues as well.

@Jdlrobson
The pl ws community has spoken out and we have reached a consensus :) We don't want those who are not logged in to be forced to read our texts in this way:

Therefore, we want the Main NS space not to be excluded from the optional limited width mode for pl ws:
https://pl.wikisource.org/wiki/Wiki%C5%BAr%C3%B3d%C5%82a:Skryptorium/Pulpit_og%C3%B3lny#Wykluczenie_przestrzeni_g%C5%82%C3%B3wnej_z_mo%C5%BCliwo%C5%9Bci_wyboru_opcji_wy%C5%9Bwietlania_w_wersji_zw%C4%99%C5%BConej_%28Vector_2022%29

Please help us implement this change, I don't know if it would look like this:

	'plwikisource' => [
		NS_SPECIAL,
		NS_CATEGORY,
	],

??
Thanks in advance for your help.

In T323185#8422591, @Soda wrote:

Per some discussions during the Wikisource Triage Meetings (...) certain Wikisources (fr (...) en) do already restrict the viewing size

certain ws do not limit the display size (pl, de,...)...

...and shrinking the viewport further can/might cause problems.

Is there at least one example (on fr, de ws) where this problem occurs?
Was "can/might" enough to change the v2022 default configuration for all ws?

In T323185#8422756, @Zdzislaw wrote:

In T323185#8422591, @Soda wrote:

Per some discussions during the Wikisource Triage Meetings (...) certain Wikisources (fr (...) en) do already restrict the viewing size

certain ws do not limit the display size (pl, de,...)...

Yeah, no this was in the context of the fact that we might possibly need specific rules for specific Wikisources, rather than an overarching solution :)

...and shrinking the viewport further can/might cause problems.

Is there at least one example (on fr, de ws) where this problem occurs?
Was "can/might" enough to change the v2022 default configuration for all ws?

T311607 has two examples of pages where the issue was observed (I feel like the issue was more severe in earlier version, since now the pages seem somewhat okay).

In general, I think anything where your trying reproduce columns/floating large images will probably be unsuitable to be viewed with a narrow viewport.

In T323185#8424218, @Soda wrote:

T311607 has two examples of pages where the issue was observed (I feel like the issue was more severe in earlier version, since now the pages seem somewhat okay).

In general, I think anything where your trying reproduce columns/floating large images will probably be unsuitable to be viewed with a narrow viewport.

Yes, but they were more about the Page NS, as I mentioned earlier, although the effect was to exclude the Main NS, where we (on pl ws) mainly present texts for reading.

Anyway, my questions are actually more rhetorical, especially since we made a decision in the pl ws community to set the configuration for pl ws without excluding the Main NS.
Can we count on your help in its implementation (T323185#8422601)?

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

[operations/mediawiki-config@master] Enable limited width on plwikisource MAIN namespace

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

In T323185#8425059, @Zdzislaw wrote:

In T323185#8424218, @Soda wrote:

T311607 has two examples of pages where the issue was observed (I feel like the issue was more severe in earlier version, since now the pages seem somewhat okay).

In general, I think anything where your trying reproduce columns/floating large images will probably be unsuitable to be viewed with a narrow viewport.

Yes, but they were more about the Page NS, as I mentioned earlier, although the effect was to exclude the Main NS, where we (on pl ws) mainly present texts for reading.

Anyway, my questions are actually more rhetorical, especially since we made a decision in the pl ws community to set the configuration for pl ws without excluding the Main NS.
Can we count on your help in its implementation (T323185#8422601)?

I've gone ahead and put in a patch for it :)

Imo I feel like we will need to have a bigger conversation at some point regarding this across all Wikisources.

In T323185#8425477, @Soda wrote:

I've gone ahead and put in a patch for it :)

Thanks! ...I'm not knowledgeable, but shouldn't there be a comma after NS_CATEGORY?
https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/861431/1/wmf-config/InitialiseSettings.php

Imo I feel like we will need to have a bigger conversation at some point regarding this across all Wikisources.

Perhaps, but first, we'd have to implement the "Dynamic Layouts" mechanisms developed by fr and en ws... firstly we don't have enough "production capacity", and secondly, I'm afraid it would be difficult to convince the community to this because over the years we have developed our own ways of handling proofread extension with which it could clash... But, maybe I'm wrong :)

Change 861431 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable limited width on plwikisource MAIN namespace

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

Mentioned in SAL (#wikimedia-operations) [2022-12-01T14:52:46Z] <lucaswerkmeister-wmde@deploy1002> Started scap: Backport for [[gerrit:861431|Enable limited width on plwikisource MAIN namespace (T323185)]]

Mentioned in SAL (#wikimedia-operations) [2022-12-01T14:53:53Z] <lucaswerkmeister-wmde@deploy1002> lucaswerkmeister-wmde and soda: Backport for [[gerrit:861431|Enable limited width on plwikisource MAIN namespace (T323185)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-12-01T15:00:53Z] <lucaswerkmeister-wmde@deploy1002> Finished scap: Backport for [[gerrit:861431|Enable limited width on plwikisource MAIN namespace (T323185)]] (duration: 08m 06s)

Changes wrt to limited width should be live on plwikisource :)

@Edtadros - could you review that the change looks okay on plwikisource, then move this back to doing and assign to @sgrabarczuk

In T323185#8435887, @Soda wrote:

Changes wrt to limited width should be live on plwikisource :)

Thanks for the info on our Scriptorium.
As I wrote there, everything works fine. :)

In T323185#8445384, @Edtadros wrote:

Go to Polish Wikisource (a pilot wiki) or English Wikisource (a non-pilot wiki)

(...)

✅ AC1: There should be more white space on both sides of the content area

note that there should be more white space on both sides of the content area only on Polish Wikisource.

Remaining work is figuring out whether this should be the default for all Wikisources.

I think the problem here is that this varies per page and not per wiki or per user. This is one main reason why enWS (and frWS and some others) have implemented a "Dynamic Layouts" system: basically a Gadget that applies different styles based on user preference with a default provided by the presence of e.g. {{default layout|Layout 2}} (Layout 2 being the main width-constrained layout on enWS).

This gadget has always been hacky and fragile, not least because it is always fighting the platform and the skin for control of certain aspects of presentation, and it always runs too late after page load so you get big visible page reflows, and it is always catching up on when it is supposed to relayout (e.g. for live preview events).

And while I think a significant number of Wikisourcen have adopted a variant of it, I don't think the majority has. You can probably get a good idea by looking for Wikisourcen with "PageNumbers.js" somewhere in their MediaWiki:Common.js (most, including frWS, cross-load it from mulWS; only enWS has reimplemented it as a local gadget). That suggests to me that perhaps the best cause of action would be to make constrained-width enabled by default in ns:0 on Wikisourcen, but disable it by default in ns:0 on projects that opt out.

The problem is that we're a bit late to the game with default-vector coming next week, so there's no time to ask the communities for their preference (this would have been worth a MassMessage saying "Constrained width is coming; please file a Phab task asking to disable for your mainspace." otherwise).

I can't speak for all of enWS, but as a technical matter we need to start out with constrained-width off by default for ns:0. I imagine the same goes for frWS, but I can in no way speak for that community on this as I'm not active there.

Longer term I would dearly like to see the platform/skin open up some control over styling the content area in a way that doesn't involve hacky gadgets and whole-page reflows, however that would look implementation-wise (I'd be very happy to explain the need and spitball about possible solutions, if anyone wants to pick up the gauntlet).