Wikisource:Scriptorium/Archives/2021-09

August Monthly Challenge summary

The August Monthly Challenge is now complete and the numbers are in: 1701 pages were processed (marked no text, proofread or validated), which is sadly under the target of 2000. The following works were fully proofread:

• Index:The Works of H G Wells Volume 2.pdf
• Index:What I saw in America.djvu
• Index:When we were very young.pdf
• Index:The Philippine Islands, 1493-1803 (Volume 01).djvu
• Index:Orley Farm (Serial Volume 3).pdf

And the following were validated:

• Index:Common sense - addressed to the inhabitants of America.djvu (also proofread)
• Index:Austen - Sense and Sensibility, vol. III, 1811.djvu, which completed the set and gives us a fully-proofread copy of Sense and Sensibility

As well as quite some progress on other volumes in the challenge.

New works in September include:

• The Book of the Duke of True Lovers by Christine de Pizan, which will be the first work of hers on Wikisource
• Kwaidan: Stories and Studies of Strange Things
• The First Folio edition of The Two Gentlemen of Verona
• Rambles in Germany and Italy in 1840, 1842, and 1843 by Mary Shelley, brought to us by a new user to enWS.
• Petition from the Citizens of Massachusetts in Support of Woman Suffrage

Continued series in September:

• Cromwell's Letters and Speeches by Thomas Carlyle (the 5th volume so far!)
• The Philippine Islands, 1493-1803 (Volume 2)
• The Works of H.G. Wells (Volume 3)
• Orley Farm (now at Volume 4)

We are also are starting a new series:

• United States Treaty Series, beginning with (Multilateral Treaties 1776–1917), including the Geneva Convention.

And many more! Over 7000 pages of fun for all the family! As always, please drop in as you wish and nominations are open for proposals and comment. Inductiveload—talk/contribs 08:04, 1 September 2021 (UTC)

English, Scottish etc. vs British vs United Kingdom authors

It seems there is a big mess among the categories mentioned in the heading.

The category English authors includes a notice that it contains authors who lived when England was a nation for itself. I guess it means that only authors from the times of the Kingdom of England should come here. Besides the fact that the contributors are forced to search by themselves when exactly it was, it is also not very systematic, because parallel category Scottish authors does not contain any limitation to include only authors from the times of the Kingdom of Scotland, or Welsh authors only from the Principality of Wales. It is also the reason why some (many?) contributors add modern authors from England to this category.

The category British authors does not contain any notice who belongs there, but I guess it should be authors from the times of the Kingdom of Great Britain, otherwise it would not make much sense to keep it separate from the United Kingdom authors. Again, contributors seem to be confused by them and seem to distribute authors between them randomly or to both of them for sure.

We could try to save the system e.g. by changing names of the categories so that they showed better that they apply only to some historical periods. The names could be Kingdom of England authors, Kingdom of Scotland authors, Principality of Wales authors, Kingdom of Great Britain authors. However, this solution has many disadvantages. I am afraid that many contributors would be disapointed that modern Scottish authors would fall under United Kingdom authors, similarly as modern English authors do. It is even more complicated for Ireland. If we wanted to keep the system distinguishing members of historical independent countries from the times when the countries are/were parts of the UK, for Ireland we would have to found e.g. Irish authors (till 1801) and the Republic of Ireland authors. I am not sure if it is not too complicated.

An easier solution would be to abandon the attempts to keep authors of historical countries of the British Isles separate and to remove this notice from the category English authors. English, Scottish etc. authors would be simply authors from these countries regardless whether independent or part of the UK. The category United Kingdom authors would contain only authors who the contributors were not able to distinguish more precisely. British authors would be redirected to the United Kingdom authors.

Or, we can make a compromise: English authors would contain no limitations as for era and Kingdom of England authors would be its subcategory. The same for Scottish authors and others. British authors would be renamed for Kingdom of Great Britain authors and subcategorized to the United Kingdom authors.

I personally would prefer the last solution, but the previous ones are imo also better than the current confusing situation. --Jan Kameníček (talk) 14:29, 5 September 2021 (UTC)

The 2022 Community Wishlist Survey will happen in January

Hello everyone,

We hope all of you are as well and safe as possible during these trying times! We wanted to share some news about a change to the Community Wishlist Survey 2022. We would like to hear your opinions as well.

Summary:

We will be running the Community Wishlist Survey 2022 in January 2022. We need more time to work on the 2021 wishes. We also need time to prepare some changes to the Wishlist 2022. In the meantime, you can use a dedicated sandbox to leave early ideas for the 2022 wishes.

Proposing and wish-fulfillment will happen during the same year

In the past, the Community Tech team has run the Community Wishlist Survey for the following year in November of the prior year. For example, we ran the Wishlist for 2021 in November 2020. That worked well a few years ago. At that time, we used to start working on the Wishlist soon after the results of the voting were published.

However, in 2021, there was a delay between the voting and the time when we could start working on the new wishes. Until July 2021, we were working on wishes from the Wishlist for 2020.

We hope having the Wishlist 2022 in January 2022 will be more intuitive. This will also give us time to fulfill more wishes from the 2021 Wishlist.

Encouraging wider participation from historically excluded communities

We are thinking how to make the Wishlist easier to participate in. We want to support more translations, and encourage under-resourced communities to be more active. We would like to have some time to make these changes.

A new space to talk to us about priorities and wishes not granted yet

We will have gone 365 days without a Wishlist. We encourage you to approach us. We hope to hear from you in the talk page, but we also hope to see you at our bi-monthly Talk to Us meetings! These will be hosted at two different times friendly to time zones around the globe.

We will begin our first meeting September 15th at 23:00 UTC. More details about the agenda and format coming soon!

Brainstorm and draft proposals before the proposal phase

If you have early ideas for wishes, you can use the new Community Wishlist Survey sandbox. This way, you will not forget about these before January 2022. You will be able to come back and refine your ideas. Remember, edits in the sandbox don't count as wishes!

Feedback

• What should we do to improve the Wishlist pages?
• How would you like to use our new sandbox?
• What, if any, risks do you foresee in our decision to change the date of the Wishlist 2022?
• What will help more people participate in the Wishlist 2022?

Answer on the talk page (in any language you prefer) or at our Talk to Us meetings.

SGrabarczuk (WMF) (talk) 00:23, 7 September 2021 (UTC)

Nested footnotes with nested poems

Pages 56 and 61 of The Philosophy of Beards have nested footnotes. To complicate matters the footnotes include <poem> markup, but are referenced from within other poems.

On the former, I have used a "user annotation" to note this. Is there a better solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 5 September 2021 (UTC)

@Pigsonthewing: Sir_Thomas_Browne's_works,_volume_3_(1835)/Hydriotaphia#cite_ref-102. If something like that doesn't behave, try eliminating the pome tag. Cygnis insignis (talk) 13:15, 7 September 2021 (UTC)

Wikisource:Upload-shared and our requirements for allocation

I have created this page that documents the recently created group that the community request. I have put some light placeholder text about its allocation, and welcome comments about how forceful we need to be with what are the provisions we wish to put in place. I would think that we would allow administrators to allocate to their bots if they can demonstrate and document their cases. When we created this we didn't see that we would generally provide this right to normal users, are people still feeling that is the situation and that anyone wishing to have that right assigned should put forward a request for rights to the whole or solely to an administrator.

Personally, I would prefer to see something to the community. — billinghurst sDrewth 01:28, 7 September 2021 (UTC)

I think it could just be self-assigned by administrators and requested for a non-admin's bot via WS:AN.

The scope for mis-use is limited, and mistakes or abuse can be trivially be rectified with Special:Nuke or Special:MassDelete and a list of that bot's contributions. There's no need for a lot of process, since a "do we trust you" process is already done as part of the admin nomination and bot flag grant. Inductiveload—talk/contribs 06:08, 7 September 2021 (UTC)

Copyright status of the original Garfield comics

I wanted to let you guys know that I started a discussion at Commons:Village pump/Copyright about the copyright status of the original Garfield cartoons (then called Jon), which were syndicated in the Pendleton Times from 1976 to 1977. It turns out they may very well be in the public domain, and if they are, it is of interest to Wikisource because we could host transcriptions of them. PseudoSkull (talk) 17:07, 7 September 2021 (UTC)

Index:The Periplus of the Erythræan Sea.djvu

I saw that the map on the front matter page of this work, at page Periplus of the Erythraean Sea, was not transcluded like the rest and was included arbitrarily. After doing a few minutes of research, I determined that (probably) the reason this was done was because the scan we have is missing the map page, even though it lists it in its table of contents. Our scan originates from https://archive.org/details/periplusoferythr00schouoft while the map was taken directly from another scan, of the same version of the same work, at https://archive.org/details/periplusoferythr00scho/page/n333/mode/2up. Furthermore, that scan appears to be in much better quality anyway.

So unless there are any contentions, the better scan here should be uploaded to Commons and our current transcription project should be moved there. Pinging @LlywelynII: who originally uploaded the map in 2019, and @Hrishikes: who uploaded the original scan. PseudoSkull (talk) 11:18, 10 September 2021 (UTC)

If the two works have the same page numbering, we can generate a djvu file from the "new" scan and replace the "old" djvu with it,so we need to do (almost) nothing in Page: ns.Mpaa (talk) 17:03, 12 September 2021 (UTC)

Done per above proposal. Mpaa (talk) 21:09, 16 September 2021 (UTC)

John Brown (1909)

This should be moved to John Brown (Du Bois) to disambiguate it from John Brown (Chamberlin) from 1899 (a work I will eventually transcribe). Putting a year is inappropriate in this situation. If there are other versions of the Du Bois work to disambiguate from, perhaps it should be at John Brown (Du Bois, 1909). See John Brown, the disambiguation page. PseudoSkull (talk) 20:15, 12 September 2021 (UTC)

Done. Mpaa (talk) 20:45, 13 September 2021 (UTC)

Miscellanies–Thoreau

This should be moved to Miscellanies (Thoreau), especially as there is no indication that I'm aware of that the work actually includes an em dash in the title in this manner. PseudoSkull (talk) 21:29, 12 September 2021 (UTC)

WP:Be bold ;-) --Jan Kameníček (talk) 21:38, 12 September 2021 (UTC)

Done. Mpaa (talk) 20:10, 13 September 2021 (UTC)

Index:Transactions and Proceedings of the New Zealand Institute - Volume 1 (2nd ed.).djvu

Found a missing page that wasn't apparent initially. Following page position 499 there should be a blank and print page 465. https://archive.org/details/mobot31753002618145 has the needed pages at postions 494 & 495. This file has other problems, so I don't want to simply upload it over the previous. Could the missing pages please be interpolated and then all proofread pages from current position 514 through to 540 be moved down by two positions? Beeswaxcandle (talk) 04:26, 14 September 2021 (UTC)

@Beeswaxcandle: Done Please check the results.

Incidentally, Inductiveload has set up Wikisource:Scan Lab (WS:LAB) for these kinds of requests, along with a {{ping project|Scan Lab}} template to notify all those that have put their names down to help out when you add a new request. Xover (talk) 10:54, 14 September 2021 (UTC)

@Xover: Out of interest, how on did you get that 300MB file to upload today? I've had 13 files (out of 13) fail to upload today with stash failures (falling back to an IA upload and a server-side request: phab:T290900). All using chunked/async uploading. Inductiveload—talk/contribs 11:25, 14 September 2021 (UTC)

@Inductiveload: Just BigChunkedUpload and prayer. It is most likely not primarily the raw file size it's choking on, but the processing time of the metadata (which includes the page structure and text layer), so raw file size is only loosely correlated with upload failures. Xover (talk) 11:48, 14 September 2021 (UTC)

