Jump to content

Wikisource:Scriptorium/Archives/2022-10

Add links
From Wikisource

PDF edit needed - 'The Gospel by Wireless'

Latest comment: 2 years ago8 comments3 people in discussion

I plan to transcribe File:The Gospel by Wireless - James Ebenezer Boon.pdf - but it's scanned with two print pages to each page of the (seventeen-page) PDF. Would anybody be minded to reformat it for me, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:06, 3 October 2022 (UTC)

@Pigsonthewing done, I hope it's good enough (no text layer, you'll have to rely on WS OCR). Mpaa (talk) 22:13, 3 October 2022 (UTC)
@Mpaa Many thanks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:29, 4 October 2022 (UTC)
@Mpaa Commons is saying the pages are 0 × 0 pixels (they were 718 × 1,089), and I'm not seeing any preview images there or here. If I download your file, it looks fine. Any ideas? Anyone else? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 4 October 2022 (UTC)
Sigh, it is a known behavior that occurs sometimes with PDFs, in Phab there are several tickets about it. I do not know how to fix it, if it is OK for you, I can upload a djvu version. Mpaa (talk) 18:09, 4 October 2022 (UTC)
@Mpaa Thank you, please do. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:13, 4 October 2022 (UTC)
@Pigsonthewing all moved to *.djvu. Mpaa (talk) 19:42, 4 October 2022 (UTC)
This section was archived on a request by: All good now. djvu version now proofed and already part validated. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 6 October 2022 (UTC)
Latest comment: 2 years ago5 comments4 people in discussion

Is it in the public domain? Blahhmosh (talk) 03:08, 2 October 2022 (UTC)

@Blahhmosh: You're going to have to give us more to go on than that. Links? Author, and author vital years? Place and date of publication? And so forth… Xover (talk) 04:35, 2 October 2022 (UTC)
@Blahhmosh Probably, since it showed up in the Public Domain Review. Shells-shells (talk) 06:51, 2 October 2022 (UTC)
c:File:Vaught's practical character reader (IA vaughtspractical00vaug).pdf don’t know why you are asking; it is not even close > 100 years. --Slowking4 亞 Farmbrough's revenge 22:48, 2 October 2022 (UTC)
word to the wise: after User:Fæ’s mass upload of a million books from IA, first check should be at commons search, "other media" tab, i.e. [1]. (caveat, this corpus is US university library google book scans, specialized items may not be there, requiring a rendez-vous with a book scanner.) --Slowking4 亞 Farmbrough's revenge 22:56, 3 October 2022 (UTC)

Tech News: 2022-40

Latest comment: 2 years ago1 comment1 person in discussion

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

  • Kartographer maps can now show geopoints from Wikidata, via QID or SPARQL query. Previously, this was only possible for geoshapes and geolines. [2] [3]
  • The Coolest Tool Award 2022 is looking for nominations. You can recommend tools until 12 October.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 October. It will be on non-Wikipedia wikis and some Wikipedias from 5 October. It will be on all wikis from 6 October (calendar).
  • Talk pages on the mobile site will change at the Arabic, Bangla, Chinese, French, Haitian Creole, Hebrew, Korean, and Vietnamese Wikipedias. They should be easier to use and provide more information. (Last week's release was delayed) [4] [5]
  • The scribunto-console API module will require a CSRF token. This module is documented as internal and use of it is not supported. [5]
  • The Vector 2022 skin will become the default across the smallest Wikimedia projects. Learn more.

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

MediaWiki message delivery 00:23, 4 October 2022 (UTC)

Tech News: 2022-41

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 11 October. It will be on non-Wikipedia wikis and some Wikipedias from 12 October. It will be on all wikis from 13 October (calendar).
  • On some wikis, Kartographer maps in full size view will be able to display nearby articles. After a feedback period, more wikis will follow. [6][7]

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

14:08, 10 October 2022 (UTC)

Breaking technical changes coming

Latest comment: 2 years ago1 comment1 person in discussion

Hi all,

Bottom line: For various reasons there's some bumpy road ahead for message boxes, navboxes, and related templates. I'll try to keep disruption to a minimum and fix issues as they crop up, but some annoyance is probably inevitable. Please report issues here, on my talk page, or ping me from a template's talk page. Good descriptions of what is broken, how it is broken, and where I can observe the breakage will be appreciated. Please also note that reverting any changes is highly unlikely to fix anything (it'll rather tend to break things more), so better to report the issue and wait for a fix. The reasons for all this are fairly technical, so feel free to skip unless you're especially interested.

The technical mumbo-jumbo: We have a whole host of "box"-related templates that are imported from enWP, that have supporting CSS (and even som JS) in global stylesheets. The styles etc. in global stylesheets are problematic in that they interact poorly with new releases of MediaWiki, the skins (i.e. Vector 2022), and our local gadgets and templates. They are also a performance issue in that they are forcibly loaded for all users on all pages, regardless of whether any relevant templates are used on that page. And not least of all, they do not work well on mobile (which is 2/3 of all pageviews) or in ebook exports.

enWP has been planning to modernise these and move stuff out of the global styles for years, but have been hampered by their sheer size and variety of uses (~5 million pages, and a contributor pool several orders of magnitude larger than ours). Now they have finally pulled the trigger on these changes, which means the next time we pull from these templates we'll get those changes too; and if we've not done the grunt work of migrating ourselves we'll get big uncontrolled breakage that's going to be 1) very visible to users, and 2) very hard to fix under time pressure.

So… I'm going to start by cleaning up our historical usages of certain obsolete CSS classes and templates (several of which should never have been used in our content spaces in the first place, and these may not have good replacements). Then I'm going to start systematically cleaning out our global stylesheets to remove things that are not needed, obsolete, broken, etc.; with the aim of having a better starting point for the next step. Which is to start importing, one by one, the new versions from enWP, and trying to fix things as I go along. The big problem here is that the different templates may have dependencies between them, such that an issue caused by importing one template may not be possible to solve without importing another template, which can in turn cause other problems.

In other words, while this is going on it is probably inevitable that there will be stuff that breaks and will stay broken for a while. I'll try my best to minimise the disruption, but I'll be shocked if there isn't at least a few problems and surprised if there isn't any middling large stuff that breaks.

The areas to watch is "boxes", of the kind exemplified by navbars, navboxes, message boxes, and so forth. The most visible and used of these are our maintenance templates that are used in content pages. Navbars and navboxes generally shouldn't be used in content (they are annotations or borderline annotations), but are in some subsets of content (US court cases, that were originally automatically imported, sporing to mind). The latter should actually be constrained to user pages and project spaces, but ironically enough are very rarely used there. It is also possible that things like user boxes will be affected. What should not be affected (famous last words) is stuff like {{header}} (and its variants) or our main formatting templates ({{c}} etc.). These are almost universally locally developed templates not affected by enWP imports.

And the best news of all is that one we are done with this, you probably will notice nothing different as all the changes are technical in nature. *sigh* But it'll be better down in the technical bits, and should make future changes easier and faster and less prone to break. Xover (talk) 06:49, 13 October 2022 (UTC)

