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

Table formatting[edit]

The table under "Distances" at Showell's Dictionary of Birmingham/D, which spans three pages in the source, is malformed. What's wrong? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 3 May 2021 (UTC)

It appears to render correctly on my browser, does it not on yours? Where is the 'malformation' appearing? I am unfamiliar with the coding style, but I may be able to fix it (or rewrite it). CYGNIS INSIGNIS 22:24, 3 May 2021 (UTC)
Actually, not correctly, but readable. I notice that something is suppressing the page numbers at those pages, can't remember what some of the causes for that are other than too clever formatting. CYGNIS INSIGNIS 22:32, 3 May 2021 (UTC)
@Pigsonthewing: the main issue was that you were closing the table on the first page: diff, which was coming through into the main NS. The right way is to close the table in the footer like this:
Also, in theory, you should use a {{nopt}} at the head of the subsequent pages to avoid accidentally running rows together if the line break on the previous page is removed by accident.
I'm not actually sure why a paragraph is introduced in the page NS under the header. @Billinghurst: any ideas? Also there appear to be no page numbers at all for the third page onwards. Which is also bizarre, because AFAIK the issue I would expect that to be (Phab:T232477) should not apply if |- is at the top of the page, and the numbers don't even appear with JS off, and they're not fostered, they're just not there at all. Inductiveloadtalk/contribs 22:38, 3 May 2021 (UTC)
  • This is a general table problem; it happens when the table has header content that isn’t included (over a page break). It also happens here. TE(æ)A,ea. (talk) 23:04, 3 May 2021 (UTC)

@Inductiveload: the page numbering is screwed due to the addition of a table row marker at the end of the body sections—fixed those. I don't know why this continues as a community behaviour, I have long harped-on of this problem and have long-changed the help pages from the mistaken guidance. I know of its origins and some use of it as a practice that is tied in with the table row issues and our subsequent nop/nopt introduction, but it was always a bodgy solution. — billinghurst sDrewth 02:14, 4 May 2021 (UTC)

Ah yes, now I see, I had missed the extra |- at the ends of the pages. Clearly I was up too late last night!
Also, with sleep and caffeine in me in the right order, I now remember that the extra space under the header in page namespace is phab:T275388 and there's not a lot we can do about that as it stands (though the ugliness is contained to the Page NS, so it's not too bad). In theory, some kind of namespace awareness could help, but then we'd have two kinds of {{nopt}} and things will get complicated to explain. Inductiveloadtalk/contribs 08:29, 4 May 2021 (UTC)

end of a page in Page: ns[edit]

@Pigsonthewing: Apologies of for the length, but it needs to be first principles.

ProofreadPage (PrP) is a set of javascripts that makes a mediawiki page appear to be three separate sections. At the end of a body section you basically have the text end and a "noinclude" that determines where the footer section starts and ends. In the following examples, the highlighting represents Page: ns presentation, the unhighlighted is what the wikitext looks like

standard empty footer
mere bulky tomes,
[footer start]
[footer end]
mere bulky tomes,<noinclude></noinclude>

So where we have table splits we need to trick Mediawiki into continuing a table it is utilising Mediawiki's noinclude terminology as it is embedded and interpreted by ProofreadPage

N table end on the first line of the footer[page 1]
[footer start]
[footer end]
Question? use of placeholder {{nopt}}[page 2], a hard return, table close[page 3]
[footer start]
[footer end]
YesY without placeholder,[page 3] so hard return at first footer line, then table close on subsequent line
[footer start]

[footer end]

Pictogram voting comment.svg Comment Other coding direction in tables

  • a column row starter (|-) please do not terminate the body section with these, it can lead to aberrant behaviour, especially can foul up marginal page numbering on tranclusion
  • use of {{nop}} at the start of a new body section should be avoided[page 4]
  • we suggest to use {{nopt}} at the head of the subsequent body section to give mediawiki the sense of a new line for table row markers[page 2]
  1. doesn't work as the table close (|}) needs to be on a new line for wikitext
  2. 2.0 2.1 Template:nopt is an empty <span> when transcluded
  3. 3.0 3.1 use of the placeholder is actually redundant and only serves as a visual cue.
  4. Template:nop is an empty <div> when transcluded
This section was archived on a request by: — billinghurst sDrewth 00:53, 9 May 2021 (UTC)

@TE(æ)A,ea.: I am not sure to what you are referring. The header is just another <noinclude> section that is not transcluded. If you foul up formatting in that header section it will bleed through the page in Page:ns, but not come through with a transclusion. If you code in a that works in the Page: ns around with specific code inside the header, then it may foul up when you transclude. If you have complex and repeating table headers in Page: ns, then I always suggest that they become standard templates as that just makes your life easier. Well, that is how I have handled it in the past.

And this is why I don't do help pages. Too complex, nitpicking that takes me forever. — billinghurst sDrewth 01:49, 4 May 2021 (UTC)

I have previously setup {{Hussey Churches table header}} for a work, though would not be adverse to us thinking about a specific ability to have something work-specific like transcluding pseudo-templates that could be subpages of something like Index:Notes on the churches in the counties of Kent, Sussex, and Surrey.djvu. Now that we have .css style pages that are subsidiary to an Index: it is not a long straw to draw to think about how we have other work specific components in the Index: namespace subsidairy to the index. I know that I have had light level discussions about work level header templates and their preloading conversations. Thoughts @Inductiveload, @Xover, @Samwilson:? Do we push everything to Template: namepsace, what are the pros and cons of utilising work specific components? It adds complexity though it separates work specific aspects. — billinghurst sDrewth 02:31, 4 May 2021 (UTC)

[outdent] Thanks all; I don't follow all of the above, but the table is now working. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:53, 4 May 2021 (UTC)

tl;dr for the record:
  • Do not put |- at the end of a page
  • Do put this at the start of a continued table page
  • If a table continues onto the next page, close it on this page in the footer with
  • You might get an unexpected gap between the header and first row in the Page NS: this is mildly annoying, but doesn't bleed into mainspace.
  • tl;dr;tl;dr it's all a PITA.
Inductiveloadtalk/contribs 10:19, 4 May 2021 (UTC)
Help:Table hopefully contains all that information. — billinghurst sDrewth 10:42, 4 May 2021 (UTC)
This section was archived on a request by: — billinghurst sDrewth 12:42, 10 May 2021 (UTC)

Allow global sysops to work on this wiki[edit]

Hi, I propose allowing global sysops to work on this wiki. It is currently not enabled because the community has more than 10 admins/3 active sysops, but I strongly recommend that the community opt-in because they often help in combating spam and vandalism (eg GRP). As an en.wikibooks admin, I can attest to the work they do and have no issues with them at all. Thanks in advance, and please ping me if you need further input, since I don't watch this page.
P.S: Global sysops won't interfere with normal Wikisource matters (for instance they do not have access to Special:UserRights) - their role is codified in the policy page and is more or less handling spam or vandalism. This wiki can enact a global rights policy if needed (couldn't find one here). They'll only help you. Leaderboard (talk) 08:54, 4 May 2021 (UTC)