Redundant templates?

Do we need {{Filename}}, {{Image extracted}} and {{Image extracted/row}} for anything? --Jan Kameníček (talk) 10:24, 2 September 2021 (UTC)

Will anybody object if I delete them? --Jan Kameníček (talk) 13:24, 5 September 2021 (UTC)

Deleted. --Jan Kameníček (talk) 08:34, 8 September 2021 (UTC)

Tech News: 2021-36

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 wikis that have Growth features deployed have been part of A/B testing since deployment, in which some newcomers did not receive the new features. Now, all of the newcomers on 21 of the smallest of those wikis will be receiving the features. [1]

Changes later this week

• There is no new MediaWiki version this week.

Future changes

• In 2017, the provided jQuery library was upgraded from version 1 to 3, with a compatibility layer. The migration will soon finish, to make the site load faster for everyone. If you maintain a gadget or user script, check if you have any JQMIGRATE errors and fix them, or they will break. [2][3]
• Last year, the Portuguese Wikipedia community embarked on an experiment to make log-in compulsory for editing.  The impact report of this trial is ready. Moving forward, the Anti-Harassment Tools team is looking for projects that are willing to experiment with restricting IP editing on their wiki for a short-term experiment. Learn more.

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

15:20, 6 September 2021 (UTC)

Comment

