Interestingly, in "vector-2022" the Sticky header shows the actual number of links, but... no links, and the message is: "No languages yet. No languages are available for now":

The same problem applies to namespaces except "main" on Wikisources (i.e. Help).
When the "vector 2022" skin is used, the message "Page contents not supported in other languages." appears instead of links:
see:
https://en.wikisource.org/wiki/Help:Contents?useskin=vector
vs
https://en.wikisource.org/wiki/Help:Contents?useskin=vector-2022
or
https://pl.wikisource.org/wiki/Pomoc:Spis_tre%C5%9Bci?useskin=vector
vs
https://pl.wikisource.org/wiki/Pomoc:Spis_tre%C5%9Bci?useskin=vector-2022

In T325193#8519948, @Nux wrote:

Wikisources table as provided by Wargo on Discord:
https://quarry.wmcloud.org/query/70467

Note though this data might require some interpretation as to which of those users were actually active (and had the chance to switch) etc.

In T325193#8515585, @jwang wrote:

Below table summarized the skin status on 2023-01-09 in percentage of the editors who edited on content pages at least once on the specific wiki project between 2022-01-01 and 2022-12-31.

Maybe, taking advantage of the fact that the fix has not been implemented for two months, it is worth considering whether it would be a better idea to move "<div id="contentSub">" over "<div class="vector-body-before-content" >", as they probably do with javascript on fr ws

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

In T323185#8435887, @Soda wrote:

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

In T323185#8425477, @Soda wrote:

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

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.

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?

@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:

Similar effects on pl ws:

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).

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

@Samwilson , @dom_walden @TheresNoTime
After the change introduced here, the preview (in the vector-2022 skin) reverted to the standard font size in the main space,
but on Wikisource in the "Page" NS it made that (in the preview) unfortunately the font size is too small(!) (
(left view; right: preview):

@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...

it looks like the preview will indeed return to normal font size after this change, but the edit page descriptions, the toolbox and other elements are still displayed in the enlarged font size:

@Soda @Nux Your discussion is very interesting, but please remember that the goal is for the native preload mechanism (T230689) to function properly and not get stuck with "1px difference". I don't think we want to create local gadgets if so much effort and time has gone into developing the native proofread preload mechanism.

In T321728#8364000, @Alserv wrote:

Thank you for the pointers, and apologies for wasting your time. I had only a browser to investigate, and no experience with your development tools.

I appreciate the investigation carried out on frwiki :), but some time ago, the closed ticket (T321883 by @jhsoby) indicated where this code came from and what change introduced it:

@Tpt It's been a while ... I don't know if anyone has dealt with it, but ... I did some tests on pl ws and it looks like the problem no longer occurs.
I think this may be closed.

@Iniquity It doesn't just increase the preview font size. "This" change caused also the enlargement of all elements of the toolbox and the editor itself on pl wikisoource....

In T321883#8352647, @jhsoby wrote:

@Samwilson I believe this may be related to this change.

I did some tests, the problem does not occur when we transclude content using the standard way:
https://pl.wikisource.org/api/rest_v1/page/html/Rest_api_test_01 (OK)
vs
https://pl.wikisource.org/wiki/Rest_api_test_01 (see: https://pl.wikisource.org/w/index.php?title=Rest_api_test_01&action=edit)

In T285311#7175938, @Inductiveload wrote:

Possibly the tool could do with a toggle in the Proofreading tool bar next to the "H/V mode" and "Show header/footer" button for "formal" user control of the visibility without having to hide it with CSS.

@Samwilson It looks like the problem has been resolved. Thank you very much for your quick reaction and implementation of the solution (many people involved in promoting pl ws breathed a sigh of relief). We appreciate it.
I also checked the cases reported here - looks like zh is ok as well.
But the problem reported here T275967 seems to be due to Auxiliary_Table_of_Contents template parsing problem rather than a wsexport problem (see: rest_v1/page/html/শকুন্তলা_(সিগনেট_প্রেস_সংস্করণ) and api/rest_v1/page/html/টেমপ্লেট:Auxiliary_Table_of_Contents).

In T275870#6974858, @Samwilson wrote:

Sounds like a more general URL encoding issue. I'll have a look now.

[edit] pl ws users let me know that the problem will also occur for many pages without a comma in the name, but all of them have didactics in the page name [/edit]

@Samwilson First, many many thanks for the development of wsexport!
I would like to make two points. Have you considered adding a target = "_blank" attribute to the "Other formats" link so as not to "lose" the Wikisource page visitor? And ... do you consider selecting (configuring) a set of formats (links) for a given wiki?

@matmarex the problem still exists (it has only been slightly reduced :) ), see:
https://pl.wikisource.org/wiki/Wikiskryba:Zdzislaw/brudnopis/test3

@Ineuw - the "visibility" of this and other templates will back within one/two days after reverting the changes (mw-parser-output -> display: flex), which cause these problems, see: T209939

@Ankry T209939#4829011 looks good, and... I agree with you that this change should come back.
@TheDJ The changes discussed here were really very good in edit mode. The question is, did they bring anything in view mode (where they caused problems)? In my opinion, no.
So the question is, could they be implemented only on edit mode - if the 'prp-page-container' does not contain the 'mw-parser-output' block inside?

@Alex_brollo ad hoc:
https://pl.wikisource.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=2155343

@Alex_brollo I appreciate the sense of humor, but the problem concerns many other templates using eg 'float:", that we do not want to place in the div.
I know the simpler way, just remove 'display: flex' from the "mw-parser-output" div on Page ns :)
Z.

@TheDJ, @Samwilson, @Tpt It turns out that the changes introduced here have a big impact on many problems with displaying current content in the Page ns. See, for example, here:
https://en.wikisource.org/wiki/Wikisource:Scriptorium#Issue_with_the_FI_Template_display.
The problem also applies to other templates using the float parameter and many others.
eg pl ws page:
https://pl.wikisource.org/wiki/Strona:Henryk_Ibsen_-_Wyb%C3%B3r_dramat%C3%B3w.djvu/792
that looked like this before the changes were made:

please, fix the ability to resize manually the textarea.
It was a very useful feature!

@MarcoAurelio - my dear fellow, we put too much effort and time in our small community to set rules for a new group of users, to wait and observe constantly changed approach to the removal right. There were no information or announcements about the changed approach. So, we do not want to wait, please change the configuration. We want to work efficiently and deal with pl ws matters.
We are not sure that such changes (https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/450450/ - and whether they will be at all) will be permanent, we are not sure that in a week or a month someone will change their minds and, of course, they will just copy the situation for admins https://gerrit.wikimedia.org/r/#/c/operations/mediawiki-config/+/440676/5/wmf-config/InitialiseSettings.php (that is, allows bureaucrats to revoke techadmin on the same wikis where they can revoke admin). In this case, we will be without these rights and we will be forced to lose time again, to carry out a discussion and vote again.

Thank you @Tpt

In T167491#3335637, @Billinghurst wrote:

I am slightly concerned about the whole scenario.

@Billinghurst This is currently enabled only for admin group. Do you think they could abuse this right?

In T99736#3274965, @Reedy wrote:

medium done

In T99736#3280356, @Reedy wrote:

It was run on all wikis.

It kind of seems we're still getting things appearing. @TTO noticed earlier that that oldwikisource was broken again

Running the script again fixed them...

Which kinda seems like something is still creating these bad rows in some very small amounts...

In T99736#3274965, @Reedy wrote:

medium done

@debt @EBernhardson Could you give similar information regarding plwikisource?

any chance to solve this problem?
on pl ws:
https://pl.wikisource.org/w/index.php?title=Specjalna:Kategorie&offset=&limit=500

In T154711#2924457, @Billinghurst wrote:

@Zdzislaw do you see that tis namespace can be aligned with the namespace numbering used for Portal?. Having an approach that looks to a universal approach for the WESes would be advantageous.

