Wikisource:Scriptorium

From Wikisource
Jump to navigation Jump to search
Scriptorium
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help.

Some announcements and newsletters are subscribed to Announcements.

Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 397 active users here.

Announcements[edit]

September Monthly Challenge summary[edit]

Wikisource laurier.svg

The September Monthly Challenge is now complete and the numbers are in: 2606 pages were processed (marked no text, proofread or validated), which is well over the target of 2000. We also had out longest streak ever of days with over 100 pages processed at the start of the month with 9 consecutive days! The following works were fully proofread:

And the following were validated:

Thank you to all contributors and I look forward to October's challenge, which starts today. There are many new works to the challenge, including (but certainly not limited to):

Now that the "nights are drawing in" as my grandmother would say (for those of us in the Northern Hemisphere), there's no need to be distracted by such fripperies as "going outside", "daylight" or "fresh air". Come and join in here! As always, please drop in as you wish and nominations are open for proposals and comment for future works. Inductiveloadtalk/contribs 06:37, 1 October 2021 (UTC)[reply]

Wikisource:WikiProject Data[edit]

I have started Wikisource:WikiProject Data to try to bring together the wider WS strategy (such that there is one) for Wikidata best practices.

If you are interested, you can sign up for {{ping project|Data}} notifications here. Inductiveloadtalk/contribs 18:55, 5 October 2021 (UTC)[reply]

Wikisource:WikiProject Women in Red[edit]

In preparation for Ada Lovelace Day this coming Tuesday I have started this WikiProject to tie in with it. The purpose of the wider Women in Red project is to deal with the gender bias across the Wikimedia sites and in particular to turn the red-linked women's names blue. The main focus of Ada Lovelace Day is on Women in STEM and most participants will be creating biographies on WP and items on WD, but I am hopeful that there will be some interest in coming here to create Authors and maybe do a bit of proofreading.

Going on from there, when and as you come across the names of women authors in your proofreading, and you can't work out who they are, please add them to the project page in an appropriate section. Adding any information you glean, including the title of a work, will help others when they come to create the Author: page. Beeswaxcandle (talk) 05:32, 10 October 2021 (UTC)[reply]

Proposals[edit]

New Request for Comment on Wikilinking Policy is open[edit]

I have just opened Wikisource:Requests for comment/Wikilinking policy. You will find there a proposed complete overhaul/rewrite of the current policy, which is now ready for review by the wider Wikisource community. It is proposed that the RfC will be open for two weeks. Please make your comments there rather than here. Beeswaxcandle (talk) 08:33, 14 March 2021 (UTC)[reply]

@Beeswaxcandle: I think 2 weeks / 72 hours is a little bit too aggressive, even for a presumed uncontroversial policy proposal like this. I understand the reasoning, but I just don't think the community is able to move that fast. For example, we have several long-time contributors that are currently in a phase where they check in only every couple of weeks. And I know for my own part that the local Covid status could easily make me too busy to check in here for weeks on end. We could still have an accelerated timeline (just not quite as accelerated as 2/72) if we notify of the proposal in an site notice and maybe even a talk page message to any established contributor that has been active in the last three months (or similar).
PS. And let me repeat my previous private kudos in public: you took my ongoing whining about the old policy and turned it into a concrete proposal for a new policy. Great work, for which I am extremely grateful! --Xover (talk) 09:25, 14 March 2021 (UTC)[reply]

Proposal: Not proofread reduction drive[edit]

The ProofreadPage Statistics show that while we are keeping up with the French on proofread pages, we are around 1/4 validation, and 1/10 reduction of not proofread. [1] I would propose a contest, in the spirit of Tenth Anniversary Contest. We could run it like #wpwp with a hashtag in the edit summary to track contestants. perhaps #npr and #v ? November would be a good timeframe. I would be willing to throw $100 in the pot for each contest. Is there interest in such a contest? Slowking4Farmbrough's revenge 19:56, 21 August 2021 (UTC)[reply]

Would this be encouraging people who don't proofread well? (I should rename as "pirfeckshunis") Shenme (talk) 20:42, 21 August 2021 (UTC)[reply]
a general encouragement will have errors in it. the existing proofread pages have errors. that would be a problem, we wish we had. but if you want to patrol, disallow, and score keep. go for it. Slowking4Farmbrough's revenge 21:26, 22 August 2021 (UTC)[reply]
'patrol … disallow … score keep' Are you, Slowking4 Farmbrough's revenge, planning to adopt one of these roles, or designate who is, or be subject to one of those who are, or just sit back, open a bag of popcorn, and watch the fur fly when people behave in a point-scoring, competitive and inevitably vengeful environment? CYGNIS INSIGNIS 12:24, 23 August 2021 (UTC)[reply]
that was not the experience at Tenth Anniversary Contest and #wpwp, but there was some shouting by loud voices at wpwp. the vindictive environment is a product of the loud voices, not the process. Slowking4Farmbrough's revenge 13:08, 23 August 2021 (UTC)[reply]
I support the idea of contests in general (obviously, see the Monthly Challenge!), but I do wonder about the usefulness of such a diffuse goal as turning any pages from red to yellow. We have have over 1 million not-proofread pages (nearly 250k of those are from a single user just pressing "save" on the auto-loaded OCR). Any kind of contest involving those pages would spread effort so thin we'd be lucky to see any completions at all.
Also, a lot of the red pages are actually Match and Split works where the text is substantially correct, but not manually verified, so not all red pages are created equal.
I (being heavily biased and not impartial at all) would suggest that choosing specific "not-proofread" works to focus on would be better, and indeed we can do this with the Monthly Challenge. Currently Index:Mrs. Dalloway - Virginia Woolf.pdf is an example of an MC work that started as an all-red Match and Split'd index. We could even have a dedicated month to "red page reduction" where all added works are fully red. It's already been proposed (disclaimer: by me) to have ongoing maintenance as a facet of the MC (for example, reserving a slot for a work WS:Requested texts per month).
Setting up per-user edit counts on the MC is pretty easy to add to the bot, though I would first want to check if people are happy with that, and if we'd need an opt out (or in) system to exclude those who don't with to be included in that aspect of the challenge. Inductiveloadtalk/contribs 06:51, 23 August 2021 (UTC)[reply]
you could make a list of red works. the object of a contest would be to recruit new editors. and the hashtag method is inherently opt in. Slowking4Farmbrough's revenge 13:28, 23 August 2021 (UTC)[reply]

Proposal: Move the Collaboration Box to above the New Text Box[edit]

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)[reply]

No, absolutely not. Your project is not the top priority here. — billinghurst sDrewth 12:06, 20 September 2021 (UTC)[reply]
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. Inductiveloadtalk/contribs 12:37, 20 September 2021 (UTC)[reply]
@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)[reply]
"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)[reply]
@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. Inductiveloadtalk/contribs 08:42, 21 September 2021 (UTC)[reply]

Proposal: Consolidate the Community Collaboration Projects[edit]

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)[reply]

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)[reply]
  • 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)[reply]
  • 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)[reply]
    • @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)[reply]
  • 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)[reply]

Blocking policy regarding spammers[edit]

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.

Inductiveloadtalk/contribs 09:27, 28 September 2021 (UTC)[reply]

Support. Languageseeker (talk) 21:17, 28 September 2021 (UTC)[reply]
Support. --Jan Kameníček (talk) 21:19, 4 October 2021 (UTC)[reply]
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. Slowking4Farmbrough's revenge 10:30, 6 October 2021 (UTC)[reply]
@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. Inductiveloadtalk/contribs 17:06, 13 October 2021 (UTC)[reply]
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. --Slowking4Farmbrough's revenge 20:41, 15 October 2021 (UTC)[reply]
Symbol support vote.svg Support PseudoSkull (talk) 17:31, 6 October 2021 (UTC)[reply]
Symbol support vote.svg 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)[reply]
@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. Inductiveloadtalk/contribs 16:55, 13 October 2021 (UTC)[reply]

Maintenance Project Proposal: Wikisorcify Wikipedia[edit]

On Wikipedia, many of the texts available on Wikisource are either unlisted or are at the bottom of the page making it difficult for users to know that the text. However, most of the articles on Wikipedia about text use the template {{Infobox book}} that has an optional parameter | wikisource = name_of_text_on_Wikisource. This optional parameter adds a link to the Wikisource inside of the info box making it extremely visible. For example, see Jane Eyre. Adding this will bring two major benefits

  1. It will improve Wikipedia by making it easier for users to find the original texts described in the article.
  2. It will benefit Wikisource by raising awareness of this project attracting more users to Wikisource. Some of these users will then contribute to Wikisource.

The only restriction that I am proposing is that the text should be scan-backed. I know that there is quite a lot of debate about scan-backed vs non-scan-backed, but I strongly believe that scan-backed works are the true strength of Wikisource and the best way to advertise this project. Languageseeker (talk) 01:29, 12 October 2021 (UTC)[reply]

I don't like the boxes, I don't see them unless I look for them. I do look in the list of links, "Further reading" where they list off-site transcriptions, if they exist. The template to put it in that list is {{cite wikisource} or {{wikisource cite} or something like that. While looking for that template the last time, the term they use (instead of infobox, which has a lot more information) is "poster", making it, for me, all the less likable.--RaboKarbakian (talk) 01:44, 12 October 2021 (UTC)[reply]
@Languageseeker: I imagine a very large amount of this can be automated: w:Template talk:Infobox_book#Automatic_Wikisource_link_via_Wikidata_sitelink. Inductiveloadtalk/contribs 13:42, 13 October 2021 (UTC)[reply]
@Inductiveload: I should have figured that you would find a much better and more elegant way to implement one of my ideas. :) That would greatly simplify thing. If this gets implemented, it might make sense to also make a scan for Indexes that are transcluded, but not listed on Wikipedia to figure out what needs to be done manually. Languageseeker (talk) 16:52, 13 October 2021 (UTC)[reply]
@Languageseeker Indexes that are transcluded, but not listed on Wikipedia: I'm not quite sure what you mean by this.
The biggest issue will be dealing with the (common) case where WP links to the work, but the Wikisource page links to an edition. This happens whenever we do not have a versions page for a edition, usually because there is only a single edition at WS. This may be better to solve with a dedicated template at Wikipedia to follow has edition or translation (P747). Inductiveloadtalk/contribs 17:13, 13 October 2021 (UTC)[reply]
@Inductiveload: I meant that not every text that is transcluded will be automatically matched to Wikipedia. Some books do not have articles or the algorithm could fail. Therefore, it would be nice to be able to easily distinguish between the books that are listed or Wikipedia and those that are not. Perhaps, it might be possible to even add a field in the Index ns Listed on Wikipedia that would be automatically set to true if the data-match happens or can be manually toggled. Then, it would be possible to find out which books are not listed. Languageseeker (talk) 01:03, 14 October 2021 (UTC)[reply]

Enable upload-by-URL for autoconfirmed users[edit]

Currently, no Wikisource can use the "upload by URL" feature that can be used at Commons. phab:T293205 would add this capability to all Wikisources from a short allowlist of acceptable sources (for now, the Internet Archive and a couple of Toolforge areas), but to actually use it, we also need to assign the upload_by_url user right to users. At Commons, this right is granted to all users. At English Wikisource, we grant the normal upload right to autoconfirmed users. Since there is no intrinsic extra "danger" to URL uploading (because if the user wanted to, they could download it and upload normally anyway), I suggest to grant auto-confirmed users this right, in addition to the upload right they already have.

If this proposal is supported by consensus, I can prepare and submit a configuration change and schedule it for deployment.

Note: please do not start suggesting other import URLs to allow in this discussion: start a new thread if you know of a specific domain we would want to import files from (that are not suitable for Commons). That would be a completely separate configuration change. Inductiveloadtalk/contribs 15:13, 13 October 2021 (UTC)[reply]

Bot approval requests[edit]

Repairs (and moves)[edit]

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

Impressions of Theophrastus Such[edit]

The work is currently the PG version of Blackwood ed., 1879, with subpages, a new version at Impressions of Theophrastus Such. Essays and Leaves from a note-book/Theophrastus Such so the title might be a dab for these. CYGNIS INSIGNIS 10:12, 1 August 2021 (UTC)

redated to stop being archived. CYGNIS INSIGNIS 12:28, 23 August 2021 (UTC)[reply]
Cygnis insignis (talk) 17:11, 9 September 2021 (UTC)[reply]
Cygnis insignis (talk) 17:37, 13 October 2021 (UTC)[reply]
Yes check.svg Done , though the new version does still need splitting to chapters. Also located and uploaded a scan for the PG version just for good measure. Inductiveloadtalk/contribs 18:31, 13 October 2021 (UTC)[reply]

Index:Swahili tales.djvu[edit]

The work contains English and Swahili, most of the other language, except where it intermixed with English (about half of the pages), has been done at old wikisource, eg Page:Swahili_tales.djvu/42. I propose they be moved here CYGNIS INSIGNIS 08:24, 2 August 2021 (UTC)

CYGNIS INSIGNIS 12:28, 23 August 2021 (UTC)[reply]
Cygnis insignis (talk) 17:11, 9 September 2021 (UTC)[reply]
Cygnis insignis (talk) 17:37, 13 October 2021 (UTC)[reply]

Undine (1909)[edit]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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. Inductiveloadtalk/contribs 06:29, 10 September 2021 (UTC)[reply]
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)[reply]

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

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)[reply]

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)[reply]
Yes check.svg Done per above proposal. Mpaa (talk) 21:09, 16 September 2021 (UTC)[reply]