Do we wish to volunteer to participate in the user trial for mandating login? Do we get sufficient value in IP editing IP edits from recent changes, and that includes 52 reverts (as time of typing). — billinghurst sDrewth 05:21, 7 September 2021 (UTC)

 Comment something that might not be that obvious as a benefit to requiring login as that IPs are not able to proofread a page in the Page namespace (which is why IPs seem to make so many red pages: that's all they can do). It's not made clear to IPs that there even is a proofreading mechanism from their point-of-view: phab:F34635385. Requiring login may therefore make editors making edits like Special:Diff/11670182 more able to proofread will all the tools. Inductiveload—talk/contribs 06:54, 7 September 2021 (UTC)

i see someone from Toronto, and Auckland being productive. are you sure you want to escalate? would not a bot be better? or an ip welcome message? otoh, it works for the pt admins, (well on the way to wikinews) --Slowking4 亞 Farmbrough's revenge 01:43, 8 September 2021 (UTC)

 Comment I've been reviewing Recent Changes here for a few weeks and I just don't see the cloud of tundra mosquitos as seen at en.wikipedia. It's so bad over there in despair I wrote:

Is there yet a general realization that Wikipedia is a proud shining obelisk inscribed with much knowledge in all the scripts of the world, but made of chalk and drenched in a corrosive continual acid rain?

At one time I argued that rather than anything or nothing, it should be changed to allow IPs to make _one_ edit a day, with the cheerful "want to contribute more - register!" This on the "first hit is free" theory - if their test of "you can edit" works, and they *really* want to contribute, they will register.

But as much as I hate IP edits in general I just don't see the need happening here. Perhaps vandals can't boast and point to Wikisource pages without someone saying "thought you didn't like books - how do you know about Wikisource?" Shenme (talk) 02:27, 10 September 2021 (UTC)

if you force people to register, then fewer will edit, and those that do will forget their password, and recreate a new account for every session. the barrier to entry of account creation and captcha are underrated. you may well abandon "anyone can edit" but there will be consequences. --Slowking4 亞 Farmbrough's revenge 22:04, 12 September 2021 (UTC)

 Comment I see no need to participate in this trial. There are some IPs who contribute usefully and conversely some logged in users who don't <shrug>. The only advantage that I can see is to prevent experienced wikisourcerors from editing while accidentally logged out. Beeswaxcandle (talk) 03:41, 13 September 2021 (UTC)

header, AuxTOC, and mbox

It was not my intention to hack {{Dotted TOC page listing}} but I did with {{Dotted TOC page listing|textbackground=inherit}} which, I really thought would grab the background color of {{AuxTOC}}. Which I was worried might change color depending on which skin is being used to view it in.

This failed, and I could see the reason that "transparent" is not allowed as a color and also, saw more about how it (the dotted) template works. So, the hack pulled in a transparent from AuxTOC and not the color.

After looking for the class being used for mbox (on media wiki) and AuxTOC (here), I read the AuxTOC docs; my priorities being a little backwards as I discovered. And, the AuxTOC uses the header "class", which is not so much a class as it is a "style setting" (which, I dearly hope I got wrong by not reading far enough down in the source), and it is safe to set the background color as this has been set locally.

So, my questions are:

1. How come inherit failed?
2. I am wrong about the header style (true or false) and (if true) the name of the class is?
3. True or false, I don't have to worry about the color changing depending upon the skin choices of the viewer.

--RaboKarbakian (talk) 18:57, 6 September 2021 (UTC)

From memory the dotted template series have a hard coding of white so that the dots are visible when that layers appears from behind the textlayer. For use AuxTOC with the dotted series use class="subheadertemplate" as that has the colour set within it. As the dotted template series is complex and never fully functional, I always say question whether its use is needed. — billinghurst sDrewth 00:58, 7 September 2021 (UTC)

i stay away from the dotted template, and use table code instead. more trouble than it is worth, even if it replicates typography of tables of contents. someone with serious css skills would be required to start over. --Slowking4 亞 Farmbrough's revenge 01:35, 8 September 2021 (UTC)

 Comment Ditto I second Slowking4. — Ineuw (talk) 02:02, 8 September 2021 (UTC)

The header class did not work either. The only thing the template will inherit is the one thing that breaks it.--RaboKarbakian (talk) 03:08, 8 September 2021 (UTC)

 Comment @RaboKarbakian: then I think that AuxTOC has the ability to force background-color => #E6F2E6 I do it so occasionally among lots of others edis so, I can forget what I do. — billinghurst sDrewth 10:33, 8 September 2021 (UTC)

Just asking some questions about the {{FI}} template css

When replying, a yes or no will do.

1. The {{FreedImg/styles.css}} specifies two font-sizes for a caption, 94% and 83%, can both be set to 83% or 85%, please?
2. Can the caption line appear on top of the image as well? I am asking because I have ~500 images with captions on top of the image and it would eliminate the use of additional templates. — Ineuw (talk) 19:02, 7 September 2021 (UTC)

@Ineuw: #1: No, because that will change the size of every caption using this template. Which I opine should never have set a default size but now we're 10930 usages deep in the mud, so that's a bit of a problem to change. The 83% is only for the "image missing" notice.

What you can do is set .wst-freedimg-caption { font-size: 83%; } in the styles.css subpage of the index for a work-specific override. Then you will not need to set it on every template.

#2: Yes: you can use the (new) top_caption parameter. Inductiveload—talk/contribs 08:36, 8 September 2021 (UTC)

@Inductiveload: Much thanks for the explanation. — Ineuw (talk) 09:25, 9 September 2021 (UTC)

@Ineuw: FYI, the CSS should go in the /styles.css subpage of the Index page, so it will also be applied in the mainspace on transclusion. More details at H:Page styles. Inductiveload—talk/contribs 06:36, 10 September 2021 (UTC)

Thanks again. Understood.— Ineuw (talk) 05:16, 11 September 2021 (UTC)

Results for the 2021 Wikimedia Foundation Board of Trustees election

Read in other languages

---

Thank you to everyone who participated in the 2021 Board election. The Elections Committee has reviewed the votes of the 2021 Wikimedia Foundation Board of Trustees election, organized to select four new trustees. A record 6,873 people from across 214 projects cast their valid votes. The following four candidates received the most support:

1. Rosie Stephenson-Goodknight
2. Victoria Doronina
3. Dariusz Jemielniak
4. Lorenzo Losa

While these candidates have been ranked through the community vote, they are not yet appointed to the Board of Trustees. They still need to pass a successful background check and meet the qualifications outlined in the Bylaws. The Board has set a tentative date to appoint new trustees at the end of this month.

Read the full announcement here. Xeno (WMF) (talk) 01:56, 9 September 2021 (UTC)

Call for Candidates for the Movement Charter Drafting Committee ending 14 September 2021

Movement Strategy announces the Call for Candidates for the Movement Charter Drafting Committee. The Call opens August 2, 2021 and closes September 14, 2021.

The Committee is expected to represent diversity in the Movement. Diversity includes gender, language, geography, and experience. This comprises participation in projects, affiliates, and the Wikimedia Foundation.

English fluency is not required to become a member. If needed, translation and interpretation support is provided. Members will receive an allowance to offset participation costs. It is US$100 every two months.

We are looking for people who have some of the following skills:

• Know how to write collaboratively. (demonstrated experience is a plus)
• Are ready to find compromises.
• Focus on inclusion and diversity.
• Have knowledge of community consultations.
• Have intercultural communication experience.
• Have governance or organization experience in non-profits or communities.
• Have experience negotiating with different parties.

The Committee is expected to start with 15 people. If there are 20 or more candidates, a mixed election and selection process will happen. If there are 19 or fewer candidates, then the process of selection without election takes place.

Will you help move Wikimedia forward in this important role? Submit your candidacy here. Please contact strategy2030wikimedia.org with questions.

---

This message may have been sent previously - please note that the deadline for candidate submissions was extended and candidacies are still being accepted until 14 September 2021. Xeno (WMF) 17:16, 10 September 2021 (UTC)

Copyright-relevant properties for Wikidata - comments sought

I have opened two property proposals at Wikidata for recording of copyright data that is currently not covered by their data models.

• Wikidata:Property proposal/copyright registration
• Wikidata:Property proposal/relevant date for copyright

In theory, these properties would allow automation of quite some boilerplate here at Wikisource. For example a template of the format {{PD/US|1941}} could be generated for Mrs. Dalloway.

I invite anyone with an interest in Wikidata modelling of Wikisource-adjacent data to comment on those proposals (and/or suggest alternatives, improvements, existing ways to models the information, etc). Inductiveload—talk/contribs 21:58, 10 September 2021 (UTC)

Server switch

Read this message in another language • Please help translate to your language

The Wikimedia Foundation tests the switch between its first and secondary data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster. To make sure everything is working, the Wikimedia Technology department needs to do a planned test. This test will show if they can reliably switch from one data centre to the other. It requires many teams to prepare for the test and to be available to fix any unexpected problems.

They will switch all traffic back to the primary data center on Tuesday, 14 September 2021.

Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.

You will be able to read, but not edit, all wikis for a short period of time.

• You will not be able to edit for up to an hour on Tuesday, 14 September 2021. The test will start at 14:00 UTC (07:00 PDT, 10:00 EDT, 15:00 WEST/BST, 16:00 CEST, 19:30 IST, 23:00 JST, and in New Zealand at 02:00 NZST on Wednesday, 15 September).
• If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.

Other effects:

• Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
• We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.

This project may be postponed if necessary. You can read the schedule at wikitech.wikimedia.org. Any changes will be announced in the schedule. There will be more notifications about this. A banner will be displayed on all wikis 30 minutes before this operation happens. Please share this information with your community.

SGrabarczuk (WMF) (talk) 00:46, 11 September 2021 (UTC)

Talk to the Community Tech

Read this message in another language • Please help translate to your language

Hello!

As we have recently announced, we, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on September 15th, 23:00 UTC on Zoom, and will last an hour. Click here to join.

Agenda

• How we prioritize the wishes to be granted
• Why we decided to change the date from November 2021 to January 2022
• Update on the disambiguation and the real-time preview wishes
• Questions and answers

Format

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (first three points in the agenda) will be given in English.

We can answer questions asked in English, French, Polish, and Spanish. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

• Join online
• Meeting ID: 898 2861 5390
• One tap mobile
  • +16465588656,,89828615390# US (New York)
  • +16699006833,,89828615390# US (San Jose)
• Dial by your location

See you! SGrabarczuk (WMF) (talk) 03:04, 11 September 2021 (UTC)

Sacred-Texts.com (an online library of religious texts)

While I frequent Wikisource as a reader I don't edit here, so I am quite curious if there are any efforts to reach out to entire websites to import them. While researching religion in South Vietnam I recently found a website called Sacred-Texts.com, they seem to know a lot about US copyright and try to make sure that as much as possible on their website is in the public domain. This website seems like "a perfect match" for the English-language Wikisource, is it already being used as a source? Is it useful or do the actual texts need to be available and not just online transcriptions? -- DonTrung (徵國單)  (討論 🤙🏻) (方孔錢 ☯) 12:50, 12 September 2021 (UTC)

•  DonTrung (徵國單) : Generally speaking, importation of text from other sites (such as Project Gutenberg and Sacred Texts) is heavily discouraged now-a-days, especially if there exist scans of the works in question. To answer your question, it is used as a source in some places, although I can’t point to any at the moment. If you would like to edit, I could try to point to a scan of a work on Sacred Texts; although from experience I can say that works from there are rarer. TE(æ)A,ea. (talk) 14:40, 12 September 2021 (UTC)

@Donald Trung: yes, please try to find a scan before working on these projects. I have no objection to usage of the websites as a replacement for preliminary OCR, but they should be proofread in the Index and Page namespaces. PseudoSkull (talk) 16:12, 12 September 2021 (UTC)

I once tried to use it as a source for something in the Sacred Books of the East, but there were enough discrepancies and formatting issues (generally sacred-texts.com doesn't preserve all the formatting) to make it not especially practical (but also not impractical). Perhaps with a more "intelligent" conversion script you could do better, but at least for works with good page scans, I judged it about that same amount of effort to just do it from decent OCR. If the only source was poor quality images and didn't OCR, it would probably be better. Inductiveload—talk/contribs 16:48, 12 September 2021 (UTC)

Problem with poem extension in mobile view

Wikilover407 has pointed out a weird problem with the poem extension. If a poem spans across page breaks, then a gap appears at the place of a page break in the mobile view, no matter if there is an end of a stanza or if it is in the middle of the stanza. However, it looks OK in the desktop view. See e. g. One Hundred Poems of Kabir/IV, (screenshot of the mobile view). I have checked it with other poems too and encountered the same problem there. --Jan Kameníček (talk) 06:26, 13 September 2021 (UTC)

Known problem, which is why most of us have stopped using the poem tags for poetry, and instead use block templates with explicit linebreaks <br />. Beeswaxcandle (talk) 07:04, 13 September 2021 (UTC)

I've done very little with poems so maybe this is a dumb question but: Shouldn't the </poem> tag on the first page have been put in the footer, and then the opening <poem> tag on the second page been put in the header? That way the transcluded form doesn't include either of them? — Dcsohl (talk)
(contribs) 12:46, 13 September 2021 (UTC)

@Dcsohl: It's a good question, but this doesn't work for <poem>, because it's not a template that inserts markup, it's a parser tag that begins a new processing "mode" within the server software. This must all happen on a single page, so you can't "distribute" the tags between multiple pages. Also you cannot interleave the tags like <noinclude><poem></noinclude>...</poem>.

{{ppoem}} is an experimental attempt to do better than <poem> (and the <br/> hack), both of which produce pretty awful markup. It's getting close to a point at which I think it think it's suitable for general use, at least in simpler cases. Inductiveload—talk/contribs 12:59, 13 September 2021 (UTC)

Tech News: 2021-37

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

• 45 new Wikipedias now have access to the Growth features. [4]
• A majority of Wikipedias now have access to the Growth features. The Growth team has published an FAQ page about the features. This translatable FAQ covers the description of the features, how to use them, how to change the configuration, and more.

Problems

• All wikis will be read-only for a few minutes on 14 September. This is planned at 14:00 UTC. [5]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 September. It will be on non-Wikipedia wikis and some Wikipedias from 15 September. It will be on all wikis from 16 September (calendar).
• Starting this week, Wikipedia in Italian will receive weekly software updates on Wednesdays. It used to receive the updates on Thursdays. Due to this change, bugs will be noticed and fixed sooner. [6]
• You can add language links in the sidebar in the new Vector skin again. You do this by connecting the page to a Wikidata item. The new Vector skin has moved the language links but the new language selector cannot add language links yet. [7]
• The syntax highlight tool marks up code with different colours. It now can highlight 23 new code languages. Additionally, golang can now be used as an alias for the Go programming language, and a special output mode has been added to show a program's output. [8][9]

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

15:35, 13 September 2021 (UTC)

Early modern and Modern author?

Hi. How is it that Author:Robert Henry Thouless can be both a Early modern and Modern author at the same time? Mpaa (talk) 22:24, 14 September 2021 (UTC)

Why not? If you have defined time periods for "early modern" and "modern", then somebody is going to cross that time period. In this case, it's automatic categorization based on the fact he was alive before 1900 and after 1900. A bit crude, but it's unerring; as long as Wikidata has birth and death years correctly, it will put them in those categories based on those years, something you can't say if you want to base it on publication dates, and even then, you'll still have "early modern" and "modern" on the same author unless we're getting completely subjective.--Prosfilaes (talk) 23:01, 14 September 2021 (UTC)

I was expecting more an either/or way, but it makes sense. Then the wording in Category:Authors by era needs rephrasing: "This category and its subcategories groups authors according to the era they were born in (see the table below). Where their lives occur in two eras, the one they wrote most of their works in is used."
Thanks for the explanation.Mpaa (talk) 18:07, 15 September 2021 (UTC)

FYI: Preloading derived header templates for serials and compilation works

A reminder that where you are working on a serial or a larger compiled work, that we are comfortable in setting up a derived header template for the work. Apart from just making life easier, it is in fact broadly quite useful to do so when working with some tools, for example Petscan, and for bulk loading data into Wikidata. If you need assistance in creating a derived header, then feel welcome to give me a ping. There are examples linked from the base template.

Further, with the mediawiki setup there is the means to have a preload functionality to have the template load into the subpages of the work so one can just complete the data. This bit does need to be undertaken by administrators due to it relationship to the Mediawiki namespace.

Happy to answer any questions here, or ping me from the talk page of the template of interest. — billinghurst sDrewth 00:23, 15 September 2021 (UTC)

What is the best way to deal with a text that is serialized in a periodical? It seems that the header should contain two previous/next entries. The first being the previous/next of the stories in that issue. The second being the previous/next part of the text. For example, for "A Scandal in Bohemia", the next story in The Strand is "The Bundle of Letters", but the next story in the Adventures of Sherlock Holmes is "The Red-Headed League" How should this be managed? Languageseeker (talk) 01:27, 15 September 2021 (UTC)

• Languageseeker: See {{series}}, used e.g. here. TE(æ)A,ea. (talk) 01:33, 15 September 2021 (UTC)

The next story in The Adventures of Sherlock Holmes is a bad example. The Adventures of Sherlock Holmes is a collection, not a work serialized in a magazine, and there's no need to link the stories published in the Strand in the order of that collection.--Prosfilaes (talk) 02:19, 15 September 2021 (UTC)

@TE(æ)A,ea.: Thank you!

@Prosfilaes: Hmm, I'm not too sure about that. The Strand magazine had them listed as part of a work with a distinct order Page:The Strand Magazine (Volume 2).djvu/663. It seems to me as if they were meant to be a whole. Languageseeker (talk) 04:35, 15 September 2021 (UTC)

Okay, I guess they did.--Prosfilaes (talk) 04:40, 15 September 2021 (UTC)

Entering a new work

I have an autobiography for a Frank Tweedy hand typed by him in 1924 that I have transcribed in a Word file to upload to Wikisource for use as a source in a Wikipedia biography on Tweedy I have co-authored. I cannot for the life of me figure out how to do this. I have spent hours trying to go through Help and I have gotten no further toward uploading this autobiography. Am I missing something? Noel Andrew Sherry (talk) 00:50, 15 September 2021 (UTC)

@Noel Andrew Sherry: Ah, very interesting that you have that. The Wikipedia article Sherry is referring to for context, for anyone else reading: Frank Tweedy. A few minutes of poking around and I could not find an original scan, but I did find what appears to be your transcription of the work at File:Life of Frank Tweedy.pdf. Very nice work.

A few things to note:

• I think 1924 above is a typo because your transcription says he wrote the autobiography in 1926, so different rules apply than normal. I believe that this work is unpublished, but I could be wrong (you probably know more about this Mr. Tweedy than I do). Normally that would not be acceptable here, but since Tweedy died over 70 years ago (in 1937), and according to your transcription it was signed by him, the work is actually in the public domain, meaning it is free of copyright restrictions in the United States. And if it was published, there was no copyright notice, so even if that's the case it would be in the public domain as well. Worst case, if it was published and there was a copyright notice that you did not place in the transcription, then I see no evidence of renewal. So, while it was quite generous for you to get permission from someone of Tweedy's estate and while it was quite generous that that person allowed you to transcribe it under a CC license, their permission or accreditation is not explicitly legally required for reuse, so a CC license was not necessary. So, the license tag should be either Template:PD-US-unpublished or Template:PD-US-no-notice. Your own current PDF file containing the transcription may (possibly) be eligible for copyright under a CC license depending on the level of originality you provided in your PDF. (Not to say you shouldn't credit them, but the PD license is meant to show the precise legal situation of the work.)
• So, since the work is out of copyright according to evidence available to me, something we recommend is that you scan the original autobiography (if a scan does not exist online; I haven't found one after some digging), and upload an original scan of the autobiography to Wikimedia Commons (see Help:Digitising texts and images for Wikisource for recommended methods). Then we recommend that you proofread the work based on the scan provided (see Help:Proofread to learn about the process). A summary is that you first create an index page, and proofread the pages within them page by page. Then when work is done, you transclude the transcription. I understand proofreading here is a little bit of a process and may take some getting used to, but feel free to ask any questions you want about it as well. The reason we recommend the scan backing is to prove that what is transcribed here appeared in the original on the precise pages they are found.
• If it is not possible for you to retrieve the document from the grand niece again and therefore scanning is impossible, entering the work as-is on a page like Autobiography of Frank Tweedy may be acceptable. However, I do not recommend this unless there is no other solution.

Thanks for offering this rare content. Hope you enjoy your time here! PseudoSkull (talk) 12:38, 15 September 2021 (UTC)

Hello PseudoSkull, Wow this is thorough, helpful, thankyou. I am new to Wikisource and Wikimedia, but have written 4 articles now for Wikipedia, one co-authored on Frank Tweedy, then three botanical articles on species Frank Tweedy collected as an amateur but accomplished botanist. Will process this in a few days. Thanks for the help as I get started here. Noel Andrew Sherry (talk) 13:11, 15 September 2021 (UTC)

@Noel Andrew Sherry PseudoSkull has given a very good précis of how to get started here. Assuming the copyright situation is fine:

Generally, we prefer scan-backed works (i.e. with a scan of the original work). If you can, the first thing to do is upload a PDF of the scanned original document. If you need help assembling a set of images into a document, let me know (type {{ping|inductiveload}} in any comment to alert me, or drop a note on User talk:Inductiveload and we'll sort something out.

Then, say you uploaded the scanned file to File:Life of Frank Tweedy (original).pdf, you would create Index:Life of Frank Tweedy (original).pdf and that will allow you to enter the transcription next to each page. Again, I can help you set this up. Finally, once the text is entered, you would Transclude the proofread pages to Autobiography of Frank Tweedy.

Welcome to Wikisource, and I truly hope you stick around even once this project of yours is complete! Inductiveload—talk/contribs 13:22, 15 September 2021 (UTC)

@Noel Andrew Sherry: By the way, another page you may find useful, since you are used to editing Wikipedia, is Wikisource:For Wikipedians. Good luck! PseudoSkull (talk) 13:35, 15 September 2021 (UTC)

I was wondering if Word could export to pdf yet.--RaboKarbakian (talk) 14:31, 15 September 2021 (UTC)

ProofreadPage Lua library will be available from today

After the deployment of Mediawiki 1.37-wmf.23 later today, a Lua library will be included in the Proofread Page extension used by Wikisource. The primary use of this library is to allow templates and modules to access proofreading statistics of indexes and individual pages.

There is an API reference here: mw:Extension:Proofread Page/Lua reference, and you can also see an example of a template here at enWS that uses the API at {{index progress bar}} (it provides a "live" progress bar of a given index). Note that this page will show a Lua error until the deployment actually happens later on.

I'd like to thank @User:Tpt and @DannyS712 for their huge patience and help in getting this from a very mediocre implementation to one far better and more powerful than I originally dreamed possible.

As always, let me know if I can be of assistance if you'd like help using this library! Inductiveload—talk/contribs 14:59, 15 September 2021 (UTC)

Oh wow, this is an amazing development. Really looking forwards to seeing it in action. A huge thanks to everyone who worked on this and made it possible. Languageseeker (talk) 15:11, 15 September 2021 (UTC)

Update: This has just been deployed (a little late because the release train was blocked on something unrelated):

{{index progress bar|Index:Galileo Galilei and the Roman Curia (IA cu31924012301754).pdf}}

Inductiveload—talk/contribs 13:36, 16 September 2021 (UTC)

Great job! Mpaa (talk) 17:27, 16 September 2021 (UTC)

Tech News: 2021-38

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

• Growth features are now deployed to almost all Wikipedias. For the majority of small Wikipedias, the features are only available for experienced users, to test the features and configure them. Features will be available for newcomers starting on 20 September 2021.
• MediaWiki had a feature that would highlight local links to short articles in a different style. Each user could pick the size at which "stubs" would be highlighted. This feature was very bad for performance, and following a consultation, has been removed. [10]
• A technical change was made to the MonoBook skin to allow for easier maintenance and upkeep. This has resulted in some minor changes to HTML that make MonoBook's HTML consistent with other skins. Efforts have been made to minimize the impact on editors, but please ping Jon (WMF) on wiki or in phabricator if any problems are reported.

Problems

• There was a problem with search last week. Many search requests did not work for 2 hours because of an accidental restart of the search servers. [11]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 September. It will be on non-Wikipedia wikis and some Wikipedias from 22 September. It will be on all wikis from 23 September (calendar).
• The meta=proofreadpage API has changed. The piprop parameter has been renamed to prpiprop. API users should update their code to avoid unrecognized parameter warnings. Pywikibot users should upgrade to 6.6.0. [12]

Future changes

• The Reply tool will be deployed to the remaining wikis in the coming weeks. It is currently part of "Discussion tools" in Beta features at most wikis. You will be able to turn it off in Editing Preferences. [13]
• The previously announced change to how you obtain tokens from the API has been delayed to September 21 because of an incompatibility with Pywikibot. Bot operators using Pywikibot can follow T291202 for progress on a fix, and should plan to upgrade to 6.6.1 when it is released.

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

18:32, 20 September 2021 (UTC)

Proposal: Move the Collaboration Box to above the New Text Box

Currently, the Collaboration Box is on the lower right hand corner of enWS. The proposal would move the box to the upper left hand corner just above the New Texts box. Experience on frWS has shown that this increases participation due to greater visibility. Languageseeker (talk) 11:56, 20 September 2021 (UTC)

No, absolutely not. Your project is not the top priority here. — billinghurst sDrewth 12:06, 20 September 2021 (UTC)

As the current collaboration box stands, it's far too big for the top-right spot, as it would push New texts below the fold. frWS has a much slimmer front-page box than {{Collaboration}} (or even just {{Collaboration/MC}}) currently is. I'm not dead-set against the concept (and I agree that frWS does do a much better job of driving interest, though I'm not sure that that box's position is the deciding factor), but I'm not in favour of simply re-arranging the existing elements as they are.

That said, I also quite like the slightly more in-depth presentation that the current below-the-fold position allows. Inductiveload—talk/contribs 12:37, 20 September 2021 (UTC)

@Billinghurst: It's not my project. It's an attempt to increase community collaboration.

@Inductiveload: Do you think this can be done without reducing the number of community collaborations? Currently, we have four: MC, POTM, COTW, and MoTM. Languageseeker (talk) 00:30, 21 September 2021 (UTC)

"Your project" as in "your football team". Contributions come from many sources, and having a singular focus to those additions is a limited focus, and not one that I favour. It is not the top priority. — billinghurst sDrewth 03:29, 21 September 2021 (UTC)

@Languageseeker: not in any form similar to how it is right now: the frWS model doesn't present any other collaboration on the front page. Inductiveload—talk/contribs 08:42, 21 September 2021 (UTC)

Spam account "created automatically" and so I don't see it in "Recent changes"?

So I spot a bit of spamming and revert. Then look for more. Then realize that even though the account was recent I can't see it in the "Recent changes" logs.

Sandeepkushwaha65 account was created 05:35, 21 September 2021, almost immediately following by the edit summary spam at 05:37. I reverted at 06:27. I could see the spamming, but I couldn't see the account creation just two minutes before?

I compared with another new account and noticed a difference

05:30, 21 September 2021 User account Altonsnike talk contribs was created

vs.

05:35, 21 September 2021 User account Sandeepkushwaha65 talk contribs was created automatically

What is "created automatically"? How is that done? Is this a hole, where we can't know a spamming account has been created? Shenme (talk) 06:51, 21 September 2021 (UTC)

The account was automatically created at enWS on login, because the account is SUL'ed from bh.wikipedia. See Special:CentralAuth/Sandeepkushwaha65. I'm not sure such account creations are visible in the RC view, but you can see them at Special:Log. Inductiveload—talk/contribs 07:39, 21 September 2021 (UTC)

Links to LCCN subjects in the Authority Control

I have noticed that the link to the Hussite Wars subject, as provided in the Authority Control box at the bottom of Portal:Hussite Wars, does not work. The link is taken from Wikidata. Surprisingly, if the link is clicked directly in Wikidata, it works well. For some reason the link from WD goes to https://id.loc.gov/authorities/subjects/sh85015311.html, while the link from our portal, although taken from WD, goes to https://id.loc.gov/authorities/names/sh85015311.html . How can it be fixed? --Jan Kameníček (talk) 09:33, 21 September 2021 (UTC)

@Jan.Kamenicek: It looks like https://id.loc.gov will transparently redirect to the correct subpath for either /name or /subjects, so Special:Diff/11705158 should do the trick. Inductiveload—talk/contribs 10:11, 21 September 2021 (UTC)

Great! Thanks. --Jan Kameníček (talk) 10:57, 21 September 2021 (UTC)

Poor Robin's True Character of a Schold

@Inductiveload: This is labeled as being 1678, but it's clearly not. Look at real books from 1678. To be concrete, it doesn't use the long-s, and it uses very weird fonts for that time, and it doesn't use italics properly for the era. After glancing through those books, I found one that actually shows the original: [14]. It doesn't look complete, though. At the very least, we should mark it and the files it uses as being from a Victorian (?) era reprint, and it's clearly been normalized to the traditions of a more modern era with modern illustrations; our copy starts "A RANK SCOLD is a Devil of the feminine gender; a serpent, perpetually hissing, and spitting of venom;" compared to "A Rank SCOLD is a Devil of the Feminine gender; a Serpent, perpetually hissing, and spitting of Venom;" in the original.--Prosfilaes (talk) 07:18, 13 September 2021 (UTC)

@Prosfilaes: hmm, true enough. I'm not sure how to mark it up without a more concrete bibliographic record though. A note in the header field? Inductiveload—talk/contribs 07:37, 13 September 2021 (UTC)

@Inductiveload: I've found the book our version comes from, "The Old Book Collector's Miscellany" (1872) (later published as "A Collection of Readable Reprints of Literary Rarities" in 1876), edited by Charles Hindley.

• https://archive.org/details/oldbookcollecto01hindgoog/page/n623/mode/2up (1872)
• https://archive.org/details/cu31924013352848/page/n207/mode/2up (1873)
• https://archive.org/details/acollectionread00hindgoog/page/n87/mode/2up (1876)

-- ei (talk) 18:06, 22 September 2021 (UTC)

Undine (1909)

1.) The work is actually from 1919, so I'm pretty sure 1909 is a typo in this title. 2.) The chapters need to be changed to "Chapter 1", "Chapter 2", etc. because according to User:RaboKarbakian, the proofreader, they are not short stories but rather logically consecutive elements of the same story. PseudoSkull (talk) 00:58, 10 September 2021 (UTC)

The translation is from 1909, as it was explained to me by whoever moved it. User:languageseeker is changing the sizes of the images, maybe there is a good reason for that, but the two were sized to go with each other.--RaboKarbakian (talk) 02:00, 10 September 2021 (UTC)

Oh, then I apologize for the misinterpretation on my part. Anyway, I struck that part of the request out. PseudoSkull (talk) 02:11, 10 September 2021 (UTC)

@RaboKarbakian: My apologies as well. The image sizes are quite small and I wanted to increase them so that they would better match the source text. Perhaps, it would be better to merge the two images into one like we do with maps? Languageseeker (talk) 03:20, 10 September 2021 (UTC)

Inductiveload set a 360px wide limit on images, I break that all the time, but not with 1000pxs which your changes would have made. Also, the different widths had to do with having the same height, Moreover, just a few days ago, Billinghurst did some <includeonely> sourcery that caused them to appear side by side, so even more not to screw up. Did you see it in its Mainspace or just in the Page space?--RaboKarbakian (talk) 03:25, 10 September 2021 (UTC)

@RaboKarbakian: I made no such "limit". You simply need to be aware that a typical mobile screen is roughly 360 effective pixels wide, so you should ensure that whatever you do do displays sensibly on a screen that width. However, care has been taken with the mobile website skin and some image templates like {{FI}} to make this not a problem for images with "native" sizes (i.e. the size actually served by MediaWiki) larger than that size. Most e-readers (at least all that I have tried) will also scale images to fit the screen if needed.

If in doubt, mobile simulation mode can be used in your browser to check: Help:Preparing_for_export#Online_viewing. Inductiveload—talk/contribs 06:29, 10 September 2021 (UTC)

Done; all the chapter subpages have been moved to their proper places. I also deleted a lot of redirects from a previous move which were redundant. PseudoSkull (talk) 00:34, 24 September 2021 (UTC)

Movement Charter Drafting Committee - Community Elections to take place October 11 - 24

Dear fellow Wikimedians,

This is an update from the Movement Charter process. We have closed the call for candidates on September 14 for the Drafting Committee and now have a pool of candidates with diverse backgrounds to choose from. As the number of candidates is quite large and thus informing yourself about them might be a bit more complicated, we want to try something different this time: an “Election Compass", more about it in this page.

The 15 member committee will be selected with a 3-step process:

• Election process for project communities to elect 7 members of the committee.
• Selection process for affiliates to select 6 members of the committee.
• Wikimedia Foundation process to appoint 2 members of the committee.

Communities elect 7 members

This announcement is related to the community elections, which will take place in a time period of 2 weeks from October 11 to October 24. We look forward to a wide participation across the communities to create the committee to curate the writing of the Movement Charter. The Election Results will be published on November 1.

Affiliates select 6 members

Parallel to the election process, all affiliates asked to contribute as well: All affiliates were divided into eight geographic and one ‘thematic’ region (check the list), and each region chooses one person who will act as a selector for that region. These 9 selectors will come together to select 6 of the committee (from the same pool of candidates). The selection results will be published on November 1.

Wikimedia Foundation appoints 2 members

Finally, the Wikimedia Foundation will appoint two members to the committee by November 1.

All three processes will be concluded by November 1, 2021, so that the Movement Charter Drafting Committee can start working by then.

For the full context of the Movement Charter, its role, as well the process for its creation, please have a look at Meta. You can also contact us at any time on Telegram or via email (wikimedia2030@wikimedia.org).

Best regards, --Civvi (WMF) (talk) 10:27, 23 September 2021 (UTC)

Drop initial + long second line in poetry formatting

• Hi all, I'm proofreading some poetry and came across a strange issue on this page -- Page:The Atlantic Monthly, Volume 19.djvu/27. I'll reproduce it here:

Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation

Basically, when inside a Template:Center block block with automatic width, usage of Template:Dropinitial along with "<br />" at the end of the somewhat long second line on the page is causing that line to break early, causing a line wrap one word before it should be, and that new "third" line ending immediately after that word. This happens using both "center block" and "block center."

I seem to have identified what is going on. This seems to be happening because "block center" calculates the maximum width of a line within the block before shifting this second line, which then causes that line to overflow when it is later rendered. The only way I have found that gets around this apparent error is to manually set the width of the center block to something that will be large enough to fit the entire second line, though this is perhaps not ideal. Any thoughts? Or is this just one of those cases where the best thing is to do the hacky thing? -- Mathmitch7 (talk) 20:12, 23 September 2021 (UTC)

@Mathmitch7: as far as I am aware (and I would dearly love to be corrected) this is an artifact of the CSS box model and how the widths are laid out. I tried for a very long time to avoid it with {{ppoem}} and failed. Setting a manual width is all that I could figure out. Sorry! Inductiveload—talk/contribs 09:42, 24 September 2021 (UTC)

I generally deal with this by adding an appropriately-long {{gap}} at the end of the first line.

Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation

Unfortunately it causes its own issues when the page is narrow and the first line wraps anyway, but it's the best I've found (and I prefer it to manual widths) —Beleg Tâl (talk) 13:08, 24 September 2021 (UTC)

{{Ditto}} is another possible hack:

Lconsectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.orem ipsum dolor sit amet,
consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation

The advantage is that you just copy the longest line into the template and do not have to figure our how long the gap should be. But it’s still just a hack, it would be better if some systematic solution could be found. --Jan Kameníček (talk) 13:27, 24 September 2021 (UTC)

FYI, both those approaches will almost certainly cause export issues: e.g. phab:F34652540 (in Koreader). Setting a manual width on {{center block}} will be OK because there's a (very deliberate) CSS rule of max-width:100% there.

Also, the gap method doesn't work for me, because in the font my browser is using (DejaVu Sans), 32em is too short.

As a general rule-of-thumb, any use of {{gap}} to "fake" alignment will probably not export correctly, because it guarantees something will go wrong as soon as there is a line break. Inductiveload—talk/contribs 14:14, 24 September 2021 (UTC)

Why is the extant means unmentionable?

UST so you haz to ask Us how we subverted it! "proofreading is easy, we just try to make it difficult" (to keep people you would avoid busy)

—unsigned comment by Cygnis insignis (talk) 15:50:22.

@Cygnis insignis: I am not quite sure what that is supposed to achieve, because without the left-hand cell, a 100%-width table is just the same as no table at all, and if you wanted to hardcode a left margin to "fake" text near the middle on a certain width of screen (which is, I hope self-evidently, a dreadful idea in terms of responsive design), you would not use a dummy table cell full of junk to do so. You would apply a margin-left.

If if you use a flexible-width table, it's the same. Indeed, {{center block}} usually uses display:table;, so there's literally no difference when it comes to layout in the CSS engine:

This is a table

Lorem ipsum dolor sit amet,

consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.
Ut enim ad minim veniam,
quis nostrud exercitation

Also do bear in mind that the width attribute is deprecated by the web standards bodies, so rather than width=100%, the correct markup is style="width:100%;". Inductiveload—talk/contribs 16:29, 24 September 2021 (UTC)

"I am not quite sure what that is supposed to achieve …" sorry cousin, stopped reading after that, but I'm not saying it is not pertinent [as it were]. Cygnis insignis (talk) 16:38, 24 September 2021 (UTC)

Proposal: Consolidate the Community Collaboration Projects

Currently, on enWS, there are four Community Collaboration Projects featured on the front page: Monthly Challenge, Proofread of the Month, Maintenance of the Month, and Community Collaboration. Of these, Maintenance of the Month and Community Collaboration are defunct, but still occupy the front page. As a result of these multiply collaborative projects, enWS does not have a central location to direct volunteers who wish to contribute. I propose the following. First, formally eliminating Maintenance of the Month and Community Collaboration. Their templates will be marked as deprecated and the Community Collaboration box will be reduced in size. Second, merge Proofread of the Month into Monthly Challenge. The Monthly Challenge project can easily feature a Proofread of the Month text and the Nominations page of the MC is more visible than the nomination page for PoTM. In the end, the Community Collaboration will be reduced to only the Monthly Challenge which will become the central hub for Community Collaboration on enWS. Languageseeker (talk) 13:40, 21 September 2021 (UTC)

a) I see this as the wrong question, it should be "how do we rejuvenate the two dormant collaborations?" When we get them back up and running again, then we can look at how best to represent them all on the Main page. Please offer suggestions on how to bring them back.

b) As to merging PotM with the experimental Monthly Challenge (remembering that we only agreed with setting it up as a trial), this is a premature proposal. The two currently have very different points of focus. The Monthly Challenge's principal focus is to get a certain volume of pages proofread and/or validated in a time period—and, it doesn't matter what work or works those pages come from. PotM has a focus on taking a work we don't already host and taking it through to completion. Given this disparity in approach, I can't agree with merging the two at present. Beeswaxcandle (talk) 09:10, 22 September 2021 (UTC)

• Beeswaxcandle: “Experimental” seems an incorrect term; while Monthly Challenge has completed over 2000 pages this month, PotM has done nothing. (The “trial” seems rather successful.) I agree that it is preferable to rejuvenate the defunct collaborations, but such work can only come through community desire. You, too, should “offer suggestions on how to bring them back.” The work which was done through Community Collaboration, for instance, could easily be rolled into work at Monthly Challenge. Your claim regarding the focus of PotM is also rather sophistic—it has been years since that project has consistently completed works month-by-month, and that problem has only gotten worse in the past year. Even in only one month, May 2021 was the last time any work was completed on time—and that work was only 93 pages. TE(æ)A,ea. (talk) 20:36, 22 September 2021 (UTC)

• Languageseeker: Oppose merging PotM and MC. At the moment, this seems premature, as those two still appeal to slightly different desires. Oppose hard-deletion of the other collaborations at the moment. Community collaboration used to be a more general place for suggesting proposals for work, but had become (before it became functionally defunct) another proofreading collaboration project. Thus, I believe that project can be phased out. As for MotM, there is much M to do, and many Ms in which to do M; certainly, I would like to see that collaboration brought back. However, the last attempt to restart that project was strongly opposed by a number of people, including you, Beeswaxcandle; but that is not relevant, as that proposal has not been raised here. TE(æ)A,ea. (talk) 20:36, 22 September 2021 (UTC)

• • @Beeswaxcandle, @TE(æ)A,ea.: I see both of you raising similar concerns and please allow me to answer both of you simultaneously. I am not against the ideas of these individual projects, but the administrative burden and user confusion that they generate. Four separate community collaboration project requires four different users to administer them, four different set of nomination pages, and four different places for users to visit if they wish to participate. Even worse, if a work gets nominated for one project, it cannot be nominated for another. In addition, to these four places to nominate a text, there are at least four separate places to request a text. I simply see too much confusion and fragmentation. My goal is to consolidate things to simplify and make them more efficient. As I'm running the MC, I'm trying to look for good maintenance works (i.e. works that have been worked on, but have stalled); I'm looking at texts that people have requested; I'm looking for texts that should be scan-backed; and I'm trying to think of texts that would attract a broad category of users. My ultimate desire is not merely to achieve a certain number of pages proofread/validated a month, but to increase the number of scan-backed texts and the number of volunteers willing to contribute to enWS. It is my ardent belief that one central hub will be far more effective than four separate projects of varying quality. Languageseeker (talk) 01:51, 25 September 2021 (UTC)

• Wrong question, we PROMOTE two community activities, PotM and the Monthly Challenge, and that is suitable. The other two are still in existence though not pushed, and that is okay; if people edit there, that is okay; and the maintenance still needs to be done. If people wish to contribute to any Wikisource:WikiProject that is okay. If they wish to do their own works, that is okay. What makes you think that the MC is the only game in town? Your singular focus is getting annoying to me, we are more than that. — billinghurst sDrewth 06:01, 25 September 2021 (UTC)

A Short View of the Frauds and Abuses committed by Apothecaries

There are a lot of things that need to be done here because this has become convoluted, and I'll explain each step.

1. Delete Merret - A short view of the frauds and abuses committed by apothecaries/Title as it's just a duplication of the content at A Short View of the Frauds and Abuses committed by Apothecaries.
2. Move A Short View of the Frauds and Abuses committed by Apothecaries to A Short View of the Frauds and Abuses Committed by Apothecaries. Reason: If we're going to do title casing, we should do it consistently.
3. Move Merret - A short view of the frauds and abuses committed by apothecaries/Chapter 1 to A Short View of the Frauds and Abuses Committed by Apothecaries/Essay. First of all, these don't need to be chapters, because they're not really "chapters" and are not labelled as such. Secondly, the transcluded sections here have different titles than the front matter page does. The page title was clearly taken from the name of the index page, whether accidentally or not I don't know.
4. Move Merret - A short view of the frauds and abuses committed by apothecaries/Chapter 2 to A Short View of the Frauds and Abuses Committed by Apothecaries/Postscript. Same reasons as for #3.

Pinging @Chrisguise: to let know of move discussion. PseudoSkull (talk) 16:55, 14 September 2021 (UTC)

Done. Mpaa (talk) 05:23, 17 September 2021 (UTC)

Apologies for the work caused - it was one of my earliest contributions and I hadn't really got the hang of transclusion (some may say I still haven't ......) Chrisguise (talk) 09:04, 25 September 2021 (UTC)

Position of clickable Wiki markup

Why does the clickable Wiki markup for inserting into the edited text ( – — {{}} {{{|}}} | [] [[|]] etc.) appear absolutely unpredictably sometimes above the editing window and sometimes below? Is it possible to fix it at either of those two positions? --Jan Kameníček (talk) 13:12, 25 September 2021 (UTC)

It (only) changes position for me when I toggle the edit bar in preferences.--RaboKarbakian (talk) 15:22, 25 September 2021 (UTC)

Meanwhile I have found a "system" in its appearance: While in main, author and even index namespaces it appears below, in the page namespace it appears above the editing area for some reason. Which means that I first have to think which namespace I am editing and only then I can scroll in the correct direction. It is not a crucial thing, just one of those details that slow one down. --Jan Kameníček (talk) 16:35, 25 September 2021 (UTC)

The last time I used it, which was months ago by now, it froze up. To "unfreeze" things, I had to wait or toggle which character set to use. It was more problem than production, so, hence, the months since then....--RaboKarbakian (talk) 17:12, 25 September 2021 (UTC)

@Jan.Kamenicek: It is an interplay of how the skins and the divisions are playing with each other and this sounds like something with your browser, your skin, the ProofreadPage extension and its hooks into the editing screen. It only ever appears below for me—Monobook skin, in Firefox. I would suggest playing with your browser width to see if that makes any difference to push that tool DIV above the editing DIV. For a test maybe try changing skins to see if the behaviour is the same. @Inductiveload: should this be a phab ticket for PrP or is it related to the JS for the inserted gadget? — billinghurst sDrewth 07:39, 26 September 2021 (UTC)

@Billinghurst: I am using the default Vector skin. I tried it with two different browsers (Chrome and Firefox), and the problem remained. So I have just tried it on a different computer and again with two different browsers, and the result was even less predictable than before: The CharInsert appeared below the editing window in the page ns, and after opening the next page of the same work it suddenly appeared above. This was in Chrome. So I switched to Firefox, and then in the page namespace it appeared always above, but in other namespaces it was below. Changing the width of the browser did not have any effect. However, when I reloaded the page in Firefox, the position changed from above to below, but not so in Chrome, where reloading did not have any effect on the position. So, it is possible that it is a browser issue, but I have no idea what to do with the browsers, especially as I tried two widespread browsers on two computers, one of them not being mine. It seems to me that Mediawiki does not communicate the position of CharInsert to the browsers in such a way that they unambiguasly recognized it. --Jan Kameníček (talk) 16:28, 26 September 2021 (UTC)

I only get this behaviour when I've got the "2010" toolbar turned on. When it's off, no problems. [I use monobook skin on Firefox in Win 10.] Beeswaxcandle (talk) 17:49, 26 September 2021 (UTC)

Ah, now I also understand what RaboKarbakian meant by toggling the edit bar. Yes, it seems the problem disappears when I switch the 2010 toolbar off, but it reappears after I switch it back on. --Jan Kameníček (talk) 20:15, 26 September 2021 (UTC)

List of namespace aliases + request for one if it doesn't exist

I am trying to look for some list of namespace aliases, like "WS:" for the Wikisource namespace, "H:" for the Help namespace, etc. There is Help:Namespaces but it gives no information about the aliases. Specifically, I'm trying to see if the Author: namespace has one. I tried "A:", "AT:", "AU:" and those all don't work. By the way, if there is no Author alias, is it possible to add a shorter alias? "H:" exists for "Help:", so can we equally have "A:", "AT:", or "AU:" for "Author:" PseudoSkull (talk) 21:42, 25 September 2021 (UTC)

Oh, and "P:" or "PO:" for the Portal namespace. PseudoSkull (talk) 21:44, 25 September 2021 (UTC)

These are configured in InitialiseSettings.php, under wgNamespaceAliases:

	'+enwikisource' => [
		'WS' => NS_PROJECT, // T44853
		'WT' => NS_PROJECT_TALK, // T44853
		'H' => NS_HELP, // T167563
	],

These can be requested after some community consensus is demonstrated, e.g. for phab:T167563 there was this discussion. Inductiveload—talk/contribs 22:01, 25 September 2021 (UTC)

You can see the shortcuts via this API call NSs and aliases. Have to be wary about creating these shortcuts as they need to play fairly with the language and site interwikis, both existing and potential, API call for existing and other data full interplay or Special:Interwiki. — billinghurst sDrewth 07:22, 26 September 2021 (UTC)

And on the page identified there is a link to the list in the sentence A current list can be found here. — billinghurst sDrewth 07:24, 26 September 2021 (UTC)

Two authors with the same name

Hi, I would like to upload a book from William Kelly, but an another author with the exact same name already exists. How can I solve this? Thanks! --Cassiodore89 (talk) 14:29, 26 September 2021 (UTC)

@Cassiodore89: Create the author page at author:William Kelly (1821-1906) add {{similar|Author:William Kelly}} above the author template. I will fix up the disambiguation. — billinghurst sDrewth 14:47, 26 September 2021 (UTC)

@Billinghurst: Thanks! That works! --Cassiodore89 (talk) 14:52, 26 September 2021 (UTC)

Portal for Leopold and Loeb

There are several works that are about this crime duo, but the individuals in the duo now have author pages, see Nathan Freudenthal Leopold and Richard Albert Loeb. There are many works that exist having to do with this infamous and unique kidnapping and murder from the early 20th century. Wikidata has an item for Leopold and Loeb as a duo (see d:Q668789), and also has individual Wikidata items for Leopold and Loeb themselves. I have a feeling that collecting works about the Leopold and Loeb trials, etc., at a portal is appropriate, because if we didn't we'd be repeating a lot of things on the two author pages... Readers interested in Leopold and Loeb would find it convenient to have them all in one place. Any objections to creating Portal:Leopold and Loeb? PseudoSkull (talk) 18:50, 26 September 2021 (UTC)

@PseudoSkull sounds eminently reasonable to me. Inductiveload—talk/contribs 19:10, 26 September 2021 (UTC)

Agreed, do it. We have such portals for other eminent duos, e.g. Portal:Brothers Grimm. You can also keep a list of their collaborative works on the Portal page, and transclude it to the Author pages, to ensure that all three locations stay updated :) —Beleg Tâl (talk) 14:03, 27 September 2021 (UTC)