Think big! An open letter about Wikimedia Commons

Latest comment: 2 years ago2 comments2 people in discussion

Dear friends of free knowledge,

Wikimedia Commons is in crisis. There are numerous concerns and complaints about our central media platform, for many years.

Therefore, this open letter asks the Wikimedia Foundation to Think big! about the future of Wikimedia Commons.

In late August 2022, we at the Commons Photographers User Group talked about Wikimedia Commons. The result of these and other talks is this open letter.

We invite everyone to sign this open letter to show how important Wikimedia Commons is to you. You may be a regular Commons contributor, a Wikipedian, an editor of Wiktionary or Wikivoyage, or maybe you represent an affiliation. We also strongly invite other people who are involved with Commons directly or indirectly, maybe in the context of a GLAM.

Please inform others about this open letter.

Kind regards, Ziko (talk) 19:59, 14 October 2022 (UTC)

Commons is foundational for all the projects, and perhaps even more than usual for Wikisource since we rely on it for our input as a core part of our workflow, as well as output like the other projects. It is also massively out of date technically, making it really hard to use. And the lack of active maintenance means technical improvements that would benefit us immensely are near impossible to get traction for. I therefore encourage everyone to sign this open letter and support any effort to get the WMF to allocate more resources to Commons and the multimedia stack. Xover (talk) 04:52, 15 October 2022 (UTC)

Untitled message

Latest comment: 2 years ago3 comments2 people in discussion

I am a very infrequent visitor to ENWS, so please bear with me. I am trying to find quotes I heard in passing on radio or tv from the January 6th senate committee hearing in the United States. I was hoping WS will have the transcriptt of these hearings, but I cannot find it. Anyone? Ottawahitech (talk) 16:55, 15 October 2022 (UTC)

@Ottawahitech Not that we shouldn't grab this stuff for here, but you'll find what you need at https://www.businessinsider.com/january-6-committee-hearing-transcripts-liz-cheney-bennie-thompson-2022-6. It's also on the Committee's website, somewhere, but probably not all on one page. Jarnsax (talk) 23:48, 15 October 2022 (UTC)
Looking a bit closer, the url on the house website is actually on each page of the documents, lol. Convenient is easy. :) Jarnsax (talk) 23:52, 15 October 2022 (UTC)

Bringing order to Pinocchio

Latest comment: 2 years ago2 comments2 people in discussion

Can The Adventures of Pinocchio be moved to The Adventures of Pinocchio (unsourced Chiesa 1926) and then Pinocchio be moved to The Adventures of Pinocchio so that the disambiguation page will be have the title of the work. Languageseeker (talk) 11:38, 1 October 2022 (UTC)

@Languageseeker: Done Please check that I didn't mess anything up. I went with The Adventures of Pinocchio (unsourced), both because the established practice for disambiguation is to keep it to the minimum necessary, and because those extra datum are of less than perfect provenance (someone made those claims, but the text was originally without them, and absent scan backing it's hard to determine at least the edition used with certainty). Xover (talk) 07:35, 16 October 2022 (UTC)

The First Men in the Moon

Latest comment: 2 years ago9 comments2 people in discussion

Can The First Men in the Moon be moved to The First Men in the Moon (1901) to make way for a disambiguation page. A check of IA shows no other editions published in 1901. Languageseeker (talk) 16:38, 10 October 2022 (UTC)

@Languageseeker: Disambiguate with what? Xover (talk) 07:55, 16 October 2022 (UTC)
@Xover The Works of H. G. Wells (Atlantic Edition)/The First Men in the Moon Languageseeker (talk) 12:47, 16 October 2022 (UTC)
@Languageseeker: Ah. A versions page. You must be very precise when speaking to us dumb techies (and yet more so to admins). The smallest detail can trip us up and make us confused. :) Xover (talk) 12:51, 16 October 2022 (UTC)
@Languageseeker: Done Xover (talk) 12:59, 16 October 2022 (UTC)
@Xover Can you also unprotect The First Men in the Moon? Sorry for the linguistical confusion. Languageseeker (talk) 13:36, 16 October 2022 (UTC)
@Languageseeker: Done Xover (talk) 13:58, 16 October 2022 (UTC)
@Xover Since The First Men in the Moon (1901) is still protected, can you transfer the notes to the version page? Languageseeker (talk) 14:13, 16 October 2022 (UTC)
@Languageseeker: Done Xover (talk) 14:22, 16 October 2022 (UTC)

The Sea Lady

Latest comment: 2 years ago2 comments2 people in discussion

Can The Sea Lady be moved to The Sea Lady (1902) to make way for a disambiguation page for The Works of H. G. Wells (Atlantic Edition)/The Sea Lady Languageseeker (talk) 03:15, 16 October 2022 (UTC)

@Languageseeker Done Xover (talk) 13:01, 16 October 2022 (UTC)

The Food of the Gods and How It Came to Earth

Latest comment: 2 years ago2 comments2 people in discussion

Can The Food of the Gods and How It Came to Earth be moved to The Food of the Gods and How It Came to Earth (1906) to make way for a disambiguation page for The Works of H. G. Wells (Atlantic Edition)/The Food of the Gods Languageseeker (talk) 03:15, 16 October 2022 (UTC)

@Languageseeker: Done Xover (talk) 13:12, 16 October 2022 (UTC)

The Golden Bough

Latest comment: 2 years ago4 comments3 people in discussion

I'm not sure of the best course of action with this one. I have created a versions page (at The Golden Bough (versions), so this one needs to move to make way for the versions page. Where is needs to move to is the problem.

The original was copy-pasted from Project Gutenberg. Then an index file (Index:The Golden Bough (1922).djvu) was uploaded, and Match and Split performed on about 75% of the work. So what we have now is neither fish nor fowl. So do we:

a.) Move this to The Golden Bough (1922), and finish converting the PG text to a scan backed one? Or

b.) Do we move it to The Golden Bough (1922 Project Gutenberg edition), revert the M&S edits, and transcribe the scan-backed edition from clean start? If we go down this route, then we can delay deciding if we want or need the PG text until the scan-backed version is validated.

One problem is the the subpages are in the format of /Title of Chapter rather than our modern standard of /Chapter ##.

Assuming option (b.) the page moves would be:

Extended content

The scan-backed version is about 4% proofread, and I’m about half-way though a scan-backed version of the 1890 edition. — Iain Bell (talk) 13:29, 1 October 2022 (UTC)