John Brown (1909)[edit]

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)[reply]

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

Miscellanies–Thoreau[edit]

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)[reply]

WP:Be bold ;-) --Jan Kameníček (talk) 21:38, 12 September 2021 (UTC)[reply]
Done. Mpaa (talk) 20:10, 13 September 2021 (UTC)[reply]

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

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)[reply]

@Beeswaxcandle: Yes check.svg 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)[reply]
@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. Inductiveloadtalk/contribs 11:25, 14 September 2021 (UTC)[reply]
@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)[reply]

A Short View of the Frauds and Abuses committed by Apothecaries[edit]

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)[reply]

Done. Mpaa (talk) 05:23, 17 September 2021 (UTC)[reply]
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)[reply]

The Shepheardes Calender[edit]

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)[reply]

@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)[reply]
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)[reply]
@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)[reply]

Enoch Arden, etc[edit]

@Chrisguise: The title page uses a period after the word "etc", which leads me to believe perhaps Enoch Arden, etc. is the official title. Any objection to me moving the title pages of this work to Enoch Arden, etc.? PseudoSkull (talk) 18:23, 3 October 2021 (UTC)[reply]

Other discussions[edit]

Policy on substantially empty works[edit]

[This is imported from WS:PD, where it applies to multiple current proposals, and several other works].

We have quite a few cases of works that are "collective" or "encyclopaedic" in that they comprise many standalone articles of individual value, which are basically just "shell pages", with no substantial content of any sort, not even imported scans or Index pages. For example, and this isn't intended to make any statement about these specific works, they're just examples and they may well get some work done soon during their respective WS:PD discussions:

Based on the usual rate of editing for things like that, unless dragged up into a process like WS:PD, they'll remain that way a very, very long time. I think it is perhaps there might be a case to host a mainspace page for this work, even though there is zero, or almost zero actual content. Do we want:

  • Mainspace pages where this is a tiny bit of information like header notes, scan links and maybe detective work on the talk page (not in this case). This provides a place for people to incrementally add content. Also gives "false positive" blue links, since there is actually no "real" content from the work itself, or
  • Do not have a mainspace page until there's some content. Only host this in terms of scan links author/portal scan links, much like we do for something like a novel.

Personally, I lean (gently) towards #2, but with a fairly low bar for how much content is needed. Say, Indexes, basic templates, a title page and one example article. Ideally, a completed TOC if practical, especially for periodical volumes/numbers. It is fair to not wish to transcribe entire volumes of these work, it is fair to not want to import dozens of scans when you only wanted one, it is fair to only want an article or two, but it's not fair, IMO, to expect the first person who wants to add an article to have to do all the groundwork themselves, despite having been lured in with a blue link. That onus feels more like it should be on the person creating the top-level page in the first place.

I do see some value in periodical top pages with decent lists of volumes and scans where known, because these are often tricky and fiddly to compile from Google books/IA/Hathi, so it's not useless work, even if there are no imported scans (though imported is better than not).

We currently have a large handful of collective works listed for deletion right now in various levels of "no real content", and, furthermore, every single periodical that gets added can fall into this situation unless the person who adds, so I think we could have a think about what we really want to see here. Inductiveloadtalk/contribs 15:43, 3 July 2020 (UTC)[reply]

  • I believe that, if there is no scan as an Index: page, the main-namespace page should not exist unless it is being actively completed or is already mostly completed. A few pages (of the volume itself) is not very helpful, and is entirely useless if their is no scan given. TE(æ)A,ea. (talk) 15:59, 3 July 2020 (UTC).[reply]
  • I think such preparatory information would ideally be on more centralized WikiProject pages (for the broad subject), both for clarity and to assist in keeping different efforts consistent -- but that it certainly should be retained as visible to non-admins. I think that the red vs blue link issue is minor (but not totally negligible) and outweighed by the disadvantages of hiding the history of previous efforts. I strongly encourage redirecting such pages to appropriate WikiProject pages (after copying over the details there). JesseW (talk) 18:11, 3 July 2020 (UTC)[reply]
  • @JesseW: I agree that history shouldn't be deleted, but I think we should approach this in terms of what we want to see from these works, rather than what to do with the handful of examples at PD. There are hundreds of periodicals we could have but don't, and this applies to those as well. If we can come to a conclusion about what is and isn't wanted, we can make all the deletion requested works conform to that easily enough. Inductiveloadtalk/contribs 20:55, 3 July 2020 (UTC)[reply]
  • I think these pages are necessary to list index pages and external scans of multi-volume works (such as encyclopaedias and periodicals) especially if they are wholly or partly anonymous or have many authors or are simply large. I think it makes no difference whether such pages are in the mainspace, the portal space or the project space (except that it is harder to find pages outside the mainspace). The point is that these works often have so many volumes (often dozens or hundreds) that they must have their own page, and cannot be merged into a larger portal or wikiproject. If the community starts insisting on index pages, what will happen is the rapid upload of a large number of scans for the periodicals that already have their own page. Likewise if the community insists on transclusion. I also think it is reasonable to have a contents page in the mainspace, as it allows transclusion of articles. Most importantly, new restrictions should not immediately apply to existing pages that were created before the introduction of the restrictions. This is necessary to prevent a bottleneck. James500 (talk) 23:55, 3 July 2020 (UTC)[reply]
move the works to a maintenance category, and i will work them; delete them and i will not: i find your sword of Damocles demotivating. Slowking4Rama's revenge 01:55, 5 July 2020 (UTC)[reply]
@User:Slowking4: I am not proposing a sword of Damocles. I agree that the imposition of deadlines is counter-productive. I do not support the deletion of any of these pages. I would prefer to see them improved. James500 (talk) 04:38, 5 July 2020 (UTC)[reply]
TEA is on his usual deletion spree. not a fan. will not be finding scans to save texts, any more. he can do it. Slowking4Rama's revenge 00:15, 6 July 2020 (UTC)[reply]
The entire point of moving this here, and not staying at WS:PD is to decouple from the emotions that get stirred up in a deletion discussion. Let's keep deletion out of this. If we come up with some idea of what we do and don't want, then we can go back to WS:PD and decide what to do. I imagine that all that will be needed will be a fairly limited amount of housework to bring those works up to some standard that we can decide on here, and all the collective works there will be easy keeps. Hopefully with some kind of consensus that we can point at to outline a minimum viable product for such works going forward. There are hundreds and thousands of dictionaries, encyclopedias, periodicals and newspapers that we could/will, quite reasonably, have only snippets of. How do we want to present them? What, exactly, is the minimum threshold? Let's head of all those future deletion proposals off at the pass, because deletion proposals often cause friction. Inductiveloadtalk/contribs 00:47, 6 July 2020 (UTC)[reply]
and yet deletion is the default method to "motivate" quality improvement. i reject your assertion that "emotions get stirred in a deletion discussion", rather, anger is a valid response to a repeated broken process being kicked down on the volunteers. it is unclear that a minimum threshold is necessary, rather a functional quality improvement process is. until we have one, you should expect to see this periodic stirring of emotions, as the non-leaders act out. Slowking4Rama's revenge 11:53, 9 July 2020 (UTC)[reply]
@Slowking4: Thank you for presenting this opinion, and I'm sorry if I have not made myself clear. We do need to figure out how to avoid a de-facto process of using WS:PD as an ill-tempered ad-hoc venue for "forcing" improvements on people who have somehow managed to generate works that are so in need of improvement that another user has nominated them for deletion. Please also consider looking at #Re-purpose_WikiProject_OCR_to_WikiProject_Scans for an idea to have a "functional quality improvement process" to which such works could be referred upon discovery rather than kicking them straight to WS:PD. If you have other ideas or you have previously suggested something similar to address these frustrations, you could detail them there. Personally, I think we should always prefer improvement over deletion. Exactly what the remediation is (refer to a putative WP:Scans, WS:Scriptorium/Help, directly WS:PD as now, or something else) is not what this thread is for. This thread is for discussing, what, if anything, should be the tipping point for deeming a page "lacking" and doing something about, whatever "something" is. I don't think I can be much clearer that this is not about deletion. If we also have a better venue for improvements, then that's even better.
For example, my personal feeling and !vote on A Critical Dictionary of English Literature is "keep and improve", despite it lacking scans or even links to scans, having only one article and no other content, not even a title page: in short, failing almost every criterion suggested so far in this thread. The only thing it does have is have is good text quality of the one entry. I personally do not think this work should be deleted, but I do think it should be improved in specific ways. The first half of that sentence is not the focus of this discussion, the second half is. Inductiveloadtalk/contribs 14:18, 9 July 2020 (UTC)[reply]
deletion threat has been an habitual method of communicating by admins since the beginning of the project. and text dumps have been habitual following in the guttenberg example. culture change and process change would be required to change those behaviors. we could may it easier to start scan backed works, but the wishlist was not supported. Slowking4Rama's revenge 21:00, 14 July 2020 (UTC)[reply]

I don't think this needs to be much of an issue going forward -- we all agree that it's OK to create Index pages for scans, even if none of the Pages have been transcribed yet; so the only case where this would come up is recording research where no scan has yet been identified as suitable to be uploaded. And for that, I still think a WikiProject page is the right location, not mainspace. (Or, if you must, your userpage.) JesseW (talk) 00:59, 6 July 2020 (UTC) I realized I may not have been clear enough here -- in my view, the ideal process goes like this:[reply]

  1. Decide on a work you are interested in (in this case, a periodical/encyclopedic one) -- don't record that anywhere on-wiki (except maybe your user page)
  2. Find and upload (to Commons) a scan of one part/issue/etc of the work.
  3. Create a ProofreadPage-managed page in the Index: namespace for the scan. (You can stop after this point, without worry that your work will later be discarded.)
  4. EITHER
    1. Put further research (on other editions, context, possible wikification, etc.) on that Index_talk page.
    2. Proofread a complete part of the scan (an article from the magazine issue, a chapter from the book, a entry from an encyclopedia, etc.) and transclude it to the mainspace (and create necessary parent pages), and put the further research on the Talk: page of the parent mainspace entry.

If you can't find any scan, and don't want to leave your working notes on your user page, put them on a relevant WikiProject's page.

If you come across such research done by others and misplaced, follow the above process to relocate it to an appropriate place, then redirect the page where you found it to the new location. That's my proposal. JesseW (talk) 01:08, 6 July 2020 (UTC)[reply]