I don't think that it is necessary at this time. We have a good time spread for our 25 admins and patrollers, and more admins than there are global sysops. — billinghurst sDrewth 10:51, 4 May 2021 (UTC)
For reference, list of global sysops and Special:GlobalGroupPermissions and their rights are quite broad, many of which we would not expect to be used here. — billinghurst sDrewth 10:55, 4 May 2021 (UTC)
Hi @Billinghurst:, that's true, however, I don't see how it would be a problem to allow a small group of highly trusted users to remove spam or vandalism. I've seen even bigger wikis benefit from having global sysops. Leaderboard (talk) 11:39, 4 May 2021 (UTC)
Always present a full picture of the situation, not one favourable to your argument. How else can the community make an informed risk-based decision? — billinghurst sDrewth 11:44, 4 May 2021 (UTC)
And for openness, I am a global sysop (among other rights I hold here, at other wikis, and globally (m:user:billinghurst/m:User:Billinghurst/matrix). — billinghurst sDrewth 11:49, 4 May 2021 (UTC)
@Billinghurst: I'm not sure what the risks are, as you say. In theory it could mean global sysops doing things they shouldn't (in which case just file a request at Meta, you know that GS have been removed that way), or some things being sensitive that you don't want global sysops touching at any cost (in which case simply have your wiki enact a global rights policy, as I linked before).
This, to me, is a proposal that has only benefits and no drawbacks (otherwise I would have mentioned them). If there are indeed risks that I'm not aware, do let me know and I'll try to address them. Leaderboard (talk) 18:24, 4 May 2021 (UTC)
Please don't come and tell me that the way to manage our risks is to open up our wiki to more administrators, and then complain about them to get them removed. That is a horrid argument. Nor tell us that we would need to create a document to limit the scope of their activity. Does that picture look wrong to you? We weigh the upsides and the downsides.

Of course there are risks in giving broader permissions to people, we would essentially creating new interface administrators on site, given rights that the community has limited so far, though the community may find benefit there, or could be horrified. We would also have those users have their edits marked as autopatrolled, and we manage that right based on competence of editors at our site. Pointing to the rights that would be inherited is simple awareness, talking about the ups and downs should be part of a deeper conversation, this is not a flutter of pixie dust. — billinghurst sDrewth 02:27, 5 May 2021 (UTC)

@Billinghurst: Two things:
  • just because they have interface-admin does not mean that they will use it - in practice they will not use it in a wiki as large as Wikisource.
  • "We would also have those users have their edits marked as autopatrolled" - that's the case for global rollback as well
  • What is the problem with, as you say, "create a document to limit the scope of their activity"? It's good practice to have one even if you don't allow GS, as enwiki has done.
And for the record, I did link to the Meta page when I made this proposal, which (if I'm not wrong) clearly gives the rights available to the group. And yes, I'm confused with your arguments - as I said earlier, just because they have admin-level powers does not mean that they're going to invade and take the role of local admins like you. I only meant good faith when I said that there is practically no downside to allowing GS to work here.
If there are downsides you have (like the interface-admin part), tell them so that I can address it. I'm not going to ask the stewards to enact this change without sufficient consensus and discussion, and will not do anything if there isn't any. Worst-case, it'll stay as status quo (that is, no GS allowed here). Leaderboard (talk) 07:38, 5 May 2021 (UTC)
Umm, I just pointed the community to the facts, and some light interpretation, I neither said it was right nor wrong. That is called aiding a discussion to have full information without every person needing to dig it out. — billinghurst sDrewth 16:44, 5 May 2021 (UTC)
rights of admin / interface admin / GS
Administrators Interface administrators Global sysops
  • Block a user from sending email (blockemail)
  • Block other users from editing (block)
  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
  • Change page language (pagelang)
  • Change protection levels and edit cascade-protected pages (protect)
  • Create and (de)activate tags (managechangetags)
  • Create new user accounts (createaccount)
  • Create or modify abuse filters (abusefilter-modify)
  • Create or modify global abuse filters (abusefilter-modify-global)
  • Delete tags from the database (deletechangetags)
  • Delete and undelete specific log entries (deletelogentry)
  • Delete and undelete specific revisions of pages (deleterevision)
  • Delete pages (delete)
  • Disable global blocks locally (globalblock-whitelist)
  • Edit other users' JSON files (edituserjson)
  • Edit pages protected as "Allow only administrators" (editprotected)
  • Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)
  • Edit sitewide JSON (editsitejson)
  • Edit the content model of a page (editcontentmodel)
  • Edit the user interface (editinterface)
  • Enable two-factor authentication (oathauth-enable)
  • Forcibly create a local account for a global account (centralauth-createlocal)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Import pages from other wikis (import)
  • Mark others' edits as patrolled (patrol)
  • Mark rolled-back edits as bot edits (markbotedits)
  • Mass delete pages (nuke)
  • Merge the history of pages (mergehistory)
  • Modify abuse filters with restricted actions (abusefilter-modify-restricted)
  • Move category pages (move-categorypages)
  • Move files (movefile)
  • Move pages (move)
  • Move pages with their subpages (move-subpages)
  • Move root user pages (move-rootuserpages)
  • Not be affected by IP-based rate limits (autoconfirmed)
  • Not be affected by rate limits (noratelimit)
  • Not create redirects from source pages when moving pages (suppressredirect)
  • Override files on the shared media repository locally (reupload-shared)
  • Override the spoofing checks (override-antispoof)
  • Override the title or username blacklist (tboverride)
  • Overwrite existing files (reupload)
  • Overwrite existing files uploaded by oneself (reupload-own)
  • Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
  • Reset failed or transcoded videos so they are inserted into the job queue again (transcode-reset)
  • Revert all changes by a given abuse filter (abusefilter-revert)
  • Search deleted pages (browsearchive)
  • Send a message to multiple users at once (massmessage)
  • Undelete a page (undelete)
  • Upload files (upload)
  • Use higher limits in API queries (apihighlimits)
  • View information about the current transcode activity (transcode-status)
  • View a list of unwatched pages (unwatchedpages)
  • View abuse filters marked as private (abusefilter-view-private)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
  • View detailed abuse log entries (abusefilter-log-detail)
  • View log entries of abuse filters marked as private (abusefilter-log-private)
  • View title blacklist log (titleblacklistlog)
  • Add groups: Autopatrollers, MassMessage senders, Patrollers and IP block exemptions
  • Remove groups: Autopatrollers, MassMessage senders, Patrollers and IP block exemptions
  • Add groups to own account: Flood flag and Translation administrators
  • Remove groups from own account: Flood flag and Translation administrators
  • Edit other users' CSS files (editusercss)
  • Edit other users' JSON files (edituserjson)
  • Edit other users' JavaScript files (edituserjs)
  • Edit sitewide CSS (editsitecss)
  • Edit sitewide JSON (editsitejson)
  • Edit sitewide JavaScript (editsitejs)
  • Edit the user interface (editinterface)
  • Enable two-factor authentication (oathauth-enable)
  • View detailed abuse log entries (abusefilter-log-detail)
  • Create or modify abuse filters (abusefilter-modify)
  • Use higher limits in API queries (apihighlimits)
  • Not be affected by IP-based rate limits (autoconfirmed)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Auto-review on rollback (autoreviewrestore)
  • Block other users from editing (block)
  • Block a user from sending email (blockemail)
  • Search deleted pages (browsearchive)
  • Delete pages (delete)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
  • Delete and undelete specific log entries (deletelogentry)
  • Delete and undelete specific revisions of pages (deleterevision)
  • Edit the content model of a page (editcontentmodel)
  • Edit the user interface (editinterface)
  • Edit pages protected as "Allow only administrators" (editprotected)
  • Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)
  • Edit sitewide CSS (editsitecss)
  • Edit sitewide JavaScript (editsitejs)
  • Edit sitewide JSON (editsitejson)
  • Edit other users' CSS files (editusercss)
  • Edit other users' JavaScript files (edituserjs)
  • Edit other users' JSON files (edituserjson)
  • Delete Structured Discussions topics and posts (flow-delete)
  • Edit Structured Discussions posts by other users (flow-edit-post)
  • Hide Structured Discussions topics and posts (flow-hide)
  • Import pages from other wikis (import)
  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
  • Mark rolled-back edits as bot edits (markbotedits)
  • Merge the history of pages (mergehistory)
  • Move pages (move)
  • Move category pages (move-categorypages)
  • Move root user pages (move-rootuserpages)
  • Move pages with their subpages (move-subpages)
  • Move files (movefile)
  • Move pages with stable versions (movestable)
  • Not be affected by rate limits (noratelimit)
  • Mass delete pages (nuke)
  • Enable two-factor authentication (oathauth-enable)
  • Override the spoofing checks (override-antispoof)
  • Mark others' edits as patrolled (patrol)
  • Change protection levels and edit cascade-protected pages (protect)
  • Overwrite existing files (reupload)
  • Overwrite existing files uploaded by oneself (reupload-own)
  • Override files on the shared media repository locally (reupload-shared)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
  • Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)
  • View the spam blacklist log (spamblacklistlog)
  • Not create redirects from source pages when moving pages (suppressredirect)
  • Override the title or username blacklist (tboverride)
  • Edit protected templates (templateeditor)
  • View title blacklist log (titleblacklistlog)
  • Undelete a page (undelete)
  • View a list of unwatched pages (unwatchedpages)
  • Upload files (upload)
  • Oppose: I don’t think vandalism is enough of a problem here to justify adding in more administrators. If emergency access is needed, it can be requested. TE(æ)A,ea. (talk) 17:44, 4 May 2021 (UTC)
    I'm not sure what you mean by that? Stewards do have the ability to perform admin-level actions, but they will do so very rarely in practice. Leaderboard (talk) 18:17, 4 May 2021 (UTC)