Tech News: 2021-39

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

• iOS 15 has a new function called Private Relay (Apple website). This can hide the user's IP when they use Safari browser. This is like using a VPN in that we see another IP address instead. It is opt-in and only for those who pay extra for iCloud. It will come to Safari users on OSX later. There is a technical discussion about what this means for the Wikimedia wikis.

Problems

• Some gadgets and user-scripts add items to the portlets (article tools) part of the skin. A recent change to the HTML may have made those links a different font-size. This can be fixed by adding the CSS class .vector-menu-dropdown-noicon. [15]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 September. It will be on non-Wikipedia wikis and some Wikipedias from 29 September. It will be on all wikis from 30 September (calendar).
• The GettingStarted extension was built in 2013, and provides an onboarding process for new account holders in a few versions of Wikipedia. However, the recently developed Growth features provide a better onboarding experience. Since the vast majority of Wikipedias now have access to the Growth features, GettingStarted will be deactivated starting on 4 October. [16]
• A small number of users will not be able to connect to the Wikimedia wikis after 30 September. This is because an old root certificate will no longer work. They will also have problems with many other websites. Users who have updated their software in the last five years are unlikely to have problems. Users in Europe, Africa and Asia are less likely to have immediate problems even if their software is too old. You can read more.
• You can receive notifications when someone leaves a comment on user talk page or mentions you in a talk page comment. Clicking the notification link will now bring you to the comment and highlight it. Previously, doing so brought you to the top of the section that contained the comment. You can find more information in T282029.