@Samwilson, In short, Kolekcja (collection) ns is intended to the presentation (in visual and “reader-friendly” way) of works and to group together (in a standardized way) works on similar subjects according to various criteria. See collection of works for children and teenagers, Skarbnica or SF Collection as an examples.
The idea is to help readers navigate through Wikisource and to show our works in a manner more similar to the shelves in the library, where the choice of the readers is often dictated by the image or arrangement of words on the cover. The Kolekcja ns just has become a marketing tool for improving “sales of our texts”. The addition of the new ns will facilitate the development of tools, scripts and templates which support it.

same issue in Chrome:

@matmarex I have done some tests on betawiki - the limit report is generated properly (with scribunto limits and logs ) - thank you!

thanks for re-adding the human readable parser limit report :)
unfortunately, in the restored version of the report, the scribunto(Lua) limit report is still missing, which are also written as a js variable, eg:

(window.RLQ=window.RLQ||[]).push(function(){mw.config.set( {
    "wgPageParseReport": {
        (...)
        "scribunto":{
            "limitreport-timeusage": {
                "value": "0.026",
                "limit": "10.000"
            },
            "limitreport-memusage": {
                "value": 626231,
                "limit": 52428800
            },
            "limitreport-logs": "'''æsthetic''' (''esthe′tyk'') estetyczny.\n"
        },
    }
} );});

is it possible to restore also the scribunto(Lua) report limits?? - This is very useful info.

@THE_IT see: echnische Neuerung, die eventuell zu Problemen führt

In T135170#2563074, @mwjames wrote:

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

So, I'm seeking an understanding of what exactly does this entail? Do you have an example as to what are those "... updated to use the API instead ..." or is it expected to endeavour on a trial and error approach?

@Aklapper : This problem occurs on mul.ws and pl.ws (and I think on others also) over a year, see: T114318.

In T138604#2405228, @Jdforrester-WMF wrote:

OK, so, first thing first: we need to fix the bug you've uncovered so it doesn't corrupt the page like this.

• We intentionally don't let you make unbalanced edits
  
  You're trying to write <header><div style="color:blue;"></header><page>…</page><footer></div></footer>. This is fundamentally not compatible with a visual editor. It's also something that eventually won't work in MediaWiki in general (see below), so we need to find a better way to do this task.

In T93525#2401285, @Jdforrester-WMF wrote:

In T93525#2399147, @Ankry wrote:

• Any attempt to edit header/footer seems to break them both (moving them or their parts into main edit area); see this diff:
  
  http://en.wikisource.beta.wmflabs.org/w/index.php?title=Page%3ADictionary_of_National_Biography_volume_51.djvu%2F377&type=revision&diff=716&oldid=649

I couldn't reproduce – http://en.wikisource.beta.wmflabs.org/w/index.php?diff=721&oldid=720 – perhaps an intermittent bug?

<onlyinclude><div id="zitierhilfe" style="clear:both; background-color...

add "new line" after <onlyinclude>:

If I understood well the proposed changes in the code, <div class="pagetext"> is removing only from output wikitext written to the database. The <div class="pagetext"> will be still generated on web pages (shown in view mode) and from the user point of view nothing will changed. All the gadgets and css styles will operate as before, without any changes.
Is not that so?

Insert -> Pages -> there is no "onlysection" attribute

reason: Difference between revisions of "টেমপ্লেট:Header"
correction: Difference between revisions of "টেমপ্লেট:Header"