i would go for option a, the 1922 abridged version is only 700 pages, the index is the hard part. (plus save you all those moves. --Slowking4 亞 Farmbrough's revenge 21:49, 5 October 2022 (UTC)
@Iain Bell: *sigh* I'm starting to think we need to restrict access to Match & Split or something. M&S-ing a Gutenberg text does not magically transform it into a specific different edition (@555: take note), and all experience shows that in 99% of cases starting from OCR is a lot easier and faster than starting from some random different edition of the text (typically Gutenberg or other secondary transcription) Matched & Split onto the index. In other words, doing this is effectively deleting the Gutenberg text (good riddance) and then forcing yourself to proofread the entire work, from scratch, but with a worse starting point. But you do need to then proofread it, otherwise we're lying about which edition the text is actually from.
Oh well; that little rant aside…
Given we are where we are, and proofreading is not proceeding all that fast, I suggest we revert the splits; move the Gutenberg text to a (unsourced)-disambiguated page name; delete the incorrectly split Page: pages (the Not Proofread ones; not those subsequently Proofread); move The Golden Bough (versions) to The Golden Bough, and list them all there. Once the actual 1922 edition has been proofread we can get rid of the Gutenberg text.
I think that is roughly what you proposed Iain? Anybody with different suggestions? Xover (talk) 07:52, 16 October 2022 (UTC)
Yes, that sounds fine to me. – Iain Bell (talk) 21:45, 17 October 2022 (UTC)

Poll regarding sixth Wikisource Triage meeting

Latest comment: 2 years ago1 comment1 person in discussion

Hello fellow Wikisource enthusiasts!

We will be organizing the sixth Wikisource Triage meeting in the next week of October 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:

https://wudele.toolforge.org/aE86KsnqQsBDNdkj

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) 14:33, 17 October 2022 (UTC)

New ProofreadPage dynamic (viewport) height in the Page namespace

Latest comment: 2 years ago5 comments2 people in discussion

The most recent change was that the text area was changed from a fixed to a dynamic height of 100vh, which is 100% of the viewport height.