Future changes

• The Reply tool will be deployed to the remaining wikis in the coming weeks. It is currently part of "Discussion tools" in Beta features at most wikis. You will be able to turn it off in Editing Preferences. See the list of wikis. [17]

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

22:22, 27 September 2021 (UTC)

The Shepheardes Calender

I think this is from an 1880s facimile, I wrote about that on the talk page. I have another version which is not complete and since I am enjoying that so much, I thought to start on an original--it has been kind of funny, in a dark way.

Maybe this could be moved to, I don't know where. Maybe rejoined with the pdf?

Another option, and one that has been used before with great success is to tell me not to worry about it until the other version is done.--RaboKarbakian (talk) 18:08, 28 September 2021 (UTC)

@RaboKarbakian: I would probably start a fresh proofreading using the photographic facsimile of the 1579 text Internet Archive identifier: cu31924013125418. Languageseeker (talk) 18:26, 28 September 2021 (UTC)

The facimile I mentioned on the talk page is "better" in that it is less pre-processed.--RaboKarbakian (talk) 19:09, 28 September 2021 (UTC)

@RaboKarbakian: My mistake. Just saw that one. Yes, it is the best version to proofread. Great find! Languageseeker (talk) 19:36, 28 September 2021 (UTC)

Philosophical Transactions of the Royal Society

