Wikisource:Scriptorium/Archives/2021-07

From Wikisource
Jump to navigation Jump to search
Warning Please do not post any new comments on this page.
This is a discussion archive first created in , although the comments contained were likely posted before and after this date.
See current discussion or the archives index.

Over 2000 pages processed in the June Monthly Challenge

The June Monthly Challenge is now complete and the numbers are in: 2051 pages were processed (marked no text, proofread or validated), which is again over the tentative goal of 2000. The following works were fully proofread:

And the following validated:

As well as quite some progress on other volumes in the challenge. New works in July include:

Tech News: 2021-27

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

Tech News

  • The next issue of Tech News will be sent out on 19 July.

Recent changes

  • AutoWikiBrowser is a tool to make repetitive tasks easier. It now uses JSON. Wikipedia:AutoWikiBrowser/CheckPage has moved to Wikipedia:AutoWikiBrowser/CheckPageJSON and Wikipedia:AutoWikiBrowser/Config. Wikipedia:AutoWikiBrowser/CheckPage/Version has moved to Wikipedia:AutoWikiBrowser/CheckPage/VersionJSON. The tool will eventually be configured on the wiki so that you don't have to wait until the new version to add templates or regular expression fixes. [1]

Problems

  • InternetArchiveBot helps saving online sources on some wikis. It adds them to Wayback Machine and links to them there. This is so they don't disappear if the page that was linked to is removed. It currently has a problem with linking to the wrong date when it moves pages from archive.is to web.archive.org. [2]

Changes later this week

  • The tool to find, add and remove templates will be updated. This is to make it easier to find and use the right templates. It will come to the first wikis on 7 July. It will come to more wikis later this year. [3][4]
  • There is no new MediaWiki version this week.

Future changes

  • Some Wikimedia wikis use Flagged Revisions or pending changes. It hides edits from new and unregistered accounts for readers until they have been patrolled. The auto review action in Flagged Revisions will no longer be logged. All old logs of auto-review will be removed. This is because it creates a lot of logs that are not very useful. [5]

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

17:33, 5 July 2021 (UTC)


Comment

  • AWB: We haven't applied controls on its user here to this point. We could consider it pro-actively, or we can live with the status quo (reactive action).

Scan needed of Low Life: A Comedy in One Act (1925) by Mazo de la Roche

This is a call to the community to create a full scan PDF/DJVU of a very rare ~40 page script for a Canadian play first produced in 1925. There currently exists no scan of this anywhere on the Internet to be found. It went into the public domain in the US this year, and has been in the public domain in Canada since 2011. I also can't find anywhere online that I can buy this book.

Here are all the libraries where this text can be found: https://www.worldcat.org/title/low-life/oclc/678885898

In particular, those at the University of Georgia, those who live in New York City with access to the New York Public Library, or those who live in various areas of Ontario or Québec, see if you could upload a scan of this text to Commons? The text will be transcribed at Wikisource once this is done. Please and thank you. PseudoSkull (talk) 17:34, 8 July 2021 (UTC)

maybe we should ping WMNYC [6] for a nypl run [7]. Slowking4 亞 Farmbrough's revenge 22:21, 8 July 2021 (UTC)
These should really go to Wikisource:Requested texts, not here.--Prosfilaes (talk) 09:27, 10 July 2021 (UTC)
Request retracted because I found a seller and I have proceeded to buy a copy. It should arrive within sometime less than a month. Hopefully this will work out. PseudoSkull (talk) 18:38, 11 July 2021 (UTC)

Simplifying the process

I am an old man, who owns many old books. When I die, I doubt if my book collection will be seen as having value by my kids. Some are so rare that they may be lost forever when the kids do the post mortem clear out. I would like to transcribe them to Cy Wikisource, but can't work out how to do so. I have spent £100s of pounds on DjVu, PDF, and other programmes but have only succeeded to upload one book to Wicidestun [8] where the original scan is almost absent. It's great that hundreds of tech savy people have uploaded hundreds of books to the English site. But it would be nice if the Wiki brains could come together to create a way for a person, taught to write with a nib pen, could scan his books in a lesser used language, with ease, on a £30 scanner (before my time runs out!) AlwynapHuw (talk) 03:40, 9 July 2021 (UTC)

I'd really suggest sending them to The Internet Archive, which will scan and upload them for you, or some Welsh library that will do the same. It is a bit of a tricky process, and given its rarity always will be.--Prosfilaes (talk) 09:33, 10 July 2021 (UTC)
yeah, have not found the killer app to make digitization easy. if you use a flatbed scanner, then you will have the fun of collation with a publisher program. if you build a scanner rig, that is expensive; scanner machines are as rare as microfilm readers. we should think about grants for small institutions for scanners, and a paid position for known machines such as Library of Congress, to make digitization easier. Slowking4 亞 Farmbrough's revenge 14:46, 12 July 2021 (UTC)
@AlwynapHuw: If you do end up with a pile of JPGs, the Internet Archive website will probably do a decent job of collating them into a PDF and OCRing them for you. Basically, you have to upload a ZIP of the image and their system is smart enough to do most the rest: https://help.archive.org/hc/en-us/articles/360001820212-How-to-upload-scanned-images-to-make-a-book. This can have reasonable results. If you just have the images, I'll be happy to deal with it for you. Feel free to drop me a message here, on my talk page or by email and we can arrange a way to transfer the files. Inductiveload—talk/contribs 16:27, 12 July 2021 (UTC)

 Comment WikimediaUK could possibly assist, so pinging @Llywelyn2000: as the Wales coordinator, and I have tweeted to Lucy who is CEO of their org. — billinghurst sDrewth 00:39, 13 July 2021 (UTC)