In my case this more than doubles the text area, where the text is less than 50% of the Textbox1 (300pixels of text and 350pixels of empty space in #Textbox1) and the same proportions apply to the header/footer space. I tested other skins including the visual editor, and the problem is identical.

[https://www.rapidtables.com/web/tools/window-size.html|using this online tool] These were the dimensions related to 'vh' on my 24" display. Resolution and inner and outer windows sizes.jpg

I wondered if other editors were affected by these changes as well, and how they deal with it. — ineuw (talk) 01:03, 13 October 2022 (UTC)

@Ineuw: Have you tested this when logged out? Your various user CSS and JS files contains a lot of code that is very likely to be a factor in this kind of problem, so the very first step is testing in a way that eliminates these as a factor.
To answer your question, there have not been reports, that I have seen, of this kind of problem from other users (with the latest iteration of the code; there were some issues in earlier versions, which the current approach seems to have eliminated).
Also, I am going to assume that the problems you are referring to are those exemplified in these screenshots you posted previously: File:220926 edit space with blank blue areas .jpg • File:220926 Side by side editing is the same.jpg • File:220926 empty vertical space.jpg. Xover (talk) 04:17, 13 October 2022 (UTC)
Those are the screenshots I am referring to. I am just curious if it appears and others cope with it. This empty also appears in side by side editing. I intend ask these questions in the ProofreadPage talk page, but I should get others' comments, if there are any. My Vector.css contains code for the Page namespace, read and edit view. I am aware of the views logged in and out, as well as tested the proofread page without Vector.css and nothing changed. The Vector.js is also devoid of code that would affect the view. — ineuw (talk) 02:40, 14 October 2022 (UTC)
P.S: I will remove both now and test it. — ineuw (talk) 02:43, 14 October 2022 (UTC)
I removed the height settings in my Vector css, but all that there is now is a 7-800px high main textbox and 200px each header and footer. I read @Xover's post below, and I thought that it might be possible to float the toolbar, and user manage it's position where the tools are needed like near the bottom of the page. — ineuw (talk) 21:32, 19 October 2022 (UTC)

Invitation to join the sixth Wikisource Triage meeting (26th October 2022)

Latest comment: 2 years ago1 comment1 person in discussion

Hello fellow Wikisource enthusiasts!

We are the hosting the sixth Wikisource Triage meeting on 26th October 2022 at 2 PM UTC / 7:30 PM IST (check your local time) according to the wudele poll.

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. We will be discussing the newly launched Wiki Rescues Manuscripts project and two Wikisource Fellows who will be supporting that project until June 2023 will be joining the conversation as well.

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) 12:53, 21 October 2022 (UTC)

Illustrations turned to GIFs

Latest comment: 2 years ago3 comments3 people in discussion

I've noticed that in one text A Complete Course in Dressmaking/Lesson 1 a few of the illustrations have been turned into animations. What is the enWS policy on such alterations? Languageseeker (talk) 00:52, 22 October 2022 (UTC)

Well, that's kinda fun! (This is not a policy comment :) For convenience, here's a link to the relevant Commons category. -Pete (talk) 04:51, 22 October 2022 (UTC)
Fun. And done in rather good taste, too. But the policy on it is a fairly emphatic "No!". Xover (talk) 07:58, 22 October 2022 (UTC)

Tech News: 2022-43

Latest comment: 2 years ago1 comment1 person in discussion

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

  • There have been some minor visual fixes in Special:Search, regarding audio player alignment and image placeholder height. Further details are in T319230.
  • On Wikipedias, a new preference has been added to hide article thumbnails in Special:Search. Full details are in T320337.

Problems

  • Last week, three wikis (French Wikipedia, Japanese Wikipedia, Russian Wikipedia) had read-only access for 25 minutes. This was caused by a hardware problem. [8]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 October. It will be on non-Wikipedia wikis and some Wikipedias from 26 October. It will be on all wikis from 27 October (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 25 October at 07:00 UTC (targeted wikis) and on 27 October at 7:00 UTC (targeted wikis).
  • Starting on Wednesday, a new set of Wikipedias will get "Add a link" (Assamese Wikipedia, Bashkir Wikipedia, Balinese Wikipedia, Bavarian Wikipedia, Samogitian Wikipedia, Bikol Central Wikipedia, Belarusian Wikipedia, Belarusian (Taraškievica) Wikipedia, Bulgarian Wikipedia, Bhojpuri Wikipedia, Bislama Wikipedia, Banjar Wikipedia, Bambara Wikipedia, Bishnupriya Wikipedia, Breton Wikipedia, Bosnian Wikipedia, Buginese Wikipedia, Buryat Wikipedia, Indonesian Wikipedia). This is part of the progressive deployment of this tool to more Wikipedias. The communities can configure how this feature works locally. [9]
  • Starting on Wednesday October 26, 2022, the list of mentors will be upgraded at wikis where Growth mentorship is available. The mentorship system will continue to work as it does now. The signup process will be replaced, and a new management option will be provided. Also, this change simplifies the creation of mentorship systems at Wikipedias. [10][11][12]
  • Pages with titles that start with a lower-case letter according to Unicode 11 will be renamed or deleted. There is a list of affected pages at m:Unicode 11 case map migration. More information can be found at T292552.
  • The Vector 2022 skin will become the default across the smallest Wikipedias. Learn more.

Future changes

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

MediaWiki message delivery 21:22, 24 October 2022 (UTC)

Index:Hand-book of Volapük (Sprauge, 1888).djvu

Latest comment: 2 years ago3 comments3 people in discussion

Can Index:Hand-book of Volapük (Sprauge, 1888).djvu be match-and-split from Hand-book of Volapük, please? TE(æ)A,ea. (talk) 16:53, 28 October 2022 (UTC)

@TE(æ)A,ea.: Done The existing page structure is highly non-standard so that will have to be fixed when retranscluding after proofreading. Just tag the old pages with {{speedy}} as you go. Xover (talk) 19:50, 28 October 2022 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:28, 22 November 2022 (UTC)

Author:ArchWiki Contributors

Latest comment: 2 years ago9 comments4 people in discussion

A new author page has been created: Author:ArchWiki Contributors (by @Matr1x-101). It's not a single human, so I think should be a portal, but I'm not quite sure. I feel like there's a precedent for this, but I can't find it. What's the right thing? Sam Wilson 03:37, 16 October 2022 (UTC)

@Samwilson: It should be neither: the one text there is out of scope as an evolving work and not previously published. We might as well start mirroring Wikipedia entries. Xover (talk) 06:47, 16 October 2022 (UTC)
@Xover, It hasn't been changed since Apr 2021 so I think it's okay to include. Correct me if I'm wrong. Also I agree that the author page should be a portal; I didn't actually know that you could make a portal a few days ago. Furthermore, the page (see https://wiki.archlinux.org/index.php?title=DeveloperWiki:TrademarkPolicy&action=history) hasn't changed since 2009. The most recent changes are minor fixes and categorization. Matr1x-101 (talk) 11:18, 16 October 2022 (UTC)
@Xover, @Matr1x-101: I don't really have an opinion on the validity of Arch Linux Trademark Policy (although I think perhaps it's okay, considering we have various others in Category:Licenses). It does sound like the author page should be moved to a portal. Sam Wilson 23:01, 16 October 2022 (UTC)
I agree with Samwilson. Matr1x-101 (talk) 09:21, 17 October 2022 (UTC)
Let's put it this way: if we're to take it seriously that this is the original 2008 publication then the author should also be Thayer Williams rather than "ArchWiki Contributors". And who is the responsible publisher for that 2008 publication? Xover (talk) 12:47, 17 October 2022 (UTC)
@Xover, @Samwilson: Hello, I have filed a deletion request for this author page, and have made it a portal (Portal:Arch Linux Wiki) instead.
Sorry for the late response, Matr1x-101 (talk) 12:56, 24 October 2022 (UTC)
@Matr1x-101: No worries! Thanks for fixing it up. Sam Wilson 15:14, 24 October 2022 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:30, 22 November 2022 (UTC)

Tech News: 2022-42

Latest comment: 2 years ago9 comments5 people in discussion

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 recently implemented feature of article thumbnails in Special:Search will be limited to Wikipedia projects only. Further details are in T320510. [14]
  • A bug that caused problems in loading article thumbnails in Special:Search has been fixed. Further details are in T320406.

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 October. It will be on non-Wikipedia wikis and some Wikipedias from 19 October. It will be on all wikis from 20 October (calendar).
  • Lua module authors can use mw.loadJsonData() to load data from JSON pages. [15]
  • Lua module authors can enable require( "strict" ) to add errors for some possible code problems. This replaces "Module:No globals" on most wikis. [16]

Future changes

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

MediaWiki message delivery 21:46, 17 October 2022 (UTC)

On the side of ProofreadPage, a new js variable, mw.config.get('prpProofreadPageBookNamespaces') has been added which contains a list of namespaces where book features (source links, completion bars etc) will be visible. This is being done to expand the list of namespaces in which the use of a <pages/> tag can be used to transclude books (for example the Translation:(114) namespace). Further details are at T53980. Sohom Datta (talk) 12:27, 20 October 2022 (UTC)
Thanks for keeping us informed Sohom. Much appreciated! Xover (talk) 08:08, 22 October 2022 (UTC)
Thanks! Also, looks like the config change to roll this out to enWS is planned for Monday: https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/843593/. Then we should be able to remove the hack in MediaWiki:Gadget-site-source-links.js (though the script itself is still required as the source tab is otherwise not present in the mobile skin: phab:T274350) Inductiveload—talk/contribs 14:31, 22 October 2022 (UTC)
@Inductiveload The rendering of the source link was recently moved server-side as well (per gerrit:828036), I don't think the link adding aspect of Gadget-site-source-links.js is required at all (in fact, the mobile site has two source links now) Sohom Datta (talk) 01:25, 23 October 2022 (UTC)
Excellent news, then, thanks! Inductiveload—talk/contribs 11:17, 23 October 2022 (UTC)
The Translation: namespaces changes should be live!! :) Sohom Datta (talk) 08:31, 24 October 2022 (UTC)
Excellent. The local hack has been disabled, and a quick test on Translation:On Discoveries and Inventions indicates it works as expected. Xover (talk) 09:42, 24 October 2022 (UTC)
This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:31, 22 November 2022 (UTC)

Wikisource:Works/2022

Latest comment: 2 years ago4 comments3 people in discussion

Wikisource:Works/2022 only goes up to April. Is something broken? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 30 October 2022 (UTC)

It looks like Template:New texts/data/2022.json last had data imported on . @Inductiveload presumably knows more about how this all works? —CalendulaAsteraceae (talk • contribs) 05:26, 31 October 2022 (UTC)
It was supposed to be a system that would allow automatic ingestion from Template:New texts/data/2022.json, processing, and presentation (e.g. permitting a Twitter/IRC/Matrix bot) and so on. However, since the native JSON data entry was removed, it needs a manual step and has been functionally useless since then. I will remove the system and revert to the fully manual system as it's obviously not workable to have it. Inductiveload—talk/contribs 21:45, 5 November 2022 (UTC)
This section was archived on a request by: Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:25, 22 November 2022 (UTC)

Does adding authority control need to be manual?

Latest comment: 2 years ago4 comments4 people in discussion

Is there some reason instances of Template:authority control need to be added manually to pages, especially Author pages? I feel like every (at least every author) page could use authority control, so we wouldn't have to remember to manually add these. Could they possibly be made to be part of the author header template or something? Maybe with an option to say "authority_control = no" if we really don't need it? I don't know, just some thoughts on reducing work at Wikisource. @Billinghurst: What are your thoughts? I often see you adding these, so if they're necessary on every page, maybe we should look into universalizing it? PseudoSkull (talk) 05:12, 29 October 2022 (UTC)

Until someone automates it to an agreed spot, it is a manual process. It is not all author namespace pages, as we don't do it author subpages. It is not entirely difficult to manage petscan:638981 or user:billinghurst/petscan:638981. It is hardly time critical. Noting that I will also do sanity checks and tidy ups, which are often needed as many seem to escape the notice of the community at their time of creation. Also noting that fixes also include addition of licences, fixing last initial, etc. We could do abuse filter that checks for the absence, however, that is just going to confuse a newbie to ping them, and noting it for the community <shrug>. — billinghurst sDrewth 06:33, 29 October 2022 (UTC)
We have no real way to add it automatically in the current position in the page (except using a bot to manually add the template, which I don't think is what you meant). We could add it to {{header}}, but I don't think that's a particularly good place to have that component. And since Billinghurst does an enormous amount of work in this area, I'd be very inclined to defer to their judgement on this absent any very obvious advantage.
But just on general principle we're due for some reassessment of {{authority control}}, so if anybody wants to brainstorm possible alternatives or improvements I'm absolutely game for that. I don't see the "better way", but don't let that discourage you if you think you see it or a potential for one. Xover (talk) 09:18, 29 October 2022 (UTC)
yeah, could we have an upgrade of author template, to pull wikidata? (similar to what was done with creator template on commons). this would incorporate authority control from there. a bot run as on english would be good also. --Slowking4 亞 Farmbrough's revenge 22:00, 29 October 2022 (UTC)

Tech News: 2022-44

Latest comment: 2 years ago1 comment1 person in discussion

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

  • When using keyboard navigation on a Kartographer map, the focus will become more visible. [18]
  • In Special:RecentChanges, you can now hide the log entries for new user creations with the filter for "⧼rcfilters-filter-newuserlogactions-label⧽". [19]

Changes later this week

  • The new version of MediaWiki will be on test wikis and MediaWiki.org from 1 November. It will be on non-Wikipedia wikis and some Wikipedias from 2 November. It will be on all wikis from 3 November (calendar).
  • The maps dialog in VisualEditor now has some help texts. [20]
  • It is now possible to select the language of a Kartographer map in VisualEditor via a dropdown menu. [21]
  • It is now possible to add a caption to a Kartographer map in VisualEditor. [22]
  • It is now possible to hide the frame of a Kartographer map in VisualEditor. [23]

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

MediaWiki message delivery 21:15, 31 October 2022 (UTC)

Size of braces by {{brace2}}

Latest comment: 2 years ago4 comments4 people in discussion

Why are the braces produced by the template {{brace2}} displayed smaller in the main namespace (see e.g. here) than in the page namespace (see e.g. here)? It must be quite a new thing, they used to be displayed the same. -- Jan Kameníček (talk) 22:52, 31 October 2022 (UTC)

The same thing is happening with images found within tables. See Page:St. Nicholas (serial) (IA stnicholasserial321dodg).pdf/133 and transcluded St. Nicholas/Volume 32/Number 1/Advertisements/Back/Stamps, etc..--RaboKarbakian (talk) 01:08, 1 November 2022 (UTC)
looks like a side effect of this:
MediaWiki:Gadget-PageNumbers-core.css
l. 98 and 100
. Zdzislaw (talk) 20:10, 1 November 2022 (UTC)
This is affecting some images within tables (but not all, for some confounding reason). {{brace2}} uses math markup to create the brace, which in most people's browsers is going to end up rendered as a PNG image, which means it's affected by this when inside a table (which braces very often are). I can maybe hack up a workaround for {{brace2}} but a real fix that takes care of general images escapes me just at the moment.
The lines of CSS Zdzislaw point to are indeed the proximate cause. They're there to prevent poor image size specifications from causing the image to exceed the width of the view port (always visible horizontal scrollbar, particularly annoying on mobile). This is pretty standard for websites, especially with user-generated content, and works well. What's biting us here is the nightmare that is HTML table layout, where web browsers have several decades worth of hacky special-casing and guesswork—different for every browser engine—and very little in the way of standardisation. For some arcane reason, the browser is deciding that the width of the container (table cell) in which the image sits is tiny; and since our global style sets the image's max-width to 100% (of that container) the image shrinks to fit within it even if the image has an explicit pixel width specified.
@Inductiveload: If you have any bright ideas… Xover (talk) 21:00, 1 November 2022 (UTC)

PD-old-X, PD-anon-X-1996, and PD-posthumous-X categories

Latest comment: 2 years ago7 comments3 people in discussion

Hi everyone! I have been working on migrating the more complicated license templates to Lua (see Module:PD), and as part of that, I'd like to take a look at how we're bucketing works based on time since author's death/time since publication. Currently, we're dividing works as follows:

  • Category:PD-old: categories for works whose author died over 25, 30, 50, 60, 70, 75, 80, 95, 96, 99, 100 years ago.
  • Category:PD-anon-1996: categories for anonymous works published over 50, 60, 70, 80 years ago. (Works published over 95 years ago qualify for Category:PD-anon-US without needing to worry about the URAA.)
  • Category:PD-posthumous: categories for posthumous works published over 25, 50, 60, 70, 99 years ago.

What I want to know is: what is the purpose of this categorization? Do we feel like the current breakdown is serving that purpose? It's a lot easier to change the buckets in Lua than it is with the current setup where you'd have to create new templates for each bucket, so this seems like a good time to check in and see if there's anything that should change. I personally don't have a great sense of what we're using the categories for, so I would really appreciate input from people who know why we have these categories and/or use these categories for a particular purpose. —CalendulaAsteraceae (talk • contribs) 00:56, 16 October 2022 (UTC)

My general thinking is that ideally we have works / authors mapped to these categories (it would be interesting if the death dates for authors could be automatically driven from wikidata, and the publication dates as well as so that entering author and publication date would generate the license template) and then we can have countries mapped to these categories as well (e.g. public domain works / authors in India are set X of categories, public domain works / authors in the UK are set Y of categories). I don't know the value of whether these should be overlapping (so 100 years is a subset of 50) are not. MarkLSteadman (talk) 14:52, 17 October 2022 (UTC)
One possibility is building an infobox listing this metadata and have it expand to a full list of countries where a work is PD. (A major digression: It also would be nice to create categories about works published in country / city X, so if you want to find works from Tokyo or Mumbai that would be possible as well) MarkLSteadman (talk) 16:13, 17 October 2022 (UTC)
One use I can think of is when we become aware that a copyright law somewhere has changed (e.g. several countries have historically changed pma. term durations by a decade or three) and we need to go looking for works affected by it. But a much better approach for that would be to query Wikidata with a cutoff (or a low—high bound), so perhaps rather approached by having tracking cats for texts that lack the requisite data in Wikidata (so we can go backfill it)? Xover (talk) 15:54, 17 October 2022 (UTC)
@MarkLSteadman, @Xover: Wikidata queries do sound like a more robust way to handle things! When it comes to what data we'd want to have in Wikidata, I can think of the following:
  • author (anonymous, work-for-hire)
  • author's death date
  • publication date
  • whether the work was published posthumously (derive from death date + publication?)
  • where the work was originally published
  • country-specific stuff like Soviet rehabilitation
  • work type (relevant for e.g. musical recordings)
  • whether the work is PD-URAA (complicated but probably in principle possible to derive?)
—CalendulaAsteraceae (talk • contribs) 03:40, 2 November 2022 (UTC)
For nonrenewal / URAA / no notice etc. cases we can rely on manual labeling in wikidata or templates if needed. MarkLSteadman (talk) 03:50, 2 November 2022 (UTC)
@MarkLSteadman: good point, no need to overcomplicate! Hmm, I don't have a lot of experience with Wikidata. What would it take to set this up? And how does querying Wikidata work? —CalendulaAsteraceae (talk • contribs) 06:14, 2 November 2022 (UTC)

Titles of Editions: Ned Farmer

Latest comment: 2 years ago5 comments2 people in discussion

I recently created:

Index:A Selection of Original Songs, Scraps, Etc., by Ned Farmer (1st ed.).djvu

and transcluded it as:

A Selection of Original Songs, Scraps, Etc., by Ned Farmer

I have now created:

Index:A Selection of Original Songs, Scraps, Etc., by Ned Farmer (3rd ed.).djvu

However, the third edition is called "Ned Farmer's Scrap Book" on its title page. It is subtitled "Being a Selection of Poems, Songs, Scraps, Etc. Etc. Enlarged and Revised."

(The 1st ed. is called "Ned Farmer's Scrap Book" on its cover and page headers, but not its title page).

My questions are:

  1. Should the first edition have its edition number as part of its page name (with the existing page as a disambiguation)?
  2. How should the pages transcluding the third edition be named?
  3. Should the index pages, and djvu file of the third edition be renamed?

I'll be working, on and off, on the 3rd ed. so please drop a note on my talk page before making any moves, so as not to edit conflict. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:24, 29 October 2022 (UTC)

Ad points 1) and 2): I would add that the 1st edition seems to have different titles on the cover ("Ned Farmer's Scrap Book", which is the same as the title of the 3rd ed.) and on the title page ("A Selection of Original Songs, Scraps, Etc., by Ned Farmer"). If you decide for the title from the title page for the first edition, then the Wikisource pages of the two editions will have different names and there is no need to disambiguate them. If you choose to have both titles the same (i.e. "Ned Farmer's Scrap Book"), they should be disambiguated by the publication year, not by the edition number. I personally prefer the first option, but would not object against the other either.
Ad point 3): There is no need to rename index page and the djvu file. --Jan Kameníček (talk) 14:47, 29 October 2022 (UTC)
Then what happens if it turns out that the 2nd ed. was also published in 1846, or in 1863, or a fourth in 1863? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:28, 29 October 2022 (UTC)
This happens quite rarely, so I would solve such a problem only if and after it appears :-) E.g. we could add the number of the edition to the year in the disambiguating brackets in such a case, or maybe we would find another solution depending on the situation. It would still be much easier than using editions for disambiguating purposes generally, because we would have to deal with problems like deciding if it is e.g. a second edition of a book or a second reprint, not speaking of a second reprint of a second edition… and people could easily make the numbers wrong by counting some reprints as editions. Years are generally much easier and rare cases when two editions are issued within one year can be solved individually. But that is what I think, you can also wait for more opinions. --Jan Kameníček (talk) 18:15, 29 October 2022 (UTC)