I am not sure what to make of this page. It's somewhere between a Work page, a Versions page, a Disambig page, and a Portal page. The issue, it seems, is that there are four series under the umbrella of the Philosophical Transactions, and this page exists as a Work page as if they were all one single multivolume periodical, but each of the four series also exist as if they were four separate periodicals.

I feel like this should be straightened out, but I am not sure whether to do this by changing Philosophical Transactions of the Royal Society into a Disambig page, or by moving the four sub-series into the work itself (cf. the way Once a Week (magazine) handles its four series). Any thoughts? —Beleg Tâl (talk) 13:10, 28 September 2021 (UTC)

@Inductiveload: @Billinghurst: @Jan.Kamenicek: @MarkLSteadman: (pinging regular editors who have contributed to this work throughout the last few years) —Beleg Tâl (talk) 13:18, 28 September 2021 (UTC)

It's a tricky one. I don't think we can put them all under the same pages as they're all different works (the original is the predecessor to by A and B, but A and B are now completely separate: different ISSN, different WD item, different enWP pages, etc). And the Abridgment Series is an edited reprint, so a different edition entirely.

I'd say make the existing page a disambiguation page (basically, what it is now, but with the right header). Inductiveload—talk/contribs 13:26, 28 September 2021 (UTC)

¯\_(ツ)_/¯ Inductiveload's suggestion sounds okay to me as they are more like successor, especially as the subpages are going to be different approaches to a hierarchy. There are a number that have similar problems, and until we have scans I have just decided that it is hard to know. — billinghurst sDrewth 13:31, 28 September 2021 (UTC)

The way I'm dealing with this for the New Zealand version is a Portal for the publisher and separate work pages for each series. A note on each series' page pointing to predecessor/successor. Beeswaxcandle (talk) 17:41, 28 September 2021 (UTC)

A redirect from Phil Trans to a relevant subsection of Portal:Royal Society does it for me too. If such a redirect is allowed, that is. We have a lot of redlinked mainspace pages with secret portals behind them that indicate that's not allowed. Inductiveload—talk/contribs 17:49, 28 September 2021 (UTC)

A portal for the Royal Society is all fine and good, but a mainspace disambiguation page for "Philosophical Transactions of the Royal Society" will still be necessary as well if there are several publications with this title. (Having both is a good idea, since that will fulfil both purposes) —Beleg Tâl (talk) 20:04, 28 September 2021 (UTC)

Alice in Wonderland in Words of One Syllable

If anyone wants an easy proofread, this is a very clean edition that I have just added a scan for. —Beleg Tâl (talk) 21:17, 28 September 2021 (UTC)

Done kathleen wright5 (talk) 13:45, 30 September 2021 (UTC)

This section was archived on a request by: —‍Mdaniels5757 (talk • contribs) 20:44, 28 October 2021 (UTC)

Center block

On Template:Center block the description This template centers a block of text, much like {{block center}}. is unhelpful. Much like in what way? What is different? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 15 September 2021 (UTC)

@Pigsonthewing: 'block center' preceded 'center block' in principle, the latter was thought a better name (agreeable, I think) and the former was redirected to the it. Then it became a fork, the text was changed to what you quoted after that; I haven't dared to look whether previous usage of either template was honoured. Not helpful, as an answer or, perhaps, a new template, but so it goes. Cygnis insignis (talk) 16:55, 17 September 2021 (UTC)