yes, and also their email info@wikimedia.org.uk from https://wikimedia.org.uk/ see also Education/News/May_2019/Education_in_Wales and 2016 GLAM National Library of Wales; 2020 GLAM Wales --Slowking4 亞 Farmbrough's revenge 01:07, 13 July 2021 (UTC)
Hi all. I think this is basically twofold: an appeal for help from experienced Wikisource editors and a suggestion that the process of creating content on Wikisource can / should be simplified. And I agree with both! I'm in touch with @AlwynapHuw:, and have been for quite a few years; Wikimedia UK may also be able to offer reimbursement for software costs and coordinate training on the process itself. I've just uploaded 720 scans of the most important Welsh manuscript here, by the Bodley but have so far failed to get a contact at the Internet Archives so they can pdf. I understand Alwyn's frustration! Llywelyn2000 (talk) 07:11, 13 July 2021 (UTC)
@Llywelyn2000: Uploading to the IA just needs a big ol' ZIP of the images uploading and the PDF process is automatic from there. I did it for you at https://archive.org/details/redbookhergest (you can see the file I uploaded as "GENERIC RAW BOOK ZIP"). The derivation process takes some time, but a PDF and an online BookReader view should drop out eventually.
I also made you a DjVu using some hacked-up script I have: File:Red Book of Hergest - Jesus College MS 111.djvu. It didn't OCR at all (predictably), and I didn't apply any crush factor to it, so it's quite big (~280MB). But it will render an order of magnitude faster than the PDF that the IA will eventually generate. Inductiveload—talk/contribs 10:39, 13 July 2021 (UTC)
thanks for helping this editor. systemically, we need a UX cross project redesign to get works done (indexing pain point) and we need to think about upstream digitization issues, to lower barriers to digitize. process does not scale, but a landing page or GLAM response team / welcome wagon could work. Slowking4 亞 Farmbrough's revenge 11:35, 13 July 2021 (UTC)
I could not agree more. The process from book through scans, upload, Index creation to proofreading is atrociously byzantine and unreasonably (unacceptably?) hard for users who just want to get stuck in. I should follow through on Wikiproject Scans. I am also chunking though backend work on various projects that will hopefully make it easier in future. Inductiveload—talk/contribs 12:28, 13 July 2021 (UTC)
@Inductiveload: Many, MANY thanks for your work on this! I may contact you again on this, if I may! ((Ping|Slowking4)) - Thanks too for the ideas on lowering the barriers and future work! Best regards to all! Llywelyn2000 (talk) 13:14, 13 July 2021 (UTC)
@Llywelyn2000: You're very welcome. My door is always open! Feel free to ask for anything - just drop me a note and we can work it out, whatever it is. Inductiveload—talk/contribs 14:09, 13 July 2021 (UTC)
The "Internet Archive" route no longer works. I am not tech savvy enough to know what is possible, but would like a means to upload my scans to somewhere in the Wikiverse where the necessary conversion processes are done in "one step", or otherwise a "one step" programme that I can download that does the same on my computer. (Hope this makes sense!) AlwynapHuw (talk) 02:15, 14 July 2021 (UTC)
@AlwynapHuw: The "Internet Archive" route no longer works. It does still work: for example, Llywelyn2000's book has been generated now: https://archive.org/details/redbookhergest. True, the IA no long generates DjVu, but it does generate PDF, which can also be used at WS. But it's still a two step process: upload images to the IA and wait for conversion, then transfer to Commons with https://ia-upload.wmcloud.org/. Due to the need for metadata and the slow process of generation, it's jolly tricky job to integrate all that into a single tool, though I do still dream that it might be possible somehow! Inductiveload—talk/contribs 09:07, 14 July 2021 (UTC)
yeah, i put an IA upload wizard on the wishlist, (we need jp2 support also) but OCR won out. maybe next year. --Slowking4 亞 Farmbrough's revenge 02:35, 15 July 2021 (UTC)

__EXPECTED_UNCONNECTED_PAGE__ behaviour switch coming in v.14

phabricator:T97577—[Story] Magic Word __EXPECTED_UNCONNECTED_PAGE__ to exclude pages from Special:UnconnectedPages

Looks like next week will see the rollout of the magic word/behaviour switch (mw:Help:Magic words#Behavior switches) that will enable us to exclude pages listing at special:UnconnectedPages.

If is pretty evident that labelling a single page will exclude it, though less evident how we would label to have it cascade, either incorporating either a rootpagename or a cat, or just excluding the subpages to the rootpagename or cat. I have asked the question of Ladsgroup.

This is going to be help to us to enable the delisting of chapters of novels, certain low-level categories, etc. We will need to think about some guidance to ourselves in where and how we should be applying this. For example what do we want listed NOVEL YesY, subpages of NOVEL N. — billinghurst sDrewth 01:11, 13 July 2021 (UTC)

@Billinghurst: Awesome! This should really help.
I haven't followed that task, but from a quick scan now it looks like it will not be possible at the magic word level to do any kind of cascade or inheritance. However, since the magic word can be applied with a template there are a lot of cases we can automate (e.g. {{header}} can apply the magic word when it's on a subpage), and a lot of deeply-nested-categories cases should be feasible to bot add it to.
What I'm a little more worried about is how we would apply it by default from a template, but then have the ability to override it on a page-by-page basis. For example, collections where the subpages are standalone works (short stories, fairytales, scholarly articles, etc.). This is definitely going to take some thinking. Xover (talk) 08:10, 13 July 2021 (UTC)
@Billinghurst, @Xover: What's an example of a page that is "validly unconnected"? Presumably nearly all mainspace pages should be connected via an author/portal page and subpages should be linted to from the relevant TOC and almost certainly from the previous and next pages? Derp this is about Wikidata connections. Pardon the expulsion of methane-rich, caffeine-poor brain gas. Inductiveload—talk/contribs 10:03, 13 July 2021 (UTC)
@Xover: I think if {{header}} sets the "expected unconnected" flag on all subpages by default, then we can add an override like expect_wikidata = yes if the subpage should get a WD item (internally, this supresses the __EXPECTED_UNCONNECTED_PAGE__ magic word generation. For templates like {{EB1911}} where all articles have a WD connection, those templates can set that for all their pages. Inductiveload—talk/contribs 10:29, 13 July 2021 (UTC)
I think that we should battle on for something that properly cascades. Manually applying something like this to 37 chapters of a novel is just bloody ludicrous. — billinghurst sDrewth 13:22, 14 July 2021 (UTC)
@Billinghurst: Something that may (may) help here is the up-and-coming ProofreadPage Lua library (to be added as part of phab:T281195): that will allow direct access to data fields stored in the Index page. If one of those were a boolean "subpages should be connected", then perhaps it can be applied automatically on the transcluding pages.
Regardless, a default "subpages are not connected" is probably a fair default in nearly all cases. Exceptions generally have a special template like {{EB1911}}, or, more properly {{collective work header}}, and the stragglers like short stories are then the only things to worry about.
Refinement: for an approach with fewer false-negatives: only auto-set __EXPECTED_UNCONNECTED_PAGE__ on subpages that look like "Chapter nn", and leave the rest idling in Special:UnconnectedPages for manual processing of some sort (even if that processing is setting a field in the index). Inductiveload—talk/contribs 14:35, 14 July 2021 (UTC)

Community Tech Wikisource Satisfaction survey

Apparently, this has been posted on Wikisource-l, but I haven't seen it advertised on-wiki: Wikisource:Wikisource Satisfaction Survey 2021.

@SGill (WMF), @NRodriguez (WMF): (or whoever is in charge) can I suggest that you use one of the mass message delivery mechanisms to get these kind of messages to the community? Engagement with the enWS community, at least, by CommTech seems distinctly lacking recently. Which is particularly ironic for the CommTech team!

@Billinghurst: one for a watchlist announcement? Inductiveload—talk/contribs 07:08, 7 July 2021 (UTC)

@Inductiveload: There was a GlobalNotice (the same facility used for the fundraising stuff) on at least one non-enWS Wikisource, so they may have been relying on that to get the word out. Xover (talk) 07:29, 7 July 2021 (UTC)
Hmm, maybe because I have the MediaWiki:Gadget-HideFundraisingNotice.js gadget enabled? Maybe that needs a tweak. Anyway, in case anyone else missed it entirely... there it is! Inductiveload—talk/contribs 07:48, 7 July 2021 (UTC)
I don't have that enabled (it's opt-in and used by less than 7.5% of active users) and I didn't see the notice here. Xover (talk) 08:14, 7 July 2021 (UTC)
@Inductiveload@Xover@Billinghurst Hello, thanks for this note. we are working on a mass message to be sent out soon. Pinging with an update because I did not want to leave you thinking this went unread. Best, NRodriguez (WMF) (talk) 20:33, 12 July 2021 (UTC)
@Inductiveload, @Xover, @Billinghurst: I just wanted to provide an update on MassMessage. There is an abuse filter that is stopping us from sending the message as it contains links to google forms. We are hoping to find a solution to this soon enough. --SGill (WMF) (talk) 09:58, 14 July 2021 (UTC)
@SGill (WMF): If it's an enWS Abuse filter, we can fix that locally, all you have to do is ask. If it's a global thing, surely just linking to Wikisource:Wikisource Satisfaction Survey 2021 in the message would do in the meantime? Inductiveload—talk/contribs 10:01, 14 July 2021 (UTC)
@SGill (WMF): On a general note, Google Docs is problematic for many contributors (for various reasons) so please try to avoid depending on it. I realise that for this specific kind of thing there aren't any great alternatives, but there's a general trend where the WMF is putting more and more stuff in non-wiki tools where they are in various ways inaccessible to the community. For example, many technical decision processes lately have been documented exclusively in private Google Docs documents, and only shared with the community when explicitly requested and after the decisions were locked in. This makes it impossible for the community to influence decisions before they become too expensive to change, and it hides the process and background for decisions that should be documented on-wiki for the future.
Again, I know there aren't any realistic alternatives for fill-in-the-form feedback gathering in the here and now, so this isn't really criticism so much as a plea to keep the issue in mind for other instances where this pops up. Xover (talk) 13:16, 14 July 2021 (UTC)
@Inductiveload, @Xover: It's a global thing and we should be able to solve it pretty soon. I agree with you Xover that we need a better alternative to Google forms and we are going to explore other options and also have the form in more languages, in the future! Thank you for your comments. We are definitely keeping this in mind. --SGill (WMF) (talk) 08:11, 15 July 2021 (UTC)