@JesseW: It's not clear to me in your above whether when you use the term "index" you refer to a ProofreadPage-managed page in the Index: namespace, or a general wikipage in the main namespace on which an index-like structure (and/or a ToC, or similar) is manually created. Could you clarify? --Xover (talk) 05:14, 6 July 2020 (UTC)[reply]
I meant the namespace. Clarified now. JesseW (talk) 05:17, 6 July 2020 (UTC)[reply]
  • Hoo-boy. Y'all sure know how to pick the difficult issues…
    My general stance is that: 1) scans and Index: (and Page:) namespace pages have no particular completion criteria to meet to merit inclusion, and can stay in whatever state indefinitely (there may be other reasons to get rid of them, but not this); and 2) the default for mainspace is that only scan-backed complete and finished works that meet a minimum standard for quality should exist there.
    That general stance must be nuanced in two main ways: 1) there must be some kind of grandfather clause for pre-existing pages; and 2) there must exist exceptions for certain kinds of works that meet certain criteria. I won't touch on the grandfather clause here much, except to say I'm generally in favour of making it minimal, maybe something like "No active effort to get rid of older works, but if they're brought to PD for other reasons they're fair game". The design of a grandfather clause for this is a whole separate discussion, and an intelligent one requires analysis of existing pages that would be affected by it. It is always preferable to migrate pages to a modern standard, so a grandfather clause is by definition a second choice option.
    Now, to the meat of the matter: the exceptions…
    We have a clear policy to start from: no excerpts. Works should either be complete as published, or they should not be in mainspace. But quite apart from the historical practices that modify this (which are somewhat subjective and inconsistent, so I'll ignore them for now), there are some fairly obvious cases that suggest a need for more nuance than a simple bright-line rule alone provides. The major ones that come to mind are: 1) massive never-completed projects like EB1911 or the New York Times (EB because it's big; NYT because new PD issues are added every year); 2) compilations or collections of stand-alone works with plausible claim to independent notability.
    For encyclopedias and encyclopedia-like things, we have to accept some subsets due to sheer scale of work. But when that is the grounds for exception, there needs to be some minimum level of completion. I'm not sure I can come up with a specific number of pages/entries or percentage, but it needs to be more than just a single entry (and, obviously, only complete entries). For this kind of exception to apply, I think it needs to be a requirement that the framing structure for it is complete: that is, the mainspace page should give a complete overview of the relevant work even if most of it is redlinks. That includes title pages and other prolegomena when relevant. For a periodical like the NYT, that means complete lists of issues with dates and other such relevant information (e,g. name changes etc.). For preference, these kinds of things should be in Portal: namespace or on a WikiProject page until actually complete, but that will not always be practical (EB1911 and NYT are examples of this). Mainspace or Portal:-space should never contain external links (i.e. to scans) or links to Index: or Page: space (except the implied link of transclusion and the "Source" tab in the MW UI provided by ProofreadPage).
    For exception claimed under independent notability there are a couple of distinct variants.
    Newspaper or magazine articles need to have a certain level of substance in addition to a specific identifiable byline (possibly anonymous or pseudonymous, and possibly identified after the fact by some other source, such as the Letters of Junius) in order to qualify. It is not enough to ipso facto be a newspaper article, a magazine article, a poem, or an encyclopedia entry. On the one hand we have things like dictionaries and thesauri, where an entry could be as little as two words. Or a one-sentence notice without byline in a newspaper. Or two rhymed lines (technically a poem) within a 1000-page scholarly monograph.
    To merit this exception it should be reasonable to argue that the "work" in question should exist as a stand-alone mainspace page (not that we generally want that; but as a test for this exception, it should be reasonable to make such an argument). This would clearly apply to moderately long entries in the EB1911 written by a known author that has their own Wikipedia article. It would apply to short stories or novella-length serialisations in literary magazines by authors that have later become famous (or "are still …"). It would apply to various longer-form journalistic material from identifiable journalists (again, rule of thumb is notable enough for enWP article), including things in magazines that have similar properties. For most periodicals the most relevant atomic (indivisable) part is the issue not the entry or article, but with some commonsense exceptions.
    It would, generally, not apply to things that are works by a single author, like a scholarly monograph that just happens to be arranged in "entries" rather than chapters. It would not apply to things that are essentially lists or tables of data. It would not apply to short entries in something encyclopedia-like or entries that are not by an identifiable author. The OED for example, iirc, is a collective work where entries are by multiple not individually identifiable authors (and each entry is mostly very short too); only the overall editor is usually cited.
    For works claiming this exception too the framing structure should be complete, even if most of it are redlinks. The same general rules about Portal:/WikiProject and no external or Index:-space links apply. An exception would be for periodicals where new issues enter the public domain every year; and we should generally avoid including even redlinks for the non-PD issues here (but may allow them in a WikiProject page). For non-periodical works in multiple volumes where some volumes were published after the PD cutoff, including listings for the non-PD volumes (but not links to scans; those are a copyvio issue) is ok.
    Poems, short stories, and novellas are a special class of works here. A lot of these were first published in a magazine (possibly serialized), and a lot of them exist as multiple editions in substantially the same form. Some exist in multiple versions. These should all primarily exist the same way as chapters as part of their various containing works; but there are some cases where we might want to have, for example, a series of connected pages of the poems of Emily Dickinson. I am significantly ambivalent about this practice, as it amounts to making our own "edition" or "collection" of her poems (in violation of several of our other policies), but I acknowledge that it is an established practice and it is something that has definite value to our readers. It may be that it is actually a practice that should be governed by its own dedicated policy rather be attempted to be handled within these other general policies.
    For the sake of example; applying this to the works Inductiveload listed at the start of this thread would shake out something like this:
    Auction Prices of Books—This work appears to have no sensible subdivisions and is in any case by a single author. I see no obvious reason to grant this work an exception, except under sheer volume of work and even there I would want to see both a substantial proportion completed and some kind of ongoing effort towards completion (no particular time frame, but definitely not infinite and definitely not as an effectively abandoned project). In a deletion discussion I would very likely vote to delete the mainspace pages here (but, as nearly always, to keep the Index: and Page: namespace artifacts). I don't see this as a reasonable candidate for a Portal:, nor really a good fit for a WikiProject (though I probably wouldn't object to a WikiProject if someone really wanted one).
    Central Law Journal/Volume 1—A single volume is too little, so I would want to see a complete structure for the entire Central Law Journal, with level of detail for each volume similar to the one existing volume. Each article in the journal can be individually considered for a stand-alone work exception; but for the collection I would want to see at minimum a full issue finished to justify having the mainspace structure, and preferably multiple issues (in a deletion discussion I might insist on multiple issues). Index: and Page:-space artefacts can, of course, stay. A Portal: might make sense for selections from the journal, of articles that meet the standalone work exception. A WikiProject to coordinate work and track links to scans etc. might be a decent fit here, if someone wanted that. As it currently stands I would probably vote delete for the mainspace artefacts (with option to move whatever content has reuse value to a non-mainspace page for preservation; and undeleting if someone wants to work on something is a low bar).
    A Critical Dictionary of English Literature—The top level mainspace page has near-zero value, existing only to link to the single transcribed entry. For a credible claim to exception to exist it would need to be a complete framework for the work as a whole, and significantly more than a single entry must be complete. I would probably also want to see ongoing work, unless a substantial percentage of the entries were complete. The single finished entry is eligible to claim a standalone work exception, but I think it probably would not meet my bar for that (I might be wrong; and the rest of the community might judge it differently). In a deletion discussion I would probably vote to delete all the mainspace artifacts here (as always keeping Index:/Page: stuff) but with a definite possibility that I might be persuaded on the one completed entry (an absolute requirement for convincing me would be to scan-back it: as a separate issue, my tolerance for grandfathering of non-scan-backed works is small, and effectively zero for new/non-grandfathered works).
    Bradshaw's Monthly Railway Guide—Would need a full framework and a number of individual issues finished to merit a mainspace page. I see no credible subdivisions for a standalone work exception, but might be persuaded otherwise if, say, one of the train tables was used as a (reliable primary) source in a Wikipedia article (implying some sort of notability beyond just being raw data). In a deletion discussion I would probably vote to delete all mainspace artifacts here. If anyone made the argument, I would entertain the notion that there is value in treating train tables like poems, and hosting a series of train tables like we do Dickinson's poems; but that would require a substantial number of them completed.
    For everything above my stance is nuanced by a willingness to accept temporary exceptions for things that are actively being worked: active being operative, but with no particular deadline to complete the work. We have differing amounts of time available, and some works are so labour-intensive or tedious to do, that my person threshold for "active" is a pretty low bar to clear. If it's months and years between every time you dip in and do a bit I might start to get antsy, but days or weeks probably won't faze me. And that the projected time to completion is very long at that pace is not particularly a problem so long as it is not infinite. Within those parameters I would always tend to err on the side of letting contributors just get on with it in peace, regardless of any of the policy-like rules sketched above.
    I also want to emphasise that I think this is a very difficult issue to deal with. There are a lot of competing concerns, and a lot of grey areas that will likely take individual discussions to resolve. My balance point on this issue is partly formed by a broader concern about our overall quality (we have waay too many works of plain sub-par quality, and too many not up to modern standards) and a hope that by preventing the creation of these kinds of works (rather than deleting them after creation) we will be able to retain the good and desirable exceptions without dragging down quality, and without the traumatic and stressful events that deletions and proposed deletion discussions are.
    And for that very reason I am grateful this issue was brought up here for discussion, and I hope we can end up with some clear guidance, possibly in the form of a policy page, going forward. And in any case, since it will create de facto policy, this is a discussion that needs to stay open for a good long while (there are several community members that have not yet commented whose opinion I would wish to hear before closing this), and depending on how well we manage to structure the consensus, may also require a formal vote (up in the #Proposals section). --Xover (talk) 09:03, 6 July 2020 (UTC)[reply]
  • Symbol oppose vote.svg Oppose. It is becoming clear that a policy on incomplete works in the mainspace is going to place enormous pressure on individual editors. I think it would be more effective to start a wikiproject devoted to scan-backing works that lack scans and so on. James500 (talk) 12:14, 6 July 2020 (UTC)[reply]
    • @James500: FYI, this thread was made in order to provide an exception to the current policy of "no excerpts". A literal reading of the policy as it stands has a plausible chance of coming down delete on the mainspace pages over at WS:PD. This thread is a chance to come up with a better way to support such partial collective works. That we have several substantially incomplete and abandoned collective works lolling around in mainspace is actually the result of laxity in respect to stated policy (not to say I think it's a bad thing). The deletion proposals, whatever you may think of them, are actually not in contradiction to policy. That said, as always, there is scope to adjust policy. Which is what this is.
    • Now, in terms of a WikiProject to scan back works, I think that is a good idea. See #Re-purpose_WikiProject_OCR_to_WikiProject_Scans above, which proposed to reboot Wikiproject OCR as a scan-backing Wikiproject. Inductiveloadtalk/contribs 14:40, 6 July 2020 (UTC)[reply]
      • The policy says "When an entire work is available as a djvu file on commons and an Index page is created here, works are considered in process not excerpts." A literal reading of that policy is that no scan-backed work is an excerpt (it is expected to be completed eventually). Further the policy refers to "Random or selected sections of a larger work". A literal reading of that expression is that it does not include lists of scans, or auxilliary content tables, as they are not "sections" (they are not part of the work), and that not every incomplete portion of a work is either "random or selected" (which would not include starting from the beginning and getting as far as you can, with intent to finish later). I could probably argue that an encyclopedia article or periodical article is a complete work. James500 (talk) 15:16, 6 July 2020 (UTC)[reply]
  • Nice wall of text, Xover (and I say that with great respect!) -- it generally makes sense and sounds good to me. As another hopefully illustrative example, take The Works of Voltaire, which I've been digging thru lately. I think this would very much satisfy your criteria as a large work, with sufficient scaffolding to justify the mainspace pages that exist for it. I would love to hear others thoughts on that. JesseW (talk) 16:07, 6 July 2020 (UTC)[reply]
    @JesseW: Yeah, apologies for the length. Brevity is just not my strong suit.
    The Works of Voltaire probably qualifies on sheer scale of work, yes. I don't think the current wikipage at The Works of Voltaire is quite it though: as it currently stands it is more WikiProject than something that should sit in mainspace (its contents are for Wikisource contributors, to organise our effort, not our readers, who want to read finished transcriptions). It also mixes a work page with a versions page in a confusing way. So I would probably say… Move the current page to Wikisource:WikiProject Voltaire; create a new The Works of Voltaire as a pure versions page, linking to…; The Works of Voltaire (1906), that is set up as a work page with the cover and title (and other relevant front matter) of the first volume, and an AuxTOC (and possibly also the {{Works of Voltaire}} volume navigation template). I don't know how tightly coupled the volumes of this edition are (does the first volume have a common ToC or index of works for all the volumes?), so some flexibility on format may be needed to make sense. But as a base rule of thumb it should start from a regular works page and deviate only as needed to accommodate this work (mainly the size is different).
    In any case… With a volume or two completed (they're only ~350 pages each) I'd be perfectly happy having something like that sitting around. With less then that I'd possibly be a bit more iffy, but it's hard to put any kind of hard limit on that. And with somebody actively working on it I'd be in no hurry whatsoever regardless of current level of completion.
    PS. I'm pretty sure a large proportion of the contents of these volumes are works that would qualify under "standalone works" that could exist independently in mainspace, regardless of what's done with the The Works of Voltaire page. Even his individual poems and essays can presumably make a credible claim here (because it's Voltaire; less famous authors would have a higher bar). Better as part of the edition, but also acceptable on their own. --Xover (talk) 16:56, 6 July 2020 (UTC)[reply]
  • @JesseW: I personally take no issue with this page's existence (actually I think it's a nice work and good way to allow an important author's works to be slotted in piece-by-piece. I have some general comments which overlap with this thread (written before Xover's reply, so pardon overlap):
    • First off, I differ with Xover in terms of the scan links: I think they're better than nothing, and I don't see much value in duplicating the volume list onto an auxiliary page just to add scan links. However, I can sympathise with the sentiment that our mainspace shouldn't direct users off-wiki (or at least off-WMF). But if we don't have the scans, and that's what the user wants, they're leaving anyway. Real answer: import moar scans!
    • No scan links are necessary where the volume exists in mainspace and is scan-backed (e.g. v3)
    • Ext scan links should only be used when there is no Index page or imported scan. Use {{small scan link}} or {{Commons link}} when possible (e.g. v2)
    • The first volume list could probably be in an AuxTOC to mark it out as WS-generated content.
    • The "Other editions" section belongs on an auxiliary namespace page (Talk, Portal or Wikisource). I suggest the Talk page is best in this case. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)[reply]
  • @Xover: I am in agreement with the majority of what you say. Particularly, I think a framework around any collective work (be it a single-volume biographical dictionary or a 400-issue literary review spanning 80 years) is the critical prerequisite, plus at least some scans, the more the merrier. Where I think I differ:
    • I am inclined to be a bit more relaxed in terms of how much of a work we need. As long as a single article exists, it's not "trivial" (e.g. only a short advert or some incidental text like a "note to correspondents", as opposed to an actual article), it's well-formatted and scan-backed, and a complete framework exists, including front matter and a TOC, such that's it is easy for anyone to slot in new pieces, I'd be fairly happy. Lots of periodicals have all sort of tricky bits like tables of stocks or weather tables and writing into policy that those must be proofread in order to get the "real" articles into mainspace would be a chilling effect, in my opinion. If you allowed an exception, it would be verbose and tricky to capture the spirit without saying "unless, like, it's totally, like, hard, man".
    • I am not dead against scan links in the mainspace at the top level, when such a top-level page exists. See my comments on Voltaire above. I am against them where they could sensibly be on an Author page and they are the only mainspace content.
    • I am ambivalent on the presence of, e.g., disjointed train timetables. It's not my thing to have a smattering of random timetables, but as long as they're individually presented nicely, it's not too offensive to my sensibilities. I might question the sanity of someone who loves doing tables that much, but whatever floats the boats! Also, I think that this might circle back to "good for export" - a mark which certainly would require completed issues or volumes. If you want to get that box ticked, you have to do it all.
    • Re the "notability" aspect of individual articles, I'm not really bothered by that, as I don't think we'll see a flood of total dross because few people really want to take the time to transcribe 1867 articles about cats in a tree from the Nowhere, Arizona Daily Reporter, and, actually I think some of the "dross" can be quite interesting in a slice-of-life kind of a way (always assuming well-formed and scan-backed). And the real dross is usually so bad (no scans, raw OCR, etc) that it can be dealt with outside of this topic. I think part of the value of WS is the tiny, weird and wonderful, not just in blockbusters like War and Peace and Pultizers. I think I might like to see more of our articles strung together thematically via Portals, but that's another day's issue. Inductiveloadtalk/contribs 17:35, 6 July 2020 (UTC)[reply]
      • @Inductiveload: We appear to be mostly in agreement. But… instead of me dropping another wall of text on the remaining points of disagreement, maybe that means we're in a position to try to hash out a draft guidance / policy type page with the rough framework? Then we could go at the remaining issues point by point. Because I think I'm in with a decent chance to persuade you to my point of view on at least some of them, but this thread is fast getting unwieldy (mostly my fault). It would also probably be easier for the community to relate to now, and much easier to lean on in the future. --Xover (talk) 18:31, 6 July 2020 (UTC)[reply]
        • @Xover: If there are no more comments forthcoming after a couple of days, I think that makes sense. I don't want to railroad it: considering we have at least one !vote for "do nothing", I'd like to see if there are any other substantially different opinions floating about. Inductiveloadtalk/contribs 17:41, 7 July 2020 (UTC)[reply]

The quantity of text here has grown far faster than my ability to absorb it, so rather than continue to put it off, here's my position: I don't see any problem with transcriptions that are scan-backed, even if the transcription only covers a small fraction of the entire scan. If Sally chooses (say) to transcribe a favorite story, that happened to be published in an issue of Harper's back in the 1890s, and goes to the trouble of uploading the full issue, but only creates pages for the one story that interests her, I think that's great. It doesn't matter to me whether she intends to work on the other pages or not. If it's not scan-backed, but it's fairly high quality, I am personally willing to do some work trying to locate a scan and match it up to the text; I'd rather we take that approach, than deletion, though of course deletion is the better option in some cases where the scan is very hard to come by.

If all this has been said above, or if I've misunderstood the topic, my apologies. Please take this comment or leave it, as appropriate. -Pete (talk) 02:00, 8 July 2020 (UTC)[reply]

Apologies, I see I had missed the point.

I disagree with Xover's statement that a top-level page for a publication, with a link only to a single article within the publication, has "near-zero value." Such a page can serve an important function linking content together in ways that help the reader (and search engines) find the content they're looking for, or understand the context around it. For instance, A Critical Dictionary of English Literature is linked from the relevant Wikidata entry. The banner on the Wikisource page clearly tells a Wikisource reader that they won't find a full transcription here; and with a simple edit, it could link to a full scan on another site, or (with perhaps a little more effort) even transcription links here on Wikisource. This page has been here since 2010; we don't have any way of knowing what links might have been created elsewhere in the intervening decade. (I do think that new pages like this should not be created without a scan at Commons to be linked to.) -Pete (talk) 02:12, 8 July 2020 (UTC)[reply]

I'm really bad with walls of text, so I have only read a tiny portion of the above discussion. But I want to mention a couple of things that I think are worth considering in this discussion.
  • Most of the time, a mainspace "work" that is only a table of contents, but which has none of the actual content, and is not actively being worked on, can be (and should be) deleted as No meaningful content or history under our deletion policy.
  • A mainspace work that has only a little bit of content, but that content is a work unto itself within the scope of Wikisourse, should be kept. Most periodicals are like this. For an example, see the Journal of English and Germanic Philology which only has one hosted article, but that hosted article is scan-backed and firmly within scope.
  • On some occasions, empty mainspace works do have value. I ended up creating the page The Roman Breviary, depsite containing no actual content, mostly because there are a lot of works that link to it, using many different titles, and if someone uploaded a copy of the work under one title then many of the links would remain red because they point to different titles of the work. This could be easily solved by creating redirects to a simple placeholder page, so I did. I tried to make the placeholder page as useful as a placeholder page can be, as it contains useful information about the history and authorship of the work, and links to the Index pages where the transcription will take place.

Anyway those are my 2 cents, sorry if they are redundant —Beleg Tâl (talk) 00:40, 29 July 2020 (UTC)[reply]

Proposal[edit]

Since there has been no extra input for a month, and not wanting this section to get archived without at least attempting a proposal, I have started a proposal #Collective work inclusion criteria above. Inductiveloadtalk/contribs 11:00, 25 August 2020 (UTC)[reply]

Since the proposal has now slipped off the main page (to here), with vague support for the first part (collective work inclusion criteria) and a fairly consistent opposition to the second (no-content pages), my plan is to transfer the first part, as guidelines rather than policy, to Wikisource:Periodical guidelines. As non-binding guidelines, they can then be worked on further in situ. Sound OK? Inductiveloadtalk/contribs 08:10, 16 April 2021 (UTC)[reply]
The example given in Wikisource:Periodical guidelines might be improved, PSM is and was an exercise that has gone its own way (no offense to @Ineuw:, this is a site under development and that is only one example).CYGNIS INSIGNIS 13:05, 17 April 2021 (UTC)[reply]
@Cygnis insignis: You would be wrong to think that I am offended. Remember that when I started, I knew everything. By now, so much of that knowledge is lost that I am happy to listen. Would you elaborate please? — Ineuw (talk) 19:50, 17 April 2021 (UTC)[reply]

I've created Bradshaw's Monthly Railway and Steam Navigation Guide (XVI) - it couldn't be done on one page, due to the very high number of template transclusions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:52, 1 September 2020 (UTC)[reply]

@Pigsonthewing: The links in the toc on that page appear non-functional. Also, depending on just exactly which templates were the culprit, it is possible that you may be able to put all the content you wanted onto one page now due to some recent technical changes (template code moved to a Lua module which drastically improves performance and prevents hitting transclusion limits until much later). Xover (talk) 11:17, 14 September 2021 (UTC)[reply]

Universal Code of Conduct News – Issue 1[edit]

Universal Code of Conduct News
Issue 1, June 2021Read the full newsletter


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

Please note, this is the first issue of UCoC Newsletter which is delivered to all subscribers and projects as an announcement of the initiative. If you want the future issues delivered to your talk page, village pumps, or any specific pages you find appropriate, you need to subscribe here.

You can help us by translating the newsletter issues in your languages to spread the news and create awareness of the new conduct to keep our beloved community safe for all of us. Please add your name here if you want to be informed of the draft issue to translate beforehand. Your participation is valued and appreciated.

  • Affiliate consultations – Wikimedia affiliates of all sizes and types were invited to participate in the UCoC affiliate consultation throughout March and April 2021. (continue reading)
  • 2021 key consultations – The Wikimedia Foundation held enforcement key questions consultations in April and May 2021 to request input about UCoC enforcement from the broader Wikimedia community. (continue reading)
  • Roundtable discussions – The UCoC facilitation team hosted two 90-minute-long public roundtable discussions in May 2021 to discuss UCoC key enforcement questions. More conversations are scheduled. (continue reading)
  • Phase 2 drafting committee – The drafting committee for the phase 2 of the UCoC started their work on 12 May 2021. Read more about their work. (continue reading)
  • Diff blogs – The UCoC facilitators wrote several blog posts based on interesting findings and insights from each community during local project consultation that took place in the 1st quarter of 2021. (continue reading)


unsigned comment by SOyeyele (WMF) (talk) 22:37, 10 June 2021‎.

Index:Robert Carter- his life and work. 1807-1889 (IA robertcarterhis00coch).pdf[edit]

First run through is done, and it's transcluded. Needs validation. Thanks in advance for any help. Jarnsax (talk)

If I may... about the Monthly Challenge[edit]

Hi! I'm Ernest-Mtl, who started this kind of monthly challenge on the French-language Wikisource in 2019… Originally called Défi 5000' for 5000 proofread pages per month but later changed in October 2020 for Mission 7500 for 7500 proofread or validated pages… Before that, our community collaboration was simply called Défi du mois (Monthly challenge) but would barely meet the completion of a few books (about 1000 to 2000 pages per month).

Our experience showed a few things:

  • Naming the challenge with a number brought the people to participate a *LOT* more… from less than 2000 pages per month, calling it Défi 5000, brought us to an average of 6319 pages per month in 2019 and now, with the Mission 7500, we have an average of 9456 pages in 2021 so far…
  • Placing the actual results of the challenge on the main page from sensibly the same place you have yours actually to the upper right side column, just before new texts in a little container brought a lot more people because they don't have to scroll down the page.
  • People like to see actual results of what they participated in… that's why we started to advertise how many books were publish with our challenge. For example, they can see in almost real time how many works were completed in the current month, for each month and for the whole year. Seeing the challenge permited to publish in 2019 305 books out of 589 on our complete wikisource project brought them to continue their implication.
  • In the beginning, every month I was doing a post on the scriptorium to show the evolution of the challenge. Nowadays, it's not necessary anymore.
  • We try to represent as much as possible all the country of publication every month (mainly France, Canada (Québec), Belgium, Switzerland) ; we try to have a variety of works as well : novels, poetry, theatre, science, novella or short-stories, etc…

It was rough to start but brought vigorous implication in the challenge. I hope the English-speaking community will make your challenge sky-rocketed! :)

--Ernest-Mtl (talk) 14:12, 11 August 2021 (UTC)[reply]

@Ernest-Mtl: thanks for the message! Some things I'm hoping to add to our MC:
  • Tags in {{New texts}} for MC works
  • Live progress bars for indexes (so it won't need a bot to keep them up-to-date) - the backend is nearly ready
  • A way to record finished books would be good. Currently, validated books are the bottom of the page, but there's no global list of MC-completed works.
  • I haven't done a Scriptorium post this month because I rushed the MC changeover
  • I avoid naming after a number because I wasn't sure what we could achieve. 2000 seems a decent target for now — we hit that the first two months, missed by hair last month). We do have limited participation (myself included), possibly due to summer and also from lack of awareness or desire to work on shared works (?)
Thank you very much for the other notes, I will bear them in mind. I plan to revisit some of the implementation soon, when I have a bit of time and once some back-end facilities are ready.
And of course a big "thank you" for the idea and frWS implementation that we could "be inspired by" (or shamelessly rip off). The massive success of the frWS Défi is what made me so keen to give it a go here. ♥ from enWS :-) Inductiveloadtalk/contribs 10:13, 12 August 2021 (UTC)[reply]
@Inductiveload: Well, nothing is a rip off in a community project… We're all working with the same goal… sharing interests and bringing people together working toward a shared goal… lol PS: I've seen your system is a lot more automated than ours… We are still doing the counting by hand (almost) using the bookworm bot reports… I'm kinda jealous! hahahaha --Ernest-Mtl (talk) 14:59, 28 August 2021 (UTC)[reply]
excellent. we are keeping up with French in proofreading, but not validation. so let the competition begin. Slowking4Farmbrough's revenge 15:03, 12 August 2021 (UTC)[reply]
@Slowking4: That could be a cute thing to do… finding 5 books in English and their French translations… Then creating a friendly competition… hehe --Ernest-Mtl (talk) 14:59, 28 August 2021 (UTC)[reply]
@Inductiveload: Thank you for your wonderful note and I'm sorry that I wasn't around during the summer. Your Défi was indeed the inspiration when I proposed this to Inductiveload. It's been utterly amazing to explore frWS and see the treasure trove of scan-backed works. Thank you for all your work.
@Inductiveload: I think that we should try these three things.
  • Tagging MC texts in the New Text box. This might require a formal proposal because one particular, powerful member is against the idea.
  • Moving the Collaboration box to above the New Text box.
  • Instead of formally naming our challenge MC, we can provide a progress bar showing our progress towards the goal number_of_pages_completed [Progress Bar] 2000. Languageseeker (talk) 10:57, 20 September 2021 (UTC)[reply]
@Languageseeker::
  • There was a proposal for this in June, which got a bit of general support, but no further comments on the implementation proposed at Template:New texts/sandbox. Based on the very strong opposition leading to instant reversion of the download links for new items after proposal and implementation, that's not enough to convince me to move forward. I'd support a new proposal, though.
  • Moving the Collaboration box to above the New Text box. This will definitely need a separate discussion.
  • Instead of formally naming... porque no los dos? I have a little more work to do on the background logic for the stats in light of the new Lua lib for that, however. Inductiveloadtalk/contribs 11:19, 20 September 2021 (UTC)[reply]

Inductiveloadtalk/contribs 11:19, 20 September 2021 (UTC)[reply]


While we're on the subject: the Monthly Challenge has just completely validated all three volumes of Sense and Sensibility, finally completing the progress on a page that has existing since 2004! Thank you everyone involved! Inductiveloadtalk/contribs 19:34, 12 August 2021 (UTC)[reply]

It's a shame though, that the work still contained scores of errors because (I'm guessing) the text was matched-and-split to a scan of a different edition with different punctuation and spelling conventions. Validation can't be relied on as a sign of quality. BethNaught (talk) 07:57, 20 September 2021 (UTC)[reply]
@BethNaught: This is a real shame. Hopefully, this is the result of an older match-and-split that does not happen anymore. Thank you for revalidating this work. Languageseeker (talk) 10:57, 20 September 2021 (UTC)[reply]
The proofread and validation should pick up that we are in a different version and correct. Something askew there. — billinghurst sDrewth 12:10, 20 September 2021 (UTC)[reply]