(e/c) I also don't think it necessary at present. Our RC patrolling processes are working well and it's rare that vandalism and spam escapes our notice. I wonder what the motivation for this suggestion is. Beeswaxcandle (talk) 17:46, 4 May 2021 (UTC)
@Beeswaxcandle: A combination of
  • my experience having global sysops work in both wikis where I'm a sysop - they have been very helpful and I have no issues with them
  • seeing cross-wiki vandalism (eg GRP) and the inability for GS to act in these situations
  • "larger wikis" (those with >=15 admins), like this, benefiting from GS in practice (the most recent being English Wikivoyage with 48 sysops that I successfully convinced to opt-in just about a week back, and the effects are already there)
  • some GS hence asking for local adminship solely to handle vandalism (not sure if there are any such users here; I've seen them elsewhere)
Personally, I felt Wikisource could benefit from allowing GS and stewards to perform routine spam/vandalism removal, and hence presented this proposal Leaderboard (talk) 18:20, 4 May 2021 (UTC)
This somewhat evangelistic approach is all very well, but what is the quid pro quo for you appearing here and attempting to persuade us? Also, please give an example (or two) of something that has happened here at enWS that would have benefited from the GS being involved. (And, what is GRP? enWP offers Glass Reinforced Plastic or Gross Rating Point, neither of which make sense in the context. Throwing obscure abbreviations around is unhelpful.) Beeswaxcandle (talk) 17:42, 5 May 2021 (UTC)
@Beeswaxcandle: I apologise if "GRP" was not clear to you; they are a serial long-term LTA (wikipedia:Wikipedia:LTA/GRP) that has affected various projects already (including Wikisource from what I understand, apparently others disagree). I mentioned them because they attack cross-wiki and are something which global sysops can help a lot. I've seen cases of the other type; my user contribution would be examples. I don't know what "quid pro quo" means. For what's worth, I'm not doing this only to Wikisource; there are other wikis of this nature that can benefit from having GS around as well. Again, if this community does not like GS, this proposal will not pass and it'll remain status quo. Leaderboard (talk) 19:21, 5 May 2021 (UTC)
@Leaderboard: you now have my attention. Would you like some candid views on LTAs and wikisource? CYGNIS INSIGNIS 21:29, 5 May 2021 (UTC)
@Cygnis insignis: I am not sure if I should answer anything else to that question other than "ok". Leaderboard (talk) 07:19, 6 May 2021 (UTC)
@Leaderboard: [fixing pings doesn't work [1], I imagine there is a good reason for that.] Pardon, I was considering my reply. This is a nice place (and the best sister-site, imo) and I don't want to make noise (This is a library :). I see that en.wikipedia has more centralised and open discussion on some I the concerns I would air. Could I discuss that elsewhere, where there may be others with similar concerns or answers to allay my own? CYGNIS INSIGNIS 17:37, 7 May 2021 (UTC)
@Cygnis insignis: I do not know why you're adding en.wikipedia to the mix, but if there's anything that you want to say that should not be said in this thread, you may post in my talk page. Leaderboard (talk) 07:28, 8 May 2021 (UTC)
Symbol neutral vote.svg Neutral I am neither for not against the proposal. I don't mistrust the GS group and I'm not about to get jealous over a missed chance to block a sock myself. But there's not a whole lot of vandalism here that would benefit, unless I misunderstand something. Generally most vandals are one-hit wonders and wander off almost immediately in search of better sport, or if not, they hop IPs and don't edit more than a few times from a single IP, so having a GS on hand to step in a few minutes faster won't change much? Inductiveloadtalk/contribs 18:31, 4 May 2021 (UTC)
@Inductiveload: Maybe Wikisource is different, but here at Wikibooks, we've got cases where the LTA would continuously abuse/revert edits, at which point a GS (or a local admin) would be needed to stop it. Yes, IP hopping is a thing, but GS can still make the life of the LTA considerably harder. For reference, I've been at the receiving end myself in other non-GS wikis. And even if that isn't the case, as you inferred, global sysops are highly trusted and there is frankly no drawback to allowing them (and by extension, stewards) to act when it would help the wiki. Leaderboard (talk) 18:35, 4 May 2021 (UTC)
  • Oppose: Sounds like a solution in search of a problem.--Prosfilaes (talk) 16:34, 5 May 2021 (UTC)
  • Oppose. And, frankly, for a user with a grand total of two non-revert edits outside of this thread to make this proposal raises serious concerns about their motivation. --Xover (talk) 06:34, 8 May 2021 (UTC)
    @Xover: That is not surprising, because I don't contribute to Wikisource (and hence asked for a ping). But for what's worth, I stand to gain nothing from this proposal directly, because I am not a global sysop or global rollback. I have been filing similar proposals in other non-GS wikis that I think can benefit as well. Leaderboard (talk) 07:27, 8 May 2021 (UTC)
    You don't contribute to the project and yet you feel it appropriate to make policy proposals here, and appear quite confident you know what the project needs and what its challenges are without having participated in it. That you are making such unsolicited proposals to other projects to which you do not contribute does not particularly suggest good judgement either. Xover (talk) 07:47, 8 May 2021 (UTC)
    @Xover: I am not sure why you think I'm making a mistake by doing this. The reason I'm making such proposals is literally because I believe that this is something that every project can benefit from. And some may approve (like en.wikivoyage and en.wikiquote), some may not (like this wiki). It is not good assumption to say that I'm not making good judgement by making such proposals - by your line of thoughs, stewards shouldn't exist, because they don't contribute to the projects they have power on, do they?
    I am not making this proposal blinded either. I do have some understanding of the challenges cross-wiki patrollers face, as someone who has assisted other wikis in handling LTAs (long-term abusers), and hence have seen the difficulty of global sysops and stewards (even though I'm neither) when they try to handle LTAs that hop across wikis. The latter can apply global locks/blocks, the former cannot. Similarly, cross-wiki doxxing is a thing, and GS cannot help if wikis like these stay opted-out.
    Let me make this clear - even though I made this proposal in good faith, the decision rests with the community, and if the community does not approve it, the proposal will not pass. Simple as that. I have no authority to override consensus. In 3 days' time, unless I see a significant rise in support, I'll consider this as a failed proposal. Leaderboard (talk) 12:36, 8 May 2021 (UTC)
    Because you're not a global sysop, but are presuming to speak for them and making assertions about what they need, and because you're not a member of the Wikisource community but you presume to tell us what we need. If the community here needs help from the global sysops then we will ask them for it, and if the global sysops need our help they will ask us for it. And you appear to be equally confused about the role of the Stewards. Xover (talk) 13:36, 8 May 2021 (UTC)
    @Xover: As stated, while I am not a global sysop (or a global rollbacker), I interact regularly with them and am familiar with how they work. And as I've repeatedly said, I brought a proposal in good faith but you're assuming bad faith for reasons that are still unclear to me, just because I don't contribute to Wikisource. Even if I was a GS, I don't know what difference it would have made.
    Regarding your statement: "If the community here needs help from the global sysops then we will ask them for it" - from my experience, many communities are simply unaware (or have forgotten) about global sysops, especially because the original opt-out lists were defined in 2010 and many of those users do not go to Meta or fight vandalism crosswiki.
    Similarly, I have no clue on why you say I'm confused about the role of Stewards. Contrary to what some people think, stewards don't locally block users unless it's an emergency - they resort to global blocking partially due to communities such as these. I say this because a couple of admins in a different wiki thought that stewards can do it, which isn't quite right.
    Nevertheless, I will respect the decision of the community and hence request this proposal to be marked, by any suitably trusted user, as X mark.svg Not done. Leaderboard (talk) 08:17, 12 May 2021 (UTC)
This section was archived on a request by: no community wish to progress suggestions — billinghurst sDrewth 09:49, 12 May 2021 (UTC)

Update Inclusion Guidelines to prohibit future non-scanned backed works[edit]

The following discussion is closed:
Proposal did not have support of broader community. — billinghurst sDrewth 08:21, 28 May 2021 (UTC)

I’m proposing to update the inclusion guidelines to exclude all works that are not transcluded. The veracity and accuracy of non-scanned back texts cannot be verified without significant effort while scan-backed works can. Currently, there are efforts to replace non-scan backed versions with scan-backed versions to improve the overall quality of this site, but this is continually made more difficult by the addition on non-scan backed works. If this proposal passes, all new, non-scan backed works will be deemed out-of-scope and speedily moved to the user's namespace. For works that are born digital, a Wikisource edition will require the creation of a PDF or other suitable digital reproduction. Languageseeker (talk) 19:44, 7 May 2021 (UTC)

So, you are proposing that we delete ca. 208,277 pages of content (i.e. 41% of our content). This includes works that are digitally native and therefore do not have printed texts to be scanned. Your proposal would do away with the match&split process and make it unavailable for the purpose you recently used it for in bringing in PG texts. Your proposal precludes the possibility of bringing in works for which there are no scans available. Beeswaxcandle (talk) 23:09, 7 May 2021 (UTC)
Question Question Are you proposing deleting all current non-scan-backed works, or are you proposing a ban-hammer on future non-scan-backed works? Either way, I’m opposed, but it’d be good to at least have that clarification. — Dcsohl (talk) 00:30, 8 May 2021 (UTC)
I am not proposing to delete past content, but to place a moratorium on future. For works born digital, a pdf can be created to preserve the content. If the goal of this site is to create accurate copies of textual sources, then there must be an original to compare it to. Otherwise, there is absolutely no way to guarantee accuracy. Placing a moratorium will allow for a slow, transition process to begin. If there is some overriding compelling reason why a particular work cannot be scan-backed, then that can be treated as an exception.
Match-and-split is a problematic and difficult process. Why it can be used to salvage past works, there is no reason to create additional work for the future.
@Dcsohl: Is there any particular reason why you are opposed? Languageseeker (talk) 03:41, 8 May 2021 (UTC)
Your description doesn't match "not proposing to delete past content". You also need to provide an explanation of how this will be policed. How will the exception process work? In terms of the "born digital", what's to stop me uploading a text then creating a pdf of the same content I just uploaded, and voila it matches? There's still no verification of the source or its public domain status. How are we better off? I recommend you withdraw this version of the proposal and rewrite it. A single paragraph of why does not explain the how. Beeswaxcandle (talk) 07:37, 8 May 2021 (UTC)
"all non-scan backed works will be deemed out-of-scope and speedily deleted." is that meant to mean all new non-scanned works or all new and current works? Maybe you forgot to include new in there? MarkLSteadman (talk) 22:02, 8 May 2021 (UTC)
I just think there are other valid sources for works besides scan-backed, the most notable of which would be PG. Are we going to forbid the import of all PG works henceforth? It should definitely be harder to bring in non-scan-backed works, but I’m simply not in favor of making it impossible. — Dcsohl (talk) 02:07, 9 May 2021 (UTC)
I would forbid the import of all PG works henceforth. They're well archived; WP can durably link to them. There's no value in copying them here.--Prosfilaes (talk) 15:03, 9 May 2021 (UTC)
Symbol support vote.svg Support, non-scan-backed works are bad for the following reasons:
  • It's hard to determine what the source of our transcription is, if no source is given.
  • It's hard to determine version information: is it the original, is it from a more modern reprint, a revised edition? In the cases of smaller works that are usually published in collections such as songs or poems, which collection was this particular version published in? Another common question: what version contained this introduction by Bob Bobberson, and is that version still under copyright? This information can unfortunately remain unknown without a scan.
  • It's hard to determine copyright status of the work, or our particular version of the work, when necessary.
  • It's harder if not impossible to verify for accuracy. Gutenberg texts have no guarantee of validity (and are sometimes wrong), they often arbitrarily correct typos or perceived typos (which is against Wikisource policy), and are by no means comparable to a scan of an original printed work.
  • It's easy to give an incorrect source link by mistake (see Talk:Winesburg, Ohio as an example), especially if you copy-paste large amounts of text from other sites within a short time span.
Quality over quantity. Editors and readers of our content alike need something original to compare our text to on the fly. Furthermore it is very obvious that modern Wikisource pages with scan backing are of far better quality than those from the past, or the present, that are copy-pasted from other sources with no scan. We have too large a backlog of pages from the 2000s or early 2010s, that were inserted with no scans to back them, simply because the technology wasn't there yet for it or that technology was in its infancy. We certainly don't need any more! PseudoSkull (talk) 04:35, 8 May 2021 (UTC)
  • Multiple many times oh-so-much opposed to this proposal. Requiring scan-backing for new texts is in itself a no-brainer; the hard part is defining what to do with existing non-scan-backed texts, and how to deal with born-digital texts and other new texts for which, for whatever exceptional reason, it is not sensible to require scans. These are the things a modified policy needs to address, and this proposal doesn't even attempt to do so.
    In particular, a dumb requirement for scans without addressing the details will just lead to a proliferation of arbitrary self-created PDFs that correspond to no published edition, hiding the problem in a "scan" instead of making it obvious. Does a Gutenberg text get any less problematic because someone printed it to a PDF file before cut&pasting the text here? Xover (talk) 06:10, 8 May 2021 (UTC)
  • no I have no issues with encourage, strongly encourage for old works, but as a requirement NO. There are some things that are not available as a scan, or not available as a scan of suitable quality. Also modern works are electronic and do not require scans, and do not require proofreading, and making a scan to the transclude to allow the text is straight daft. — billinghurst sDrewth 09:00, 8 May 2021 (UTC)
  • This type moratorium on future is very good conception in my opinion and it will bring much benefits and will raise value of project. More about it I wrote on this too long thread. Could we delete old pages? Absolutely no. We can't to delete anyone's work. I propose to place main emphasis on texts with scans and change old non-scanned texts to new texts with scans. In my experience on one much smaller project I know how many mistakes are on non-scanned texts. Mistakes by procedure copy-paste, disorted words and whole sentences, disastrous punctuation. We can't also prohibit to create version without scans especially if scans are not available on this moment. On my opinion data based on non-scanned texts are worth as much as texts and articles with no source. In my experience I know that the more are texts with scans, the more users (even newbies) add texts with scans, and non-scaned texts appear less often. And, at last, small digression, @Billinghurst:, I'm hearing your experiences and I assure you I appreciate it very much. I think that we need to oblige users to updating Wikidata preferably right after overwriting old non-scanned texts, if a adequate items are existing on Wikidata. Maybe it is impossible and I'm just idealistic dreamer. I think, if a scan exist or appear we should will place the most emphasis on change old and unbelievable text with no source to the new believable and verifiable. Exactly like on Wikipedia articles, when user is adding new informations based on sources he can change old unbelievable informations. Tommy J. (talk) 13:57, 8 May 2021 (UTC)
  • Oppose. This is a terrible proposal, with obvious, and obviously disastrous, consequences. I oppose any scan-backing requirements, and especially one so draconian as this. While you may find the existence of non-scan-backed works reprehensible, they are nonetheless an integral part of English Wikisource. Certainly, and especially for larger and/or more important works, the encouragement of scan-backing is acceptable; but a requirement of the sort you propose will greatly damage the project. TE(æ)A,ea. (talk) 15:02, 8 May 2021 (UTC)
  • Oppose. I can certainly see where this proposal comes from. However, our backlog of non-scan-backed works that should be scan-backed ("Shouldies") has two origins: 1) very old works that predate modern WS norms, and, indeed, the ProofreadPage extension ("Oldies") and 2) new works that should be scan-backed from the outset ("Newbies").
"Oldies" ae uniquely annoying, because they are usually not without value and are often "core" texts, often via PG (Which probably made sense in the mind noughties, when there were far, far fewer scans online). I certainly don't think that deletion-without-replacement is a good idea. While these works are probably a chilling effect on building out the core scan-backed corpus, because scan-backing an existing work isn't as "sexy" as a whole new work, deleting them outright with no replacement plan will just be blowing holes in the library for ideology's sake. I think an unsourced or non-scan-backed work is (just slightly) better than no work at all.
"Newbies" are easier to deal with, since they can be addressed at the time by engagement with the contributor.
I don't have a good handle on this, but "Newbies" don't seem to be an overwhelming proportion of "Shouldies". Most "Shouldies" that I come across are from the mid-noughties and are often complete, but unloved.
At the risk of talking the talk without walking the walk (since I am not personally volunteering to take point), I think what we actually need here is something like:
  • As I have previously suggested, figure out a more collegial and less adversarial improvement venue than WS:PD. This will allow us to put eyes on "Newbies" and hopefully get them sorted before they get buried. This might be a hypothetical WS:SCANS (or a whimsical name like The Bindery, whatever), possibly repurposed from the obsolete WS:OCR.
  • For "Oldies", management is broadly similar, but there contributors are generally long gone. My proposal, which is contingent on the Monthly Challenge becoming a "thing" is to reserve a slot or two for "Wikisource-internal" works, which could be an "Oldie" in need of scan backing. This would provide a slow, but hopefully steady, impetus to slowly chip away at the backlog. If we can bring more proofreading firepower to bear on it that the MC can contain, we can set up a separate WikiProject, but, honestly, I can't see that happening.
What I don't really want to see here is writing new policy that will strengthen the (IMO undesirable) tendency to view policy-backed deletion as a quality control measure rather than a last resort for unsalvageable works). I would like to see it made clear to new users that if a scan is available and sensible, a work should be scan-backed. But it is already pretty clear, e.g. at Help:Adding texts.
@Languageseeker: my suggestion to you personally is that if you'd like to see progress made on the issue, firstly you should attempt to quantify it. We have 283 works tagged with {{migrate to}}, and 24 tagged {{scans available}}. That's not an epidemic of "Shouldies", but I certainly do not think that count is anywhere near the true count. Secondly, I suggest that you (continue) work on the Monthly Challenge as that is, IMO, a very interesting and engaging way to get eyes on specific "important" (either due to "Shouldie" status, or as a "core" text, FSVO "core"). Finally, if you still feel MC is not enough, I suggest taking your quantified statement of the issue from step one and using that to set up scan-backign workshop where we problematic works can be laid out for review and improvement. Inductiveloadtalk/contribs 22:12, 8 May 2021 (UTC)
... AND users can link to PG from author pages, there is no need for their versions to be here. — billinghurst sDrewth 12:44, 10 May 2021 (UTC)
My thoughts on this in general are: 1) We should be very strict on {{no source}} when works new works are created without a source and if those are not resolved by engagement with the contributors at that point consider deletion. 2) It would be good to easily track the size of that category over time and see how we can resolve many of the works in it 3) We as a community should use things like POTM / Monthly Challenge / Community Collaboration / WikiProjects etc. to include some component to identify and encourage migration of the backlog so that we can bring up the proportion of scan backed content up significantly to bring this down rather than flat. MarkLSteadman (talk) 22:40, 8 May 2021 (UTC)
  • oppose filling a void here with proofread content from PG can be linked from other texts, a virtue of this site. Adding scan based texts is all I do, and I've gone to bother of adding an alternative to a PG text, but I value having a link to anything usable. The minutes taken to convert a text for use here versus the hours of one or more users it not such a delicate balance in evaluating their worth. CYGNIS INSIGNIS 18:12, 9 May 2021 (UTC)