Wikisource Satisfaction Survey 2021

Hello!

Apologies for writing in English. Please help translate to your language

In the past year, there has been a lot of changes to Wikisource features and tools. This was done by the Community Tech team at the Wikimedia Foundation, grantees funded by the Foundation or through projects like Google Summer of Code. We would like to understand what you feel about the changes. Tell us what you think about such tools as the Wikisource Pagelist Widget or the new Ebook Export tool.

Take the survey in English, French, Spanish, Polish, Hindi or Punjabi. The deadline is 25th July 2021.

This survey will be conducted via a third-party service, which may subject it to additional terms. For more information on privacy and data-handling, see the survey privacy statement (English, Spanish, French, Polish, Hindi and Punjabi).

If you prefer to send your answers via email, copy the text of the survey and send to sgill@wikimedia.org.

If you have any questions or feedback about the survey, write to me at sgill@wikimedia.org.

Thank you! SGill (WMF) 22:30, 16 July 2021 (UTC)

Index:A hairdresser's experience in high life.djvu

All pages except 19 and 20 have been validated, so if someone could validate those pages that'd be great. The local scan has some illegible words, but I found another scan of the same edition where the words are legible. —CalendulaAsteraceae (talk | contribs) 06:53, 18 July 2021 (UTC)

@CalendulaAsteraceae: Done Xover (talk) 08:04, 18 July 2021 (UTC)
@Xover: Thank you! —CalendulaAsteraceae (talk | contribs) 08:06, 18 July 2021 (UTC)

Micromegas

There is a Gutenberg published translation currently at Micromegas, and now a regularly published version at The Works of Voltaire/Volume 3/Micromegas, so a move and dab would be helpful. CYGNIS INSIGNIS 17:22, 19 July 2021 (UTC)

Harper's Weekly Editorials on Carl Schurz and Harper's Weekly Articles on Carl Schurz

The page hierarchy for which the root and sub pages to Harper's Weekly Editorials on Carl Schurz and Harper's Weekly Articles on Carl Schurz is not in the framework for how other works are presented at enWS, especially for articles from periodicals where we have a preferred means, and soe variations to it.

Harper's Weekly Editorials on Carl Schurz
Harper's Weekly Articles on Carl Schurz