new page notice[edit]

The blurb when creating a new Page is currently:

"This page does not exist yet; you can create it by typing in the box below and publishing the page. If you are new to Wikisource, please see Help:Adding texts. If you are here by mistake, just click your browser's back button. If no text layer is automatically made available, click the OCR button [obsolete] on the toolbar to try to generate one. To open and close the header and footer fields, toggle Button category plus.png. Also see Proofreading instructions. [links, etc]"

There is a very small audience for these instructions, most of which is out of date and unneeded by proofreaders. I recall their introduction as a reaction to a test or other by a 'new user', not fulfilling an actual need.

"This transcription page has not been created. For assistance see Help:Adding texts."

To the point, more helpful, and returns screen territory to users who see this more than once. CYGNIS INSIGNIS 13:00, 12 August 2021 (UTC)[reply]

yes. the instruction creep gets ignored, so less is more. but also some UX with veterans and newbies would be helpful.--Slowking4Farmbrough's revenge 14:51, 12 August 2021 (UTC)[reply]
Yes, yes, it is really really annoying to see the same blurbishnessblup over and over. And over. Toggle this info or make it curt and direct. Shenme (talk) 20:53, 18 August 2021 (UTC)[reply]

Pictogram voting comment.svg Comment can we have suggestions to improve or pointers the change that should be made rather than "I don't like it", "this is old", etc. Some of the pages for text are