Anyone else want to chip in? I'm ready to start transcluding this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:49, 4 November 2022 (UTC)

Latest comment: 2 years ago13 comments6 people in discussion

Hi all,

This is a kind of straw poll of the community to check the feasibility of a potential technical change that will have some advantages, but will require some user-visible / contributor-affecting changes to how we do things. I'm interested in feedback on whether the community would find this approach acceptable, or, obviously, any other good ideas.

We have the system for dynamic layouts that 1) gives better formatting and layout to our texts at a macro level, 2) lets readers (even non-logged in visitors) control certain aspects to their preference (which layout; whether to use serif fonts; whether to show page numbers; etc.). This is implemented through a JavaScript Gadget (MediaWiki:Gadget-PageNumbers.js) that currently works by wrapping the whole rendered content area (not the MediaWiki chrome, just the bits users can edit directly) in a couple of extra HTML containers, and adding CSS styling to them. Each distinct selectable layout is at heart just a set of CSS style rules. Because our texts contain certain elements that should not be subjected to these layout rules (the header, maintenance templates, authority control, license tags, etc.), the Gadget has to identify these and hoist them out of the layout containers. That is, it is guessing what parts of the page is part of the text and what parts are something else.

This approach has all sorts of problems. Wrapping with the extra elements after the page has been rendered forces the browser to relayout the page. Then hoisting the elements out of the layout containers causes another relayout. Each of these degrade the page load performance measurably, and sometimes causes items to "jump around" on the page. And perhaps worse, moving elements around in the DOM may divorce them from their own TemplateStyles, making complicated and obscure special-casing necessary. It also has limitations, like making the layout definitions hard to edit and having to always apply them late in rendering, again potentially causing page elements to "jump around".