It seems that this proposal will not pass. Most of the community appears to be more in favor of a voluntary approach rather than a forceful one which I can understand. I have a few lingering questions and thoughts.

  1. Is it possible to distinguish in the Author NS between a scan-backed and non-scan backed copy? Perhaps, a book icon next to the link for a scan-backed copy. This would make it possible to visibly distinuish between the two.
  2. For born-digital texts, especially from websites, how do you guaranteed authenticity?
  3. How can users who continue to contribute non-scan backed texts of public domain material be guided to moving to scan-backing so that the number of texts to migrate does not continual to grow.
  4. Should the sources page be updated to remove sites such as Project Gutenberg? Languageseeker (talk) 20:58, 17 May 2021 (UTC)
Please take your general questions about how to handle specific scenarios to the general section. — billinghurst sDrewth 08:22, 28 May 2021 (UTC)
This section was archived on a request by: Please take your general questions about how to handle specific scenarios to the general section. — billinghurst sDrewth 08:22, 28 May 2021 (UTC)

Index:Rudimentary Treatise on the Construction of Locks (1853).djvu[edit]

The text layer in this is off by one page. The original DJVU (from before pages being removed) also had this problem although the cover's text layer didn't contain anything. -Einstein95 (talk) 14:49, 10 May 2021 (UTC)

@Einstein95: Yes check.svg Done I had to compress it quite aggressively due to phab:T278104, so please let me know if any pages have become unreadable and I'll try to tweak it. Xover (talk) 06:24, 11 May 2021 (UTC)
@Xover: FYI: After an unreasonable amount of experimentation and being told that >100MB files are basically user error (rest of rant omitted), I have found that bypassing the upload pages altogether, creating a File: page at Commons with the description, and then uploading a file directly into that with Rillke's chunked upload JS works for me.
Also Pywikibot should now be fixed (pending next release) to allow async uploads, and has been flawless for me since. My hypothesis is the PHP library used by IA-Upload has to same issue. Inductiveloadtalk/contribs 07:01, 11 May 2021 (UTC)
There is no way I am buying that this is a client-side issue. The exceptions getting thrown are down in the DB layer. If manually pre-creating a file description page works then that must mean it is the metadata part of the overall file upload process that is triggering it (not, perhaps, surprisingly), but it's still a server-side problem for which this is merely a workaround.
Who told you it was user error? The Pywikibot folks? Chunked upload, which exists specifically to upload >100MB files, is definitely supported (fsvo) functionality. --Xover (talk) 07:09, 11 May 2021 (UTC)
Rant continued on your talk page for avoidance of derailing this thread ^_^. Inductiveloadtalk/contribs 07:46, 11 May 2021 (UTC)
This section was archived on a request by: — billinghurst sDrewth 08:26, 28 May 2021 (UTC)

Index:Some Account of New Zealand.pdf[edit]

Due to sdelete requests I found the original upload was faulty. I've uploaded a new version of the same file with the duplicate pages removed. I've manually adjusted pages around the initial faulty section and now request bot assistance to fix the rest. Pages in the range 31 to 142 need to be moved back seven places to 24 to 135. Beeswaxcandle (talk) 19:55, 20 May 2021 (UTC)