So pointers to the image in use would be great. Some of us don't see it either for blocking or with older toolbars.

Also noting that we have some paired text in special:preferences at MediaWiki:Proofreadpage-preferences-showheaders-label. — billinghurst sDrewth 02:13, 26 August 2021 (UTC)[reply]

  • Two supports and a comment from the creator of the former text. Does anyone have a tweak to the replacement text—proposed above—before it is implemented? Cygnis insignis (talk) 16:59, 9 September 2021 (UTC)[reply]

Request for comment notification[edit]

Here is a link to a RFC on Meta concerning all Wikimedia projects. unsigned comment by Lionel Scheepmans (talk) .

Template:PD-nonUK[edit]

I've been confused by this template for a long time and it's been bothering me, and it has occurred to me now that it's because of the template's vagueness and lack of specificity.

It currently says "This work is in the public domain outside the United Kingdom because the author has been deceased at least 100 years. However, owing to the subsistence of certain long-standing restrictions on publication and distribution, the work is NOT necessarily copyright or restriction free in the United Kingdom." What certain long-standing restrictions are these? Which UK laws apply here specifically? And does this only apply to certain old works in the United Kingdom, all old works originally published in the UK, or all old works regardless of country of origin? As someone completely unfamiliar with UK copyright law, I have no idea what someone ought to be worried about if they're in the UK.

Some past discussion on this matter: Wikisource:Possible_copyright_violations/Archives/2006/04#Book_of_Common_Prayer and Template talk:PD-nonUK#This perpetual copyright will eventually end

While it's been talked about before in these places, I think the wording of this template still needs to be more specific so our readers don't have to dig around our community chatter to find out why this template exists. Pinging User:Jusjih. PseudoSkull (talk) 13:36, 25 August 2021 (UTC)[reply]

There isn't a single route to this template. The uses I know of:
  • Peter and Wendy: the play (not the book, which came later) was granted perpetual copyright in the UK (because just allocating funds for a children's hospital would be too easy): details here, but the law is a specific section of the CPDA 1988.
  • KJV and Book of Common Prayer are another, totally separate, weird thing where permission to print the works is restricted by royal prerogative via letters patent, rather than copyright. The CPDA 1988 has a (non-specific) carve-out under para (1)(b) here (and I don't know if the actual letters patent are published anywhere, but if they were, we can have them too since, y'know, pre-1925).
Tl;dr there's not a single law that applies here, though both these cases are covered partly under the CPDA, which makes sense because that provides pretty much all relevant law in the UK. Inductiveloadtalk/contribs 14:15, 25 August 2021 (UTC)[reply]
I started the template only due to others talking about the British perpetual copyright. I am unfamiliar with it, so correct the template as needed.--Jusjih (talk) 18:04, 13 September 2021 (UTC)[reply]

Should no The and The be disambiguated?[edit]

There is Orange Grove (1866) by Sarah E. Wall, but there's also a book called The Orange Grove (1829) by Mary Martha Sherwood. Should they be disambiguated at a main Orange Grove page? This would put the wall text at Orange Grove (Wall) and the Sherwood text at The Orange Grove (Sherwood). @Billinghurst: if you think this is compelling, can you please make the more from Orange Grove -> Orange Grove (Wall)? PseudoSkull (talk) 18:32, 26 August 2021 (UTC)[reply]

I suppose it should be moved because "The Orange Grove" by Sherwood could just be referred to as "Orange Grove" in some sources. PseudoSkull (talk) 18:33, 26 August 2021 (UTC)[reply]
**If** we are to disambiguate, then we would go to "Orange Grove"; when they have been like that we have not forced a disambig, nor have we been concerned if someone does. It just means that we cannot have hatnotes until we do. Your call on what you would like done. — billinghurst sDrewth 08:39, 28 August 2021 (UTC)[reply]
@Billinghurst: After some thought, I would like the move to be carried out. Could you please initiate that process as I cannot? PseudoSkull (talk) 17:43, 9 September 2021 (UTC)[reply]
Will do. — billinghurst sDrewth 23:25, 9 September 2021 (UTC)[reply]
"It sometimes seems wrong to omit a, some say the, definite article." [adapted from unattributed] CYGNIS INSIGNIS 12:39, 28 August 2021 (UTC)[reply]
Definitely would agree on produced works that we don't omit "A"/"An"/"The". The ability to group on disambiguation pages, and have redirects gets us around this issue, especially where the names of works are regularly referred to without these articles, and maintaining multiple disambiguation pages for each was leading to holes, confusion and related issues. I would also say that if we are doing a {{versions}} page that we would do that **with** the article not without as we do for disambiguation. — billinghurst sDrewth 23:25, 9 September 2021 (UTC)[reply]
@Cygnis insignis: Wrong as it may be, many times I've seen book titles referred to in this way in works I've proofread, which in my mind makes it make sense for there to be redirects from articleless titles. Perhaps the writer had an incorrect memory that the external work title did not begin with "The", or perhaps they had some idea that omitting it was okay. PseudoSkull (talk) 12:05, 15 September 2021 (UTC)[reply]
@PseudoSkull: it's all good in context, and we might see: '… the Orange Grove' as a reference to either work, but I'm guessing it is always The Tiger / Raven. Definitely following the context, by reading, than predisambiguation, by rule, is reasonable. (I didn't look deeply at teh examples, one is a red link) … actually, unbracket, one is a redlink :/ Cygnis insignis (talk) 12:24, 15 September 2021 (UTC)[reply]
and citation for authoress-ship please? Cygnis insignis (talk) 12:29, 15 September 2021 (UTC)[reply]

Redundant templates?[edit]

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

Will anybody object if I delete them? --Jan Kameníček (talk) 13:24, 5 September 2021 (UTC)[reply]
Deleted. --Jan Kameníček (talk) 08:34, 8 September 2021 (UTC)[reply]

Tech News: 2021-36[edit]

15:20, 6 September 2021 (UTC)

Comment[edit]

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)[reply]

Pictogram voting comment.svg 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. Inductiveloadtalk/contribs 06:54, 7 September 2021 (UTC)[reply]
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) --Slowking4Farmbrough's revenge 01:43, 8 September 2021 (UTC)[reply]
Pictogram voting comment.svg 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)[reply]
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. --Slowking4Farmbrough's revenge 22:04, 12 September 2021 (UTC)[reply]
Pictogram voting comment.svg 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)[reply]

header, AuxTOC, and mbox[edit]

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)[reply]

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)[reply]
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. --Slowking4Farmbrough's revenge 01:35, 8 September 2021 (UTC)[reply]
Pictogram voting comment.svg Comment Ditto I second Slowking4. — Ineuw (talk) 02:02, 8 September 2021 (UTC)[reply]
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)[reply]

Pictogram voting comment.svg 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)[reply]

Just asking some questions about the {{FI}} template css[edit]

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)[reply]
@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. Inductiveloadtalk/contribs 08:36, 8 September 2021 (UTC)[reply]
@Inductiveload: Much thanks for the explanation. — Ineuw (talk) 09:25, 9 September 2021 (UTC)[reply]
@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. Inductiveloadtalk/contribs 06:36, 10 September 2021 (UTC)[reply]
Thanks again. Understood.— Ineuw (talk) 05:16, 11 September 2021 (UTC)[reply]

Results for the 2021 Wikimedia Foundation Board of Trustees election[edit]

Read in other languages

Wikimedia-logo black.svg

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)[reply]

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

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 strategy2030(_AT_)wikimedia.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)[reply]

Copyright-relevant properties for Wikidata - comments sought[edit]

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

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). Inductiveloadtalk/contribs 21:58, 10 September 2021 (UTC)[reply]

Server switch[edit]

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