Inductiveload has put a lot of effort into making this system as robust as it can probably get under the current limitations, but it still causes problems regularly.

I've expended a lot of thought on this seemingly intractable problem over the years, and now I think possibly I've hit on an alternate approach that has the potential to solve most of these issues. If instead of wrapping the content in HTML containers (nested/tree structure) we insert sibling elements that represent the left margin, main content area, and right margin, and then use CSS Grid to lay them out at the macro level. And then instead of doing this with JavaScript after page load, we use {{header}} to insert the start tag for the main content area and a new {{footer}} template to insert the end tag. This would eliminate all the repaints, obviate the need to move elements around in the DOM, and do the core of the layout functionality using HTML and CSS (robust, predictable, handled by the web browser) instead of coding it ourselves. It might also let us more easily serve each layout as a distinct stylesheet, serve any suggested default layout at page load time, and make it easier to experiment with and customise layouts.

The big downside to this is that it requires us to place an explicit {{footer}} template in the right place on every single text, where today the footer is generated automatically by a different JavaScript Gadget. We can backfill such a footer to existing pages using various forms of automation (not 100%, I don't think, so we'll need to have a maintenance queue for this), but going forward everyone will have to remember to add it as a required element just like {{header}}.

I'm not sure this approach will work, and prototyping it is a relatively big job, so before I sink any more time into it I'd like to hear what the community thinks. Would having to add a {{footer}} to every page be too tedious? Would it be too error-prone? Any other thoughts? Xover (talk) 09:37, 16 October 2022 (UTC)