@Inductiveload: did the move earlier, and I updated the transclusion links, Please review.ShakespeareFan00 (talk) 08:19, 21 May 2021 (UTC)
This section was archived on a request by: — billinghurst sDrewth 08:26, 28 May 2021 (UTC)

[Maintenance] Editions marked as "literary work" at wikidata[edit]

Looking at Wikidata we have about 1400 editions of works that are called "literary work" rather than version, edition, or translation (Q3331189).

Only a rough query, but it gives a good example of fixes that we need to make.

I will guess that we have some other variations of work that we will need to fix. Cannot just relabel them as some have merged editions into works. :-(

billinghurst sDrewth 03:04, 3 May 2021 (UTC)


Please can someone explain to me in simple terms (or point to page which does so) how sections can be transcluded?

I tried on Showell's Dictionary of Birmingham/A, but that failed. What did I do wrong?

I am confused that we appear to have two types of markup: ## A ## and <section end="A" />. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:43, 2 May 2021 (UTC)

  • You needed to add the sections on the final page. On the final page, there are two sections: “A” and “B.” You should put ##A## at the top of the page (where the “A” section begins on that page) and ##B## between the “A” and “B” sections. I have done this, so the page now transcludes properly. TE(æ)A,ea. (talk) 13:19, 2 May 2021 (UTC)
In terms of the two types of markup: the # style is "Easy LST", while the <section /> is the standard style. Which you see/use depends on whether "Easy LST" is switched on in your Preferences. It's on by default. Beeswaxcandle (talk) 17:12, 2 May 2021 (UTC)
  • Essentially they are the same, the Easy LST is simply a javascript that converts the section tag to ##. At a point in time it was considered easier to have what was considered an easier methodology of simply requiring to mark the start of a section, and allowing the next section to open and close. — billinghurst sDrewth 08:31, 3 May 2021 (UTC)
<section end="A" /> is more commonly used, familiar, and self evident code that is available with a click. CYGNIS INSIGNIS 11:46, 3 May 2021 (UTC)
Noting that the section tag is in the editlist wiki markup drop down, and I knwo that I have made buttons for my toolbar to make my life easier. — billinghurst sDrewth 13:43, 3 May 2021 (UTC)

Tech News: 2021-18[edit]

15:43, 3 May 2021 (UTC)

Philosophical Transactions of the Royal Society A – Volume 184[edit]

Wasn't sure where to post about this since WikiProject Royal Society Journals seems to be dead, but I'm taking on the task of filling out Volume 184 of the journal Philosophical Transactions of the Royal Society A, published in 1893. Why Volume 184 specifically? Can't remember. This is a pretty big undertaking, and I'm mostly doing whatever random pages I feel like in whatever order, so anyone who's up for learning about chemistry or higher mathematics or astronomy or aether theory, etc., as it existed in the late 19th century: feel free to jump in! I already have about 50 pages "done" (several are still missing images, and a handful have ostensible misprints such as teeny tiny exponents that I can't read; nevertheless, those have been proofread as best I can otherwise), but that's just put a dent in it, let alone the other volumes of the journal. A fair warning that a lot of these pages require prolific use of the 'math' tag, but that certainly doesn't apply to all of them. Either way, I think it's a lot of fun, and it'd be great to have more eyes on the project than just my own. :) TheTechnician27 (talk) 17:33, 3 May 2021 (UTC)

@TheTechnician27: Thanks for letting the community know, and great to have you with us. I am not particularly into proofreading those works, though if you need assistance in working in the page: ns, or transclusions, etc. then please let me or the community know here. If you need a bot run through to apply text layers, then please put a detailed note on Wikisource:Bot requests and ping me. When one is jumping about for particular articles having the text there, and a tuned {{engine}} to search within the work can be quite handy. And with regard to proofreading, we all just do our best, and learn on a daily basis, so don't overly sweat that. — billinghurst sDrewth 01:56, 4 May 2021 (UTC)

French speaker needed[edit]

Would someone proficient in French kindly check the three pages starting at Page:Aerial Flight - Volume 2 - Aerodonetics - Frederick Lanchester - 1908.djvu/374? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:26, 4 May 2021 (UTC)

I've reviewed this pages; accents were missing in the source, e.g. in Pénaud; I've used a SIC only for the first occurrence in the text. I've used symbols ′ and ″ for prime and second. M-le-mot-dit (talk) 11:05, 4 May 2021 (UTC)

Is this an acceptable Index page name?[edit]

Index:Narrative of Henry Box Brown - who escaped from slavery enclosed in a box three feet long and two wide and two and a half high (IA narrativeofhenry00brow).pdf

The document is always referred to as "Narrative of Henry Box Brown" am I permitted to shorten it? This is the only copy on IA, and I have it as a .djvu file but is identical to this pdf. — Ineuw (talk) 04:48, 2 May 2021 (UTC)

My first question would be "but why?". There is no direct relationship between the transcluded work name and the Index: page name. Renames at Commons generally related to their criteria, so it is more into that space than ours when we have no requirement. I have shortened filenames at Commons though only where they have been problematic/wrong. — billinghurst sDrewth 10:57, 2 May 2021 (UTC)
Now that you moved the file name on commons the text had to be moved by an admin. I know that the file name wasn’t ideal, but It’s really creating more work for very little reward. Languageseeker (talk) 11:46, 2 May 2021 (UTC)
Ineuw is an admin so essentially they are just creating work for themself. — billinghurst sDrewth
the 19th century practice of putting all the metadata in the title is a little tiresome, but index title length or sense does not matter, as we can name the work what wikisource wants. and they tend to have machine generated internet archive artifacts. so all pdf names should be acceptable including "qwerty123". Slowking4Farmbrough's revenge 16:01, 3 May 2021 (UTC)

Thanks for all the comments, and apologies for these belated clarifications. I was distracted by unrelated issues.

My primary concern in renaming the index was hoping not to offend Languageseeker the original uploader. The reason for doing it was aesthetical, simplifies web search, and it's short, clear, and unambiguous. It is also uncluttered when proofreading. As long as this does not breach WS rules, the critiques are non-sequitur. — Ineuw (talk) 11:38, 6 May 2021 (UTC)

Google OCR does not work[edit]

⧼error⧽ undefined cURL error 60: SSL certificate problem: certificate has expired (see

Anybody knows where is the source of this problem? Ankry (talk) 09:04, 6 May 2021 (UTC)

@Ankry: It should be back up now. There was a transient problem with the SSL certificates for all services hosted on Tool Labs. I don't have details on the cause or remedial actions, but the issue was reported regarding multiple other tools and subsequent reports that the issue was no longer present. Xover (talk) 11:12, 6 May 2021 (UTC)
Yes check.svg Done confirmed. Ankry (talk) 11:38, 6 May 2021 (UTC)

Text in both margins[edit]

Suggestions, please on layout for pages like Page:The Grand junction railway companion to Liverpool, Manchester, and Birmingham; (IA grandjunctionrai00free).pdf/41, which has text in both margins. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:40, 6 May 2021 (UTC)

Push it all left, otherwise it looks like the teeth of a saw, and is just problematic when transcluded. If you are truly concerned about the Page: ns, then there are some templates that show right, and transclude left. — billinghurst sDrewth 14:14, 6 May 2021 (UTC)
And how will that relate to the subheadings "From Birmingham" and "From L'pool & Manch'r"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 6 May 2021 (UTC)
How about {{Sidenotes begin}} and its siblings, as seen in The_Solar_System/Chapter_1? The rendering won't be exact (in particular I’m not sure how you would get the rules down the page), but it will get you lined up with the text nicely in a way I’m not sure how else to do… — Dcsohl (talk) 17:25, 6 May 2021 (UTC)
Footnotes, with the cute arrangement of to and from distances linked to the nearest full stop, period CYGNIS INSIGNIS 18:38, 6 May 2021 (UTC)
I've implemented a form of that on the above page, but with the footnotes attached to the place where the mileposts are mentioned in the text. The footnotes are going to get very repetitive like that though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 6 May 2021 (UTC)
We also need to account for the change in presentation on pages like scan 64, which differentiates between two types of content. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:08, 6 May 2021 (UTC)
i would be tempted to ignore the double side notes. some right waypoints are in the text. unclear what the value added is. Slowking4Farmbrough's revenge 22:34, 6 May 2021 (UTC)
@Pigsonthewing: On second thoughts, don't see them them as marginal, and just see it as a table, and set it a three column table, centre floated, and manage the intervening lines as a merged column and embed {{RunningHeader}} for that row. (Don't answer questions late late at night when dog-tired.) — billinghurst sDrewth 00:30, 7 May 2021 (UTC)

Rollbacker group[edit]

A long time go, there was the proposal to have rollback group, and there has been some mentions (a, b, c). Since that time, accounts have been m:SUL'd so we have a different base, better xwiki tools so more likely to have trusted xwiki visitors. As the community has been more stable and less giving and encouraging of taking up adminship, is rollback something that should be re-considered? There are certainly people here that I would trust to rollback bad edits, who I would not (yet) consider for adminship. — billinghurst sDrewth 06:21, 26 May 2021 (UTC)