Talk to the Community Tech[edit]

Magic Wand Icon 229981 Color Flipped.svg

Read this message in another languagePlease 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

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

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

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

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)[reply]

  •  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)[reply]
@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)[reply]
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. Inductiveloadtalk/contribs 16:48, 12 September 2021 (UTC)[reply]

Problem with poem extension in mobile view[edit]

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)[reply]

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)[reply]
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)[reply]
@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. Inductiveloadtalk/contribs 12:59, 13 September 2021 (UTC)[reply]

Poor Robin's True Character of a Schold[edit]

@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: [6]. 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)[reply]

@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? Inductiveloadtalk/contribs 07:37, 13 September 2021 (UTC)[reply]
@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.
-- ei (talk) 18:06, 22 September 2021 (UTC)[reply]

Tech News: 2021-37[edit]

15:35, 13 September 2021 (UTC)

Early modern and Modern author?[edit]

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)[reply]

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)[reply]
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)[reply]

FYI: Preloading derived header templates for serials and compilation works[edit]

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)[reply]

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)[reply]
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)[reply]
@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)[reply]
Okay, I guess they did.--Prosfilaes (talk) 04:40, 15 September 2021 (UTC)[reply]

Entering a new work[edit]

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)[reply]

@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)[reply]

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)[reply]

@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! Inductiveloadtalk/contribs 13:22, 15 September 2021 (UTC)[reply]
@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)[reply]
I was wondering if Word could export to pdf yet.--RaboKarbakian (talk) 14:31, 15 September 2021 (UTC)[reply]

ProofreadPage Lua library will be available from today[edit]

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! Inductiveloadtalk/contribs 14:59, 15 September 2021 (UTC)[reply]

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)[reply]

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}}

Inductiveloadtalk/contribs 13:36, 16 September 2021 (UTC)[reply]

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

Center block[edit]

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)[reply]

@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)[reply]

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)[reply]

@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}}. Inductiveloadtalk/contribs 11:53, 5 October 2021 (UTC)[reply]
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. Inductiveloadtalk/contribs 13:09, 5 October 2021 (UTC)[reply]
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)[reply]
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)[reply]

Camera Work[edit]

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)[reply]

That's a really pretty work. If I had more wall space, I'd be down to the print shop this lunchtime! Inductiveloadtalk/contribs 11:01, 20 September 2021 (UTC)[reply]
@Yann: Please continue to upload the volumes and I will make a page for them. Languageseeker (talk) 11:18, 20 September 2021 (UTC)[reply]
It will take some days to have the complete collection. Already 24 (+ 1 supplement) uploaded. Regards, Yann (talk) 12:56, 21 September 2021 (UTC)[reply]
@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)[reply]
Hi, Did you create a page for the whole set? Yann (talk) 20:47, 25 September 2021 (UTC)[reply]
@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)[reply]
@Yann Yes check.svg Done : Camera Work. Enjoy, and thanks for the work so far! Inductiveloadtalk/contribs 22:05, 4 October 2021 (UTC)[reply]
Also I set up {{Camera Work link}} and {{Camera Work volumes}} for you. Inductiveloadtalk/contribs 22:20, 4 October 2021 (UTC)[reply]

Camera Notes[edit]

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)[reply]

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)[reply]
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. Inductiveloadtalk/contribs 21:33, 6 October 2021 (UTC)[reply]

291[edit]

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)[reply]

Tech News: 2021-38[edit]

18:32, 20 September 2021 (UTC)

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

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)[reply]

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. Inductiveloadtalk/contribs 07:39, 21 September 2021 (UTC)[reply]

Links to LCCN subjects in the Authority Control[edit]

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)[reply]

@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. Inductiveloadtalk/contribs 10:11, 21 September 2021 (UTC)[reply]
Great! Thanks. --Jan Kameníček (talk) 10:57, 21 September 2021 (UTC)[reply]

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

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)[reply]

Drop initial + long second line in poetry formatting[edit]

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)[reply]

@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! Inductiveloadtalk/contribs 09:42, 24 September 2021 (UTC)[reply]
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)[reply]
{{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)[reply]
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. Inductiveloadtalk/contribs 14:14, 24 September 2021 (UTC)[reply]
Why is the extant means unmentionable? JUST 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%;". Inductiveloadtalk/contribs 16:29, 24 September 2021 (UTC)[reply]
"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)[reply]

Position of clickable Wiki markup[edit]

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)[reply]

It (only) changes position for me when I toggle the edit bar in preferences.--RaboKarbakian (talk) 15:22, 25 September 2021 (UTC)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]

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

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)[reply]

Oh, and "P:" or "PO:" for the Portal namespace. PseudoSkull (talk) 21:44, 25 September 2021 (UTC)[reply]
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. Inductiveloadtalk/contribs 22:01, 25 September 2021 (UTC)[reply]
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)[reply]
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)[reply]

Should we include state propaganda?[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
"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)[reply]
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)[reply]
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)[reply]
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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • you would have a better case deleting as not scan backed. bloggy sources here:[17], [18], [19] 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.--Slowking4Farmbrough's revenge 21:33, 7 October 2021 (UTC)[reply]

Two authors with the same name[edit]

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)[reply]

@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)[reply]
@Billinghurst: Thanks! That works! --Cassiodore89 (talk) 14:52, 26 September 2021 (UTC)[reply]

Portal for Leopold and Loeb[edit]

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)[reply]

@PseudoSkull sounds eminently reasonable to me. Inductiveloadtalk/contribs 19:10, 26 September 2021 (UTC)[reply]
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)[reply]

Tech News: 2021-39[edit]

22:22, 27 September 2021 (UTC)

Philosophical Transactions of the Royal Society[edit]

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)[reply]

@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)[reply]
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). Inductiveloadtalk/contribs 13:26, 28 September 2021 (UTC)[reply]
¯\_(ツ)_/¯ 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)[reply]
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)[reply]
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. Inductiveloadtalk/contribs 17:49, 28 September 2021 (UTC)[reply]
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)[reply]

Alice in Wonderland in Words of One Syllable[edit]

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)[reply]

Yes check.svg Done kathleen wright5 (talk) 13:45, 30 September 2021 (UTC)[reply]

Localisation request[edit]

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)[reply]

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)[reply]

I have moved the two djvu files over, though we still have the category contents. — billinghurst sDrewth 12:38, 3 October 2021 (UTC)[reply]
Yes check.svg 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)[reply]
c:Commons:Deletion_requests/Files_in_Category:Hansel_and_Gretel_and_other_stories_(1921) ShakespeareFan00 (talk) 08:49, 9 October 2021 (UTC)[reply]
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)[reply]
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)[reply]

Translation:Shulchan Aruch/Orach Chaim/507[edit]

I have just come across Translation:Shulchan Aruch/Orach Chaim/507. I cannot speak Hebrew, but Google translate suggests that there are completely different Hebrew and English texts. What can be done about it? Should it be deleted? --Jan Kameníček (talk) 08:01, 3 October 2021 (UTC)[reply]

Perrsonally I think we should just get rid of all Wikisource translations that aren't scan-backed, because they are impossible to verify in practice; and in particular they make it effectively impossible to verify random changes to them while patrolling recent changes. But so long as we permit this crud to accumulate there is little to be productively done about cases such as Translation:Shulchan Aruch/Orach Chaim/507 (or all of Translation:Shulchan Aruch for that matter: it is all equally unverifiable, and I regularly see arbitrary changes to the very same bits of it since I happen to have it watchlisted after some technical maintenance). I have essentially given up both patrolling and other improvements to non-scan-backed stuff in the Translation: namespace. Xover (talk) 08:09, 3 October 2021 (UTC)[reply]
Incidentally, see also Translation:Manshu, currently listed at WS:PD#Translation:Manshu (with predictable results), which claims to be a translation of some ancient work, but which is really mostly an original analytical/comparative/interpretative work by the contributor and in violation of multiple of our policies. But because it is in the Translation: namespace it seemingly gets a pass on any number of sins (policy violations). We should just go ahead and rename it "ThePolicyFreeZoneAndAnythingGoes:" and be done with it. Xover (talk) 08:15, 3 October 2021 (UTC)[reply]
Hm, that is strange… While a couple of hours ago Google translated the Hebrew text in a completely different way to what the page contains in English (i.e. as if it were a completely different text about something different), now I tried it again and now the meaning of the translations more or less coincides. Looks like Google makes fun of me. --Jan Kameníček (talk) 13:57, 3 October 2021 (UTC)[reply]

Orphaned pages[edit]

Hi. We should work out a way to avoid these pages to appear in Orphaned pages: Page:Hesiod, The Homeric Hymns, and Homerica.djvu/100.Mpaa (talk) Mpaa (talk) 22:18, 3 October 2021 (UTC)[reply]

@Mpaa: Transwiki it to either elWS or mulWS and then delete it. — billinghurst sDrewth 22:20, 3 October 2021 (UTC)[reply]
I tried to understand the process but I guess I do not have rights for Special:Import. Mpaa (talk) 20:08, 5 October 2021 (UTC)[reply]

Let's talk about the Desktop Improvements[edit]

Annotated Wikipedia Vector interface (logged-out).png

Hello!

Have you noticed that some wikis have a different desktop interface? Are you curious about the next steps? Maybe you have questions or ideas regarding the design or technical matters?

Join an online meeting with the team working on the Desktop Improvements! It will take place on October 12th, 16:00 UTC on Zoom. It will last an hour. Click here to join.

Agenda

  • Update on the recent developments
  • Sticky header - presentation of the demo version
  • Questions and answers, discussion

Format