Phone-posting a transient thought: maybe there's scope for having the Wikisource extension (which we did not have when header templates or PageNumbers.js were first created) could be used to inject an appropriate MediaWiki: template page at the end of mainspace pages (perhaps controlled by the presence of the header templates or something similar). Inductiveload—talk/contribs 12:01, 16 October 2022 (UTC)
@Inductiveload: That's an idea. @Tpt/@Sohom data/@Samwilson: Does that sound feasible? If Extension:Wikisource can transclude something like MediaWiki:wikisource-endofpage-template at the end of #mw-content-text, we could put in </div> to end up with a coherent DOM (having opened the div in the header). Being able to selectively trigger the behaviour from wikicode somehow would be even better. A magic word maybe? Some way we could have {{header}} spit out the opening tag or tags, and then ask Extension:Wikisource to spit out the closing tag or tags. Xover (talk) 12:36, 16 October 2022 (UTC)
@Xover: Which namespaces does this impact? I was considering at some point previously if overloading 
<noinclude>...</noinclude>
was the best way of doing complicated Page: headers and footers, compared to a more JOSN based approach would be used, where the header/content/footer WHERE actually seperate fields. :) —unsigned comment by ShakespeareFan00 (talk) 15:51, 16 October 2022‎ (UTC).
@ShakespeareFan00: The above is all about mainspace. The issue of header/footer in Page: is orthogonal, and actually more complicated to implement (well, or I think so anyway, but I'm not very familiar with that area so I could be wrong). Xover (talk) 14:09, 16 October 2022 (UTC)
Does that sound feasible? If Extension:Wikisource can transclude something like MediaWiki:wikisource-endofpage-template at the end of #mw-content-text, we could put in </div> to end up with a coherent DOM (having opened the div in the header). It's doable with the current MediaWiki parser but not with Parsoid that prevents opened tags without matching closing tags. Parsoid is already used in a lot of places so it will create a lot of problems. Tpt (talk) 09:47, 1 November 2022 (UTC)
@Tpt: In other words, if we're to do this we will in practice have to do it by a manually placed "footer" or "end of content" template until some hypothetical future where Parsoid caters for such a use case
@Matma Rex: Can you advice on how/where/who to start a conversation about this need? The Wikisourcen depend generally on being able to emit a html start tag (typically a div or span to which we will attach some formatting) in one template and the close tag in a different template. And here we have a variant of this where a template emits a start tag that will have the corresponding end tag emitted by a MediaWiki extension towards the end of #mw-content-text. If we're ever to retire the old parser we've got to figure out some way for Parsoid to accommodate this kind of use case, and I have no idea of how to even approach this.
There are also, I think, a couple of Phabs that boil down to needing Parsoid implementations of the Proofread Page extension tags (<pages … /> and <pagelist … />), and the header/body/footer divided content of wikipages in the Page: namespace (though maybe that's more VE than Parsoid?).
So maybe there's a bigger conversation about "Wikisource ❤️ Parsoid (and VE)" that needs to happen? Who needs to be involved in that? What's the venue? How can I—poor dumb non-+2'er that I am—help facilitate that?
In other words: help?
CC for info/interest/input: @Samwilson, @Sohom data, @Inductiveload. Xover (talk) 07:25, 2 November 2022 (UTC)
If you want to start a conversation about Parsoid and Wikisource, I'd start by emailing the Wikitech-l mailing list, and if you get no reply, reaching out directly to the people working on Parsoid.
For this particular idea, let me just say that I advise against having a critical interface element generated in half by an extension, and in half by wikitext. It seems like a good way to end up with something you can never change again without breaking the whole site for a while, because you can't synchronize changes in wikitext and changes in the extension.
But if you want to do it anyway, maybe you don't need to do anything at all for a prototype to work (if you only need to add some closing tags): any unclosed HTML tags in wikitext are automatically closed at the end of the page content (by running the HTML through the HTML5 parsing and then serialization algorithms, which replaced Tidy some years ago as you might remember). You will get a Linter warning about this, but those can be ignored…
Or if you want to do it in an extension, then there's probably a way to modify the wikitext before it is handed to the parser (whether current parser or Parsoid, this should work in the same way). The ProofreadPage extension already does this to book pages ("Page:" namespace) to add some <templatestyles> to them out of thin air [24]. I'm not sure how you'd do it for pages that your extension doesn't control, but I'm sure there's a way. (If nothing else works, you could add a new content model, perhaps "proofread-work", and change the main namespace pages to use it.)
(The key here is that you'd add the closing tags before parsing wikitext, not after. Adding them after actually wouldn't work in the current parser either, due to the same HTML5 parsing / serialization I mentioned, because your tags will already have been closed.)
Still, I suggest just adding {{footer}} with a bot. At least everyone understands how that works. Matma Rex (talk) 03:57, 3 November 2022 (UTC)
@Matma Rex: Thanks!
From this I take that for the immediate case adding the </div> from the extension is essentially a non-starter, so we're back to the question of whether the community will find it excessively onerous to manually add a {{footer}} (or whatever) template like they add {{header}} today.
But there's still a bunch of issues where "won't work with Parsoid" crops up. So perhaps raising this on wikitech-l would be worthwhile? It's not sustainable to have two parser stacks (editors and all) indefinitely, so sooner or later Wikisource will be faced with a looming deadline there. The sooner "someone who understands Wikisource" starts talking to "someone who understands Parsoid" the more time there'll be to fix things, and the more scope there'll be for finding pragmatic solutions. Xover (talk) 13:29, 3 November 2022 (UTC)
Yes, it's definitely worthwhile. Matma Rex (talk) 16:18, 3 November 2022 (UTC)
I am a little unclear about how how we are thinking about handling 1. Transcluded content footers (e.g. the rule with printer information we sometime see on the last page of a text) 2. Nontranscluded content footers (I am mainly thinking about footnotes / endnotes here, stuff which isn't at that particular place in the original text, but is part of the work) and 3. Non content metadata like license, or authority control information. I can see the value of demarcating 1 from 2, I also don't know whether there is a desire to allow control over the references formatting based on the layout, but if we want to have different handling for cases like 2 where we moved the footnotes around, we might need to have manual invocation anyways to distinguish from case 1. MarkLSteadman (talk) 19:07, 3 November 2022 (UTC)
I'm not entirely sure I follow you, but to maybe answer some parts of it… The hypothetical {{footer}} template would be placed after all transcluded content—including {{smallrefs}}–but before {{authority control}} and the license template. All content between the {{header}} and {{footer}} would be technically possible to style, but our layouts would not necessarily style all parts. One example of what might be possible with this approach is to make certain wide images full bleed in narrow layouts like Layout 2; that is, let the image stretch the full available width even if the surrounding text is constrained to a reasonable line length for reading. For things like maps this would improve legibility immensely. It should also be possible to do the same for the footnotes: let them use the full width even if body text is constrained. Whether and how to style such elements would be a matter for policy, consensus, and preference of course. Xover (talk) 19:31, 3 November 2022 (UTC)
Just to note: based on the very limited feedback in this thread, I have no idea whether the community would find this approach acceptable or not. I would very much appreciate hearing whether you would find the mandatory use of a {{footer}} template (like {{header}}) a) acceptable, b) unacceptable, c) "don't care, stop bugging me", d) "other". It'd be an "empty" template, so no need to fiddle parameters and such, but you would need to add it to the end of every mainspace page (or have a bot come add it afterwards) so it is one more thing to keep track of. Xover (talk) 08:40, 13 November 2022 (UTC)

Allowing for fair use for non-PD-USGov court briefs

Latest comment: 2 years ago22 comments9 people in discussion

In looking around copyright-related court cases, I came upon White v. West Publishing Corporation (which I have now scan-backed). It finds that the uploading of court briefs, in their entirety, to the proprietary, for-profit databases of defendants West Pub’g Corp. and Reed Elsevier, Inc.—even where, as in this case, the briefs were registered in the Copyright Office. There are many briefs relating to court cases, the cases of which are hosted here and which reference such briefs, and it would be very nice to be able to host these briefs. The concerns regarding the first and fourth factors, at issue in White, are less present for the cases to which I make reference. Generally speaking, the briefs hosted would be in reference to major court cases—ones already hosted here—rather than for active court cases (as was Beer in White). In addition, commerciality concerns are less prevalent on Wikisource than on West or LexisNexis. TE(æ)A,ea. (talk) 01:04, 18 October 2022 (UTC)