the same on pl ws; the problem occurs only when [[ https://phabricator.wikimedia.org/diffusion/EPRP/browse/master/SpecialProofreadPages.php | $this->searchTerm is set ]].
sorry, not only - without searchTerm problem https://fr.wikisource.org/w/index.php?title=Sp%C3%A9cial:IndexPages&limit=100&offset=10000&order=size&sortascending=1 also occurs

In T127657#2064138, @ezachte wrote:

Yes, that's why I asked:

"I wonder should we remove the presets? That would require the API to be up date for all wikisource wikis. Is that the case?"

Yes, @Nemo_bis is right!

In T127657#2061647, @ezachte wrote:

Here is today's list of countable namespaces, mostly from the API + presets mainly for wikisource, I wonder should we remove the presets? That would require the API to be up date for all wikisource wikis. Is that the case?

StatisticsContentNamespaces.csv7 KBDownload

In T8419#1985504, @Danny_B wrote:

the same similar:

<poem>
lorem
ipsum
<div>loren</div>
dolor
sit
amet
</poem>

gives

<div class="poem">
<p>lorem<br />
ipsum<br /></p>
<div>loren</div>
<br />
<p>dolor<br />
sit<br />
amet</p>
</div>

(note <br /> after </div>)

In T8419#1985461, @Danny_B wrote:

This is obvious misunderstanding due to ambiguous task description. I am pretty sure it was not meant to convert every single ...<br /> to <p>...</p> but the following:

In T8419#1984488, @Danny_B wrote:

Can you please exactly describe what would be the problem? It is not apparent from the code you wrote... A link to a real life example would be helpful. Thanks.

oppose - in poem extension <br /> are added by its definition. This property is used eg. in "reverse indentation":

<poem style="margin-left:20px;text-indent:-20px">
Line1 Line Line
Line2 Line Line
Line3 Line Line
</poem>

, etc. Changing the functioning of poem would require to look at all texts that use it, in all ws. I suggest to consider the preparation of a new (independent) extensions and a new tag (<ppoem>).
Z.

works fine, thanks.

the same issue on pl ws.

In T119841#1842133, @jcrespo wrote:

@Zdzislaw Are those inconsistent?

@jcrespo thank you for reimporting categorylinks table, but... what about the other tables? very important for us are also tables page and templatelinks, try:

@Billinghurst as I mentioned in T93397, if we want to make Special:IndexPages showing the current state of quality-bars, Index: page shall be always refresh after a change of status (none ->Not proofread; Not proofread -> Proofraed...) of any Page: from the Index (as we do by bot on pl ws).
The problem is (it is not only problem with the "new" Index: ns pages) that changing status of any Page:, the Index: page is updated but Special:IndexPages is update only after a next purge or edit of the Index:, see: Special:IndexPages of The story of geographical discovery.djvu -> qualitybar (0 validated pages, 5 only proofread pages and 5 not proofread pages) while nearly all of the Pages are validated (yellow) on Index:The_story_of_geographical_discovery.djvu. The same on Special:IndexPages নির্ঘণ্ট:গীতরত্ন গ্রন্থঃ (১৮৭০)- রামনিধি গুপ্ত.djvu (28 pages->red) and Index:গীতরত্ন গ্রন্থঃ (১৮৭০)- রামনিধি গুপ্ত (40 pages -> red).
So, if you want to fix this problem by using a bot, and no change the way of Special:IndexPages refresh, bot would purge the Index: ns pages on all ws every few hours :(

@Tpt, this problem has been described in detail in T93397.
modifying an Index page updates Special:IndexPages with the previous revision of the Index page, so... if someone creates new Index page, the Special:IndexPages is updated only after a purge or next edit of the Index page (before that the new Index is "invisible" on Special:IndexPages).
I have refreshed page # 1 from the list and... already Index is on Special:IndexPages.

@Krenair Yes, the problem still exists. I made a change in "MediaWiki:Gadgets-definition" a half-hour ago, and (on pl source) the changes are not visible. But, what we can observe is a state (of Special:Gadgets and Preferences) before the change, and randomly... state of "a few changes ago".
@Ankry: I made a change at 11:37 , so... the one of the version you can receive it's not "the newest one" but "before the change" :)

Please, do something, roll-back 210260 or... disable completely the gadget extension. In the current state it is not possible to manage and supervise (introduced) changes in Gadgets extension. I have made a few changes (not knowing about the problems), ... waiting for the effects... and nothing happens - how do I test the changes if I do not know when they will appear in the users (and my) preferences tab?
Additional side effects of the problem (as I noticed) are such that changes in "Gadgets-definition" (i.e. new gadgets) occur in the users preferences tab for a moment (randomly) and the next time when I refresh the browser they disappear.
Testing the changes in gadgets-definition immediately as they are added is critical, and I can not imagine waiting "for 24 hours" every time when I change gadgets-definition.

In T93397#1137936, @Tpt wrote:

The cause of this issue is maybe a new cache layer that cache the results of Special:IndexPages. But I have no idea of where it may be done.

Thank you very much!