Symbol support vote.svg Support, but it might make sense to decouple the group's rights from just rollback. We may want to allow some other permissions in that group in future and it will be confusing if the "rollbacker" group actually grants rollback and, say, suppressredirect. The latter right is useful when, say, moving pages in the Page: namespace. Inductiveloadtalk/contribs 09:10, 28 May 2021 (UTC)
Better to create a separate group separately. I was keeping it simple per other places "Rollbackers" => "Quickly rollback the edits of the last user who edited a particular page (rollback)". If we want a page/index page mover we discuss it, request it and deal with it and apply it as required, as I am unaware that the suggested right can be selective to a namespace. — billinghurst sDrewth 10:53, 28 May 2021 (UTC)
Fair enough, I don't really mind either way. It was just a thought. Still support.
I am unaware that the suggested right can be selective to a namespace: I don't think it can, but someone trusted to wield the tool in the Page NS can hopefully be trusted not to run riot (and rights can be revoked if someone we thought would behave does not). Though ideally, we could dream of a page-moving tool at Toolforge (or, better, built into ProofreadPage 🤯). One day soon I will figure out OAuthing a Toolforge tool. Inductiveloadtalk/contribs 11:07, 28 May 2021 (UTC)
@Inductiveload: As a by-the-by, we can leverage this right in abusefilters if we impose restrictions on who can move Index: and Page: ns moves. Though if we wanted to have the ability to suppress redirects then it should be part of a larger thinking about how we manage moves, and what that entails and how we might restrict/manage matters. I am not sure whether we can log through AF if the suppression right is used or not. It looks to be possible in AF as there is Page ID of move source page (moved_from_id) which is set to 0 (ZERO) after a move (untested in filter, so presuming). — billinghurst sDrewth 05:06, 30 May 2021 (UTC)
I'm not opposed per se, but I am uncertain what problem this is solving. Global rollbackers already have rollback rights globally, and any user can technically simulate rollback through scripts (e.g. I have, and use, rollback functionality on enWP through Twinkle, despite having no non-standard permissions there).
If there is any significant number of users who have a legitimate need for this permission I am unaware of them; and if we start using this we need to establish process and policy for assigning and revoking the group. Xover (talk) 12:59, 29 May 2021 (UTC)
Functionally Rollback reverts AND PATROLS in one action. Undo, save and patrol is three actions, and all slower. We have numbers of users here who undo edits, of vandals. I am simply raising this with the community as some of these users are trusted to undo, and it eases some of those actions. — billinghurst sDrewth 13:14, 29 May 2021 (UTC)
Pictogram voting comment.svg Comment This would be far more useful with the ability to issue short bans of say six hours. This is probably the best way to stop a vandal until an administrator can decide if a longer ban is merited. Of course, any member of this group who abuses this power should be given a short ban and lose their privilege. Also, maybe restrict the banning ability to users less than 1 week old. Languageseeker (talk) 19:59, 29 May 2021 (UTC)
Won't happen. Cannot happen as not technically possible. — billinghurst sDrewth 04:38, 30 May 2021 (UTC)
you talk about bans as if you think they work. skinner is dead, but the dead thought lives on. punishment doesn't work -- Slowking4Farmbrough's revenge 00:26, 31 May 2021 (UTC)
This section was archived on a request by: would appear to not be particularly of interest — billinghurst sDrewth 10:23, 2 June 2021 (UTC)

Need to stop overwriting old versions, need to make a new version and disambiguate[edit]

Can I ask that as a rule that we typically never overwrite an edition of a literary work, especially a long-held work. When we have a new edition of a work, then we should name and disambiguate it. The community can then have the conversation about what to do with works.

With our long-held works where works were often not done as subpages there are redirects, versions, blah blah blah that need tidying up and it getting disconnected; plus the wikidata is getting horribly inaccurate. I hate having to upick these Gordian knots for lack of a simple solution being undertaken at the beginning, especially where an admin who can move with subpages, and without redirects. There may be exceptions to the rule, but these exceptions should be made with a clear mind, and by consensus. — billinghurst sDrewth 07:30, 3 May 2021 (UTC)

I think there should be a lot of caution in overwriting, it probably needs to go through discussion when the content is sourced and presentable.

Burning redirects has widowed content I linked from wikipedia in the past, I have opted to link sites like BHL instead for that and other reasons, and I already see how moving the second edition of Descent of Man on a whim or head-canon of a rule may make the deeplink I just added there useless. CYGNIS INSIGNIS 11:38, 3 May 2021 (UTC)

yeah, need some guidance about editions. we have a lot of non-scanned back works with no edition information, that we would like to update. and a lot of non-scanned backed poems (extracts from books). in addition to non-scanned backed works where the available scan is a different edition. Slowking4Farmbrough's revenge 15:47, 3 May 2021 (UTC)
@Billinghurst: I don't understand why? Look at The Deserted House (Alfred Tennyson) - a poem with edition information, but introduced by user, we can't verify it here and now. And other The Sun Rising - no edition information, no source. Why we can't overwrite works of this type? What's wrong if we will do it? Tommy Jantarek (talk) 23:47, 3 May 2021 (UTC)
@Tommy Jantarek: Firstly for your first example our version reputedly comes from The Works of Alfred Lord Tennyson (see its talk page), where is your version coming from? Should there be two versions? What will be the harm, issue with nnn versions?

Secondly, those works by our current methodology we would set them as subpages of their published work, and create either a redirect from root if we only have the one version, or we have a {{versions}} page and point to each.

Thirdly, because people have been doing a ham-fisted and half-arsed job of it, and fixing it up from that is an absolute PITA and waste of (my) time. A version of a poem will most likely have come from another work/source, so it should now be a subpage, not a root work; they overwrite with a different edition and a different source, they don't update the wikidata, etc.

Fourthly, we try to have half measures, and general guidance, and then we get hung by someone saying that they were not told that they could not do it by our written instruction. So I would like to see a gentle review process on how we better handle a new version where no one person makes such a decision, there is at least an independent review that we are not losing works where versions should exist. It does not have to be convoluted or power-based, though it should be reviewed against a set of criteria.

So I see that it is best that the each new work is rendered newly, with the wikidata freshly entered, AND THEN we look what we do with the old version. We can move and overwrite at that stage if we determine that is the best way to progress. — billinghurst sDrewth 03:11, 4 May 2021 (UTC)

I will also note that your Tennyson example, it directly matched to the work The Deserted House (Q7729810) rather than being its own edition of a work. There is not one version of many of our works, so we create editions with their provenance. — billinghurst sDrewth 03:16, 4 May 2021 (UTC)
Regarding 3. What if scan is exactly the same like on edition information? Do we overwrite old version and move it to subpage? And what if old version have no edition information or wikidata item? If user overwrite old version, he might move the overwrote poem to subpage. Tommy J. (talk) 12:37, 4 May 2021 (UTC)
That will be the review process to determine what to do. I am saying that we should typically not replace/overwrite as the first step of actions. If you have a new scan, transclude its edition of the work. Do you see the string of "what ifs" that make it hard to write rules for the newbie or less aware that we work on versions, and of our processes, and all the factors to check. — billinghurst sDrewth 13:48, 4 May 2021 (UTC)
I think the fundamental issue is that most texts are presented as the one-and-only one of text. However, every text is an edition. The Deserted House (Alfred Tennyson) is ambiguous because this poem probably exists in several versions. If this site wants to stop having confusion over texts, then it needs to do two things. 1) Ban non-scanned back copies. This whole entire situation exists because users are trying to replace non-scan backed versions with scan-backed version. Non-scan backed versions are always going to be dubious because there is no simple way to verify their authenticity or accuracy. 2) Set up rules for publishing works. At minimum, it should include the date. 3) Make the deletion on non-scan backed versions when a scan backed exists a criteria for speedy deletion. Languageseeker (talk) 14:42, 4 May 2021 (UTC)
In re your proposal #3, no. As a text repository, we need to ensure that incoming external links don't break. This is the point of what Cygnis is saying and a principal reason for Billinghurst's initial post. The various forms of disambiguation pages and the soft redirect process assist with ensuring this. Beeswaxcandle (talk) 17:40, 4 May 2021 (UTC)
Most texts are the one-and-only one. Once in a long while, a work will get reprinted with some changes, but it's the exception, not the rule. Reams of fiction and non-fiction get written every year and even after you filter for intent to publish and actually getting published, most of it just disappears. This is doubly true if you ignore facsimile reprints and other reprints that don't introduce any interesting changes.
I get it; you have an interest in certain works widely considered important that have important distinct editions. I don't. I'm much more interested in the rare and esoteric. Please understand the differing needs and concerns of some of your fellow users. I can't really imagine that continuing to push the banning of non-scan backed editions is in your best interest; work with the community as it is, don't walk in and trying and make huge changes.--Prosfilaes (talk) 17:55, 4 May 2021 (UTC)
@Prosfilaes: As far as I can tell, the issue that billinghurst is raising is the overriding of non-scan back editions with the text of a different edition: a user overriding Version X of a title with Version Y. This creates confusion in the WD. Therefore, billinghurst is requesting that users do not override a non-scan backed version prior to discussion. Otherwise, the WD becomes inaccurate. Cygnis insignis points out that excessive disambiguation breaks links and makes this site less usefull to Wikipedia.
I am arguing that this occurs for two reasons. First, many pages are created in a way that can lead to ambiguity. Yes, most texts are one-off, but that is no reason not to take more care in creating page name. Even title (year) would lead to less ambiguity than currently exists. I recently had a long discussion about disambiguation where the administrators stated that the current policy is to allow ambiguity and then disambiguate later. Poor naming leading to more future disambiguation and link breakage. Instead, disambiguation should be the exception and not the norm. Second, users are overriding these texts because they wish to improve the quality of the text. Many users see scan-backed versions as better than non-scanned back versions. This will continue until this site needs to make a firm policy on non-scan backed copies. If we allow them, they they can never be deleted. If they are to be replaced, then they should stop being made to avoid creating additional work.
Finally, I'm not against obscure work or only for those considered important. What is important changes over time. Paradise Lost used to be an obscure work. However, I believe that most users will come looking for the texts currently seen as important. Creating scan-backed versions of these works can attract more users that will proofread more works obscure, important, or otherwise. Languageseeker (talk) 00:59, 5 May 2021 (UTC)
Don't presume, ask. It is broader. I have numbers of reasons why, and essentially the free-for-all for numbers of situations the overwriting process is broken. I am saying that the community needs to holistically manage overwrites, and the way that I see it best to do it is to keep it simple "any new work coming in scan-backed to be transcluded as a new version". Then if we think a version is redundant, then the community manages it by its processes. This is typically not a single-person decision.