Because of the reuse allowed for all of our hosted materials, we cannot allow "fair use" for non-PD materials—regardless of their merits and utility otherwise. Beeswaxcandle (talk) 04:37, 19 October 2022 (UTC)
we could have a fair use limited exemption policy for court briefs, but i doubt you could find a consensus. the free software ideology is strong. --Slowking4 亞 Farmbrough's revenge 13:30, 11 November 2022 (UTC)
  • Slowking4: I made this proposal not because I thought free-wheeling fair-use exceptions are beneficial, but because of White’s very generous grant of fair use to court briefs. Of course, there isn’t a fair use policy on enWS now, which is why I made the request. Just like all of our works, reuse is dependent on following copyright law—especially in regards to foreign copyright law, which enWS generally ignores. Similarly, the reuse of fair-use court briefs would also have to be in line with copyright law—it’s just that this time, it would be U.S. fair use standards. TE(æ)A,ea. (talk) 13:57, 11 November 2022 (UTC)
we have a community that disdains fair use as non free, i.e. the right to profit is more important than the dissemination of knowledge. fair use is not a copyright violation: all the federal judges say so, but ease of use of open knowledge from behind the paywall does not matter. as we know, references in open wikipedia gets cited in briefs more often in Irish courts. but, any fair use is characterized as free wheeling. so it goes. --Slowking4 亞 Farmbrough's revenge 15:14, 11 November 2022 (UTC)
 Oppose, same reasoning as Beeswaxcandle —Beleg Tâl (talk) 19:30, 11 November 2022 (UTC)
 Oppose; Wikimedia does not permit Wikisources to have fair use materials. In addition, I'm not sure your analogy with West works perfectly; there's a difference between WestLaw posting Action Comics #1 for a limited audience of lawyers as a part of legal documents, and us posting the same thing here, even if we file it as part of the court case it was part of.--Prosfilaes (talk) 21:40, 11 November 2022 (UTC)
  • Prosfilaes: Actually, WMF does allow WS EDPs, and they are listed here. It was after seeing this list that I first thought that there could be a enWS EDP such as this one. As to your example, the briefs at issue in White had USCO registration numbers, and it was still considered fair use to reupload them. TE(æ)A,ea. (talk) 21:48, 11 November 2022 (UTC)
Strong  Oppose — please keep this a totally free website. While the WMF might not explicitly prohibit Wikisources from allowing fair use content or having an EDP, I wouldn't support having one. Maybe it's up to us to make that call, I'll grant that possibility, but I don't think the community at large (or I myself) can in good faith risk the purity of this project. PseudoSkull (talk) 00:03, 12 November 2022 (UTC)
speaking of purity, you realize that english wikisource has local versions of works PD in the US, but not EU ? --Slowking4 亞 Farmbrough's revenge 18:02, 13 November 2022 (UTC)
Having worked on countless briefs and motions, I would generally note that almost every brief I have ever seen (with the exception of a few written by non-lawyers that really were "creative works of fiction") basically regurgitates the law, with lengthy quotes from statutes, public hearings, and previous court decisions (all already public domain), and sections of arguments boldly plagiarized from previous filings by other lawyers. That is practically the way of the world. That said, there is some originality in the recitation of many cases, so I would tend to agree that we should not include a brief filed by a private party unless it can pretty clearly be demonstrated that every part of that brief is uncopyrightable for some reason or other. I would also note that briefs filed by the U.S. government are always and automatically in the public domain, and briefs filed by U.S. state governments are probably also automatically in the public domain. BD2412 T 08:32, 14 November 2022 (UTC)
  •  Oppose I am not certain how we can claim "fair use" when we are just regurgitating another's work verbatim without some context around its re-use. That is not fair use, that is just copying. If it was incorporated into some other analysis that is fair use, and that is not us, that is wikibooks and wikiversity. — billinghurst sDrewth 23:06, 17 November 2022 (UTC)
"SCENARIO 1: A professor copies one article from a periodical for distribution to the class. ALLOWED? Yes. Distribution of multiple copies for classroom use is fair use. " [25] --Slowking4 亞 Farmbrough's revenge 02:17, 18 November 2022 (UTC)
SCENARIO 2 : Person photocopies hundreds of random articles and leaves them on a pile on a street corner for anyone to take. Not fair use. — billinghurst sDrewth 05:02, 18 November 2022 (UTC)
yeah, welcome to the precautionary librarians, they say "probably", as you don’t really know, until you get into court. see also the running list of cases, "copying a post from one social networking platform to another is fair use" Monsarrat v. Newman & "photographs posted on social media in a news article to illustrate the subject of the photograph is fair use when accompanied by commentary." McGucken v. Pub Ocean Ltd. [26] --Slowking4 亞 Farmbrough's revenge 00:25, 21 November 2022 (UTC)
@Slowking4: I see that your examples are all cases of "use" for a purpose, which I don't see in our reproducing for no clear use. Someone's reproduction here is not for illustrative use with commentary at this site (as that is not our purpose), it is a "just because". We are not demonstrating that we have the right to make a copy ... copyright! MSM and some social media is a place of commentary and opinion and easier to demonstrate a fair use in support of that commentary and opinion. — billinghurst sDrewth 03:41, 21 November 2022 (UTC)
 Oppose. This proposal does not even seem to fit c:Commons:De minimis. May we have a policy or guideline on de minimis?--Jusjih (talk) 05:26, 18 November 2022 (UTC)
you pointed to the commons one. this is yet another US federal judge case law interpretation. Ets-Hokin v. Skyy Spirits, Inc. - but commons is idiosyncratic in their interpretation, i.e. Mueller Report - [27] but [28] . --Slowking4 亞 Farmbrough's revenge 00:12, 21 November 2022 (UTC)
If you wish to criticise Commons's decisions, then it is better to do it over there, rather than here. Personally, I think that two discussions that you reference are consistent with each other, and the actions in the second discussion reflect the conversation and differentiaton in the first. — billinghurst sDrewth 03:45, 21 November 2022 (UTC)
i’m not criticising commons, just pointing out they have made legal distinctions not founded on any case law, such as "a page of a document is de minimus, but that individual page is not". at least claiming fair use for that example is coherent. --Slowking4 亞 Farmbrough's revenge 13:28, 21 November 2022 (UTC)
There are zillion of those distinctions based on interpretations at Commons, as there is no case law, and as such it becomes our determiners of how they do things around there. Same here. Same at Wikipedias. Otherwise, not certain of your point. That you think something is idiosyncratic at Commons, and you mention it here is, a criticism, and not helpful to the discussion here. — billinghurst sDrewth 05:22, 22 November 2022 (UTC)
we could adopt some consistent reasoning, that solves the perennial issue of public domain documents, with copyrighted exhibits, or commentaries; but we choose not to, which means researchers will go to other websites, or build their own - such is your walled garden. and the star contributors there started on wiki, but left for friendlier communities: the culture (including purity culture) is the primary limiting factor to editor retention. --Slowking4 亞 Farmbrough's revenge 04:00, 24 November 2022 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2022-10&oldid=14663378"