The meeting will not be recorded or streamed. Notes will be taken in a Google Docs file. The presentation part (first two 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 talk page or send them to sgrabarczuk@wikimedia.org.

Olga Vasileva (the team manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) 15:09, 4 October 2021 (UTC)[reply]

Tech News: 2021-40[edit]

16:31, 4 October 2021 (UTC)

Why I write (George Orwell)[edit]

Hi all, sorry new to wikisource and not sure if this is the right place for this, but wanted to query about "Why I Write" by George Orwell.

I can't find a copy on here for the text, and wanted to see if this was a copyright issue at all? I think the work is public domain now (published in 1946). Jamzze (talk) 18:27, 6 October 2021 (UTC)[reply]

Hello. Unfortunately, this work is in the public domain in the UK, but for English Wikisource it is necessary it was in the public domain in the United States, which will not happen until 95 years after publication. For details see Wikisource:Copyright policy and Help:Public domain. --Jan Kameníček (talk) 18:45, 6 October 2021 (UTC)[reply]
Thanks - I thought it might be something to do with copyright! Jamzze (talk) 19:13, 6 October 2021 (UTC)[reply]
here it is at Internet Archive, [27] in collected essays, not digital controlled lending. here is File:George Orwell - 'Politics & the English Language' (1946) (IA orwell-politics-the-english-language-1946).pdf, but you are at the mercy of the uneven URAA enforcement, given the legal memo suggesting actual evidence of a copyright violation. --Slowking4Farmbrough's revenge 13:50, 7 October 2021 (UTC)[reply]
This has nothing to do with the URAA; under US law it's a US work that dotted all its i's and crossed all its t's.--Prosfilaes (talk) 09:18, 9 October 2021 (UTC)[reply]
good, then upload the local version of the essays right now. --Slowking4Farmbrough's revenge 22:45, 9 October 2021 (UTC)[reply]
The point is that it has nothing to do with the URAA or the status in the UK. Why I Write is copyrighted in the United States because it was published in 1953 with renewal (Renewal: RE121351). Politics and the English language was published in 1950 and renewed (Renewal: RE014467) MarkLSteadman (talk) 23:15, 9 October 2021 (UTC)[reply]
thanks, we are left to guess, when broad claims of copyright are made, and works exist on commons, a deletionist place; and "Politics and the English language" may be public domain, since there is enough of a gap between the serial and book, but i leave that to your deletion discussion. Slowking4Farmbrough's revenge 15:16, 10 October 2021 (UTC)[reply]

Adding Alternative Image[edit]

I've noticed that on many books there is the image from the book and often a second, higher-quality version of the same image. For example, a black-and-white painting and then a full color, modern scan of the same image. This sometimes leads to debates over which one to use. I was wondering if it would be possible to add an alternative image (maybe to floating image) and then toggle it in the same way that long s is dealt with. The alternative parameter would be optional. In this way, each user can decide whether to see the original or the modern scans.

{{img float | file = original file | alternative = modern scan … }}

Languageseeker (talk) 22:36, 8 October 2021 (UTC)[reply]

Help with formatting a transcription[edit]

Can someone help me with my transcription, I want to match the format and font more closely. See: Commons:File:War Department letter to Eloise Lindauer II (1856-1935) concerning the reburial of Louis Julius Freudenberg I (1894-1918).png --RAN (talk) 06:39, 9 October 2021 (UTC)[reply]

@Richard Arthur Norton (1958- ): Something like this? Xover (talk) 08:30, 9 October 2021 (UTC)[reply]
  • Perfect, thank you! I will use it as a template for other War Department letters I am transcribing. --RAN (talk) 15:08, 9 October 2021 (UTC)[reply]
@Xover: More questions: Where would I add Portal:Eloise Lindauer and how would I change the font to Courier, to see if it more closely matched the original font. I am sorry to bother with such basic questions. --RAN (talk) 23:44, 9 October 2021 (UTC)[reply]
@Richard Arthur Norton (1958- ): Specific fonts are challenging here, but you might look into <code> and its variations or even use html <pre>. As for the "Portal": here, people are typically found in the Author namespace (like Author:Edgar Allan Poe or Author:Lewis Carroll) and groups of people or Subjects are found in the Portal namespace (Like Portal:Brothers Grimm or Portal:United States Office of Education or Portal:Biology). Perhaps your Portal should be moved to Author.--RaboKarbakian (talk) 18:35, 10 October 2021 (UTC)[reply]
@RAN: Portals are added through a parameter to the {{header}} template, like this.
Regarding the font, we do not add specific fonts (vs. a general type of font), both because we cannot guarantee all users have it available and because we want users to be able to choose their font for a given style. The only exceptions are {{blackletter}} and some specialised fonts for non-English scripts (Hebrew etc.). If you just want to experiment you can manually do it with raw HTML (<div style="font-family: Courier;"> page content </div>) and preview, but please don't actually use that in any non-sandbox page. Xover (talk) 17:51, 11 October 2021 (UTC)[reply]
  • Thanks again! Author:Eloise Lindauer was deleted by User:Bilinghurst, when it was restored, he deleted it again.
    To be accurate the page was moved to your user namespace.

Localisation requests ...[edit]

Localization is requested due to additional/new material consisting of editorial notes and Commentary by Robert William Chapman (1881-1960), meaning that regrettably the work is not PD in the UK yet, and so cannot be hosted on Commons. ShakespeareFan00 (talk) 09:00, 9 October 2021 (UTC)[reply]

Thank you for finding out about this. I would add Index:Fragment of a novel written by Jane Austen.pdf to the list because it was also edited by R.W. Chapman. Languageseeker (talk) 00:00, 10 October 2021 (UTC)[reply]
Bar the PDF for Chapman's Jane Austen, the other five files have been made local. The other file should be brought to Commons as a djvu and I will move it over here. The pdf is just dying when I try to migrate it and after three attempts that is enough time-wasting. — billinghurst sDrewth 11:31, 13 October 2021 (UTC)[reply]

Template:Default layout[edit]

Why does Template:Default layout not work in user pages? --PastelKos (talk) 13:07, 10 October 2021 (UTC)[reply]

Because it's designed for Mainspace: only. Beeswaxcandle (talk) 03:57, 12 October 2021 (UTC)[reply]

wikipedia link for work via wikidata[edit]

A wikipedia article on a work here is what I expect and usually see being linked in the header, one-to-one for a text if it exists, however, I notice that the link will correspond with the 'main subject' of a work at its own wikidata item. I assume that must be unintentional and can be corrected in our header's coding for sister links. Cygnis insignis (talk) 15:28, 11 October 2021 (UTC)[reply]

In the early days of linking with WD there was some automations that got it wrong. The way to fix is to repoint over at Wikidata. Beeswaxcandle (talk) 03:59, 12 October 2021 (UTC)[reply]
The links to Wikipedia are graduated. 1) Direct interwikink; then 2) Through the WD edition of; then 3) main subject. There is no need to do direct WP links, it is better if the links are managed through WD so the most relevant link is used, AND it better corresponds with the target page at WP wherever it may be. If there is nothing at WD then no link; all works well. — billinghurst sDrewth 07:05, 13 October 2021 (UTC)[reply]
Think we documented these at Template talk:plain sister. I could be mistaken that we had a brief conversation here, I forget. — billinghurst sDrewth 07:08, 13 October 2021 (UTC)[reply]

I have a related question about this, and to mention that I think the wikidata interaction described above is very cool. My question is: Does wikipedia sift through the versions to find the wikisource version, and if not when?--RaboKarbakian (talk) 13:36, 13 October 2021 (UTC)[reply]

Tech News: 2021-41[edit]

15:30, 11 October 2021 (UTC)

Technical issues with lilypond markup[edit]

See [28] and compare with the previous version. I've tried a few of the commands in the documentation, but none appear to work. I don't know if this is something caused by the new method lilypond is implemented. @ShakespeareFan00: FYI, you seem to have edited some of those recently. RandomCanadian (talk) 02:08, 12 October 2021 (UTC)[reply]

Yes, some of the markup commands no longer work in the safe implementation. The A&N Hymnal is a low priority for me at present, so I haven't taken the time to look into what's going on. By the way, we're now on version 2.22. Beeswaxcandle (talk) 03:56, 12 October 2021 (UTC)[reply]
@Beeswaxcandle: Would it be a better idea, then, to do something similar to this template I've created (adapting it for the specific formatting of the A&H hymnal, naturally)? RandomCanadian (talk) 18:02, 15 October 2021 (UTC)[reply]
No. And I would not recommend using such in the English Hymnal either. The reasons for including the text as part of the Lilypond score is that when a user grabs a copy of the score, then they will get that header text with it. If it's in a separate template, then the data will be disconnected and they will just have a score with no indication of what it is and where it came from. This is why I was gradually removing the hymn header template (or whatever it's called) out of the A&H hymnal pages. Beeswaxcandle (talk) 19:55, 15 October 2021 (UTC)[reply]
@Beeswaxcandle: I've just tested this out but the new implementation does not appear to yield much if any data. The MP3 has strictly nothing useful, the midi only has the title (see below).
Auto-generated MIDI source code

MThd � � ��€MTrk ˆ ÿ�7Behold the Bridegroom cometh in the middle of the night ÿ� creator: ÿ��GNU LilyPond 2.22.0 ÿX����� ÿQ��¢^‚Ü ÿX�� ��° ÿ/ MTrk �û ÀI ÀI ÿ��flute ÿY�� @> ;>Œ @ ; C> ;>† C ; B> ;>† B ; @> ;>† @ ; @> 9>† @ 9 @> ;>† @ ?>ƒ ; ;>ƒ ? ; @> ;>† @ ; C> ;>† C ; B> ;>† B ; @> 7>ƒ 7 9>ƒ @ 9 @> ;>† @ ; ?> ;>† ? ; @> ;>Œ @ ; † C> @>† C @ H> @>† H @ G> @>† G @ E> @>† E @ E> @>† E @ E> @>† E @ D> @>† D @ E> @>† E @ H> @>† H @ G> @>† G @ E> <>ƒ < >>ƒ E > E> @>† E @ D> @>† D @ E> @>Œ E @ † B> >>† B > G> >>† G > E> >>† E > >>† > C> <>† C < C> >>† C > B> >>† B > C> >>† C > G> >>† G > E> >>† E > C> ;>ƒ ; <>ƒ C < C> >>† C > B> >>† B > C> >>Œ C > † C> ;>† C ; >> ;>† > ; @> ;>† @ ; B> >>† B > E> >>† E > C> ;>† C ; B> ;>ƒ B @>ƒ ; @ ?> ;>† ? ; @> ;>† @ ; C> 7>† C 7 B> >>† > ;>ƒ B @>ƒ @ @>Œ ; @ ?> ;>† ? ; @> ;>Œ @ ; ÿ/ MTrk �– ÁI ÁI ÿ��flute ÿY�� ‘4>Œ ‘4 ‘4>† ‘4 ‘6> ‘2>† ‘6 ‘2 ‘7> ‘4>† ‘7 ‘4 ‘4> ‘0>† ‘4 ‘0 ‘6> ‘/>‰ ‘6 ‘/ ‘6> ‘/>ƒ ‘6 ‘/ ‘4>† ‘4 ‘4>† ‘4 ‘2> ‘/>† ‘2 ‘/ ‘4> ‘0>† ‘4 ‘0 ‘6> ‘/>† ‘6 ‘/ ‘6> ‘/>† ‘6 ‘/ ‘4>Œ ‘4 † ‘4>† ‘4 ‘9> ‘->† ‘9 ‘- ‘;> ‘,>† ‘; ‘, ‘<> ‘->† ‘< ‘- ‘9> ‘->† ‘9 ‘- ‘;> ‘4>† ‘; ‘4 ‘;> ‘4>† ‘; ‘4 ‘9> ‘->† ‘9 ‘- ‘9> ‘->† ‘9 ‘- ‘7> ‘4>† ‘7 ‘4 ‘9> ‘5>† ‘9 ‘5 ‘;> ‘4>† ‘; ‘4 ‘;> ‘4>† ‘; ‘4 ‘9> ‘->Œ ‘9 ‘- † ‘2>† ‘2 ‘7> ‘+>† ‘7 ‘+ ‘9> ‘2>† ‘9 ‘2 ‘;> ‘7>† ‘; ‘7 ‘7> ‘4>† ‘7 ‘4 ‘9> ‘2>† ‘9 ‘2 ‘9> ‘2>† ‘9 ‘2 ‘7> ‘+>† ‘7 ‘+ ‘7> ‘+>† ‘7 ‘+ ‘6> ‘2>† ‘6 ‘2 ‘7> ‘4>† ‘7 ‘4 ‘9> ‘2>† ‘9 ‘2 ‘9> ‘2>† ‘9 ‘2 ‘7> ‘+>Œ ‘7 ‘+ † ‘7> ‘4>† ‘7 ‘4 ‘6> ‘/>† ‘6 ‘/ ‘7> ‘4>† ‘7 ‘4 ‘9> ‘2>† ‘9 ‘2 ‘6> ‘2>† ‘6 ‘2 ‘7> ‘4>† ‘7 ‘4 ‘7> ‘4>† ‘7 ‘4 ‘6> ‘/>† ‘6 ‘/ ‘4>† ‘4 ‘4> ‘;>† ‘4 ‘2>ƒ ‘; ‘9>ƒ ‘2 ‘9 ‘4> ‘7>† ‘7 ‘4 ‘4>† ‘4 ‘6> ‘/>Œ ‘6 ‘/ ‘4>Œ ‘4 ÿ/