At this stage non-scanned editions are within scope, so please do NOT pollute this conversation with that matter. Separate conversation deserving of its own discussion at a later time. Dealing with what we have. — billinghurst sDrewth 02:46, 5 May 2021 (UTC)

My humble opinion and suggestion. The community will do what you all will decide, I'm just guest here. It seems to me you all plays too much value to non-scanned texts. This type texts are like Wikipedia articels without sources and footnotes. Are these letters, words, sentences and punctuation correct? Nobody knows it (even author of page) and a verification is very hinderet or impossible. Data based on non-scanned texts is like divination by the cards. "Create new text and the community can then have the conversation about what to do with old version". OK. But what is if community make a decision to delete? We will delete not just text but user's contribution and work also whole history of page. It's no good and honest practice. And it's destructive. In my opinion Proofread project offers most usefulness and credibility on this days. When user (usually experienced) overwrite non-scanned text then text's quality and credibility grow and whole history is preserve. Unbelievable text without source gains its strenght. Proofread pages aren't transcluded by newbies or very rarely. Few newbies know this project sufficiently to do it. What's with Wikidata? If user overwrite and move old text to adequate subpage good practice will be to visit Wikidata item and update all information. There is not a lot of work and it require just one visit preferably right after overwriting. I think that user who know how transclude and move pages also he know how visit and update Wikidata items. The plwikisource community attach much importance to Proofread Project from many years and it brings great results in my opinion. Forgive me for this long scribble, please. Tommy J. (talk) 21:35, 6 May 2021 (UTC)

@Tommy Jantarek: I've started a discussion about this at the Scriptorium if you'd like to express your excellent points there. Languageseeker (talk) 04:59, 8 May 2021 (UTC)
Pictogram voting comment.svg Comment @Tommy Jantarek: I don't disagree with your opinions about scan-backed texts being preferred than a copy and paste. I don't think that the community disagrees either. Now this may be an English language issue alone, that I cannot say, however, I started this thread because the practice of users has been problematic, so you are hearing my experiences with having to resolve problems.

There n be no updating of Wikidata. There are partial moves, partial overwrites, no link fixes, US editions replacing UK versions; illustrated versus non-illustrated versions. So to me we have to change the practice, instead of users themselves choosing to overwrite, instead create a new version [keep it simple]. The community can then decide what to do about versions, and how to go about it. — billinghurst sDrewth 09:50, 8 May 2021 (UTC)

Text of Template:migrate to needs to be adjusted as it encourages the in situ replacement, and no guarantee that the replacement is appropriate. We have no clear quality control on the placement of the the template to even know that a one-for-one replacement is the correct instruction. — billinghurst sDrewth 09:53, 8 May 2021 (UTC)

Tech News: 2021-19[edit]

15:10, 10 May 2021 (UTC)

Wikidata integration[edit]

Please see d:Wikidata talk:WikiProject Source MetaData#Wikisource integration project, requesting assistance for documentation + implementation. It reminded me of our recent discussion at Wikisource:Scriptorium#Google often unable to find works at Wikisource. Whatamidoing (WMF) (talk) 15:34, 11 May 2021 (UTC)

1000 pages processed in the Monthly Challenge[edit]

Wikisource laurier.svg

The first-ever Monthly Challenge, after a fairly sedate start, passed 1000 processed (marked no text, proofread or validated) pages yesterday, and has sustained over 100 processed pages for 2 days straight. Very, very approximately, This represents 10% of pages at enWS processed in the last 2 weeks.

In the spirit of friendly competition, there were more pages processed the day before yesterday than Mission 7500, the French equivalent challenge (which recently has been racking up ~12000 page a month) did yesterday. We're still to reach a milestone of 200 pages in a day, at which point the stats table gets a shiny green row.

There is nothing different about proofreading in the Monthly Challenge, and everyone is free to dive in. Nominations for future months are always open, but if you really want your favoured book to feature, you will need to help make a space for it! Inductiveloadtalk/contribs 01:05, 13 May 2021 (UTC)

Use of notes= for annotations[edit]

Is there community concensus for this edit? I always thought notes= is the right place for annotations. Hesperian 04:38, 12 May 2021 (UTC)

That does indeed look like an appropriate use of the notes field to me. Xover (talk) 04:48, 12 May 2021 (UTC)
Always has, always will be. How else have we ever added {{wikipediaref}} statements in situ. I have reversed their edit. — billinghurst sDrewth 09:59, 12 May 2021 (UTC)

Proposal: Amending autoconfirmed position at English Wikisource[edit]

I am proposing that autoconfirmed at English Wikisource be amended from 4 days and zero edits to 4 days and 10 edits

Current settings are wiki default

'wgAutoConfirmAge' => [
	'default' => 4 * 3600 * 24, ... // 4 days to pass isNewbie()
'wgAutoConfirmCount' => [
	'default' => 0,

Other wikis that have modified time have moved that to 7, though I don't think that a time change is necessary. Other wikis that have changed their edit count have a range of 5, 10, 15, 20, 50.

I am proposing this change as at this time to give better protection to the wiki for edits on pages that have autoconfirmed settings, either through direct soft protection, or where that protection is wrapped into the title blacklists (local or global). At this point of time there are vandals exploiting this issue, and the zero edits becomes virtually ineffective.

To have a change this community needs to reach a consensus and submit a phabricator ticket to have site settings amended. — billinghurst sDrewth 08:18, 28 May 2021 (UTC)

Symbol support vote.svg Support, should certainly not be zero. Edit: 10 seems fine, my support applies to anything up to and including 25. 50 seems a little on the high side. Inductiveloadtalk/contribs 09:13, 28 May 2021 (UTC)
Symbol support vote.svg Support, 10-20 seems like the right range to me. — Dcsohl (talk) 15:12, 28 May 2021 (UTC)
Symbol support vote.svg Support, I would prefer something in the middle of the range mentioned above. Beeswaxcandle (talk) 19:47, 28 May 2021 (UTC)
Symbol support vote.svg Support Tommy J. (talk) 23:50, 28 May 2021 (UTC)
Symbol support vote.svg Support as proposed.
Anything in the ranges 4–7 days and 10–50 edits is fine by me. 4/10 as proposed is a good place to start, although I would personally be inclined towards 7/50 and scaling down if it turned out to be too strict. But bottom line is that I trust the proposer's judgement on this. Xover (talk) 12:30, 29 May 2021 (UTC)

Pictogram voting comment.svg Comment if 10 is not the correct number, then suggest a number that the community can consider. Any codejunkie implementing will want to see a number to set. — billinghurst sDrewth 01:42, 29 May 2021 (UTC)

Suggesting that we can close as a consensus of the community exists for proposal, and submit a phabricator ticket that asks for a wgAutoConfirmCount = 10billinghurst sDrewth 14:25, 3 June 2021 (UTC)

Closing and lodged phabricator:T284627 ticket. — billinghurst sDrewth 07:40, 9 June 2021 (UTC)
Yes check.svg Done by DannyS712. Thanks. — billinghurst sDrewth 11:48, 9 June 2021 (UTC)
This section was archived on a request by: — billinghurst sDrewth 12:00, 9 June 2021 (UTC)

Introducing {{Annotate QID}}[edit]

For some time I have been noting the Wikidata IDs of people mentioned in works I'm transcribing, who have no author, portal or Wikipedia link, using HTML comments, thus: John Moss <!-- Q27478536 -->

I mentioned on Twitter today that I wanted a template for this, so that the terms are more clearly and semantically tagged, and User:Mfchris84 kindly implemented the idea. I have imported it as Template:Annotate QID (shortcut: {{aqid}}), used thus: {{aqid|Q27478536|John Moss}}.

The name John Moss in this sentence is an example of its use.

It is therefore now possible to write a Wikidata query to interrogate a work on Wikisource, and produce (or process) a list of people or things mentioned in it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:47, 11 May 2021 (UTC)

There's also {{wdl}} which will link to, in order of preference, the first found of: an author/portal, a Wikipedia page, a Commons category and finally to Wikidata (via Reasonator) for a given Q-ID. Inductiveloadtalk/contribs 19:31, 11 May 2021 (UTC)

Question Question For both of these usages we need to explore how they work in linking policy, and annotation policy, and improve our guidance accordingly. What is the ultimate outcome? How does it improve our site? Where do we expect it used? How much do we expect it used? Both within a work, and withina page? What are our limitations in its usage? Once per page? per chapter per work? When do we annotate vs when or link? [We have a lot of non-fiction works] Also how do both work in the export realm? — billinghurst sDrewth 00:22, 12 May 2021 (UTC)

Wikisource:Requests for comment/Wikilinking policy mentioned it. Where does that stand? @Beeswaxcandle:?
WRT to export, they're "just" links, so they export as links. From an ebook, there is no difference between link to Wikisource and a link to Wikipedia or Wikidata other than the URL - both would prompt the user "do you want to visit this location". Depending on the reader that might or might not work (for a start, it needs network access which not all readers have).
Another issue is that nearly all reader devices have no concept of "hover", so using the title attribute for anything is going to be functionally invisible in the end result. This problem also affects {{SIC}}, {{tooltip}} and friends. Inductiveloadtalk/contribs 15:45, 12 May 2021 (UTC)
@Inductiveload: The new version of the policy should be ready for release next week. Still juggling the various thoughts and coming to a conclusion. Beeswaxcandle (talk) 07:48, 13 May 2021 (UTC)
Not concerned about tooltips generated. SIC as it is, is just meant to be an indicator to the reader who may edit there and then. It is meant to be non-vital information, so never been an issue to not export. — billinghurst sDrewth 01:41, 13 May 2021 (UTC)
Should any template like "Annotate QID" have "tooltip" as an underlying component if we are using it to annotate? Even if we have to fiddle with tootip itself. — billinghurst sDrewth 01:43, 13 May 2021 (UTC)

FYI: Wikisource-bot has stopped archiving[edit]

A note to those who watch for archiving around the place. The bot stopped working April 30th, and I am seeking assistance to get the script investigated and the issue resolved. Bear with us. — billinghurst sDrewth 06:08, 13 May 2021 (UTC)

Yes check.svg resolved — billinghurst sDrewth 11:03, 13 May 2021 (UTC)

Lower case naming of book by myself[edit]

Index:Some feudal coats of arms.djvu - I think I should have used caps when creating this and I don't know how to fix it. It's because I saw it in lowercase in the WorldCat books catalog, but also the name is sooooo long. I think it should just be Some Feudal Coats of Arms. Can someone fix it. I'm sorry. --The Eloquent Peasant (talk) 21:43, 10 May 2021 (UTC)

@The Eloquent Peasant: the name of the file (and therefore the index page) isn't really important as long as its not actively misleading. Just update the link to mainspace to be Some Feudal Coats of Arms. No need up be sorry :) Inductiveloadtalk/contribs 22:00, 10 May 2021 (UTC)
Thank you! --The Eloquent Peasant (talk) 23:08, 10 May 2021 (UTC)
@The Eloquent Peasant: and the thing is that the standards used by cataloguers change so both are right at different times. So for us both forms are right, just ensure that you create redirects between the forms. In the end, as Inductiveload said, as long as it can be found as an accurate title, then no issues. We rile about the use of all capitals as that is just butt ugly. — billinghurst sDrewth 00:04, 11 May 2021 (UTC)
I have 1 GF. My husband says shouldn't come around 'cause she's butt ugly - ... but I like her and besides, while he's not lying, it's mean to say she is. She's a great person oh except she likes to drink too much. So for that reason, I keep her at bay and also because she lives 4540.9 miles away. All caps is crazy for a book name and all this makes me realize I should have more than just 1 GF. :) Thank you. :) --The Eloquent Peasant (talk) 00:10, 11 May 2021 (UTC)

