Wikisource:Scriptorium/Archives/2022-06

May Monthly Challenge

The contributors to the Monthly Challenge of May processed 6306 pages in all, increasing both the number of proofread and validated pages compared to the April challenge. Again, more than one work per day was promoted to proofread and/or validated status. The works processed included:

• Index:Dobbs_v._Jackson_Women's_Health_Organization_-_Court_opinion_draft,_February_2022.pdf
• The Kobzar of the Ukraine was proofread, a work requiring lots of poem formatting and images.
• Several works of the Anne of Green Gables series. The transcription of this series has seen enormous progress over the last two months.
• The last two volumes of George Eliot's Daniel Deronda. After completing the transcription of the Brontë sisters' works, the MC contributors are making rapid progress at transcribing also a complete set of Eliot's most well-known works.
• The Orley Farm series was finalized with the validation of the last two volumes.
• Several long-term projects/series made significant steps forward: Sherlock Holmes, The Philippine Islands, Historic Highways of America, to name only a few.

Everyone is welcome to the challenge for June. Good transcribing to all!--Tylopous (talk) 18:57, 3 June 2022 (UTC)

This section was archived on a request by: Ciridae (talk) 08:20, 1 July 2022 (UTC)

Tech News: 2022-23

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 June. It will be on non-Wikipedia wikis and some Wikipedias from 8 June. It will be on all wikis from 9 June (calendar).
• A new str_replace_regexp() function can be used in abuse filters to replace parts of text using a regular expression. [1]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

02:46, 7 June 2022 (UTC)

California Child Actor's Bill

Anybody interested in California, or law, or both? There's a bill called the California Child Actor's Bill, also known as the Coogan Bill, that I would like to see transcribed. It "is a law applicable to child performers, designed to safeguard a portion of their earnings for when they reach the age of majority, and protect them from exploitation and abuse. The original Bill was passed in 1939 by the State of California in response to the plight of Jackie Coogan, who earned millions of dollars as a successful child actor only to discover, upon reaching adulthood, that his mother and stepfather had spent almost all of his money."

As a California law it is an edict of a government, and therefore in the public domain. Law isn't my area, so this is a request. PseudoSkull (talk) 16:54, 7 June 2022 (UTC)

• PseudoSkull: There are two relevant versions of the law: the law as it was originally enacted, and the law as it stands to-day. The law is chapter 637 of 1939, and may be found on pp. 2064–2065 of the California Statutes for 1939, or pp. 2065–2066 of this PDF. According to the Wikipedia article, the law as it exists is spread across fives sections in two codes: sections 6750–6753 of the Family Code and section 1700.37 of the Labor Code. The most specific, relevant part is chapter 3 of part 3 of division 11 of the Family Code, which contains the abovementioned sections of the Family Code, and contain the central part of the act, as it is currently codified; that can be accessed here. The latter appears to be the official version, despite the lack of a PDF; for an “official” PDF, I would recommend collating the official PDFs of the four relevant sections. TE(æ)A,ea. (talk) 03:38, 8 June 2022 (UTC)