(Based on this). It's possible to have both the custom-formatted header and this (limited) information, though. RandomCanadian (talk) 21:17, 15 October 2021 (UTC)[reply]
I couldn't give a toss about the midi as I never use it. It's the score image itself that is taken and printed. If I need the score of a hymn (or any other piece), then I don't want the Wikimedia fluff around it, I just want the music. Then six months later, when I'm sorting through a pile of printed music, if I don't have at least the tune name, metre, composer and author, then it's useless. These need to be part of the Lilypond score, otherwise we're not producing a hymnal of any practical use to church musicians. Beeswaxcandle (talk) 21:37, 15 October 2021 (UTC)[reply]
Well there's multiple solutions to that problem (copy-pasting the header and the score image to Word or some other software before printing also allows you to keep the information; and this isn't much different or more complex than just saving the score image...). And having one easily useable template for all the 700-odd hymns (give or take a few, depending on whether you want to count the gregorian examples, since these can't work with Lilypond in safe mode, see for ex. Page:The English hymnal (1906).djvu/26 - not caused by a lilypond error AFAICS); is certainly quite more useful for both editors in and in terms of final output than having to deal with a disabled lilypond feature. RandomCanadian (talk) 22:00, 15 October 2021 (UTC)[reply]

Category:Authors with honorifics in title[edit]

FYI: I've created a maintenance template and category to help track Author pages where there is a honorific in the page title. Normally we'd just remove the honorific by moving the page, but sometimes that would leave us with no more than a surname, or sometimes an Author page should have a honorific in the name for whatever reason. Anyway, you can now use {{honorifics}} and Category:Authors with honorifics in title to keep track of such pages. —Beleg Tâl (talk) 18:14, 13 October 2021 (UTC)[reply]

I would be interested in any feedback, especially with regards to the functionality I built in to allow for pages where the honorific is supposed to be there (based on what I've seen billinghurst do with {{initials}}) —Beleg Tâl (talk) 19:06, 13 October 2021 (UTC)[reply]
The problem is that Beleg Tâl says that it is only a tracking template, but in fact it distributes a message about the alleged inappropriateness of the title of the page. If the title is inapropriate, it should be moved. If it is decided that the honorifics can or should be kept in the page title for some reason, then it is the message that is inappropriate. I have nothing against tracking such pages without the message, in such a case the tracking and categorizing template can be put to the bottom of the page where other categories are located and where it would be less disturbing to editors. --Jan Kameníček (talk) 19:24, 13 October 2021 (UTC)[reply]
That's no different from any of the other maintenance tracking templates we use ({{initials}}, {{incomplete}}, {{migrate to djvu}}, etc) - and it encourages editors to improve Wikisource while showing them how to do so - so I don't see how this is a bad thing? —Beleg Tâl (talk) 19:44, 13 October 2021 (UTC)[reply]
That is different. E.g. {{incomplete}} asks readers to improve an incomplete page. Similarly, {{initials}} says that the page should use the full name but we do not know it, so if any reader knows more, they can improve it. However the situation with honorifics is different. In all cases where it is possible or desirable to remove honorifics, it should be done immediately. But how can readers help us in cases when we simply decided to keep the honorifics? You have admitted that such cases may occur, so why should we inform readers about alleged inappropriateness honorifics in titles if we decided not to remove them? What do we ask the readers to do in such cases? --Jan Kameníček (talk) 20:25, 13 October 2021 (UTC)[reply]
If we decide to keep the honorifics, we can put the {{honorifics}} tag on the Author Talk page (so it does not make the page ugly, just like we do with {{initials}}), and I have added a parameter to the template to differentiate this situation (it removes the page from the maintenance category, and adds text to the template confirming that the honorific should be kept).
In fact, most of the Author pages in Category:Authors with honorifics in title should not be kept with honorifics indefinitely, but the honorifics can't be removed immediately either. For example, if we remove the honorific from Author:Miss Morrison all we will have left is Author:Morrison, which is not a usable title for an Author page. More research is needed to find out her full name so that we can remove the honorific, and in the meantime it is tracked with a maintenance template and tracking category. —Beleg Tâl (talk) 20:46, 13 October 2021 (UTC)[reply]
If something is considered OK, than it is OK. Message is needed only if we want people to encourage to do something, e. g. to do a research and correct something. Placing the template to the talk page would remove it from the direct sight but would not make it less redundant. Besides that some contributors might be unnecessarily confused where to place it. I prefer simple solutions, and not using the template in such cases seems much simpler and cleaner to me, although if it were placed at talk pages, I could live with it. --Jan Kameníček (talk) 22:07, 14 October 2021 (UTC)[reply]
@Billinghurst: I wonder if the "ignore=yes" parameter could be helpful for {{initials}} as well, in case of individuals such as Author:Harry S. Truman whose middle name is "S." (i.e. it's not short for anything), or for Author:T. S. Eliot depending on the outcome of the discussion regarding that page title, or for pseudonyms like Author:Franklin W. Dixon and other Stratemeyer personas —Beleg Tâl (talk) 13:29, 15 October 2021 (UTC)[reply]

Splitting of works into chapters[edit]

As I understand it, it's "conventional" to split book-like works into units about the size of chapters, rather than transcluding in one huge lump.

Benefits of this, to me (partly as an export nerd), include:

  • Pages are "tractable" in terms of scrolling, rather then being hundreds of screenfuls long. Especially annoying on mobile.
  • It's possible to link to chapters. A minor factor for most books, as opposed to collective works like encyclopedias.
  • It exports to formats like Epub with a table of contents which allows the reader to navigate the text more easily (admittedly this could be resolved by allowing intra-page ToC entries; phab:T270612).
  • Each chapter starts on a new page on export without needing manual page breaks.

The downside, obviously, is that it's a right old tedious pain to transclude into many pages than doing it all in one massive go.

With reference to pages like Impressions of Theophrastus Such, Essays and Leaves from a note-book/Theophrastus Such (which is also published as single book, but here published in a volume alongside other works), is that merely "convention", or something more towards "expected"? The existence of {{split}} and pages like Help:Subpages indicate one thing, but on the other hand it's never indicated what, if any, the general expectations around actually splitting of works at all are.

Courtesy @Cygnis insignis: since that's !your page and you opposed the use of {{split}} there. Inductiveloadtalk/contribs 20:36, 13 October 2021 (UTC)[reply]

I don't think there is a clear-cut line. It seems to me that there is a basic standard, in that a work which is not easily navigable when transcluded onto a single page should be broken up. Also if the work is long enough that it starts hitting template transclusion limitations. —Beleg Tâl (talk) 20:48, 13 October 2021 (UTC)[reply]
  • This work is at the edge of what needs to be split (on desktop computer); I think it should be. Another work of a similar or slightly shorter length, without natural breaks, might not need to be split. TE(æ)A,ea. (talk) 21:04, 13 October 2021 (UTC)[reply]
  • After removing the tag I said "I see no reason to split this, or any other work, merely because it could be done that way; it hardly makes it easier for the reader." The could split this text emerges from 'something to do' with copy pastes of PG texts, it has become something that must be done, to the most discrete fragment of text in any circumstance (breaking a lot of links in works that I chose not to split). Navigating is more annoying than scrolling for me, especially when using multiple windows to search, skim, or read texts. Linking chapter, section and verse is possible with the page numbers in their larger context. Is having the software recognise book's inherent convention such a trick, I don't imagine the largely unsplit works at PG have a problem with exporting content that doesn't suit readers and their readers. Cygnis insignis (talk) 21:32, 13 October 2021 (UTC)[reply]
    You haven't put in any ToC or page breaks though, so it's functionally an amorphous lump of 58,000 words.
    PG do their exports manually, as far as I know, after the work is "locked": they ensure the work has a navigable TOC at that stage. We have no such luxury because we keep the works open for editing forever (that's, like, our whole "thing"), so the exports have to be automatically generated "live" every time.
    I do not recommend "splitting to the most discrete fragment"; in fact I have recently advised against splitting a legal work into 400+ sections. However, chapters do seem a natural split level (I normally do not split finer than that, even if the chapter has "subparts"), and failing that you should at least make sure your exports are navigable. Even if phab:T270612 were done today, you would require a ToC which links to some kind of anchors (even if just page numbers) and probably some page-break mechanism (which could be with {{tl|classed header]} and break-before:always is index CSS, or with {{page break}} of some sort). Inductiveloadtalk/contribs 21:55, 13 October 2021 (UTC)[reply]



Barging in, I was going to ask for help in this same question area. I'm interested in suggestions/opinions for another work I'm helping with, which *cannot* be easily split into simple 'chapters' as it rather has an academic outline form that does *not* have nice regular like-sized divisions. Please see notes and summary at Looking ahead at subdividing text for publishing to main space.

The work does need to be split since it is 325+ pages, but has an idiosyncratic organization at best. One division has 2/3 of the whole work! Ultimately divided into small 'paragraphs' (sections) (e.g. § 204 we need to be able to link from paragraph references to main space. But to do that we need a somewhat regular system of dividing into named subparts. No nice hierarchy suggests itself.

How to divide into named main space subdivisions, when *not* amenable to 'chapter' divisions? And I note above and agree with the "most discrete fragment" comment above. Such would completely distress the work. Some intermediate rule is needed. Shenme (talk) 22:01, 13 October 2021 (UTC)[reply]

This is a debate between the lumpers and splitters and I think that both sides have valid arguments. Texts on a single-page are easier to read through in one session, while a text in separate chapters is easier for longer reads, when exported, and on mobile. Generally, I prefer split texts. frWS usually has presents both options: a split text and a single-page text. I was wondering if it would be possible to modify the auxtoc and TOC templates to allow for a single-page option. In this way, even if a text is split, a users would have the option to view the text on a single page. By default this single-page option would transclude the entire index, but there would be an override parameter to set the page range manual.

Something like this Chapter 1
Chapter 2
....
Chapter N

View on Single Page


Languageseeker (talk) 01:01, 14 October 2021 (UTC)[reply]
yeah, i would support a reader option of lump or split. we do not know if readers are desktop or phone with limited connectivity / memory issues. a flexible response would be nice.--Slowking4Farmbrough's revenge 19:34, 14 October 2021 (UTC)[reply]
Well I've wandered around and seen 'chapters' of over 100 pages in peeking at even a few works from the "New Texts" page. So my 325 pages split into only ~7 parts sounds fine, except that two of the parts are 97 and 85 pages long. It would be nice to know what the comfortable limits are for mobile devices, as a guide here at WS. Shenme (talk) 19:13, 15 October 2021 (UTC)[reply]

Older IP address[edit]

I was using an older IP address is 72.183.34.65 Time Warner Cable. When I search google and click information Wikipedia and I didn't know how should I test the sandbox. In February 2020, after 13 years, it was internet outages and it was replaced new IP Address Spectrum. No one exciting edit Wikipedia 72.176.0.0/13. Now it is replaced New IP address 47.234.128.0/17. Everyone is excited to research edit Wikipedia.

Thanks 47.234.198.142 01:02, 14 October 2021 (UTC)[reply]

This is not Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:58, 15 October 2021 (UTC)[reply]

Voting for the MCDC Election[edit]

Voting for the election of the members for the Movement Charter drafting committee is now open. In total, 70 Wikimedians from around the world are running for 7 seats in this election.

Voting is open from October 12 to October 24, 2021.

The Movement Charter committee will consist of 15 members in total: The online communities will vote for 7 members, 6 members will be selected by the Wikimedia affiliates through a parallel process, and 2 members will be appointed by the Wikimedia Foundation. The plan is to assemble the committee by November 1, 2021.

You can learn more about each candidate to inform your vote here

You can also learn more about the Drafting Committee here

We are piloting a voting advice application for this election. Click through the tool and you will see which candidate is closest to you! To try out this tool, visit: App

Go vote at SecurePoll: Vote

Read the full announcement: here

Best, --Civvi (WMF) (talk) 15:13, 14 October 2021 (UTC)[reply]

Author:T. S. Eliot‎ vs Author:Thomas Stearns Eliot[edit]

I was doing some routine maintenance stuff yesterday, and I cleaned up a bunch of authors with initials in their page titles. I noticed, however, that despite our practice of moving Author pages with initials wherever possible, nevertheless Author:T. S. Eliot‎ remains as the only prominent holdout. Is there community consensus to keep Author:T. S. Eliot‎ at its current location with its initials, or should we redirect it to Author:Thomas Stearns Eliot like we do with everyone else? —Beleg Tâl (talk) 14:47, 14 October 2021 (UTC)[reply]

@Billinghurst, @Cygnis insignis: pinging interested parties —Beleg Tâl (talk) 14:49, 14 October 2021 (UTC)[reply]
There is no exception to the guidance. Just an individual's commentary that there is no consensus for such a move and we that are to follow the author's preference for that form. I have the conversation over and over with the individual, and asked them to bring that conversation here, and that has not happened. I thank you for raising the issue. I believe that the standard/guidance should stand. — billinghurst sDrewth 06:11, 15 October 2021 (UTC)[reply]
  • @Beleg Tâl: why did you redirect Shakespeare to Bill Shaxberd? Cygnis insignis (talk) 12:41, 15 October 2021 (UTC)[reply]
    • Updating links after a page move, that's all. If you think that it should point somewhere else, like Author:William Shakespeare, or even a separate disambig page for anyone surnamed Shakepseare ... well I personally don't think that surname-disambig is something we should do, but I won't object to it either. I don't think the name "Shakespeare" by itself can really be expected to refer to any Shakespeare but the one it currently redirects to, but I would not be unhappy to be proven to be mistaken. —Beleg Tâl (talk) 13:04, 15 October 2021 (UTC)[reply]
@Beleg Tâl: There is no such consensus that I am aware of, and I am frankly surprised the point needs to be argued. Do we really need to hold a vote and make it a policy? Don't get me wrong, I like having stuff like this enshrined clearly in policy, but it seems quite a waste of the community's time on this particular point. Whether you like the "full name" page naming scheme or not, it is the long-standing and essentially universal practice on the project and I see no reasonable argument why Eliot should be an exception. Xover (talk) 17:18, 15 October 2021 (UTC)[reply]

Localisation request: File:A Catalogue of the Birmingham Collection - 1918.pdf[edit]

Request because of a lack of clarity concerning the applicability of the PD-UK-anon license at Commons, As a 1918 work it is PD-US and so could be hosted locally, irrespective of any UK status. ShakespeareFan00 (talk) 17:03, 15 October 2021 (UTC)[reply]