In this case we have the subpages presented with an out of scope rootpages and as such they are a collection of excerpts, rather than as works. The listings as presented are suitable as material for author subpages, and once the articles locations is determined, I would say move these two pages to be subpages to [[author:Carl Schurz]

If we follow the expressed preferred periodical hierarchy design they will be either Periodical/Volume/Issue/Article name or Periodical/YYYY/MM/DD. Seeking people's thoughts on what we should be doing.

The easiest interim solution is solely Periodical/Article though that would not be the long term presentation nor allow good article flow. (Ping @Bob Burkhardt: as you have transcribed these pages.) People can review the published structure of the periodical at portal:Harper's Weekly. A quick search does not indicate existing subpages of the work are onsite. — billinghurst sDrewth 08:12, 19 July 2021 (UTC)

I put these up about a decade ago. I have been going through things and making scans more available. How I rename the files has been of lesser concern (in the best case scenario, no renaming takes place, so names are not of concern). Many times I am dealing with very isolated scans from obscure sources, so the names aren't even close to the systematization you allude to. Harper's Weekly seems worthy of more systematic presentation. But again getting source scans for Wikimedia is my main priority, as opposed to bare citations which I think is all I have for many of those items. Thank you for keeping me in the loop on this project. Bob Burkhardt (talk) 13:11, 19 July 2021 (UTC)

Tech News: 2021-29

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 tool to find, add and remove templates was updated. This is to make it easier to find and use the right templates. It was supposed to come to the first wikis on 7 July. It was delayed to 12 July instead. It will come to more wikis later this year. [9][10]
  • Special:UnconnectedPages lists pages that are not connected to Wikidata. This helps you find pages that can be connected to Wikidata items. Some pages should not be connected to Wikidata. You can use the magic word __EXPECTED_UNCONNECTED_PAGE__ on pages that should not be listed on the special page. [11]

Changes later this week

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 20 July. It will be on non-Wikipedia wikis and some Wikipedias from 21 July. It will be on all wikis from 22 July (calendar).

Future changes

  • Advanced item How media is structured in the parser's HTML output will soon change. This can affect bots, gadgets, user scripts and extensions. You can read more. You can test it on Testwiki or Testwiki 2.
  • Advanced item The parameters for how you obtain tokens in the MediaWiki API were changed in 2014. The old way will no longer work from 1 September. Scripts, bots and tools that use the parameters from before the 2014 change need to be updated. You can read more.

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

15:31, 19 July 2021 (UTC)

Wikisource:Scan Lab

Following on from a long-archived, weakly-supported proposal, I have finally put my money where my mouth was and set up Wikisource:Scan Lab for centralising general scan work in a "workshop" type environment.

If you'd like to get involved, you can add yourself to Module:Mass notification/groups/Scan Lab to get alerts when people use {{ping project|Scan Lab}}.

I will also close/archive Wikisource:WikiProject OCR at some point because it's totally moribund, having been largely made obsolete by the OCR tooling we have now had for years. What few OCR tasks that do come up can then fall under Scan Lab's job description. Inductiveload—talk/contribs 13:57, 15 July 2021 (UTC)

Wikisource:WikiProject OCR has now been closed and marked inactive, and a notice added redirecting to the Scan Lab.
@Zhaladshar: (the only other listed member there who has edited in the last 12 years): you may wish to subscribe to the Scan Lab group. Inductiveload—talk/contribs 00:08, 21 July 2021 (UTC)

Wikisource:WikiProject Open Access pages

I reckon that it is time to do something with the pages special:prefixindex/Wikisource:WikiProject Open Access/. I think that we either need to move them into place and update their headers to capture their data, or just delete them. I equivocate between both approaches, and happy to help whatever is the consensus. I am not happy with them sitting like they are in the WS: ns. — billinghurst sDrewth 05:21, 20 July 2021 (UTC)

Category:Pages where template include size is exceeded

I just saw this category for the first time, and I have a page in it. I am pretty sure that when I made the page, that there were no restrictions applied upon it. I looked into the origin of the category, to see if it was a recent thing and it is apparently from 2008 with very strange beginnings (see here).

I can split that page into two, but I am wondering where the documentation is that I missed about this size restriction?--RaboKarbakian (talk) 18:33, 20 July 2021 (UTC)

@RaboKarbakian: It's a MediaWiki issue. See [12] and [13]. TDLR, when all templates are transcluded into the page (the raw wikitext) the page can't be larger than 2MB, or templates start not working. Jarnsax (talk) 21:39, 20 July 2021 (UTC)
Stuff I mentioned in the section below (about block right and hi) (combining templates, using a stylesheet) can help a lot in making pages smaller (which also makes them load faster) ... also, if you edit and then 'preview' the page, the expandable 'parser profiling data' show you where you stand compared to the limits. Jarnsax (talk) 23:12, 20 July 2021 (UTC)
Usually this is caused by one of the evil "dotted table" templates, which produce a face-meltingly large quantity of HTML to achieve it. If that's the issue (you didn't say which page is the issue, so I don't know), I suggest just not using dotted TOCs at all. Inductiveload—talk/contribs 00:04, 21 July 2021 (UTC)

Universal Code of Conduct News – Issue 2

Universal Code of Conduct News
Issue 2, July 2021Read the full newsletter

Welcome to the second issue of Universal Code of Conduct News! This newsletter will help Wikimedians stay involved with the development of the new code and will distribute relevant news, research, and upcoming events related to the UCoC.

If you haven’t already, please remember to subscribe here if you would like to be notified about future editions of the newsletter, and also leave your username here if you’d like to be contacted to help with translations in the future.

  • Enforcement Draft Guidelines Review - Initial meetings of the drafting committee have helped to connect and align key topics on enforcement, while highlighting prior research around existing processes and gaps within our movement. (continue reading)
  • Targets of Harassment Research - To support the drafting committee, the Wikimedia Foundation has conducted a research project focused on experiences of harassment on Wikimedia projects. (continue reading)
  • Functionaries’ Consultation - Since June, Functionaries from across the various wikis have been meeting to discuss what the future will look like in a global context with the UCoC. (continue reading)
  • Roundtable Discussions - The UCoC facilitation team once again, hosted another roundtable discussion, this time for Korean-speaking community members and participants of other ESEAP projects to discuss the enforcement of the UCoC. (continue reading)
  • Early Adoption of UCoC by Communities - Since its ratification by the Board in February 2021, situations whereby UCoC is being adopted and applied within the Wikimedia community have grown. (continue reading)
  • New Timeline for the Interim Trust & Safety Case Review Committee - The CRC was originally expected to conclude by July 1. However, with the UCoC now expected to be in development until December, the timeline for the CRC has also changed. (continue reading)
  • Wikimania - The UCoC team is planning to hold a moderated discussion featuring representatives across the movement during Wikimania 2021. It also plans to have a presence at the conference’s Community Village. (continue reading)
  • Diff blogs - Check out the most recent publications about the UCoC on Wikimedia Diff blog. (continue reading)

Thanks for reading - we welcome feedback about this newsletter. Xeno (WMF) (talk) 02:53, 21 July 2021 (UTC)

Block right + Hanging indent

How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26

So please, how do I combine the effect of these two templates? --EncycloPetey (talk) 21:56, 20 July 2021 (UTC)

@EncycloPetey: {{block right|style=margin-left:2em; text-indent:-2em;}} (for the default indentation given by {{hi}}) should give you what you want. Jarnsax (talk) 22:12, 20 July 2021 (UTC)
Thanks! I will add that information to my toolbox of useful things. --EncycloPetey (talk) 22:15, 20 July 2021 (UTC)
@EncycloPetey: To make it easier, see my edits to Index:Frogs (Murray 1912).djvu/styles.css and Page:Frogs (Murray 1912).djvu/26 just now (and feel free to give the class a better name). Jarnsax (talk) 22:25, 20 July 2021 (UTC)
Given that this issue is frequent across many dramatic works, and the issue can be solved by applying a single template with parameters, I expect that will be the approach I take, rather than having to create a stylesheet for each work where this issue occurs. --EncycloPetey (talk) 22:28, 20 July 2021 (UTC)
Either way works... using a stylesheet just consolidates the possible typos in one place. Mainly just demonstrating, don't feel obligated to use it. Jarnsax (talk) 22:31, 20 July 2021 (UTC)

 Comment@EncycloPetey: The template seems to work as specific. To note offset works on its own, however, if you want to use gutter that it requiries offset to be used. I have added "max-width" to the template as we typically have that in most of templates of this sort as we prefer to not fix the widths.

  1. standard YesY
  2. offset YesY
  3. gutter N
  4. offset and gutter YesY
  5. max-width YesY
  6. max-width, offset and gutter YesY
examples
{{block right|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
{{block right|offset=10em|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
{{block right|gutter=10em|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
{{block right|offset=10em|gutter=10em|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
{{block right|max-width=38em|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
{{block right|max-width=38em|offset=10em|gutter=10em|1={{hi|1=How do I combine <nowiki>{{Block right}}</nowiki> with <nowiki>{{Hanging indent}}</nowiki>? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26}}}}
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26
How do I combine {{Block right}} with {{Hanging indent}}? Specifically, I have instances in dramatic works where a paragraph is formatted with a hanging indent, but the paragraph block is against the right-hand margin. It is not formatted with the text aligned to the right-hand margin, but the block is against the margin. Example: Page:Frogs (Murray 1912).djvu/26

It would have been best if {{block right}} had been set with a right indent function like {{right}} and {{float right}} however, different authors, so it hasn't. ¯\_(ツ)_/¯ — billinghurst sDrewth 11:10, 21 July 2021 (UTC)

Score Extension re-enabled at enWS

The Score extension has been re-enabled on this Wiki prior to a more general roll-out to all Wikisources: phab:T257066.

Users with specific interest in score images, please keep an eye out for issues and report at the ticket (or here, and I will pass them on). Currently rendered scores will remain cached until edited. Please do not mass-regenerate scores at enWS, but rather slowly test a few out and report issues.

For example: adding a '.' to the title of Abide_with_Me_(Illustrated_Victorian_Songbook) does not work yet (this is reported). Inductiveload—talk/contribs 13:01, 22 July 2021 (UTC)

  • Inductiveload: A score from this page (which does not render on that page) is transcluded to this page, where it is loaded and is broken. When I first tried to load this page, it gave me some fatal-exception error; but that no longer appears. Addition: in trying to edit the page, I also get that error, on occasion. TE(æ)A,ea. (talk) 15:07, 22 July 2021 (UTC)
Corrected the syntax in this score snippet so that it can render. Beeswaxcandle (talk) 04:35, 23 July 2021 (UTC)

Homo Sum move

Category:Text integrity and redundancy

@CalendulaAsteraceae: has been removing instances of {{Tq}} where the value is 100% because that is equivalent to being validated. If someone is navigating Category:Text integrity, we have both Category:100% and Category:Validated texts. If these are equivalent, should they be merged? We also have Category:0% but it is empty. Should it be deleted? —Justin (koavf)❤T☮C☺M☯ 17:57, 24 July 2021 (UTC)

Only equivalent if the work is scan-backed and fully validated through the ProofreadPage process. Keep the 0% category for unproofread text-dumps that aren't being deleted. Beeswaxcandle (talk) 18:06, 24 July 2021 (UTC)
don’t know why you would want to delete old quality assessment categories. they are not hurting anyone, and some old timers might find them useful. Slowking4 亞 Farmbrough's revenge 01:04, 25 July 2021 (UTC)
Community made the decision years ago that they were not directly equivalent and to review these on a case-by-case basis. Validated text have traditionally been twice read works through the PrP process, and the 100% twice read through external sources. If the scenario is now different some examples of the differences and what the solution should be would be appreciated. — billinghurst sDrewth 01:48, 25 July 2021 (UTC)

Transclusion required

If anyone is looking for a task, the work Myths and Legends of British North America has its pages proofread, though not all transcluded. — billinghurst sDrewth 05:52, 26 July 2021 (UTC)

Tech News: 2021-30

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

  • A new version of MediaWiki came to the Wikimedia wikis the week before last week. This was not in Tech News because there was no newsletter that week.

Changes later this week

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 27 July. It will be on non-Wikipedia wikis and some Wikipedias from 28 July. It will be on all wikis from 29 July (calendar).

Future changes

  • If you use the Monobook skin you can choose to switch off responsive design on mobile. This will now work for more skins. If ⧼monobook-responsive-label⧽ is unticked you need to also untick the new preference Enable responsive mode. Otherwise it will stop working. Interface admins can automate this process on your wiki. You can read more.

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

21:11, 26 July 2021 (UTC)

Becoming an administrator

According to Cy wikisource etc there are no stewards, administrators, or any officials that manage the Welsh language Wikisource site. It is a little used site, but one I would like to improve. But with nobody with any administration rights, it's a bit difficult. How does one become a bureaucrat, an administrator a steward etc on a site that appears to have no officers? Llywelyn2000 AlwynapHuw (talk) 04:45, 16 July 2021 (UTC)

@AlwynapHuw (and CC Llywelyn2000): Stewards are by definition not local. See m:Stewards for details. And you do have local administrators: cy:Special:ListUsers/sysop (Mahagaja is also an admin here on enWS).
If there is something you cannot currently get done I suggest you start by having a discussion on the local Scriptorium. If the consensus is that you need to add or rejig permissions and roles on the project, you can ask the Stewards for advice on their noticeboard at meta. I'd be happy to help too, but not speaking Cymru I'm a little handicapped in that department. :) Xover (talk) 08:08, 16 July 2021 (UTC)
  • @AlwynapHuw: Indeed, I'm an admin at Welsh Wikisource, and up until recently usually the only contributor. Since Welsh Wikisource is so little used, the way I became an admin was to go to Welsh Wikipedia and ask people there to support my bid for adminship. If you need my help with anything, don't hesitate to ask. A message at my talk page on English Wiktionary will probably get to me fastest, since that's where I spend most of my Wiki time, or send me an e-mail. —Mahāgaja · talk 15:26, 16 July 2021 (UTC)

@AlwynapHuw: Where there is no local policy for appointment of administrators, then the global process applies. That global/general process for adminship at small wikis is explained at m:SRP. Where there is no bureaucrat, the process is to propose yourself for admin rights at your central discussion space so that the community has the opportunity to comment. After a week, if there is no comment, or no unfavourable comment then you go back to m:SRP and place a request to be allocated rights. Stewards will act as the bureaucrat for the wiki, and either approve, reject, or provide guidance on your request. — billinghurst sDrewth 08:18, 19 July 2021 (UTC)

Getting any new bureaucrats is generally better for larger wikis. Chinese wikis have no bureaucrats except Wikipedia.--Jusjih (talk) 03:31, 27 July 2021 (UTC)

Manual indexing vs. automatic indexing of periodical articles

Why have we standardized on the manual aggregation/indexing of periodical articles over the automatic aggregation/indexing method? Several times I have searched for articles in a manual index and have not found them, because they require someone to add them to the list manually. For instance we have Brooklyn Eagle with manual aggregation/indexing and we had The Brooklyn Eagle, now deleted, using the automated aggregation/indexing. Why do we choose one over the other? I have catalogued a half-dozen methods that periodical articles are indexed, so why is one deleted and the other kept. --RAN (talk) 06:20, 28 July 2021 (UTC)

There is one top level page per work. The automated/non-curated {{header periodical}} use has been the poke coverall when something is created, as people were forgetting to add them, and we just had unconnected subpages (ugly!). Once one starts to curate the parent page and add detail, that will be the default. That page should also sit over the top of the all the subpages in the work's hierarchy, not off to one-side on variation of the name. All name variations should be redirects to the main page for the periodica;. If you want to have an autogenerated list then I would suggest that you poke into the header notes [[Special:PrefixIndex/{{FULLPAGENAME}}]] or [[Special:PrefixIndex/{{FULLPAGENAME}}|some text]]. That formula will show all subpages in whichever page in whichever namespace that page is are sitting. — billinghurst sDrewth 12:01, 28 July 2021 (UTC)

Proposal: Include date on all subpages within a work

This proposal is motivated by the stripping of dates from the headers of a collection of poetry, where each poem is a complete "work" in its own right. [14] I don't see any reason to remove this bit of information.

I asked why the information was being removed, and here is the reply I received:

No, why would we want to do that? Year of publication sits on the parent page, it doesn't differ as it cascades. We have always said to put the data on the top page, and not overly categorise subpages. We add it when we are differentiating a subpage from the parent/ — billinghurst sDrewth 14:29, 21 July 2021 (UTC)

But as I see it:

(1) Title and author "don't change" either, but we include them. Except that sometimes the title and author do change, because it is a dictionary entry, and because the subsetrion has its own title.
(2) Yes, the date can change on subpages, and providing that information only sometimes does not help the reader, who may arrive at any point within a work from an outside link. There are works published in volumes where different volumes may have different dates, and we cannot rely on the date appearing on the main page. So just like title and author, sometimes it changes, yet we include the author and title on all subpages, but not the date? Even though they work the same?
(3) The title, author, and date are the minimum information needed for a bibliographic citation, so why provide only two of those three? Why force our readers to look elsewhere for the final bit of data?
(4) A reader does not always arrive on a page through the primary page for that work. "Deep" links are quite common, as are pointers to poems, chapters, acts, etc. from outside Wikisource. Letting the reader know where they are is a Good Idea, and the header is the best way to do that.
(5) Creating a system where sometimes we have something, sometimes we don't, and there is an ambiguous (or lengthy) list of criteria to constantly haggle over would waste our community's time.

I therefore propose that we mandate inclusion of the date on every subpage of a work, for the reasons listed above. --EncycloPetey (talk) 15:54, 21 July 2021 (UTC)

  • Strong oppose. There is no lenghty list of criteria: dates are put on the individual published work, not on any part of the work. The title and author are included because the {{header}} requires them; adding the year is unnecessary and greatly complicates matters. TE(æ)A,ea. (talk) 02:42, 22 July 2021 (UTC)
    So on a volume that includes academic articles, which would be subpages, and those articles each have their own dates, you would not include them? When the work comes in three volumes with different dates, you would not include the dates on the subpages? So on an edited volume, where the contents are short stories, those works would not receive a date? Those are all works that are themselves subpages or where some subpages have a different date than other subpages. This is what leads to a lengthy set of criteria; debating whether components that were published together in a volume are "works" or not. I am proposing we sidestep that whole mess and just include the dates always. This also demonstrates that the dates are not always unnecessary, and that the matter is complicated both ways, so an argument that including dates is "unnecessary and greatly complicates matters" is not supported. --EncycloPetey (talk) 06:04, 22 July 2021 (UTC)
    • My response EncycloPetey:
      1. The articles would not have “their own dates;” the volume would, and the date would be put on the volume page.
      2. For this instance, there are three levels: Work, Work/Volume 1, and Work/Volume 1/Chapter 1. Work/Volume 1 would have a date, because it is a separate published volume; but Work/Volume 1/Chapter 1 would not.
      3. Correct; only the edited volume (whether Edited Work or Edited Work/Volume 1, as appropriate) would have a date.
      4. Re: “Those are all works.” I don’t care; the standard is not whether something is a work (which poems, articles, and short stories are), but whether those works are published individually in the edition referenced. This is because Wikisource focuses on editions. Whether an article was published at a different time than another article originally does not matter if both were published in one work; that work would get a date, and the articles would not.
      5. I don’t think it as difficult as you make it out to be to determine what is and is not a “work;” but, as I have said, that does not matter.
    • My response to CYGNIS INSIGNIS:
    1. If this is the case, then that page (Author: or Portal:) should list the date for the published volume from which the work in question is derived.
    1. This is a separate problem, and should not justify adding the date to a subpage (because, technically speaking, if there is no parent page, then the subpage is the top-level page).
(6) the link to a subpage is also likely to be from an author or translator's page, or from the dabs for translation and version pages for shorter works or frequently cited sections. It is internal and outside links that could benefit from the bibliographic data for citation [as noted at EP's (3)] and navigation [or orientation]. It is potentially useful or crucial context.
(7) The parent page might not exist.

Perhaps that is implicit or stated in the original proposal statement, but aside from my addendum I think the case is already well made on why to include them; I don't see [or understand] the rationale for opposing or routinely removing them. CYGNIS INSIGNIS 05:18, 22 July 2021 (UTC)

Oppose

  1. The publication date applies to the work, not the subpart; and bibliographic citation would be citing the _poem_, the _work_ in which it was published and year of the publication of the _work_. And that is as it was explained to me for FRBR citing on what were the required components into which to add for the subpage detail at Wikidata.
  2. Which bit of unreasonable comparison is going on here "the title and author don't change" these are particularly relevant for context, and clearly for disambiguating any work. If that detail wasn't there then there would be no context to the subpage, and there is loss of link navigation. The date provides no such value nor purpose, and in some ways it is misleading to put a publication date against it without referencing to the parent work.
  3. Volume works, I have left all the standalone volumes with their dates
  4. Re-academic articles. I haven't touched the periodicals, and these works were not part of your question to me, so not part of the answer. You are changing the basis of the question and your argument with which you started of poems in a published collection.
  5. One would ask why any parent page did not exist, and in this maintenance work that I am doing all parent pages exist, so it is not relevant.
  6. Re parameters where sometimes we have something and sometimes we don't. Strike me stupid, have you looked at Template:header recently? Look at that huge long list and which we use. Also look at how they are marked and explained. ALSO with the header gadget, it applies year parameter to the ROOTPAGE Some dumb page, not to the subpages Some dumb page/subpage. So we manage that aspect, and ideally we minimise the data that needs to be added.
  7. For consistency we say that if it is true at the top (portals, categories), then don't do it to the subpages, just do it when different.
  8. Links from author and portal pages should have a date against the work.

— billinghurst sDrewth 11:52, 22 July 2021 (UTC)

Oppose as written

  • I am not opposed to presenting the date on a subpage per se. I am opposed to having actually to add it to all subpages. If we had a way to copy the data from a sensible source (mostly likely in the longer term: Wikidata) automagically then fine. Adding the author to all subpages is already dumb enough. All this data, both in the Index and Main NS should come from Wikidata. But we don't yet have functional tools for adding that data (they're on my list). I don't think embarking on a major project to spam repeated dates into subpages would be a good idea, when the same effort could be spent on figuring out how to get this data sensibly. Inductiveload—talk/contribs 12:46, 22 July 2021 (UTC)

I personally prefer having the date on all the subpages just as we have the work title and author on all the subpages. I don't think we need to enforce the addition of dates, but I don't think we need to remove the dates either. Noting also that <pages ... header=1 /> will place dates on subpages automatically. —Beleg Tâl (talk) 22:15, 30 July 2021 (UTC)

Now you see it; now you don't

The useful "Transcribe text" button has vanished. It was there yesterday. Why was it taken away? Beeswaxcandle (talk) 08:40, 30 July 2021 (UTC)

@Beeswaxcandle: Due to user feedback it was moved to the regular editing toolbar. It should be right-aligned in the top of the toolbar, over the scan image in the default layout, and otherwise looks roughly the same as before. Xover (talk) 08:51, 30 July 2021 (UTC)
Well, that's awkward as I don't use the "regular" editing toolbar. It takes up too much space on my screen. I've turned the 2006 toolbar gadget on, but that doesn't have an OCR button on it—which is why the new "transcribe" button was useful. Guess I'm back to re-typing the pages with bad OCR. Beeswaxcandle (talk) 09:08, 30 July 2021 (UTC)
In that case you're out of luck, yes. But I also do have to say that in this you are fighting a hopeless battle: ~15 year old technology that was actively replaced ~10 years ago (the 2010 wiki editor) by tech that has subsequently been (soft) deprecated in turn (in favour of the 2017 editor) is going to break in numerous ways and require escalating workarounds. I really can't emphasise enough how much I encourage you, and anyone else clinging to the 2016 editor, to bite the bullet and migrate to at least the 2010 editor sooner rather than later.
That being said, we can look into options for making the new OCR available in the old editor as a stop-gap. It is possible, I'm just not sure how much effort will be involved and how hacky it'll be. Do the old OCR tools (the old Phe tool, and the newer GoogleOcr tool, both enabled/disabled in the Gadget section of the preferences) show in your toolbar? Xover (talk) 09:31, 30 July 2021 (UTC)
Ah, no, no OCR button. Actually, it's only recently (February) that the Gadget became available (Billinghurst's work). For the previous couple of years I operated without one at all. The only button I actully use from it is the 'add hyphenated word' one, so am not far from turning the gadget off as well. When one is on a 14" monitor any screen real estate is valuable. Beeswaxcandle (talk) 10:04, 30 July 2021 (UTC)

NSFW label template for erotic works

I propose to create a template that would be used to label certain works, particularly erotic ones, as not safe for work (NSFW). The label would exist in the header notes section of the front matter page of the work. The name might be something like Template:NSFW or Template:NSFW disclaimer.

I wouldn't normally propose something like this to be used on a wiki, since wikis are generally used for educational purposes only. However, Wikisource is meant to present works, including fiction, as is in full without censorship. This means that many of our readers probably come to read our content, particularly fiction which includes erotica, for the purposes of entertainment and not necessarily for strictly educational reasons. For this reason I take a little issue with the fact that we present works like this with no warning alongside them. If someone were to press the "Random work" button for example, or stumble across it via search without knowing what they came across was NSFW, some may find it unpleasant to have stumbled across it unexpectedly.

There's also the issue of minors potentially viewing erotic works, and I don't know the exact legal situation of this, but most sites would label that material 18+ so as to avoid legal complications.

I understand our coverage of erotic works is pretty limited at the time of writing, but check Portal:Erotica to find a good number of examples in our collection. To further substantiate my argument, there are a handful of pornographic films that have fallen into the PD, the most notable example I can think of being Debbie Does Dallas. Films like these, in theory, can and should transcribed here, as they count as published works (yet there are none here right now). Yet another issue is pornographic comics which are likely to be in the PD as well (again none yet exist here); for example, there were Tijuana bibles produced since the 1920s.

Proposed text of the template (amend if necessary):

NSFW warning: This is an erotic work that may be sensitive to some audiences. Works are presented as-is with no censorship involved, including with erotic works. See Wikisource:General disclaimer for more information.

PseudoSkull (talk) 23:15, 28 July 2021 (UTC)

No. Please do not place any such label in the main namespace to deface our works. That is quite a prurient approach, and not one that I have seen in public libraries or in public bookshops where you can walk up and grab any book off the shelf. The works are labelled in Category:Erotica and I don't believe that any of our books require classification or are banned in the USA. If there is any LEGAL requirement to label or protect works, then we should look to that and discuss with WMF Legal prior to implementing anything. I do not think that we are there. — billinghurst sDrewth 23:47, 30 July 2021 (UTC)
What ⇧ said… Xover (talk) 11:56, 31 July 2021 (UTC)
solution in search of a problem. and you have the conundrum of poems once considered erotic, such as Madam be covered, why stand you bare?, so you become "w:banned in Boston". Slowking4 亞 Farmbrough's revenge 14:13, 31 July 2021 (UTC)
One mother described it as shocking to be reading w:And to Think That I Saw It on Mulberry Street to her children and turn the page to have a very stereotypical "Chinese man" facing her. That's not the edition we'll be transcribing, of course; before changes in the 1970s, he was a "Chinaman". Your bêtes noires are not the same as everyone else's. Not to mention: Random work brought me to five soporific Presidential proclamations and court cases, then The Rum Parade (content warnings: alcohol use, out-of-date medical advice), several more of the first, Copy of a letter, written by the Rev. Mr. William Barlas (content warning: religious threat, anti-medical rhetoric, inside baseball). No erotica.
I should do one of the bibliographies of what a small college/high school/prison library should look like, just to provide a list of works that don't threaten to put the random browser into a coma. (That's at least somewhat tongue-in-cheek; it's great to have all the Presidential proclamations and Supreme Court cases here, and I've used that resource before. But in part because of how we separate works, Random work is worse than randomly browsing a library, or randomly digging through Project Gutenberg. It reminds me of a modern college library catalog, where as works the school had to pay for, bundled up in to physically convenient volumes are listed besides electronic works listed in bulk that the college would not have paid for separately, nor even taken the time to catalog separately. But whatever; work on what you want, and even if we could agree on changes to Random work so it didn't turn up mainly stuff that should be part of a larger volume, it probably wouldn't be worth the time to work on. (I might argue that we should clean up small works that really should be part of a larger work, instead of dumping every poem at the top level, or every page in the Notebooks.) Rant/ramble off.
--Prosfilaes (talk) 15:09, 31 July 2021 (UTC)
  • (Prosfilaes: For Supreme Court decisions, the pages could be moved to subpages of United States Reports, which would eliminate them from the “Random work” pull.) TE(æ)A,ea. (talk) 00:19, 4 August 2021 (UTC)
    I would definitely support that: we can have redirects from the individual case names etc., but the pages should live within the page structure of the work in which they were published. There are plenty of dedicated websites that try to present Supreme Court cases intelligently, there's no reason for us to do a half-baked job of imitating them instead of concentrating on our core purpose. Xover (talk) 06:39, 4 August 2021 (UTC)
  • If we (as English Wikisource or Wikimedia) decided erotic works were problematic, it would be simpler to delete all currently held and prevent new erotic works from being created. Just like your previous request for a “racism” warning, an “erotic” or “pornographic” warning would be highly dependent on personal opinion. Too much time would be spent in discussions determining the threshold for what does or does not “appeal[] to the prurient interest,” which is wholly wasteful. TE(æ)A,ea. (talk) 00:19, 4 August 2021 (UTC)
  •  Support … more comments [only, 'tis for anthropological study] CYGNIS INSIGNIS 11:31, 4 August 2021 (UTC)

500k validated pages

This week, English Wikisource surpassed 500,000 Validated pages. Good work, everyone!

More stats for the curious: https://phetools.toolforge.org/statistics.php. Inductiveload—talk/contribs 22:31, 11 July 2021 (UTC)

the monthly diffs are interesting also -683 not proof.; +16590 proof.; +4087 valid. [15] --Slowking4 亞 Farmbrough's revenge 03:20, 7 August 2021 (UTC)

over a million pages …

not proofread. CYGNIS INSIGNIS 06:04, 29 July 2021 (UTC)

Is there any faster way to proofread? I am adding more indexes to the United Nations Treaty Series. Yet each volume has hundreds of pages.--Jusjih (talk) 04:17, 7 August 2021 (UTC)
apparently, by the diffs, more effort in proofreading, than in reducing non-proofread, or validating.[16] the languages who concentrate on minimizing not proofread, have been left in the dust, they are much less productive. if you had some contest to reduce not proofread, that made it fun, that might work. --Slowking4 亞 Farmbrough's revenge 14:24, 7 August 2021 (UTC)
  • Jusjih: The volumes of UNTS are, for the most part, not contributing to this list. For pages to be marked “not proofread,” they must be created; and the only pages of the UNTS volumes which have been created are the title pages. There are many works which have hundred of pages created without any formatting, and so marked as “not proofread.” To more easily proofread the volumes of UNTS, I would recommend creating work styles. (Inductiveload may be able to help you in that regard.) Also, running headers that work automatically on all pages will help. These improvements would allow for relatively rapid proofreading of UNTS pages, without too much consideration (on the Page: level) for formatting. TE(æ)A,ea. (talk) 14:29, 10 August 2021 (UTC)

There are indexes here that have been mechanically saved as not proofread, I know of no reason to do that (and many not to). Others have been match and split, more or less successfully: I proposed that a recent set—that failed to include the extensive footnotes—be deleted, so allowing any proofreading user to more easily complete pages. These efforts require only a bright idea and a couple of clicks to create a significant obstruction to any genuine intention to contribute works, the evidence above also suggests that no-one is interested working on these indexes; the easiest way is to start again! CYGNIS INSIGNIS 05:33, 8 August 2021 (UTC)

given the success of WPWP, we could do the same here. there is no quality backlog that cannot be surmounted by some leadership and prizes. Slowking4 亞 Farmbrough's revenge 01:35, 9 August 2021 (UTC)

Help:Footnotes_and_endnotes#Footnotes_that_continue_over_page_breaks

It's stated there that "The position of this text does not matter to the footnote but adding it to the bottom of the page, where the footnote would normally be, is the most obvious position." It's correct that it doesn't affect the footnote, but if you put the following footnote at the top of the page it breaks the auto-hyphenation of ProofreadPage (i.e. you will have to use {{hws}} and {{hwe}} in the main text to join words) I noticed this while validating Blackstone, which was originally proofread back in 2013 (and updating the hyphenation method since I'm touching it). I'm sure the help page also dates from way back, but might be good to note there's an actually a reason to get in the habit of putting them at the bottom now. Jarnsax (talk) 18:27, 21 July 2021 (UTC)

It can be anywhere on the page, you can put it one word in. It probably is more a note that should against the text on autohyphenation as there will be lots of things that will break it like that. — billinghurst sDrewth 10:39, 22 July 2021 (UTC)
I pondered over that recently when plodding through this page for the helpful bit. The obvious rationale is that is where it appears in the scan, using a workaround to put it elsewhere is likely to baffle all concerned with why [is this purposeful?] when it is not at the same position on the page. CYGNIS INSIGNIS 07:04, 23 July 2021 (UTC)
P. S. The only known exception to the usual practice is perhaps illustrative: Schmelzle's Reise CYGNIS INSIGNIS 07:22, 23 July 2021 (UTC)
Agreed. My initial reaction to 'randomly' finding following footnotes at the top, usually munged together with the beginning of the page's running text, is that it violates the POLA. (High WTF factor) It's not inherently 'wrong', but definitely counter-intuitive. It's also usually hard to find the end of a (typically long) footnote if it's buried in the middle of a block with completely unrelated text. Jarnsax (talk) 22:35, 23 July 2021 (UTC)
What I'm on about, if not clear, is on the order of someone using {{RunningHeader|right=##|center=text}}... it's perfectly valid, but doesn't fit people's "mental model" of how the thing works. {{rh||text|##}} is obviously better...not because it's shorter, but because it's intuitive. After a bit of experience, your brain can 'read' that as the rendered header pretty easily.
Don't do things in an unexpected way just because you can, and have pity on the person that has to figure the shit out later. Jarnsax (talk) 23:20, 23 July 2021 (UTC)
There is no perfect. There can be good operational reasons to stick a "follow" ref at the top, especially when it can be the first bit of proofreading on that page. The issue of hyphenation and continuing footnotes doesn't happen often—I cannot remember a case—and typically all the old works will have {{hwe}} in place, well they should have. I would generally recommend that if "HWE" is in place, then probably best to leave it as it is guaranteed to work. If uncertain, use it; I have continued to use the template. With regard to standard empirical approach, yes it would be lovely, especially where we need to run a bot through. It simply isn't the reality. — billinghurst sDrewth 02:14, 24 July 2021 (UTC)
  • @TE(æ)A,ea: My edit here moved a ref follow section to the bottom because I noticed it breaking what I was reading. As @Billinghurst: suggests above, instead of what others suggest, is to move it 'one word in', I presume to avoid it breaking, but continues adding it to the top for 'operational reasons'. CYGNIS INSIGNIS 07:38, 18 August 2021 (UTC)

Proposal: Volunteer to test the reintroduction of the Score extension

Following behind-the-scenes hackery, the Score extension is now ready to be phased back into production. The current plan is to enable on the test wikis this week and then enable on some "medium" sized wikis after that. I suggest that we, as a wiki, volunteer to be a guinea pig for that (despite not actually being a "medium" wiki; we are classified as "large") so that we can help drive forward the process of getting Scores fixed globally. See phab:T257066 for more detail.

As I understand it, the major risk to us is that particularly big scores might timeout and make it impossible to save affected pages (unless the score is disabled on that page until the extension is fixed). Note that currently, the score won't show at all if you modify it, so it might not change much for that page anyway. During the test period, I would volunteer relay any concerns raised only here at enWS to Phabricator if needed.

As well as a straight !vote on "should we volunteer", if people who know of particularly "unusual", "gnarly" or just very large scores could drop some links, that would be good for testing should we be included as a test wiki. Inductiveload—talk/contribs 17:47, 12 July 2021 (UTC)

If a timeout appears, the workaround is to wait few minutes and try saving the same code again. As I noticed, even if the parser returns timeout, the actual score images are still being generated in background. So hitting just a timeout should not be a big problem. Ankry (talk) 20:52, 12 July 2021 (UTC)
This sounds good: some improvement is better than none. Also, it was claimed at some point that the cache will maintain the score, but that is untrue; but that is not quite the same as what you said. TE(æ)A,ea. (talk) 02:42, 22 July 2021 (UTC)
My biggest score here (Essentials in Conducting/Appendix B) has just behaved nicely. Beeswaxcandle (talk) 03:08, 24 July 2021 (UTC)
The score at Page:The music of Bohemia.djvu/25 and at some other pages of the same work stopped working, although not a long time ago at least the image of the score was visible. The same applies to Page:The music of Bohemia.djvu/33 where Inductiveload did some workaround in April which enabled the readers to see the image, but that stopped working too. --Jan Kameníček (talk) 23:09, 20 August 2021 (UTC)
Both fixed. There was a problem with the lyrics, in that they were initiated in two different ways in the same sequence. Beeswaxcandle (talk) 02:45, 21 August 2021 (UTC)
Great, thanks! --Jan Kameníček (talk) 17:42, 21 August 2021 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2021-07&oldid=11977758"