Copyright Status of the Sonic Bible (I'm serious)

Hello.

So here's an introduction of what the Sonic Bible is.

So the Sonic bible is the guide for Sega employees and developers to represent Sonic the Hedgehog in the way that Sega wants and requires. I am not joking. This thing actually exists. You can find more information here: https://sonic.fandom.com/wiki/Sonic_Bible

But here is the kicker, are these sets of documents subjected to copyright?Blahhmosh (talk) 21:08, 8 June 2022 (UTC)

• Blahhmosh: In short, yes, the “Sonic Bible” is copyrighted, and cannot be uploaded. The standard tool of reference for historical U.S. copyrights is the Hirtle chart. According to the reference you gave, the “Bible” was produced in 1991; thus, it was published in “1 March 1989 through 2002” and “Created after 1977.” Following the chart, the copyright lasts from 95 years after official publication, or 120 years after creation, if the author(s) is/are never identified. The cutoff date is March 1, 1989, though, so if you have anything from before then, it might be in the public domain. TE(æ)A,ea. (talk) 21:15, 8 June 2022 (UTC)

Half a million were uploaded as part of the "library back up project". Welcome to participate to upload all public domain books in the world!

In 213 BCE, Qin Shi Huang destroyed all privately-held unorthodox books in by fire. In 206 BCE, Xiang Yu set a fire on the governmental library containing unique copies of the books, sounding the death of ancient Chinese thoughts and history. Yongle Encyclopedia was finished in 1408. It comprised 22,937 chapters in 11,095 volumes and 917,480 pages. Only one copy after that original copy was made. Most of them are lost in history and only about 800 chapters survive today. In 1932, 463 thousand Han Fen Lou rare books were burned in war.

To prevent such regrettable things that destroy the memory of mankind ever happen again, let's systematically back up the world's all surviving books in public domain to Wikimedia Commons.

“

Imagine a world in which every single person on the planet is given free access to the sum of all human knowledge.

”

Half a million book files were uploaded as part of the project. Currently only Chinese and Japanese books were uploaded, but the ultimate goal is ALL books in ALL languages from ALL countries as long as in public domain. Welcome to participate to accomplish the grand goal! 維基小霸王 (talk) 05:40, 9 June 2022 (UTC)

Headers generated by pages tag

Owing to a current dispute (see User talk:EncycloPetey § Index:As a Man Thinketh), there seems to be necessary a clarification regarding the use of headers. The “pages” tag, used for transcluding text from the “page” namespace, can, with “header=1,” call on the bibliographical fields of the “index” page to automatically generate a header. EncycloPetey has continued to mark As a Man Thinketh as being in need of standardisation because it uses the header generated through the “pages” tag, rather than through the “header” template. Does using the header generated by the tag meet the requirement of having a header? If not, what is the purpose of the “header” function of the “pages” tag? TE(æ)A,ea. (talk) 20:17, 8 June 2022 (UTC)

Wikisource:Style guide#Formatting item number 1: "The {{header}} template should be used at the top of every article page". That's pretty straightforward. The pages-header implementation exists so that bots have the means to auto-generate a "quick-and-dirty" work once the table of contents is completed. It is possible to use the pages tag generated headers, but only as a stop-gap while setting up a work. A completed work should not have them. --EncycloPetey (talk) 20:20, 8 June 2022 (UTC)

• EncycloPetey: Your very quote belies your point: “The [template] should be used”! An obvious alternative to the use of the template is the use of the “header” function of the “pages” tag. From Help:Transclusion: “Generates and inserts a {{header}} at the top of the page, using the information from the Index page. This is an alternative to adding a manual header.” TE(æ)A,ea. (talk) 20:24, 8 June 2022 (UTC)

  You're quibbling over "should"? Then see the first definition under wikt:should: "Ought to; indicating opinion, advice, or instruction, about what is required or desirable." --EncycloPetey (talk) 20:29, 8 June 2022 (UTC)

  • EncycloPetey: Again, your quote belies your point: “indicating opinion, advice, or instruction, about what is required or desirable.” The word “should” never indicates a requirement. TE(æ)A,ea. (talk) 20:31, 8 June 2022 (UTC)

    What? It's right there in the definition, and I bolded it, yet you claim that it never does this? A wikt:requirement is, quite literally, something that is required. --EncycloPetey (talk) 20:34, 8 June 2022 (UTC)

    • EncycloPetey: You misunderstand the definition of “should.” It is not “what is required or desirable,” but “opinion, advice, or instruction, about what is required or desirable.” The “opinion, advice, or instruction, about” modifies the “what is required or desirable,” making it clear that “should” is not a requirement, but “opinion, advice, or instruction” about some requirement. TE(æ)A,ea. (talk) 20:37, 8 June 2022 (UTC)

      The word "should" is a verb, so of course it is not "what is required or desirable", which is a phrase defining a noun. If this discussion hinges entirely on the meaning of "should", then please note that the Style Guide uses "should" throughout. There are 32 instances of "should" in the Style Guide and 0 instances of "must". This does not mean that the Style Guide is devoid of policy, nor that the Style Guide can be ignored. --EncycloPetey (talk) 20:44, 8 June 2022 (UTC)

      • EncycloPetey: Exactly! The style guide is a guide, not the law, so there are no requirements. So why do you require the “header” template to be used? TE(æ)A,ea. (talk) 20:46, 8 June 2022 (UTC)

        From the Style Guide: "Unless there is a good reason for deviating, the standard should be presumed correct." and "These are not hard rules, and can be ignored where necessary. However, users should follow these guidelines where possible to ensure that Wikisource is consistent and maintains a high standard of quality." So why is it not possible to follow the Style Guide in this instance? Why is it necessary to not follow them? What good reason is there for deviating from the Style Guide? --EncycloPetey (talk) 20:48, 8 June 2022 (UTC)

        • EncycloPetey: The style guide, and other “help” documents that it references, allow for the use of the “header” function of the “pages” tag: Help:Transclusion says so explicitly. And, again, the “header” template is being used, just through the “pages” functionality. TE(æ)A,ea. (talk) 21:19, 8 June 2022 (UTC)

          The Style Guide does no such thing. Nowhere does it allow for the pages tag use in place of templates. Help:Transclusion points out that the functionality exists, without recommending it. Nor is it a policy page; it's a Help page. So again, what is the reason for a deviation from the Style Guide in this instance? --EncycloPetey (talk) 21:24, 8 June 2022 (UTC)

          • EncycloPetey: Just because you claim something isn’t true, doesn’t make it false. The style guide is written in general terms, with references to more detailed help pages. One of those is Help:Transclusion, which gives detailed information on transclusion. That page mentions “header=1,” and states: “Generates and inserts a {{header}} at the top of the page, using the information from the Index page. This is an alternative to adding a manual header.” Given the style guide’s reference to the use of a header, and to this specification “help” page, it is clear that the style guide allows the use of the “header” functionality of the “pages” tag. You have claimed that the “header=1” functionality is used only for bots, and that it is not a substitute for the template itself; but this is directly contradicted. TE(æ)A,ea. (talk) 21:53, 8 June 2022 (UTC)

            You've made several misleading and false claims there, including a patently false claim that I said anything was "only for bots". But to address the central issue: Yes, the page mentions the header generation; says that this is an "alternative", but nowhere is this recommended or advocated in any way. The fact that a page notes that something is possible does not make it good practice. The fact that something appears on a Help page (which can be edited as needs) does not affect Policy pages (which are voted on by the Community). Your issue seems to be a misunderstanding about the status of (and relationship between) Policy and Help materials. --EncycloPetey (talk) 22:19, 8 June 2022 (UTC)

            • EncycloPetey: “The pages-header implementation exists so that bots have the means to auto-generate” works: your words, not mine. Your casting of aspersions is not appreciated. The “header=1” functionality is declared as an “alternative,” as you have now admitted; nowhere is it described as an inferior alternative, or a deprecated system. The use of the “header” template and the use of the “header” function of the “pages” tag are two alternatives to meet the style guide’s mention of a header; thus, you cannot claim (as you had previously) that the work in question “need[s] to be standardized using Wikisource's style guidelines.” There are many things which are technically possible, though not recommended; for example, the use of the “page” template or direct transclusion in the place of the “pages” tag for transclusion. Both of those are technically possible, but they are both explicitly disapproved of, and deprecated. That is not the case here; the “header” function of the “pages” tag is not listed as an inferior system, but just as an “alternative.” The fact that there is no mention that the “header” function of the “pages” tag is deprecated or in any way not recommended means that its use is good practice—an alternative to the use of the “header” template, but good practice nonetheless. TE(æ)A,ea. (talk) 23:03, 8 June 2022 (UTC)

              You have taken free liberty with reinterpreting what I have said. I did not say "only", and you quoted a statement that did not say "only", but seem to maintain that I said "only" nonetheless. I stated a rationale, in response to your query as to why the option exists. You clearly misconstrued the context of my reply. An explanation as to the cause of a thing existing does not imply sole function. This is why I let you know that you have made false and misleading claims. This is very bizarre to me, considering the previous surgical argument placed on the meaning of the single word "should".

              But the issue: Yes, Help pages exist and are linked from Policy pages, but that does not give the information them the weight of Policy. The fact that an alternative has not been explicitly forbidden is a far cry from a recommendation as good practice. Those are two ends of a broad spectrum, and not the same thing. Why do you think that "good practice" is the default assumption here? Or do you consider anything that has not been deprecated or expressly forbidden to be automatically "good practice"? Recall that "good practice" is "not only a practice that is good, but a practice that has been proven to work well and produce good results, and is therefore recommended as a model." The use of the header function for the pages tag has not been recommended anywhere. So why do you think it is good practice? --EncycloPetey (talk) 00:07, 9 June 2022 (UTC)

              • EncycloPetey: You said that the “header” function of the “pages” tag “exists so that bots” can do something. This claim seems to me to mean that it was created for that purpose, and exists only for that purpose, as “exists” is a very strong word in this context. You seem to think that there can be only one way of doing something; that is counter to the very nature of English Wikisource. Different editors can work on different projects with different work styles; and yet, their respective works may all be in compliance with the style guide. As an example, either straight or curly quotes may be used in a work, and the work may be in compliance, so long as the use is consistent. In such a case, the use of straight quotation marks consistently is a “good practice,” and the use of curly quotation marks consistently is a “good practice;” the two methods are alternatives, and are both valid. That is the case here; either the “header” template may be used, or the “header” function of the “pages” tag, which are two alternatives, both of which are valid. There need not be one singular method of performing all of the functions of this project; that would interfere with the autonomy of the individual editor. The style guide sets out general goals and recommendations, but, so long as those are being met, I do not see why a complying practice would not be “good practice.” I do not see how your claim that you do not like a certain method of doing something makes an equally valid alternative method out of line with standard practice; you have made that claim against me before, and have been rebutted. TE(æ)A,ea. (talk) 00:25, 9 June 2022 (UTC)

                You have tried to put words in my mouth again; this is not an issue of "not liking" a method. Straight and curly quotes are both acceptable because we had a discussion and changed policy to allow either, so long as there is consistency. The two options are both noted in the Style Guide. That is not the case for the topic of discussion, and so the punctuation situation has no relevance to the current discussion. It is not an analogous issue. No discussion has ever permitted use of the page tag in place of the Header template, and the Style Guide makes no mention of such usage. The pages tag itself has functionality issues. Among those issues, the Pages tag transclusion product violates the basic recommendation for use of the {{Header}} template. The standard is to include chapter titles in the "section" field, but to avoid including them in the "previous" and "next" fields. The pages tag displays the opposite of this recommendation; it displays the chapter title instead of the chapter number. The pages tag also pulls data that, if altered by an editor at the source, will silently break chapter linkages throughout the work. There are additional issues, but these two alone show why the pages tag method is not "equally valid", but is out of step with standards. I ask again: why do you think use of the pages tag to generate header is good practice? and: why is it necessary to deviate from the standard? You have not answered these questions. --EncycloPetey (talk) 02:46, 9 June 2022 (UTC)

                • EncycloPetey: Before the policy change, only straight quotation marks were allowed. At the time, only straight quotation marks were considered to be “good practice.” Now, after the change, both are allowed. The fact that both are allowed, and neither is given a superior place, is the fact I was emphasizing. That is the state of affairs as regards headers: there are two methods, the “header” template and the “header” function of the “pages” tag, and, despite your protestations to the contrary, neither is given a superior place in the style guide, and neither is discouraged. The only discouragement to the use of the latter method is your persistent hounding of people who do things differently than you do. As to your two questions, I have already answered the first, and the second is based on an understanding of facts at odds with reality. Absent a contrary statement by the style guide, either method of generating a header is “good practice,” assuming that the use of a header is good practice. There is no deviation from “the standard,” because the use of the “header” function of the “pages” tag is standard: again, despite your claims to the contrary. The second question is premised on the response to the first question being that the use of the “header” function of the “pages” tag is not good practice, which is your claim, but it is not my claim. TE(æ)A,ea. (talk) 13:26, 9 June 2022 (UTC)

                  @EncycloPetey, @TE(æ)A,ea.: In my opinion, creating a header via the pages tag should be accepted as long as it has not been deprecated.

                  The help pages are at the top of the list of links that new users are given in a welcome message. The help page for transclusion states that using the "header=1" option in the pages tag generates and adds a header and that it is an alternative to a manual header. The style guide says that every article should include a header.

                  Thus, it is at least not surprising that many users, especially newer users, will use the "header=1" option of the pages tag. With the information given, they will assume that they have added a header and followed the style guide.--Tylopous (talk) 08:37, 10 June 2022 (UTC)

Ignoring most of the robust discussion above as TL;DR. Help:Beginner's guide to transclusion tells newbies to use the header=1 option when transcluding. It then goes on to imply that there may be problems with this approach, or that more control might be needed. The "simple" method is fine for works that flow in a straightforward manner and there is a single author. However, as soon as there are editors, contributors, different authors for different sections, sections being cross-transcluded outside a chapter structure, &c., &c., then a manual header is the only workable method. For those of us who have the "Preload useful templates" gadget switched on, the simple header is never used, as the appropriate header template appears automatically when creating a new page. Of course, even for the simple method, if the fields on the Index page are filled with garbage, then the header will be useless. This means that, regardless of the method used to create the header, the onus is on the transcluding editor to make sure it's as good as it can be. Beeswaxcandle (talk) 09:37, 10 June 2022 (UTC)

"Wikisources"

I wanted to let you guys know about this domain name I found recently called https://www.wikisources.org/, which appears to function as a mirror site of Wikisource. They are "dedicated to providing you the best of Library", but they give no acknowledgment whatsoever that the content all comes from Wikisource anywhere on the site that I can find, including in their terms of service or about us pages. I thought this was pretty peculiar, and I'm not really sure what to think about this weird site. But thought I'd get the word out just in case anything needed to be done, and because of how funny it all is. PseudoSkull (talk) 06:14, 5 June 2022 (UTC)

@PseudoSkull: *shrug* Amateurish mirrors of Wikimedia content pop up from time to time. On Wikisource, most of our content is freely reusable (unlike Wikipedia, where the otherwise free content requires attribution) so there's not much point pursuing things like this. I suppose we could throw them an email asking them to acknowledge the source of the content, but given the site looks pretty skeevy I very much doubt they'd listen (and gods only know what they'd do with the email address you used). It's good to be aware of sites like this, but beyond keeping half an eye on what they do we should probably just ignore them. Xover (talk) 07:05, 5 June 2022 (UTC)

Those names and photos look awfully generic.. Someone's using a web template? ShakespeareFan00 (talk) 12:32, 5 June 2022 (UTC)

My favorite is that the html contains such bits as <a dir="ltr" href="https://en.wikisource.org/w/index.php?title=The_Rock_of_Wisdom;_An_Explanation_of_the_Sacred_Scriptures/Biography_of_the_Author&oldid=12120013">https://en.wikisource.org/w/index.php?title=The_Rock_of_Wisdom;_An_Explanation_of_the_Sacred_Scriptures/Biography_of_the_Author&oldid=12120013</a>. It's clearly a rip-off, but, as Xover said, our works are in the public domain and anything can do anything with them legally. Languageseeker (talk) 12:57, 5 June 2022 (UTC)

Those are most likely stock photos or photos similarly ripped from some random website, yes. Xover (talk) 16:08, 5 June 2022 (UTC)

If they are using the name Wikisource on their site, there may be legal action from our parent corporation, as use of the name may be protected as a trademark. --EncycloPetey (talk) 18:22, 5 June 2022 (UTC)

I see "2022 © WikiSources. All rights reserved." The Wikimedia Foundation better pursue a very serious legal action.--Jusjih (talk) 02:33, 8 June 2022 (UTC)

i have yet to see any case law enforcing SA. the closest has been the Highsmith case, [2] they might try a stern letter about copyfraud. so it goes. --Slowking4 亞 Farmbrough's revenge 00:52, 11 June 2022 (UTC)

Our source material is public domain, but our discussion pages aren't. They're licensed under Creative Commons Attribution-ShareAlike, as it says at the bottom of the page. And yet this strange site has scraped this very discussion page and copied it... Also, is there any copyright/licensing to be had on our particular rendering of the works? If they take the text, that's fine, but if they take all the HTML/template rendering, does it then have to be CC-BY-SA? — Dcsohl (talk)
(contribs) 16:36, 8 June 2022 (UTC)

No. None of the formatting we do in texts is independently copyrightable, especially because our formatting aims to mimic the originally published version. Anything copyrightable as layout would be out of scope. But all other parts of the site are, as you note, licensed under {{CC-BY-SA-3.0}} which both requires attribution of the source (i.e. a link back to the original page here) and re-sharing derivative works under the same license terms. Xover (talk) 08:10, 11 June 2022 (UTC)

Recent Changes does not link to other languages

Special:RecentChanges does not link to the other languages (see de:Special:RecentChanges or bs:Special:RecentChanges for how it should look. NilsLindenberg (talk) 20:59, 12 June 2022 (UTC)

Tech News: 2022-24

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• All wikis can now use Kartographer maps. Kartographer maps now also work on pages with pending changes. [3][4]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 June. It will be on non-Wikipedia wikis and some Wikipedias from 15 June. It will be on all wikis from 16 June (calendar).
• Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 14 June at 06:00 UTC (targeted wikis). [5]
• Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Abkhazian Wikipedia, Achinese Wikipedia, Adyghe Wikipedia, Afrikaans Wikipedia, Akan Wikipedia, Alemannisch Wikipedia, Amharic Wikipedia, Aragonese Wikipedia, Old English Wikipedia, Syriac Wikipedia, Egyptian Arabic Wikipedia, Asturian Wikipedia, Atikamekw Wikipedia, Avaric Wikipedia, Aymara Wikipedia, Azerbaijani Wikipedia, South Azerbaijani Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [6]
• The New Topic Tool will be deployed for all editors at Commons, Wikidata, and some other wikis soon. You will be able to opt out from within the tool and in Preferences. [7][8]

Future meetings

• The next open meeting with the Web team about Vector (2022) will take place today (13 June). The following meetings will take place on: 28 June, 12 July, 26 July.

Future changes

• By the end of July, the Vector 2022 skin should be ready to become the default across all wikis. Discussions on how to adjust it to the communities' needs will begin in the next weeks. It will always be possible to revert to the previous version on an individual basis. Learn more.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

16:58, 13 June 2022 (UTC)

Poll regarding Fourth Wikisource Triage meeting

Hello fellow Wikisource enthusiasts!

We will be organizing the fourth Wikisource Triage meeting in the last week of June and we need your help to decide on a time and date that works best for the most number of people. Kindly share your availabilities at the wudele link below by 20th June 2022:

https://wudele.toolforge.org/wstriage4

Meanwhile, feel free to check out the page on Meta-wiki and suggest topics for the agenda.

Regards

Sam Wilson (WMF) and Satdeep Gill (WMF)

Sent via MediaWiki message delivery (talk) 13:22, 14 June 2022 (UTC)

Paragraphs HTML not closed

I noticed that in the HTML code when there's an image inserted into a paragraph, the closing tag will be missing (no </p>). -- bp

@BluePrawn: P-tags are allowed to be unclosed in HTML5 (unsure about prior versions): MDN docs. Inductiveload—talk/contribs 21:52, 18 June 2022 (UTC)

Oh ok html5 became permissive again like html3 was. Html4 was more strict indeed. When there is an image inserted in a paragraph, then opening p tag is also sometimes missing too. Even if it's allowed, closing it would be nicer, and I don't think this is intentional because it's only when there is an image inserted that the closing p tag is missing. -- bp

Category:Index_-_File_to_check

Can someone consider putting in the effort to get the remainder of works in this folder pagelisted? I didn't feel comfortable doing this on the remainder in that category, some of which seem to need compiling into DJVU collections of the relevant scans. ShakespeareFan00 (talk) 07:34, 13 June 2022 (UTC)

For anyone considering this now, the Epigraphia Indica volumes are pretty straightforward, if somewhat time-consuming due to the large number of image pages. —CalendulaAsteraceae (talk • contribs) 12:33, 20 June 2022 (UTC)

Tech News: 2022-25

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• The Wikipedia App for Android now has an option for editing the whole page at once, located in the overflow menu (three-dots menu ). [9]
• Some recent database changes may affect queries using the Quarry tool. Queries for site_stats at English Wikipedia, Commons, and Wikidata will need to be updated. Read more.
• A new user_global_editcount variable can be used in abuse filters to avoid affecting globally active users. [10]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 June. It will be on non-Wikipedia wikis and some Wikipedias from 22 June. It will be on all wikis from 23 June (calendar).
• Users of non-responsive skins (e.g. MonoBook or Vector) on mobile devices may notice a slight change in the default zoom level. This is intended to optimize zooming and ensure all interface elements are present on the page (for example the table of contents on Vector 2022). In the unlikely event this causes any problems with how you use the site, we'd love to understand better, please ping Jon (WMF) to any on-wiki conversations. [11]

Future changes

• The Beta Feature for DiscussionTools will be updated throughout July. Discussions will look different. You can see some of the proposed changes.
• Parsoid's HTML output will soon stop annotating file links with different typeof attribute values, and instead use mw:File for all types. Tool authors should adjust any code that expects: mw:Image, mw:Audio, or mw:Video. [12]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

20:18, 20 June 2022 (UTC)

Validation request Index:My Mysterious Mademoiselle Frank Leslie.pdf

Short story by Louisa May Alcott (published anonymously and attributed to her in 1993). If anyone wants to take a look, I'd appreciate it :) —CalendulaAsteraceae (talk • contribs) 12:21, 21 June 2022 (UTC)

Common.js: faux red links?

(@Inductiveload:) There's a script in th:MediaWiki:Common.js, which I found out to be the same one as MediaWiki:Common.js#L-33 (to line 34) here. I wonder what this script actually does because from asking around in Wikimedia Community Discord, they assume that the script wasn't even necessary.

I would guess that a.stub was added by the automatic stub threshold setting that may or may not have been removed in the recent past
[picture]
yep
so in addition to being poorly documented, that user script/JS snippet wasn't even necessary; the user just needed to disable the stub link formatting threshold in their preferences
-- Dinoguy1000 on Discord

it looks through all links in the div.mw-body (more or less the content area at a guess), and removes the .stub class from any links that have it
if the comment is anything to go by, it was added because of a misunderstanding
and even before the relevant preference was removed, it would've been useless for >99.9% of visitors
basically, if you're looking for JS to axe, that snippet is a trivially easy gain
I'd also suggest to leave a comment on en.WS to have them remove it from their file, too
.
.
make sure to clearly note that that preference no longer exists on WMF wikis, so even for the handful of editors who might've set it once upon a time, the snippet no longer does anything
it probably wouldn't hurt to also note that just disabling that preference would've been the way to disable the link coloring even before the pref was removed, too
-- Dinoguy1000 on Discord, some time after above quote

stjn on Discord told me it's removed in phab:T284917. The script came in revision Special:Diff/5230099. --Bebiezaza (talk) 13:19, 21 June 2022 (UTC)

@Bebiezaza: Removed. I can't find any context for why it was added, but I'd guess it was an attempt to override a feature added for Wikipedia that made zero sense for Wikisource (what the heck would a "Stub" be on Wikisource?). Thanks for the headsup! Xover (talk) 16:13, 21 June 2022 (UTC)

New Talk page creation text

Has anyone else noticed the new text that gets displayed when someone creates a Talk page? I foresee problems if that's the text we're going to have.

Start a discussion about Agreement on Trade-Related Aspects of Intellectual Property Rights

Talk pages are where people discuss how to make content on Wikisource the best that it can be. You can use this page to start a discussion with others about how to improve Agreement on Trade-Related Aspects of Intellectual Property Rights.

Do others see a potential problem? --EncycloPetey (talk) 03:23, 9 June 2022 (UTC)

I see what you mean—one could easily construe this in a misleading way. New users especially might get a false impression (which is an issue, as the text is clearly directed at new users). Can the default text be changed? Shells-shells (talk) 18:09, 23 June 2022 (UTC)

Invitation to join the fourth Wikisource Triage meeting (29th June 2022)

Hello fellow Wikisource enthusiasts!

We are the hosting the fourth Wikisource Triage meeting on 29th June 2022 at 10:00 AM UTC / 3:30 PM IST (check your local time) according to the wudele poll.

There is some exciting news about a few technical projects related to Wikisource that are getting started right now and we will be sharing more information during the meeting.

As always, you don't have to be a developer to participate in these meetings but the focus of these meetings is to improve the Wikisource infrastructure.

If you are interested in joining the meeting, kindly leave a message on sgill@wikimedia.org and we will add you to the calendar invite.

Meanwhile, feel free to check out the page on Meta-wiki and suggest any other topics for the agenda.

Regards

Sam Wilson (WMF) and Satdeep Gill (WMF)

Sent using MediaWiki message delivery (talk) 07:39, 23 June 2022 (UTC)

Index:Karl Kautsky - Georgia - tr. Henry James Stenning (1921).pdf

Sorry about this but the backing pdf needs to move from commons to wikisource because Stenning died in 1971 so it still has UK copyright. MarkLSteadman (talk) 14:01, 2 June 2022 (UTC)

Tech News: 2022-26

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Recent changes

• Wikimedia Enterprise API service now has self-service accounts with free on-demand requests and monthly snapshots (API documentation). Community access via database dumps & Wikimedia Cloud Services continues.
• All Wikimedia wikis can now use Wikidata Lexemes in Lua after creating local modules and templates. Discussions are welcome on the project talk page.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 June. It will be on non-Wikipedia wikis and some Wikipedias from 29 June. It will be on all wikis from 30 June (calendar).
• Some wikis will be in read-only for a few minutes because of a switch of their main database. It will be performed on 28 June at 06:00 UTC (targeted wikis). [13]
• Some global and cross-wiki services will be in read-only for a few minutes because of a switch of their main database. It will be performed on 30 June at 06:00 UTC. This will impact ContentTranslation, Echo, StructuredDiscussions, Growth experiments and a few more services. [14]
• Users will be able to sort columns within sortable tables in the mobile skin. [15]

Future meetings

• The next open meeting with the Web team about Vector (2022) will take place tomorrow (28 June). The following meetings will take place on 12 July and 26 July.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

20:02, 27 June 2022 (UTC)

J. Michael Luttig

Judge J. Michael Luttig is very much in the news in the United States since he testified before the January 6 Select committee. Are there any thoughts about adding his testimony to Wikisource? Just curious. Ottawahitech (talk) 15:44, 21 June 2022 (UTC)

It depends on how it may or may not be copyrighted.--Jusjih (talk) 03:31, 29 June 2022 (UTC)

Are we allowed to link names in the djvu files to Wikidata

Are we allowed to link names in the djvu files to Wikidata? Lets say there is an obituary stored as a djvu file and names a few people that already have a Wikidata entry? Can I link to them? RAN (talk) 02:51, 17 June 2022 (UTC)

A good question. But why not? I constantly link to Wiktionary and Wikipedia. — ineuw (talk) 05:33, 17 June 2022 (UTC)

• I agree 100%, but in the past all my links had been removed. I prefer linking to Wikidata since the links are more stable, and you can always add in a person, they do not have to be famous. --RAN (talk) 05:39, 17 June 2022 (UTC)

However, I can see why it is removed, I guess because of double linking. Were they all removed? — ineuw (talk) 05:48, 17 June 2022 (UTC)

The relevant section of the draft policy on linking (which I must get back to and finish tidying up):

The default item view on Wikidata is not user friendly or useful for most people, and for this reason direct wikilinks to Wikidata are not permitted in presentation namespaces. In some cases, however, it may be useful to identify a person or work for which a Wikidata item exists, but for which there is no suitable link target on Wikisource or the permitted sister projects. In these cases it is acceptable to link to Wikidata using the {{wdl}} template, which dynamically displays a link to the most suitable destination based on which targets are available.

Beeswaxcandle (talk) 06:00, 17 June 2022 (UTC)

For an obituary, I'd say so. Generally, I link to other projects (Wikipedia, Commons categories, or Wikidata via Reasonator) in non-fiction and not in fiction. And yep, as Beeswaxcandle says, using the {{wdl}} template makes it easy (it'll start of linking to Wikidata, but if someone makes an English Wikipedia article it'll change to that without anyone at Wikisource having to do a thing). Sam Wilson 11:26, 17 June 2022 (UTC)

• The problem with Wikipedia vs. Wikidata is that common names in Wikipedia may have a dozen entries that are always being renamed or being turned into disambiguation pages. For example John Smith (politician) may be turned into a disambiguation page for John Smith (mayor) and John Smith (governor). Wikidata is stable. --RAN (talk) 02:35, 1 July 2022 (UTC)

First work on Wikisource

What was the first work ever to be published on Wikisource, out of curiosity? PseudoSkull (talk) 16:54, 29 June 2022 (UTC)

I can't state this to a certainty; maybe somebody with a better grasp of the search API can verify, but the very first revision of the Main Page had a single link to the Gettysburg Address, so that looks likely to have been the first. It's also worth noting that Gettysburg Address has page id number 1 while Main Page is #2, so I'm pretty confident here. — Dcsohl (talk)
(contribs) 19:05, 29 June 2022 (UTC)

It's not a page ID, it's a revision ID: Special:PermanentLink/1. So the first edit on Wikisource, by an IP editor, was adding the Gettysburg Address. Xover (talk) 19:26, 29 June 2022 (UTC)

And the first work to be fully proofread and validated was Frontiers, but that was several years later. Beeswaxcandle (talk) 05:30, 30 June 2022 (UTC)

Messed up rendering..

https://en.wikisource.org/w/index.php?title=Page:Northmost_Australia_volume_2.djvu/25&oldid=12433298

Here something gets mis-wrapped meaning what should be a continuous division/paragrpah isn't. What's actually 'wrong' because there were NO linter warnings at all about this... ShakespeareFan00 (talk) 17:05, 30 June 2022 (UTC)

Don't leave line breaks is the simple answer. The more complex is that line break characters don't behave very well, so don't leave them in. I note that the original text has small-caps throughout the page, all of which have been done as all-caps. Beeswaxcandle (talk) 05:14, 1 July 2022 (UTC)

@Beeswaxcandle: I had taken out the line-breaks on a subsequent edit, However, currently the Linter generates no warnings about the soft line-breaks in SPAN issue. Is there a regular expression that could be used to find related situations in wiki-text, as trying to find these manually isn't practical for templates with widespread usage?ShakespeareFan00 (talk) 06:39, 1 July 2022 (UTC)

Sorry, but I know not of what you speak. Beeswaxcandle (talk) 09:39, 1 July 2022 (UTC)

Is there anyone technically minded reading this? I'm currently running a query in AWB to try and find some of the usages of {{smaller}} where there are line-feeds in the paramter which causes the (mis-rendering). I've also raised a ticket on Phabricator (T311769), which gives a little more detail on what actually happens.

As I said, trying to find the "'line-breaks' intterupt a SPAN error" manually isn't feasible, it needs some kind of semi-automated filter.

ShakespeareFan00 (talk) 10:16, 1 July 2022 (UTC)

@ShakespeareFan00: This is just p-wrapping. The parser tries to detect when it needs to insert p tags around content (it thinks all content must be wrapped in a block element of some kind, and inserts p tags when it thinks such is missing), and frequently gets triggered by all sorts of things you wouldn't really think mattered. This is one reason why hard line breaks should generally be removed from running prose (it works fine most of the time, but sometimes creates intractable problems) and why block-based templates should always have a newline after its opening tag and before its closing tag. It's the only way to get predictable behaviour. There's no lint error because the parser has silently "corrected" it.

And, yes, p-wrapping should be ripped out of the codebase and killed with fire, but from the WMF/developer perspective it costs too much to do, will break too many things, and will give too little benefit to be worth it. Wikisource is just about the only project that runs into this kind of problem regularly and we're a mere drop in the ocean compared to the Wikipedias etc. Xover (talk) 15:41, 1 July 2022 (UTC)

@Xover:

Can you have a look at {{hi}} then? When I changed that in debugging a lint error to include the newlines as you suggest above, I got loads and loads of previously undetected misnesting errors? (on a related note, {{hanging indent inherit}} and {{dent}} and related may also cause the same issue in rendering to manifest in related situations.

Is there an automated way to 'find' and repair these hard line breaks, because the manual regexp I was using listpages.py with found at least 4500 for {{smaller}} alone? (https://public.paws.wmcloud.org/User:ShakespeareFan00/linebreaks_in_SPAN)

A related check found at least 500 templates that were SPAN based and accepted a parameter based input, (https://public.paws.wmcloud.org/User:ShakespeareFan00/obs_spans_unfiltered), and that's without considering the DIV based templates that wrap parameters in a span.

This either needs a fix in the parser, or it needs a specifc 'Linter' rule to look for the P in SPAN mis-nesting that results, in the output.

(I consider the P wrapping useful as it let me set up some use case specific behavior in {{hi/m}} , {{dent/m}} which wouldn't be as easy to setup otherwise. )

ShakespeareFan00 (talk) 17:16, 1 July 2022 (UTC)

Pages and index at different locations breaking internal linking..

Page:An introduction to Indonesian linguistics, being four essays.djvu/112 links upward to Index:An introduction to Indonesian linguistics, being four essays; Renward Brandstetter; 1916; London, Royal Asiatic Society.djvu

Where is the Index SUPPOSED to be please? ShakespeareFan00 (talk) 18:09, 30 June 2022 (UTC)

@ShakespeareFan00 Special:WhatLinksHere/Page:An introduction to Indonesian linguistics, being four essays.djvu/112 tells us (accurately) that the index is at Index:An introduction to Indonesian linguistics, being four essays.djvu. I don't know why the wrong link is being generated in the top bar. Also note that the forward/back buttons are missing. The index page doesn't appear to have ever been moved, and the djvu file has never been edited since its creation, so I'm not sure what could be causing this. Shells-shells (talk) 22:40, 30 June 2022 (UTC)

File was renamed at Commons. [ https://commons.wikimedia.org/w/index.php?title=File:An_introduction_to_Indonesian_linguistics,_being_four_essays.djvu&redirect=no] appears to confuse Proofread Page. ShakespeareFan00 (talk) 08:35, 1 July 2022 (UTC)

Index:IA Query "sponsor-(Sloan) date-(1000 TO 1925) publisher-((New York) OR Chicago OR Jersey OR Illan)" (IA conductorgeneral00park).pdf

Please move this to a new title of Index: Conductor Generalis (1788) (IA conductorgeneral00park).pdf which is a more sensible name. This would also involve a rename at Commons. ShakespeareFan00 (talk) 07:08, 23 June 2022 (UTC)

• ShakespeareFan00: I have moved the file on Commons. TE(æ)A,ea. (talk) 02:10, 4 July 2022 (UTC)

Desktop Improvements update

Making this the new default

Hello. I wanted to give you an update about the Desktop Improvements project, which the Wikimedia Foundation Web team has been working on for the past few years. Our work is almost finished! 🎉

We would love to see these improvements become the default for readers and editors across all wikis. In the coming weeks, we will begin conversations on more wikis, including yours. 🗓️ We will gladly read your suggestions!

The goals of the project are to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use article tabs and the user menu, and more. The improvements are already visible by default for readers and editors on more than 30 wikis, including Wikipedias in French, Portuguese, and Persian.

The changes apply to the Vector skin only, although it will always be possible to revert to the previous version on an individual basis. Monobook or Timeless users will not notice any changes.

The newest features

• Table of contents - our version is easier to reach, gain context of the page, and navigate throughout the page without needing to scroll. It is currently tested across our pilot wikis. It is also available for editors who have opted into the Vector 2022 skin.
• Page tools - now, there are two types of links in the sidebar. There are actions and tools for individual pages (like Related changes) and links of the wiki-wide nature (like Recent changes). We are going to separate these into two intuitive menus.

How to enable/disable the improvements

Global preferences

• It is possible to opt-in individually in the appearance tab within the preferences by selecting "Vector (2022)". Also, it is possible to opt-in on all wikis using the global preferences.
• On wikis where the changes are visible by default for all, logged-in users can always opt-out to the Legacy Vector. There is an easily accessible link in the sidebar of the new Vector.

Learn more and join our events

If you would like to follow the progress of our project, you can subscribe to our newsletter. You can read the pages of the project, check our FAQ, write on the project talk page, and join an online meeting with us.

Thank you! SGrabarczuk (WMF) (talk) 16:59, 21 June 2022 (UTC)

Join us on Tuesday

Join an online meeting with the team working on the Desktop Improvements! It will take place on 28 June 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location. The following events will take place on 12 July and 26 July.

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file and copied to Etherpad. Olga Vasileva (the Product Manager) will be hosting this meeting. The presentation part will be given in English. At this meeting, both Friendly space policy and the Code of Conduct for Wikimedia technical spaces apply. Zoom is not subject to the WMF Privacy Policy.

We can answer questions asked in English and a number of other languages. If you would like to ask questions in advance, add them on the talk page or send them to sgrabarczukwikimedia.org. We hope to see you! SGrabarczuk (WMF) (talk) 21:43, 23 June 2022 (UTC)

I can already see how these changes are very Wikipedia-centric. (1) For example, things like "Wikidata item" and "Upload file" are not "article-specific" on Wikisource. Nor does Wikisource even have pages that are "articles" unless they are magazine articles or articles from other periodicals. Most pages in the main namespace are not articles, and most mainspace entities consist of multiple pages which together have one Wikidata item. (2) How will the new table of content affect the layout of works on Wikisource that require placing sidenotes in the margins, or rely on other multi-page formatting? (3) Also, will the changes make it possible to find links to a redirect, which used to be possible? Currently, such searches are suppressed, and the supposed way to do such a search does not function. --EncycloPetey (talk) 01:33, 24 June 2022 (UTC)

Hello @EncycloPetey, thanks for this comment.

1. Some details may be Wikipedia-centric despite of our general approach - sorry for that. I've just replaced every single use of "article" on the documentation page about the page tools menu. I'm well aware that different sister projects have different natures, not everything is an article, not everyone is a Wikipedian.
2. Could you provide some examples? When it comes to Proofread and the Page namespace, we've restored the full width (made an exception to the limited width feature). Works requiring placing sidenotes in the margins - could you share some links?
3. I'll ask, but I doubt if this is about the skin. Perhaps it's more about the search itself... (@Sannita (WMF), FYI.)

SGrabarczuk (WMF) (talk) 02:04, 24 June 2022 (UTC)

1. It's more than just the label; it's also the placement of those two items which, on Wikisource, are broader (even site-wide) rather than specific to one work. (a) When we upload a DjVu file, for example, it applies to a multi=page work that does not yet exist here, and not to some existing page. And nearly all files should instead be uploaded to Commons; those that are loaded here are either specific to something in the Page namespace or else apply to all the pages of a work. Nothing is ever uploaded for something in the Main namespace. (b) Likewise, Wikidata items usually apply to whole groups of pages and their subpages, and not just to one page.
2. An example of a Page namespace item with Sidenotes is Page:The Solar System - Six Lectures - Lowell.djvu/20 and it is transcluded to The Solar System/Chapter 1 (activate Layout 1 or Layout 2 from the margin to put the Sidenotes into the side; or use default Layout 1 to be them "embedded" in the text. It is unlikely that a ToC will be used in the Main namespace, but there is potential for unforeseen interactions in various namespaces with any new change that alters page layout. This is also true for works that apply a Layout, such as at Coriolanus (1924) Yale/Text/Act III, where the margins are changed by the applied layout. The ToC appears most often on Wikisource in the Author namespace and the Portal namespace. Have these been checked? Such as, against Portal:Ancient Greek drama; Portal:Ancient poetry; Author:Aristophanes; and Author:Henry David Thoreau, to be sure the new ToC interacts appropriately in those namespaces with Wikisource namespace headers? The headers should be full-page width along with the notes displayed below them. The content of a page in the Portal namespace may be full width in content boxes, or may be sections of bulleted lists. And I note that Page Layout is not listed in either sub-menu for the change. Where will it appear?
3. The method for enabling the Search is supposed to be toggable in the Preferences, but the toggle makes no difference. I do not know enough to determine why it isn't working, but it makes page moves a nightmare here, since when a work with multiple chapters gets moved, links to the various chapters need to be checked, including redirects to those targets. It used to be that redirects automatically showed up in searching, but they do not anymore.
4. I did not notice before that there is a plan to move the page-specific Tools to the right-hand side of the page. This will be problematic for Wikisource as a whole. Will users be able to opt out of this placement, or can specific projects opt to not have an additional menu on the right side of the page? For Wikisource, this will be distracting and horizontally compress works, which is a huge problem for poetry, plays, and other kinds of works that need horizontal space for formatting.
5. Moving the Page title above the Tools is also problematic for Wikisource. I would like to know which Wikisource projects thought this would be a good idea?

--EncycloPetey (talk) 02:42, 24 June 2022 (UTC)

@EncycloPetey, thanks for all these arguments and examples. I'm not familiar with all the workflows and peculiarities of Wikisource, so I've asked @Samwilson to help me assess to what degree your comments are related to the skin itself. SGrabarczuk (WMF) (talk) 19:24, 27 June 2022 (UTC)

@SGrabarczuk (WMF), @EncycloPetey: Hello! I don't know if I'm totally across everything, but can try to help. :)

1. "Wikidata item" and "Upload file" are not "article-specific" on Wikisource. As far as I can see, these are in the same part of the sidebar that they've always been. I agree that it'd be nice to display the relevant Wikidata item link on every page of a work (in all namespaces) but I don't think Vector-2022 has anything to do with that.
2. The layouts in question are from the PageNumbers gadget (not the best name :-P), see its source for details. It's a default gadget, so everyone sees the new part of the sidebar. I note that Page Layout is not listed in either sub-menu for the change. I see it in the main sidebar in Vector-2022. Is this not what we'd expect? It's pretty independent from the ToC.
3. Search is a separate thing, and I'm not sure it's changed with Vector-2022.

In general, I totally think there's plenty of Wikisource-specific stuff that could be improved! I guess we're just looking for things that are actively broken with Vector-2022 at the moment though.

—Sam Wilson 07:55, 28 June 2022 (UTC)

@SGrabarczuk (WMF) After using the skin for two or three months, I have noticed a minor issue—the small popup that appears after successfully creating or editing a page perfectly covers the Edit and View History buttons (on my machine, at least), which is slightly inconvenient. Is there an option to turn it off, or shift its location slightly?

Also, can individual wikis change the text displayed when a new talk page is created? Currently it might be easily misconstrued (especially here on WS), as mentioned above.

Besides these quibbles, I have not had a specifically negative experience with the new skin, and some new features are quite nice—for example, the toolbar docked to the top of the window is useful, and I like the use of icons instead of text in both the docked and top-of-page toolbars. Shells-shells (talk) 03:15, 24 June 2022 (UTC)

The popup issue that Shells-shells mentions in their first paragraph is not unique to the new skin. It happens in Monobook as well. Beeswaxcandle (talk) 03:25, 24 June 2022 (UTC)

Thank you @Shells-shells. Indeed, @Beeswaxcandle is correct, this popup is related to the editing tools. I think @Whatamidoing (WMF) might help you. SGrabarczuk (WMF) (talk) 03:31, 24 June 2022 (UTC)

The page-creation "toast" (because it "pops up" like toast out of a toaster, right?) can be suppressed in your common.css if you don't ever want to see it. It should disappear after a few seconds (about two seconds too slow for me, but it does disappear). Whatamidoing (WMF) (talk) 20:04, 5 July 2022 (UTC)

I just tried the new skin and I like it and have made it my default. I like the table of contents on the side but I would prefer it to be collapsible since I use a small screen and it takes up some space. Jpez (talk) 04:06, 27 June 2022 (UTC)

Thank you @Jpez. Look at the newest prototype. Both the table of contents and the sidebar will be nicely collapsible. SGrabarczuk (WMF) (talk) 17:10, 27 June 2022 (UTC)

Perfect! Jpez (talk) 18:46, 27 June 2022 (UTC)

I share the objections raised by EncycloPetey above. What I especially dislike is the TOC in the left sidebar. 1) Its position at the bottom of the sidebar puts it out of sight and I have to scroll down to get to it. 2) Some headings are very long, which is not a problem in the current way of displaying the TOC, but the sidebar is narrow, and so some headings in the 2022 Vector layout take several lines, which makes the TOC more difficult to skim through. For example the TOC of this Scriptorium page is an absolute mess (after unwrapping the headings) in the proposed layout. 3) The TOC in the sidebar is also probably the reason, why the sidebar is wider (and the space for the text narower) than in the 2010 Vector layout, which is also quite unfortunate, as it can make problems to Wikisource pages containing tables, columns etc. --Jan Kameníček (talk) 21:27, 5 July 2022 (UTC)