I have .png and .jpg images for the book and have uploaded both (38 files) as .jpgs and as .png files but now I don't know which one would end up being used in the book here on Wikisource. I cropped and reuploaded one .jpg but the book has tons of images. Which is preferable here, .jpg or .png? See here: [[c:Category:Some feudal coats of arms (Book) The .pngs are a little big. Thank you. --The Eloquent Peasant (talk) 01:57, 11 May 2021 (UTC)

@The Eloquent Peasant: If you are talking page illustrations, we are file type agnostic and more interested in the output. Probably the best guidance of which is better in which situation is c:Commons:File types, and as while their primary use is the transcluded work here, their re-use anywhere should be more in your thinking. — billinghurst sDrewth 02:27, 11 May 2021 (UTC)
@Billinghurst: ok. --The Eloquent Peasant (talk) 02:29, 11 May 2021 (UTC)
@The Eloquent Peasant: in this case, since the images come from a source that is already compressed with a JPEG-like compression scheme (the IA usually uses JP2, but the idea is similar) there is not a lot of value in PNG. This is because PNG expends a lot of file size on slavishly recording all the pseudo-random noise produced by the JP2 compression, which is pretty much incompressible under the PNG format.
However, if you were to extract the images and clean then up so that they are black-on-white diagrams and the image noise is removed, then PNG would be a good choice. This is because the sharp edges between colours (i.e. black and white) represents "high-frequency" image data, which produces substantial image noise when compressed lossily as JPG. For example, below is the image noise (coloured red) that is introduced when a diagram is saved as a JPG:
April 01-40N-2100-Fieldbook of Stars-025 - JPEG noise.png
Also, since the colors are limited in a greyscale, you may find that a greyscale PNG of a cleaned diagram is roughly comparable to a JPG anyway (YMMV, there are too many variables to make a global statement here).
tl;dr rule of thumb: JPG for photos and things that are already JPGs, PNG for "clean" diagrams. Inductiveloadtalk/contribs 07:18, 11 May 2021 (UTC)
@Inductiveload: TY. I'll try to upload vivid, clean files and name all the files so it's easy to know what page they belong to (for eventual use in WS). I found a better scan of this book where the pages don't look yellow. --The Eloquent Peasant (talk) 15:03, 11 May 2021 (UTC)
@The Eloquent Peasant: note that often the yellowish files are actually a better starting point for your own extraction of the image than the black/while ones. The black/white ones are generally automatically processed fairly brutally to remove the paper colour and then recompressed heavily and this often produces a fairly rough image that might look cleaner from a distance, but on closer inspection will be found to have lost a lot of detail. H:EXTRACT has some details (but still needs a lot of expansion). Inductiveloadtalk/contribs 15:58, 12 May 2021 (UTC)
@Inductiveload:That's exactly what I just surmised! I'm starting with the yellow .pdf pages and from there will clean up the files. The .jpgs that were extracted sometimes have entire sections of the image missing. I appreciate the guidance. I'll end up with .pngs and a smaller pixels size and blackish and whitish images that may not be perfect, but good enough! :) --The Eloquent Peasant (talk) 16:10, 12 May 2021 (UTC)
@The Eloquent Peasant: Just checking that you are aware that you can get the best quality individual file images easily from IA. If you look at something like click and open the VIEW CONTENTS and each page in the work is available right there for download. Usually far better than any manipulated PDF. — billinghurst sDrewth 02:24, 13 May 2021 (UTC)
@Billinghurst: I did spend quite a bit of time at that place and I searched through the different files. I downloaded what I thought would have the images, .jp2 for example but couldn't open. I did try there, but had no luck - not sure why. --The Eloquent Peasant (talk) 02:28, 13 May 2021 (UTC)
I downloaded GIMP for handling JP2000 images, and Inductiveload has some importable filters in his subpages. Though I will note that I am pretty rubbish in graphics tools, beyond the absolute basics. — billinghurst sDrewth 02:30, 13 May 2021 (UTC)
I do have the files in .png format and it's easy to work with them. The difficulty will be on pages with 12-17 images since each will have to be cropped, saved and uploaded. the worst part about is that the book doesn't give them good captions like "Fig. #" so I'll have to name them like Pg 27 img 1, Pg 27 img 2 etc. In total its about 2000 images or so the author states. So, I have pretty good organization skills but I'll soon be a little bogged down with real life. I almost downloaded GIMP. -The Eloquent Peasant (talk) 03:09, 13 May 2021 (UTC)
@The Eloquent Peasant: I finally wrote up a guide to how I use GIMP to do this: Help:Image extraction/With GIMP. Your images are much cleaner that the example, but the process is the same.
Also, the GIMP script Billinghurst refers is User:Inductiveload/Remove-background-colour.scm, which I think will work well for these images: they have nice even, light paper colours and dark ink. If the script works, it's a one-click solution. It doesn't always work, though. Inductiveloadtalk/contribs 03:26, 13 May 2021 (UTC)
Okay. I'll download and try GIMP and (the importable filter). If it works for me, "Some feudal coats of arms" project may be in better shape sooner rather than later. --The Eloquent Peasant (talk) 12:18, 13 May 2021 (UTC)

@Inductiveload: Just an FYI, I like how this one turned out. (Rather than try learn that program we talked about (which reminds me of Pulp Fiction), I've decided to just use my Photoshop)... In Photo Shop, The "Artistic" / "Poster Edge" filter worked well on the last one I tried. What do you think? I like it because it's sharp, compared to the other ones I did. I'm not an expert on images, and I hate to practice on the little guys but, in essence, that's just what I'm doing. --The Eloquent Peasant (talk) 20:22, 14 May 2021 (UTC)

But also, the filter that works on one image, will not work as well on another., yet they should look consistent from one page to the next.... I think the best use of my time is get the images to look pretty good, upload them and map them to the pages... and it's a collaborative work so someone might improve the images in the future. Have a nice weekend! --The Eloquent Peasant (talk) 20:51, 14 May 2021 (UTC)
@Billinghurst: Thank you again. What you do here is really amazing! Anyway this "Some coats of arms" Project is too difficult for me but I'll cleanup, and upload images to Commons and create shell pages in WS. The text review by the Optical Character Recognition software doesn't work on that book at all. Thanks again and take care! --The Eloquent Peasant (talk) 21:27, 14 May 2021 (UTC)

Title for a Copyright Office letter[edit]

I have at User:BD2412/Affirmance of Refusal for Registration (Prancer DNA Sequence) an untitled letter from the Copyright Office to a copyright applicant. The letter indicates who it is from and to, and has a correspondence ID, but I'm not sure how to title it for the move to mainspace. Wikisource:Style guide appears to offer no guidance on this. BD2412 T 04:33, 11 May 2021 (UTC)

Not sure either, I don't know enough about patents and their form of letters. Does it have a common usage name? I think that there should some indication of the target to of the letter, and something to indicate the source, or a date. As this presumably sits in a series of letters, I think some consideration to how such letters look in a series, for the work itself, and also how the authority acts, as we are setting some indicators for future works. Consider some redirects too if part of a series. — billinghurst sDrewth 00:17, 12 May 2021 (UTC)
I suppose if it were in a citation the title would be Copyright Office letter from Robert J. Kasunic to Howard Simon affirming refusal to register the "Prancer DNA Sequence" (February 11, 2014). BD2412 T 15:30, 12 May 2021 (UTC)
That may be a tad long. If we have multiples of these in the series; or had others from the Office to another, how& what is suitably unique and distinguishing? — billinghurst sDrewth 01:36, 13 May 2021 (UTC)
I suppose Copyright Office letter affirming refusal to register the "Prancer DNA Sequence" would be sufficiently unique and identifying. I don't have any other documents in this area, but this one is of particular interest in modern times, given that the determination that copyright does not extend to DNA sequences means that you can't copyright the mRNA vaccine sequence. BD2412 T 07:22, 14 May 2021 (UTC)