Can we, as a community, resolve this issue, by clarifying the documentatin and/ or perging the tempaltes? The relevant markup of the two templates is:

Center block:

<includeonly><div class="__center_block" style="position:relative; margin:0 auto; text-align:{{{talign|left}}}; {{ #if: {{{width|}}} | display:block; width:{{{width}}}; max-width:100%; | display:table; width:auto; }} {{ #if: {{{height|}}} | height:{{{height}}}; }} {{ #if: {{{style|}}} | {{{style}}}; }}"><!--
-->{{#if:{{{title|}}}|<span style="display:inline-block;text-align:center;{{ #if: {{{width|}}} | width:{{{width}}}; | width:auto; }}">{{{title}}}</span>|}}
{{{text|{{{1}}}}}}
</div></includeonly

Block center:

<includeonly><templatestyles src="Block center/styles.css" /><!--


--><div class="wst-block-center {{{class|}}}" style="<!--

    -->{{#if:{{{width|}}}|width:{{{width|}}};}}<!--
    -->{{#if:{{{talign|{{{align|}}}}}}|text-align:{{{talign|{{{align|}}}}}};}}<!--
    -->{{#if:{{{max-width|}}}|max-width:{{{max-width}}};}}<!--
    -->{{#if:{{{style|}}}|{{{style}}};|}}"<!--
-->><!--

-->{{#if:{{{title|}}}|<div class="wst-block-center-title">{{{title}}}</div>|}}
{{{body|{{{1|}}}}}}
</div></includeonly>

@Inductiveload: who last edited both templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:00, 5 October 2021 (UTC)

@Pigsonthewing IIRC, one used to a be a table (ew), and one was a div. They are now both, quite correctly, divs. I can't speak for anyone else, but I have not attempted to merge them because they may have slightly different quirks (e.g. {{center block}} has a height parameter), and embarking on a crusade against one or the other sounds like it'll cause more drama than it's worth. Personally, I imagine {{block center}} is "better", because it uses TemplateStyles and is therefore less verbose and more flexible, and it has a better name ({{center block}} sounds like a block-variant of {{center}}). If I had to do anything it would be to deprecate {{center block}}. Inductiveload—talk/contribs 11:53, 5 October 2021 (UTC)

Also based purely on numbers: {{center block}} has 14684 uses, {{block center}}. So the latter "wins". But 14k is a lot to replace without very high confidence of correctness. Inductiveload—talk/contribs 13:09, 5 October 2021 (UTC)

I agree with this - now that they are both div-based they should both be acceptable, but the number of issues that could happen if they are merged is really high. Perhaps we could do it incrementally - slowly update each to introduce feature parity with the other, and then when they are identical we delete one and redirect it to the other? —Beleg Tâl (talk) 17:05, 5 October 2021 (UTC)

I usually use "block center" as routine, but when doing Page:Index to Trans. N.Z. Inst. 1to40.djvu/5 I had to use "center block" so that the alignment of the two links would be left within the block. "block center" wasn't doing that and was taking on the centre alignment from the surrounding template. Beeswaxcandle (talk) 19:17, 5 October 2021 (UTC)

Should we include state propaganda?

I noticed the recent addition of Xinjiang Population Dynamics and Data (@Zzhtju:) which lists as author State Council Information Office of the People's Republic of China as author, with the w:State Council Information Office also called the Central Office of Foreign Propaganda, which "was formed in 1991 when the Central Committee of the Chinese Communist Party made the External Propaganda Leading Group of the Propaganda Department of the Chinese Communist Party its own office." I'm uncomfortable with being a publishing outlet for this and suggest works of this office fit at best uneasily within WS:WWI and we should exclude them.

I'm sure there's going to be arguments about what is propaganda and all the US government stuff. Portal:State Council of the People's Republic of China, to which the author link redirects, lists only two works not by the State Council Information Office, and both of them are bureaucratic rules, on banking and space samples. Are there lots and lots of US government works here? Yes, but they're pretty much all interior pieces created for reasons ostentatiously other than propaganda. We have no State Department works, as far as I can tell, and for the CIA, we have old, leaked documents, like Documents from the Den of Espionage (released by the Islamic Republic of Iran) with The World Factbook being the only recent or official release. The US may be, probably is, targeting propaganda at Chinese people, but not in English, and it's not being collected here. I wouldn't object to works from Author:Xi Jinping; statements of leaders are not what I'm targeting here.--Prosfilaes (talk) 04:17, 26 September 2021 (UTC)

I'm leaning oppose for excluding state propaganda, because excluding them would mean making another one of these weirdly arbitrary rules at WS:WWI that only apply to a specific era in history. Furthermore, we should never have any bias for or against inclusion of a work based on its political message, whether it carries a political message, who is involved or when the political message was expressed, or even whether or not the information provided is factually correct. IMO, if we allow government works of any kind, we should allow all of them, unless there is some exceedingly good reason not to; and I don't think we don't want to push their politics is an exceedingly good reason. We're not really supporting their nationalism specifically if we also could include the propaganda of the governments of any other country, indiscriminately except to their copyright statuses in the US. PseudoSkull (talk) 05:02, 26 September 2021 (UTC)

Note that we do have a strong bias against inclusion of works by non-state actors; these are all self-published works, which we wouldn't include for non-states. We in fact specifically exclude advertisements. WS:WWI doesn't clearly include them; not that it could use a good rewrite, but they're not peer-reviewed, and if we're calling them documentary sources, the examples are "These documents may range from constitutions and treaties to personal correspondence and diaries. This category may include material not historically available, such as historical telephone calls, judicial proceedings, and transcriptions of military operations."--Prosfilaes (talk) 05:28, 26 September 2021 (UTC)

I was going to say that I disagree with many of the policies listed for post-1925 works. I think that disallowing self-published works specifically after 1925 is too much and should be removed, although I admit I don't know exactly what precedent to use to wade out things like "2013 personal blog post by Freddie Joe Bob from Kentucky, about his dog, with 16 views to date". That precedent, however, certainly shouldn't be "anything at all that was self-published"; there should be something more, or maybe something different. So yes, WWI badly needs a rewrite, and it needs less arbitration based on date of publication. Of course, to bring back the propaganda specifically, I imagine any works released by China's federal government are going to be substantially more significant to history than Freddie Joe Bob's blog post. PseudoSkull (talk) 05:50, 26 September 2021 (UTC)

Hey what, we don't allow self-published works? Where are you seeing that inclusion in WWI? — billinghurst sDrewth 07:09, 26 September 2021 (UTC)

"Works created after 1925" is a mess, but maybe you could search for "self-published works" in WWI?--Prosfilaes (talk) 09:06, 26 September 2021 (UTC)

If you are meaning Analytical works are publications that compile information from other sources and analyze this information. Any non-fiction work which is written about a topic after the main events have occurred generally fits in this category. These as well as any artistic works must have been published in a medium that includes peer review or editorial controls; this excludes self-publication. That is disallowing self-publication of works of that type. It is not allowing their publication. — billinghurst sDrewth 13:05, 26 September 2021 (UTC)

If it is official government publication, it will have had a review process within the institution. I am comfortable with its inclusion, it is what it is. If we want to categorise it, as being of the type of work that it is then we can do that, or if you can think of a good universal template to include on a work's talk page, then great. — billinghurst sDrewth 07:09, 26 September 2021 (UTC)

So why a specific ban on advertisements? And we'd accept a similar paper from Amazon or Dow Corning justifying themselves?

I'd rather remove them, but I'd settle for including

the w:State Council Information Office is called the Central Office of Foreign Propaganda, and "was formed in 1991 when the Central Committee of the Chinese Communist Party made the External Propaganda Leading Group of the Propaganda Department of the Chinese Communist Party its own office."

as a note on all works of this organization.--Prosfilaes (talk) 09:06, 26 September 2021 (UTC)

• In my mind, this falls clearly under the given definition of “documentary sources,” being an “official document[] of the body producing” it. Propaganda is not an advertisement, as that term is understood in the section noting the precedential exclusion of advertisements. Thus, state propaganda falls squarely within the bounds of inclusion, unless the rules are specifically rewritten to exclude such works. As for this being a proposal to change that definition, I oppose. I find no reason to exclude SCIO propaganda in particular, and I don’t believe a fair consensus could be reached defining what state propaganda is and is not acceptable for inclusion—or, if all state propaganda should be excluded, what counts as state propaganda. TE(æ)A,ea. (talk) 13:44, 26 September 2021 (UTC)

• One person's propaganda output is another person's demonstration of propaganda to be pointed to. That is, often the best illustration of the untrustworthiness of a group's statements is a document that that group considers their best work. I think WS preserves and makes 'documents' available?

Do remember that that government described their 'work' in the South China sea as "reef conservation". Reefs don't need military bomber runways. I wish we had that statement here.

Thus I am not against keeping the 'document' here. However, competition and proliferation on the international level is not a small worry.

I do second the idea that the description of publisher, if not the document itself, needs to be well-qualified as to their purpose in publishing anything. Shenme (talk) 13:48, 26 September 2021 (UTC)

• Re US State Department works we have reports like 2008 Human Rights Report: China (includes Tibet, Hong Kong, and Macau), Documents on the Nicaraguan Resistance and Patterns of Global Terrorism Report/1996, the Pentagon Papers contain a large number of CIA and State works, we have documents, excerpted from Foreign Relations of the United States, we have US State Department statements statements. We also have explicit historical US Government advertisments from WWI / WWII such as: Four Years in the Fight. MarkLSteadman (talk) 15:53, 26 September 2021 (UTC)

• More generally, I think we have to rely on our readers being able to read critically and engage with the sources we have and understand that they might be misleading or even outright lies since we are hosting works and not contextualizing or criticizing them ourselves (unlike say, Wikibooks or Wikipedia). My two thoughts on this are 1) That we might think of a generic "This is a Work of Government X" style message to make clear what organizations are independent vs. government agency 2) That what contemporary information to include or not include is going to always be contentious (publications by non-recognized states? reports by think tanks and independent organizations that influenced policy etc.? which international organizations are allowed?) Most of these are lurking issues because we have focused on historical + government works rather than licensed works. MarkLSteadman (talk) 15:53, 26 September 2021 (UTC)

• you would have a better case deleting as not scan backed. bloggy sources here:[18], [19], [20] and needs a copyright template; but rather than theorizing about reasons to delete things you do not like, maybe you could show us the steward or admin, plan or discussion, to deal with the abuse of admin tools, by the propagandists. m:Office actions/September 2021 statement; thanks.--Slowking4 亞 Farmbrough's revenge 21:33, 7 October 2021 (UTC)

Localisation request

File:Hansel and Gretel and other stories.djvu - Illustrator is Kay Rasmus Nielsen (March 12, 1886 – June 21, 1957) who is Danish, and working in the Denmark at the date of publication.

Applying a 70 pma term, means that the illustrations are not out of copyright in Europe, and hence the file should not necessarily be hosted on Commons. ShakespeareFan00 (talk) 09:44, 29 September 2021 (UTC)

Also:- File:East of the sun and west of the moon; old tales from the North.djvu ShakespeareFan00 (talk) 09:47, 29 September 2021 (UTC)

I have moved the two djvu files over, though we still have the category contents. — billinghurst sDrewth 12:38, 3 October 2021 (UTC)

Done The relevant files for the works have been moved here c:Category:Hansel_and_Gretel_and_other_stories_(1921) and c:Category:East of the Sun and West of the Moon (1914, Nielsen)) I am about to do maintenance on them, though others can play as they require. They will need to be marked as CV at Commons. — billinghurst sDrewth 13:56, 3 October 2021 (UTC)

c:Commons:Deletion_requests/Files_in_Category:Hansel_and_Gretel_and_other_stories_(1921) ShakespeareFan00 (talk) 08:49, 9 October 2021 (UTC)

c:Commons:Deletion requests/Files in Category:East of the sun and west of the moon - old tales from the North (1922) ShakespeareFan00 (talk) 08:54, 9 October 2021 (UTC)

c:Commons:Deletion requests/Files in Category:East of the Sun and West of the Moon (1914, Nielsen) ShakespeareFan00 (talk) 08:54, 9 October 2021 (UTC)

• @ShakespeareFan00, @Billinghurst: I had requested that the discussion be centralised, here is a good place: it emerged in response to my attempts to work on this illustrator. If the close as keep at commons is acceptable, not a 'violation' as stated above and elsewhere, is there anything needs reversing? Cygnis insignis (talk) 11:30, 17 October 2021 (UTC)

  @Cygnis insignis: At this point of time all I have done is copied over the two files, and *not* deleted them at Commons. I did that as if they were speedy deleted at Commons, it effs up things locally. If the files are determined as kept at Commons, we just need to delete them here. Anything at Commons or here which is done by an administrator is stuff that I can fix/resolve. — billinghurst sDrewth 22:31, 17 October 2021 (UTC)

Camera Work

Hi, Just in case someone here might be interested, I am uploading to Commons all the 49 volumes of Camera Work, the quarterly photographic journal of Alfred Stieglitz. These are high quality scans. I am mostly interested by the images, but maybe someone would like to transcribe the text here. Regards, Yann (talk) 22:33, 17 September 2021 (UTC)

That's a really pretty work. If I had more wall space, I'd be down to the print shop this lunchtime! Inductiveload—talk/contribs 11:01, 20 September 2021 (UTC)

@Yann: Please continue to upload the volumes and I will make a page for them. Languageseeker (talk) 11:18, 20 September 2021 (UTC)

It will take some days to have the complete collection. Already 24 (+ 1 supplement) uploaded. Regards, Yann (talk) 12:56, 21 September 2021 (UTC)

@Yann: I've started work on transcribing the first issue. Also of note are the high quality scans of Camera Notes (1900–1) from the Camera Club of New York available from Rijksmuseum Amsterdam. - ei (talk) 11:31, 23 September 2021 (UTC)

Hi, Did you create a page for the whole set? Yann (talk) 20:47, 25 September 2021 (UTC)

@Languageseeker, @Einstein95, @Inductiveload: All files uploaded. Could you please create a page here for the whole set, so it could be linked in WD? I will look at Camera Notes in a few days. Regards, Yann (talk) 21:52, 4 October 2021 (UTC)

@Yann Done: Camera Work. Enjoy, and thanks for the work so far! Inductiveload—talk/contribs 22:05, 4 October 2021 (UTC)

Also I set up {{Camera Work link}} and {{Camera Work volumes}} for you. Inductiveload—talk/contribs 22:20, 4 October 2021 (UTC)

Camera Notes

I couldn’t get Camera Notes from Rijksmuseum, as each page has to be downloaded separately. It would take ages. But I got complete scans on Hathitrust in 3 files. First file is on Commons: c:File:Camera Notes, v. 1-2, 1897-1899.pdf. The others will follow. Regards, Yann (talk) 20:48, 5 October 2021 (UTC)

I can’t upload the other volumes from Hathitrust due to a bug somewhere when uploading large files (714 and 864 MB). However I managed to upload File:Camera Notes, 1897-1903.pdf, which is only 163 MB, but still 1,662 pages! Not sure about the quality, so may be it is better to wait for the other files. What do you think? Yann (talk) 20:03, 6 October 2021 (UTC)

Welcome to the upload bug party! If you can upload to the Internet Archive (or anywhere I can reach them), I can try upload them for you via a secret method (involving Toolforge, SSH, duct tape and prayer). And if that still fails, I can file a server-side-upload request for you, but that can take "some time" to be actioned. Inductiveload—talk/contribs 21:33, 6 October 2021 (UTC)

It seems at least one bug was fixed, and the server-side uploads were done: File:Camera Notes, v. 3-4, 1899-1901.pdf, File:Camera Notes, v. 5-6, 1901-1903.pdf. Regards, Yann (talk) 20:00, 31 October 2021 (UTC)

291

While waiting for Camera Notes, I found some scans of the 291 magazine: c:File:291 magazine, No. 1, March 1915.pdf. Text is available at IA. Yann (talk) 20:50, 7 October 2021 (UTC)

Blocking policy regarding spammers

Context: Following on from Wikisource:Administrators'_noticeboard#Spamming_as_a_block_reason.

A very high proportion of the undesirable edits at Wikisource are spam: people or bots adding screeds of text to pages, usually their own users pages, usually containing links to external websites. We do not, as it happens, have a specific clause in the WS:Blocking policy to cover this. This means that the standard admin actions of blocking spammers may technically be outside the policy, depending on how you interpret "vandalism", and no-warning spam-bot blocks are counter to the "friendly warning" guidance.

I am particularly hostile to single-purpose spam accounts where the only action is spamming and the account is either one of the auto-generated names like BobSmith56 or has a particular connection to the spammed link or some other business.

I suggest the following section under "Justifications for blocking" to be added:

Spamming

Promotion of third-party websites, product or company is forbidden. This includes, but is not limited to, inserting links to external websites. This applies even if the spam is accompanied by text unrelated to the spammed material. This does not apply if the links or material is relevant to Wikisource (for example a link to a bookshop relating to a specific work under discussion).

Users who create accounts for the sole purpose of spamming may be blocked indefinitely and without prior warning, and the associated IPs blocked for a short period (the autoblock default is 1 day) to prevent immediate account recreations.

Spam may be reverted by any user without warning, and the revision may also be hidden by an administrator. If the the user is not a single-purpose spammer, the revert should be explained on their talk page.

Users who have made constructive edits, either before or after the spam edits, should not be blocked without warning.

Users should not be blocked from editing their own talk pages, unless they continue to insert spam there after being warned not to do so.

Blocks may also be performed by administrators who see attempted spam in logs of tools such as Special:AbuseFilter, even if the edit is prevented by the filter, as if the edit were made.

Some notes and rationale:

• Allowing instant-blocks: single-purpose spammers generally do not engage or check for replies, so it's a waste of time to attempt to warn, and wastes editor time on the follow-up. Meanwhile the IP is available for further spamming. Blocks here also show in the SUL log for users at other wikis, so this can help other wikis too if it's cross-wiki spam account
• Allowing instant-revert: this lowers the ping-pong overheads associated with handling spam
• Any constructive edit prevents instant blocking: I have never seen a bot spammer make useful edits
• Allowing talk page access by default: users should be allowed to appeal (no bot spammer will bother, this is an escape hatch in case a mistake is made)
• Unrelated text: lots of spammers disguise the spam with some junk text like a fake mini-biography.
• Abuse filter: often, spammers get stuck in one of the local or global abuse filters before they make a successful spam edit. Blocking at that time avoids having to later check back to see if they have eventually been successful example.

Inductiveload—talk/contribs 09:27, 28 September 2021 (UTC)

Support. Languageseeker (talk) 21:17, 28 September 2021 (UTC)

Support. --Jan Kameníček (talk) 21:19, 4 October 2021 (UTC)

comment - expressing your "extremely unsympathetic" view as a summary block can become slippery. where would you include admin "wriggle room" for spammy newbies who have not been onboarded? could a bot revert, and add to a work list? it's good to document standards of practice, but a link to an appeal process would be helpful for the small amount clueless newbies. Slowking4 亞 Farmbrough's revenge 10:30, 6 October 2021 (UTC)

@Slowking4 the wiggle room is in the (quite deliberate) use of "may" rather than "should", "shall" or "must" in the phrase may be blocked. Putting it another way, the above authorises a block for spamming, but does not mandate it. Administrators are, as always, expected and required to use common sense when using their powers. Fortunately, it's also abundantly clear who is an capital-s Spammer and who is merely clueless.

Also, there is often nothing to revert, because the first signs of many spammers is hits on the spam filter or abuse filters, which act as something of an early warning system. Blocking them at that point avoids having to re-patrol for edits they do manage to slip though later on. Inductiveload—talk/contribs 17:06, 13 October 2021 (UTC)

filters are opaque, and you should provide a path for audit of actions and appeal. veterans from time to time wonder what the red wall of text is preventing a save. if the filter prevents the disruption, then your rationale of "block because convenient" seems rather weak. you are creating a system of expanding no go zones, with no review or rationalization. i.e. you are going to get "willy on wheels" forever, even beyond the grave. --Slowking4 亞 Farmbrough's revenge 20:41, 15 October 2021 (UTC)

Veterans will not hit the (local at least) spam filters because they only apply to IPs and users with very small (single digit) edit counts. Mostly the spam appears to be overspray from other wikis, mostly NTSAMR, SEO services, or, oddly specifically, Indian politicians and entertainers.

Filters prevent the disruption in the first, but relying on them completely means that spammers are left free to experiment with filter-circumvention, because the spam filters purposely do not auto-block, no matter how many times someone hits them. Blocking when noticed also 1) prevents re-use of the account in future when no-one is looking 2) re-use of the IP for other accounts for the next day and 3) makes a record of the activity in the SUL log, which makes it clear to other wikis that the user is identifed as a spammer. Inductiveload—talk/contribs 14:31, 3 November 2021 (UTC)

 Support PseudoSkull (talk) 17:31, 6 October 2021 (UTC)

 Support Modulo the talk page exception. Some of the spam bots specifically use the talk page, and the activity that is the target of this policy is so unequivocal that there is no need to permit them talk page access. There are in any case off-wiki options for appeal (e.g. through VRT, or approaching an admin on a different project (and we have unblocked users through this path that have been blocked under other provisions)) if by some miracle, or bad admin judgement, someone with a valid appeal reason should be caught in such a block. Or put another way, if there is a genuine need to permit them talk page access they probably shouldn't be blocked under this particular policy provision in the first place (it's "disruption" not spamming). --Xover (talk) 05:39, 12 October 2021 (UTC)

@Xover I understand the point, but currently there is not a major issue of spamming on their own talk pages after a block. I'd personally rather reactively amend the policy if needed. Inductiveload—talk/contribs 16:55, 13 October 2021 (UTC)

@Xover also we have a shiny new AbuseFilter (#48) that disallows edits by blocked users only that contain non-wiki-relevant links in the User_talk namespace. So if a user has been blocked, they can still appeal on their user talk page. If they're a spammer and try to abuse their talk page access to post any spam that's got an external link in it (i.e. all of it), it will be disallowed. If disallowed, a specific reason will be given: MediaWiki:Abusefilter-blocked-user-adding-links. The block will not be extended, the user will just be told to try again, but without the external links.

I don't anticipate this being hit very often (most spammers move on after blocks, those who don't are more likely to be vandals or LTAs than garden-variety spammers), but I think it should cover the bases while also ensuring that the chance of a bad block being un-appealable on-wiki is as low as possible. While that is extremely unlikely (due to spam being generally very obvious), IMO we should make an effort to ensure we do not have a policy that results un-appealable blocks.

Again, if spammers do start trying to game it, we can revisit, but I don't see evidence that they are reactive to us specifically since we're a small target and mostly just receive overspray spam from the big boys. Inductiveload—talk/contribs 10:43, 30 October 2021 (UTC)