Wikisource:Scriptorium/Archives/2021-05

Table formatting

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:

{{nopt}}
|}

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. Inductiveload—talk/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. Inductiveload—talk/contribs 08:29, 4 May 2021 (UTC)

end of a page in Page: ns

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

|-
|Bilston
|9
[footer start]
|}
[footer end]

|-
|Bilston
|9<noinclude>|}</noinclude>

? use of placeholder {{nopt}}^{[page 2]}, a hard return, table close^{[page 3]}

|-
|Bilston
|9
[footer start]
{{nopt}}
|}
[footer end]

|-
|Bilston
|9<noinclude>{{nopt}}
|}</noinclude>

Y without placeholder,^{[page 3]} so hard return at first footer line, then table close on subsequent line

|-
|Bilston
|9
[footer start]

|}
[footer end]

|-
|Bilston
|9<noinclude>
|}</noinclude>

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

Notes

1. doesn't work as the table close (|}) needs to be on a new line for wikitext
2. Template:nopt is an empty <span> when transcluded
3. 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

{{nopt}}
|-

• If a table continues onto the next page, close it on this page in the footer with

{{nopt}}
|}

• 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.

Inductiveload—talk/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

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)

 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? Inductiveload—talk/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 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

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

 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. Inductiveload—talk/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 https://phetools.toolforge.org/graphs/Wikisource_-_texts_en.svg 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

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: 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. Inductiveload—talk/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 ^_^. Inductiveload—talk/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

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

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

• petscan:18998946

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)

Sections

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

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

Recent changes

• Twinkle is a gadget on English Wikipedia. It can help with maintenance and patrolling. It can now be used on other wikis. You can get Twinkle on your wiki using the twinkle-starter GitHub repository.

Problems

• The content translation tool did not work for many articles for a little while. This was because of a bug. [2]
• Some things will not work for about a minute on 5 May. This will happen around 06:00 UTC. This will affect the content translation tool and notifications among other things. This is because of an upgrade to avoid crashes. [3]

Changes later this week

• Reference Previews will become a default feature on a number of wikis on 5 May. This is later than planned because of some changes. You can use it without using Page Previews if you want to. The earlier plan was to have the preference to use both or none. [4][5]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 May. It will be on non-Wikipedia wikis and some Wikipedias from 5 May. It will be on all wikis from 6 May (calendar).

Future changes

• The CSS classes .error, .warning and .success do not work for mobile readers if they have not been specifically defined on your wiki. From June they will not work for desktop readers. This can affect gadgets and templates. The classes can be defined in MediaWiki:Common.css or template styles instead. [6]

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

15:43, 3 May 2021 (UTC)

Philosophical Transactions of the Royal Society A – Volume 184

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

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?

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". Slowking4 亞 Farmbrough'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

⧼error⧽ undefined cURL error 60: SSL certificate problem: certificate has expired (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)

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)

Done confirmed. Ankry (talk) 11:38, 6 May 2021 (UTC)

Text in both margins

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. Slowking4 亞 Farmbrough'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

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)

 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. Inductiveload—talk/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. Inductiveload—talk/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)

 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 -- Slowking4 亞 Farmbrough'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

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. Slowking4 亞 Farmbrough'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)

 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

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

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 May. It will be on non-Wikipedia wikis and some Wikipedias from 12 May. It will be on all wikis from 13 May (calendar).

Future changes

• You can see what participants plan to work on at the online Wikimedia hackathon 22–23 May.

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

15:10, 10 May 2021 (UTC)

Wikidata integration

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

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! Inductiveload—talk/contribs 01:05, 13 May 2021 (UTC)

Use of notes= for annotations

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

Tracked in PhabricatorTask T284627Resolved

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)

 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. Inductiveload—talk/contribs 09:13, 28 May 2021 (UTC)

 Support, 10-20 seems like the right range to me. — Dcsohl (talk) 15:12, 28 May 2021 (UTC)

 Support, I would prefer something in the middle of the range mentioned above. Beeswaxcandle (talk) 19:47, 28 May 2021 (UTC)

 Support Tommy J. (talk) 23:50, 28 May 2021 (UTC)

 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)

 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 = 10 — billinghurst sDrewth 14:25, 3 June 2021 (UTC)

Closing and lodged phabricator:T284627 ticket. — billinghurst sDrewth 07:40, 9 June 2021 (UTC)

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

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. Inductiveload—talk/contribs 19:31, 11 May 2021 (UTC)

 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. Inductiveload—talk/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

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)

resolved — billinghurst sDrewth 11:03, 13 May 2021 (UTC)

Lower case naming of book by myself

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 :) Inductiveload—talk/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:

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. Inductiveload—talk/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). Inductiveload—talk/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 https://archive.org/download/macliseportraitg00macl_0 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. Inductiveload—talk/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

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)

Removed the "proposals" hatnote from Wikisource:Annotations

The document has been long in place and been pointed to and treated as de facto policy for an extended period, and not been targeted to be removed. So I have removed {{proposal}} which allows it to be a clear guiding document. If there is any dissent, then please revert that edit, and tell us what is clearly problematic with the document and how it should be otherwise actioned. Thanks. — billinghurst sDrewth 10:04, 12 May 2021 (UTC)

Thanks a lot, billinghurst, you have asked if I have an other point of view to add to this discussion. Well, my point of view is: Wikisource:Annotations is exactly what I would have liked to write myself!

I am translating it now into French in order to complete it with French wikisorcerers' additions, if any, to the French Wikisource corresponding page, and will tell you of the result.

Many thanks and many regards here,

--Zyephyrus (talk) 19:58, 14 May 2021 (UTC)

Then I am confused Zyephyrus. If you think that it is okay, why shouldn't we remove the proposal tag, and accept it as our current official guidance? — billinghurst sDrewth 00:54, 16 May 2021 (UTC)

Old English texts: potential for a project?

I've been looking at the English literature portal and it looks like there could be a project to input pre-1926 editions of Old English works on Wikisource. There ought to be a Portal for OE literature which can list all the texts already uploaded; then, the aim of the project would be to input at least one edition for each text. Lists of texts of the OE corpora can be found in the respective poetry and prose category templates on Wikipedia. A lot of these are available in HathiTrust, but there is no one readable (as opposed to purely searchable) corpus of Old English works

The Category 'Old English works' is also a hodge-podge of editorial anthologies, translations into 'revived' Old English (which don't seem to be indicated as such as to distinguish them from real historical documents) and unsourced, contextless poems. So another aim of the project would be to reorder the portal along the lines of the Wikipedia template (i.e. organised on a thematic, historical or Manuscript basis).

Thoughts? —unsigned comment by Rho9998 (talk) .

@Rho9998: Wikisource:WikiProjects are able to be started by anyone; they are coordinating hubs for people of like interests. Help:Portal will guide you on portals, and they are generally aligned with a subject, so no issue from my PoV. For us categories are generally less populated than elsewhere, so we tend to not drill down too far until truly required—lots of near empty categories aren't useful. I would rather see 1 category of 40 items, than 20 categories of 2 items. Also noting that Category:Bright's Anglo-Saxon Reader additions is not usual for us, we tend to only categorise the root page in such a circumstance. A WikiProject is a great space to discuss and coordinate categorisation for such a subject. — billinghurst sDrewth 06:45, 17 May 2021 (UTC)

@Rho9998: I think an Old English Wikiproject is a great idea. The Old English section of Portal:English language certainly needs expanding, and if it expands over, say, 10 items, or gets thematic or other divisions, Portal:Old English should probably be created (containing both literature and language unless those need further splitting, which I think is unlikely for now). It's certainly odd that we have Portal:Old Norse literature but nothing at Portal:Old English!

I have no domain knowledge of Old (or Middle) English, so I can't do much other than provide moral and technical support, so you'll have to do the subject legwork (or find someone who does know their thorn from their wynn to help!)

If you choose a fairly "easy" text (one that doesn't need too much esoteric formatting or detailed domain knowledge of Old English, and is fairly short), it could also be a candidate for the Wikisource:Monthly Challenge.

If you would like a text or two from Hathi, let me know. If you want a lot of texts from Hathi, that's OK too, but I'd like some information from you in that case. Inductiveload—talk/contribs 09:07, 17 May 2021 (UTC)

@Billinghurst: @Inductiveload: I've made a draft of Portal:Old English on my user page; there's more texts in Category:Old English works than there are in Portal:English literature, so I think that it meets the criteria. As regards monthly challenge, I'm sure most of the texts will be easy enough to copy if anyone knows some way of shortcutting ash (æ), thorn (þ) and eth (ð) in the editor. Most editions put wynn (ƿ) as 'w' anyway, so no problem there. If I were inputting I'd also not copy the macrons as (1) this is difficult to input and (2) they were not used in the Anglo-Saxon era anyways. Personally, I wouldn't see a problem omitting the macrons consistently (and perhaps accompanying this with a note at the start of the Wikisource version), but then I'm not fully versed in copying best practices. I also have access to Hathi, but I'm not familiar with adding the scans and also even if the book is in the public domain, I'm sure Hathi still reserve copyright on the scan itself, except for those texts accessible without login? Finally you're right to say I'd need the involvement of others who know a bit about OE literature, regardless of whether non-specialists can also participate in the project, to discuss decisions like omitting the macrons. Rho9998 (talk) 12:13, 17 May 2021 (UTC)

@Rho9998: The draft looks pretty good in general. I'd just put it in place and it can tweaked in situ.

This is the kick up the backside I need to add an Old/Middle English section to the Wikieditor toolbar (some of the characters are in the Latin section, but they're all mixed up). I'll get back to you about that, but in the meantime if you can make me a list of all the characters you might need and drop it on my talk page, that would be great.

Re macrons: in general we'll be proofreading from a scan of something. If that uses macrons, so do we. If if does not, we do not.

Re Hathi copyright: even if the claim copyright, they don't actually have copyright. At least in the US where w:sweat of the brow doesn't hold, and that is what matters at English Wikisource. Commons concurs on that, so there's no problem uploading Hathi documents to there, as long as they are out of copyright in the country of origin and the US. If only in the US, they come here until they can be moved to Commons.

If you can find the same scan on the Internet Archive, that's usually better because it's much much easier to import scans from there anyway. Inductiveload—talk/contribs 12:24, 17 May 2021 (UTC)

Tech News: 2021-20

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

Recent changes

• There is a new toolbar in the Reply tool. It works in the wikitext source mode. You can enable it in your preferences. [7] [8] [9]
• Wikimedia mailing lists are being moved to Mailman 3. This is a newer version. For the character encoding to work it will change from UTF-8 to utf8mb3. [10][11]
• An earlier issue of Tech News said that the citoid API would handle dates with a month but no days in a new way. This has been reverted for now. There needs to be more discussion of how it affects different wikis first. [12]

Changes later this week

• MediaWiki:Pageimages-blacklist will be renamed MediaWiki:Pageimages-denylist. The list can be copied to the new name. It will happen on 19 May for some wikis and 20 May for some wikis. Most wikis don't use it. It lists images that should never be used as thumbnails for articles. [13]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 May. It will be on non-Wikipedia wikis and some Wikipedias from 19 May. It will be on all wikis from 20 May (calendar).

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

13:49, 17 May 2021 (UTC)

Overheard

About a month ago, I was in a meeting with some other WMF folks, and one said:

"Wikisource editors, to me, are heroes."

Unfortunately, I forgot to write down who said it, so I can't give proper credit, but I did want to let you know that your work is appreciated. Whatamidoing (WMF) (talk) 22:54, 17 May 2021 (UTC)

Announcing w:Template:Cite Q does Wikisource connections

It has been a long time in the waiting, however, this Wikidata-populated template cite Q now will automatically link to English Wikisource if you populate Wikidata appropriately.

Example: enWS—Abbott, Leonard Dalton <=> WD—Abbott, Leonard Dalton (Q106554722) <=> enWP—w:Leonard Abbott
Usage: {{cite Q|Q106554722}}

Thanks to Pigsonthewing and Mike Peel for their coding and time to get this implemented at enWP.

We need to find a good place to notate this for local usage. One place we should be adding it is to Wikisource:for Wikipedians though there should be other places locally. — billinghurst sDrewth 13:48, 18 May 2021 (UTC)

Woman in Art

This book is listed with a year of 1900. I knew this to be incorrect, as I have observed numerous later (pre 1926) dates being mentioned in the text while proofing it. Now on page 175 I see the date 1927 mentioned. Is this work now a copyright violation, and if so does it need to be withdrawn from the site? If so can the work I have already done be archived until it becomes out of copyright? Thanks Sp1nd01 (talk) 21:46, 13 May 2021 (UTC)

@Sp1nd01: there's no date, publisher or location mentioned (WorldCat agrees). This copy was signed by the author in 1930, so that puts it c. 1927–1930. And since Armstrong was American and presumably this is an American book (also considering the WorldCat holdings are all in the US), and there's no copyright notices, I think it would be covered by {{PD-US-no-notice}}. Inductiveload—talk/contribs 21:57, 13 May 2021 (UTC)

Great, thank you for checking it out! I'll continue working on it unless told otherwise. Sp1nd01 (talk) 22:15, 13 May 2021 (UTC)

yeah, the place to raise copyright is on commons, licensed as PD US no notice [14] - there are no easy formulas about copyright. berne might think so, but CC is blowing a hole in it. Slowking4 亞 Farmbrough's revenge 00:51, 19 May 2021 (UTC)

Template:author link and shortcut => substitution

I am asking that we reconsider how we use Template:Author link and its shortcut {{al}}. The template makes disambiguation (automatic / semi-automatic / tools) more difficult so I would like for us to consider either making it a requirement to substitute it or we have a process to go through and substitute it by bot. — billinghurst sDrewth 01:04, 14 May 2021 (UTC)

I've never been quite sure what itch this template scratches. Simply a typing aid? Inductiveload—talk/contribs 08:25, 18 May 2021 (UTC)

Yeah. You could of course hang lots of extra stuff onto it ({{wdl}}-like or microformats etc.), but so far as I know it serves no other purpose than convenience. On the flip side, it does generate a WhatLinksHere-listed wikilink, so I'm not sure I buy that it significantly complicates automated tools. It will generally be easier to deal with than plain wikilinks because it has more limited allowable syntax. Xover (talk) 08:35, 18 May 2021 (UTC)

Well, w:Wikipedia:Tools/Navigation popups doesn't work on it, it doesn't handle the template. Most of the existing disambiguation tools/scripts seem to be looking for square brackets. In AWB it adds more complexity to all disambiguation code as you never know whether it is one or two parameters, so never know whether to code for a pipe or curly bracket, and with possible long lines the regex can run for ages for the next of the type. If it was limited to author or portal namespace it wouldn't be as problematic but page ns is a nightmare. So I would much prefer that if we need WDL type, that we wrap them, not embed the code. — billinghurst sDrewth 15:57, 18 May 2021 (UTC)

@Inductiveload: I am guessing that it is lack of toolbar button, the convenience of "al" in combination of not knowing of the "w:Help:pipe trick". For me having a toolbar button for [[author:+|]], and wrapping [[Author:Charles John Huffam Dickens|]] outputs [[Author:Charles John Huffam Dickens|Charles Dickens]] makes it easier for me than any typing of curly brackets, letters and pipes. — billinghurst sDrewth 16:06, 18 May 2021 (UTC)

Tolstoy (Wiener)...

We seem to have 2 incomplete sets:-

• Template:The complete works of Count Tolstoy volumes (As PDF)
• Template:Works of Tolstoy (Wiener) (As DJVU)

Can someone make a decision and upload one complete set in a consistent format? Thanks :) ShakespeareFan00 (talk) 10:01, 17 May 2021 (UTC)

I tried to make a complete set of PDFs, but Beeswaxcandle deleted the duplicate PDFs. Languageseeker (talk) 20:06, 17 May 2021 (UTC)

Are they complete between the two sets? If so, then sort the templates so there is one that points to both sets. The pdf versions that I deleted were the more recent upload. And minimal or no work had been done on them, while there had been some work on the DjVu versions. Beeswaxcandle (talk) 05:50, 18 May 2021 (UTC)

FYI, I have moved v2 to the PDF (was marked for speedy). The DJVU was missing pages, so the scan would have needed fixing anyway. Inductiveload—talk/contribs 08:24, 18 May 2021 (UTC)

Volume 12 is identical between the PDF and DJVU, I checked the pagelist , so can be migrated. I will check the remaining DJVU later. ShakespeareFan00 (talk) 09:29, 18 May 2021 (UTC)

Volume 17 is not identical. The difference seems to be some pages at the front. I've not found a content difference as suchShakespeareFan00 (talk) 09:38, 18 May 2021 (UTC)

Migrating The Warden to The Warden (Trollope) for disambiguation

There exists another work of the same name: The Warden (Coleman), a poem which can be found at the page Songs and Sonnets (Coleman)/The Warden. @Billinghurst, @Inductiveload: Could one of you mass-migrate the chapters so this could be disambiguated? Thanks. PseudoSkull (talk) 17:02, 18 May 2021 (UTC)

moved chose a variation of the name, and disambiguation page is at Warden. — billinghurst sDrewth 04:02, 19 May 2021 (UTC)

Move The Sanctuary to Sanctuary

Most of the works listed at The Sanctuary actually have the title "Sanctuary" except one of them. Could the disambiguation page be moved by an admin to Sanctuary for better titling? PseudoSkull (talk) 17:03, 18 May 2021 (UTC)

Done per request, though I'm not an admin. Seemed uncontroversial. -- Mathmitch7 (talk) 18:31, 18 May 2021 (UTC)

Yes, that is our preferred location anyway. Do note that you can use intro to suggest variations of title that are there. — billinghurst sDrewth 04:03, 19 May 2021 (UTC)

Who are the Election Volunteers in your community?

Do you want to be an Election Volunteer?

Would you like to get more people taking part in the Wikimedia Foundation’s Board of Trustees election?

The Wikimedia Foundation Board of Trustees announced the plan for the 2021 Board elections. That plan includes outreach and communication support for the Board elections. The Board election facilitators will:

• Inform communities of the trustee selection process
• Invite communities to engage in voting
• Encourage people representing emerging Wikimedia communities to run as candidates

Voter turnout in prior elections was about 10% globally. It was better in communities with volunteer election support. Some of those communities reached over 20% voter turnout. We know we can get more voters to help assess and promote the best candidates, but to do that, we need your help.

We are looking for volunteers to serve as Election Volunteers. Election Volunteers should have a good understanding of their communities. The facilitation team sees Election Volunteers as doing the following:

• Promote the election in their communities’ channels
• Organize discussions about the election in their communities
• Translate messages for their communities

Who are the Election Volunteers to connect your community with this movement effort? Is it you? Or someone you know? Check out more details about Election Volunteers and add your name next to the community you will support in this table or get in contact with a facilitator. We aim to have at least one Election Volunteer for Wiki Projects in the top 30 for eligible voters. Even better if there are two or more sharing the work.

Best, JKoerner (WMF) (talk) 18:04, 21 May 2021 (UTC)

Interaction ban with billinghurst

Frankly, I've had enough of billinghurst. billinghurst is removing content that I've created and is generally behaving like a rude and threatening administrator. So I am asking for an interaction ban with billinghurst. If billinghurst has a problem with my edits, I politely request that billinghurst request another administrator to step in and review them. Languageseeker (talk) 12:33, 19 May 2021 (UTC)

Well how about you edit according to the style, rather than thinking that everything is subservient to your project. Template:New texts has a format and direction, and you are expected to use it, not create your own style without consulting with the community. Author pages have a style, and not to be made into an holy mess solely for the benefit of your project. If you wish to change the style, start a conversation with the community. I am doing nothing but putting things back to the determined styles. — billinghurst sDrewth 12:39, 19 May 2021 (UTC)

my - that did not take long. this is a pretty friendly project (see accolade above) and billinghurst is a pretty friendly admin. (i have a "rude and threatening" list and he is near the bottom i have seen far worse rudeness by far higher functionaries, and far worse abusive conduct.) trying to follow community norms is a happier practice. you might not like how the other admins treat you. Slowking4 亞 Farmbrough's revenge 15:28, 19 May 2021 (UTC)

I don't think the comments that billinghurst left on my talk page, namely You are leaving spots of crap all over the place and Don't play games with me, would be considered friendly. Languageseeker (talk) 16:50, 19 May 2021 (UTC)

You are leaving spots of crap all over the place. Everywhere I look I find your edits that look like bird crap under a tree that someone needs to go and clean away. Your quality control is rubbish. You talk a great game, and then come up hugely short on the action. Here is this moments examples

• Hamlet, Second Quarto (Folger Shelfmark: STC 22276)
• Hamlet, Second Quarto (Huntington Shelfmark: 69305)
• Hamlet, Second Quarto Variant (British Library Shelfmark: C.34.k.2)
• Hamlet, Third Quarto (Bodleian Shelfmark: Arch. G e.13)
• Hamlet, Third Quarto (British Library Shelfmark: C.34.k.4)
• Hamlet, Third Quarto (British Library Shelfmark: C.71.b.2)
• Hamlet, Third Quarto (Edinburgh Shelfmark: JA 3734)
• Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 2
• Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 3
• Hamlet, Third Quarto (Huntington Shelfmark: 69306)
• Hamlet, Third Quarto (Huntington Shelfmark: 69307)

... Some of this was done a month ago, and I will be able to unearth more pretty easily.

So I cannot talk to you about this, I am not allowed to clean it up, and I have to talk to another admin about it. You have to be kidding! So I have a better plan: lift your game. Edit according to our styles, do not leave crap, do your quality control. Stop treating this place like a door mat.

With regard to my pugilism. I have tried being nice with you, and I have tried being collegiate, it doesn't work. You reverted my clean up on template:new texts with the temerity to say "There is no community consensus for this change. Please discuss it at the Scriptorium first." when it was your additions that were outside the norm, and which you had had zero discussion, and the instruction on the page is pretty clear on what is in scope on the page. So you will get "don't play games with me" if you try and play games with me.

I am big on consensus, and I abide by the consensus whether I agree with it or not. I edit to our consensus as comes through our guides or as discussed here. I fix up people's bird droppings without much complaint. I discuss on their talk page, I don't make big hullaballoos, and parade people in front of the community for their mistakes. However, when some people like to think their individual style trumps the community's and when they are asked politely to review their edits, and I get the passive aggressive metaphorical middle finger, I will not take that one. — billinghurst sDrewth 01:57, 20 May 2021 (UTC)

you have not tangled with admins. they tend to drag you to a drama board, where they talk about you as a problem user, with a block, and a demanded apology. they are vindictive, and bear false witness. but yrmv. Slowking4 亞 Farmbrough's revenge 23:45, 19 May 2021 (UTC)

Looking at the contributions highlighted by billinghurst, I don't see any "false witness" being borne here. The criticism of the editor's contributions is spot-on. Big blocks of unformatted text for what should be indicated in the format of a play. BD2412 T 02:11, 20 May 2021 (UTC)

glad you agree. it is important to contrast the situation here where it is a dispute about quality of work and community norms, and elsewhere, where there are false claims of legal threat, false claims of personal attack, false claims of non-notability, and false clams of plagiarism. Slowking4 亞 Farmbrough's revenge 13:39, 22 May 2021 (UTC)

"Hamlet, Second Quarto (Folger Shelfmark: STC 22276)"? "Hamlet, Third Quarto (Bodleian Shelfmark: Arch. G e.13)"? "Hamlet, Third Quarto (Folger Shelfmark: STC 22277) Copy 3"? Holy cow! I've seen some horrid examples of titling before on Wikisource but this probably takes the cake out of all of them. First of all, nowhere in the titling conventions does it ever mention these weird library ID things you put in there, and for good reason. Look at it: I don't want to have to know some weird code language to find what I'm looking for on a wiki where titles are supposed to be relatively simple enough to be coherent to the general public...

As far as the content goes: I think Billinghurst's complaints are totally reasonable and I'm not even sure what you're trying to accomplish with these. Looks to me like they're some way of treating the mainspace like a draft space maybe, which is not what the mainspace is for on any wiki including this one. The mainspace is for finished pages, not incomplete and unformatted works. We have enough of those already as it is, and we certainly don't need more, that are copied several times over with different titles for each instance.

I'm only addressing what was presented to me in this discussion, but as I'm sure as people have been implying that there's been a deeper problematic past, I  Oppose the interaction ban and support any efforts to delete the clutter listed above. Why slow down the process of getting rid of, or fixing, bad content by implementing an interaction ban with a certain admin who was dealing with it a lot, when we could just not do that and have a better time? If it were me in his position I would be speedying these pages right now as blatant violations of consensus. PseudoSkull (talk) 05:22, 20 May 2021 (UTC)

Thank you for drawing my attention to this list. I have speedy deleted them all because they are text dumps from a site that states "creative commons - non-commercial". We don't accept works under the NC variant here. If there are other such dumps on any of the other 38 plays, please tag them for Speedy Deletion (G6). Beeswaxcandle (talk) 09:17, 20 May 2021 (UTC)

The Hamlet texts came about because Billinghurst decided that ext and small scan links did not belong on the Hamlet page and removed all non-transcluded links from the Hamlet page. This triggered an edit war with EncycloPetey. Billinghurst informed me then that I could not post an ssl unless I already had a text in ns. Since the text was the proofread text of a PD source, I think that sweat-of-the-brow still appears. However, if you believe that a text from the sixteenth century is in copyright, then I will not challenge that decision. Languageseeker (talk) 12:09, 20 May 2021 (UTC)

So it is all my fault that you pasted rubbish text into pages. Right. I stood over you and twisted your arm, and held your cat hostage. I can see me there, standing over you. "Contribute the Hamlets, or the pussycat gets it." For goodness sake, what is wrong with this picture? — billinghurst sDrewth 13:43, 20 May 2021 (UTC)

I'm intentionally not commenting on the behavioral issues here, but assuming that the deleted pages above were in fact transcripts of scans of really old quartos of Shakespeare plays, without any modern annotations, they're in the public domain regardless of what the license says. See c:Commons:When to use the PD-scan tag for how they deal with it; I can't find any Wikisource policy in favor of respecting copyfraud claims. Vahurzpu (talk) 19:09, 20 May 2021 (UTC)

<sigh> I did not state that these were copyright nor do I support any copyfraud claims. An example of the original of the pasted text-dump is here. All the content of the page was pasted here including the preliminary guff, the annotations of the annotations, page headers, &c. &c. In that state, the page here was useless and contained material that we cannot host. Ergo, it was deleted. The reason for using G6 is simply that that is the best option when there is modern material on a page. Beeswaxcandle (talk) 20:20, 20 May 2021 (UTC)

• A word of caution for those responding. The account Slowking4 has stated they maintain an ordered list of admins, their grievances with process, a provocative tag in their signature, please also note this list https://en.wikisource.org/wiki/Special:CentralAuth/Slowking4 and reasons given for community actions at other big sister sites. CYGNIS INSIGNIS 03:00, 21 May 2021 (UTC)

  I thought it was metaphorical speech, and if it is, how about we just remove those bits for clarity. — billinghurst sDrewth 03:17, 21 May 2021 (UTC)

  there nothing provocative in knowing Rich Farmbrough, and viewing his treatment on english as an injustice. the mis-governance of that wiki is an open scandal, and outsiders are astonished. but let the fate of both of us be a warning to any who dare cross an admin anywhere. maybe you need a slowking warning template like "mad, bad, and dangerous to know" Slowking4 亞 Farmbrough's revenge 01:44, 22 May 2021 (UTC)

  When did you become aware of those bans? CYGNIS INSIGNIS 03:35, 21 May 2021 (UTC)

  Pinging @Billinghurst:, my question was smothered so notifying you I had a question. CYGNIS INSIGNIS 06:16, 21 May 2021 (UTC)

  @Cygnis insignis: Bans? I cannot say I have specific *knowledge* of any local bans external to this wiki with regard to any individual. Any other comment does not belong in this topicked conversation, though I am happy to answer on your or my talk page, or a pertinent conversation of the community. — billinghurst sDrewth 07:48, 21 May 2021 (UTC) And to add some openness ... my Special:CentralAuth/Billinghurst and xtools:ec/en.wikisource.org/Billinghurst — billinghurst sDrewth 08:18, 21 May 2021 (UTC)

  Billinghurst may have forgotten, but does have knowledge of a least one individual that have been banned elsewhere and welcomed here, although it was a long time ago it's sure I have not forgotten. Billinghurst or any user in good standing may request a diff here, but preferably offline to avoid further drama and 'not feeding of … ". CYGNIS INSIGNIS 11:08, 21 May 2021 (UTC)

  I said specific knowledge, and for me that would be about a formal ban motion of a community. And I am struggling to see the relevance of the point in this topic, and wondering where this fork is going, and how it is relevant. Not into playing gotcha. — billinghurst sDrewth 15:31, 21 May 2021 (UTC)

  the vindictiveness towards users that may be "banned" elsewhere: “C'est pire qu'un crime, c'est une faute”. [15] Slowking4 亞 Farmbrough's revenge 02:13, 22 May 2021 (UTC)

I understand that you might not find all of my contributions up to your standard and that I have made mistakes. However, you, billinghurst, are an administrator. That means that you have an immense amount of power on this site. The kind of speech that you use would not be acceptable by a regular user. Nor does it conform to standard of civility. You can mock the Hamlet case, but you decided, without community consensus, to remove all the external scan links, links to indexes, and red links on that page. Languageseeker (talk) 03:43, 21 May 2021 (UTC)

• The contributions of this user seems to be invoking bots or making edits that could be done by the same, generating the discussions they have stated they wish to engage in. They do not respond to any concern raised in those previous discussions, it seems they write more comments more than read and that is becoming increasingly looking like NOT HERE to improve our works. CYGNIS INSIGNIS 06:10, 21 May 2021 (UTC)

(outdent)  Comment You started this conversation, and I responded in what I am trying to do to bring your edits to a standard and to our style. So please stop trying to divert the conversation to it being my fault that I fix and highlight to the individual poor editing, or non-use of the style guide. [PLUS you do not get to re-prosecute the case, nor try to re-frame it when it is clear above that is not the situation.] And thank you for talking about Wikisource:Adminship, you will see that I am doing what it requires of administrators, and access to tools. I especially like this line Follows established Wikisource policy and guidelines. FWIW the only power that I have is the power of argument and experience, that does not come from the tools. — billinghurst sDrewth 08:09, 21 May 2021 (UTC)

I've been following this discussion from a distance, both here on the Scriptorium and (to a small degree) through some of the interactions that preceded it. My general sense is that both Billinghurst and Languageseeker have a great deal of knowledge and good will toward the purpose of Wikisource, but that each each has in some cases fallen short of expressing themselves with enough clarity, equanimity, or context to support the possibility of working together effectively. I agree with others in this thread that an interaction ban is not at all appropriate to this situation; and to the extent that this discussion was started with that narrow goal, it seems to me it'd be in everyone's interest to close this discussion ASAP, as it seems everybody is in agreement about that. Beyond that narrow decision, I think that if either Billinghurst or Languageseeker wants their interactions to get better, there are many things either one of them could do that would support that. I tend to agree that it's more incumbent on Billinghurst, who occupies an important position of trust, to do that; but also, he doesn't have an easy task. To both of you, I'd urge you to find ways to talk more clearly about your broader goals (my sense is that in both cases you have uncontroversial, good, and insightful goals motivating what you do here, if only others could see what they are) and be in less of a hurry to get specific outcomes. -Pete (talk) 19:14, 21 May 2021 (UTC)

RFC: External link styling nomenclature => some proposed changes

For quite a while we have utilised the following styles for link templates

• (work) lkpl (link plain) for shortened links (intrawork, interwork)
• (work) link (link) for full link with overt identification of the parent work

Inductiveload and I have found that there are some (old) templates that point externally, we renamed one to {{NYT ext link}} so that we could re-factor {{NYT link}}.

I am proposing that all our templates that are externally pointing utilise (site) ext link nomenclature. The exception to this is WMF wikis which have a separate functionality hopefully leveraging Wikidata, and Special:Interwiki. Not proposing to change {{ext scan link}}.

We need to do the separation to minimise confusing overlap, and happy to hear counter proposals. Unsure of the scope at this point, though think that is immaterial for the benefit. I am not asking anyone else to do the work, and would report back on what are the changes if the community agrees to progress. — billinghurst sDrewth 02:39, 21 May 2021 (UTC)

Fine by me, though I think it probably only have real value when the abbreviation (e.g. "NYT") could refer to an on-wiki title as well as an external site. For example, {{OCLC link}} doesn't seem to me to urgently need to become {{OCLC ext link}} (wrt the above, "OCLC lkpl" doesn't really make sense, so I don't see major scope for confusion). Though I wouldn't shed tears if it gain the "ext", so ¯\_(ツ)_/¯. Inductiveload—talk/contribs 23:50, 21 May 2021 (UTC)

I would prefer to see that one just disappear. OCLC linking is better through {{authority control}}. Seems that maybe a list brought here may be useful. I know that we have {{ADB link}} and it is thinks like that and certainly anything that is amibiguous. — billinghurst sDrewth 00:26, 22 May 2021 (UTC)

Category:External link templates holds those that we have categorised; list unaudited. — billinghurst sDrewth 01:06, 22 May 2021 (UTC)

oclc is better for work information, authority control better for author information. i would suggest restricting authority control to author page, and oclc to list of works, and work header. Slowking4 亞 Farmbrough's revenge 22:48, 22 May 2021 (UTC)

Scan Localisation Requests...

For those that don't necessarily follow WS:CV,

I had noted some scans that should be localised.

The expertise of other contributors in reviewing these items, so that a contributor or admin with appropriate tools can localise the works concerned.

The reason is that whilst the works are potentially PD-US (based on publication dates), there are not necessarily PD in their original country of publication, given any lifetime the author given ( or absence of that information.).

Once moved the discussions at WS:CV can be closed rapidly :) ShakespeareFan00 (talk) 14:09, 22 May 2021 (UTC)

WS:CV is for works that are copyright violations at enWS, not Commons, so I am not certain that listing works that need to be shifted at that place is appropriate. Maybe a subsection here, or maybe a section at WS:AN though it doesn't actually require admin permissions.

As commentary, shifting works locally from Commons is a bit of an UGH task at this time. pywikibot's script imagetransfer.py fails, in that it is won't ignore the existence of the file at Commons and won't force. Magnus's script at c:MediaWiki:ExCommons.js use to work though me fails in the oauth components and I cannot get MM's attention to resolve the issue. — billinghurst sDrewth 02:20, 23 May 2021 (UTC)

Second parameter of {{wikt}}

I'm working on a dictionary of foreign phrases, and I'm linking to Wiktionary whenever the page exists and has an entry in English or the language in question. I've found two phrases so far which vary slightly between the printed version and the Wiktionary page, so I tried to use the wt page as the first parameter in {{wikt}} and the alternate (printed) text as the second. The problem is that the template currently uses the second parameter to link to a language section instead of displaying alt text. I would argue that alt text is a more important feature for the template, but maybe it can be worked to have both. Can someone please help with this? Ultimateria (talk) 21:36, 22 May 2021 (UTC)

@Ultimateria: Please read Help:Wikilinks. It would not be usual for us to have pages with that many links externally to wiktionary. You don't need to use a template for a link you can simply use link syntax like [[wikt:target word|word]]. I would also argue that if you have a term of difference that under Wiktionary's approach that you are better to create the extra page, the variation, at Wiktionary. It is my understanding that they wish to capture such variations.

With such an approach I am also wondering whether it may be better aligned to using the Wikidata: lexeme componentry, rather than direct links to Wiktionary. @Jura1: would you care to add some informed comment? (not my speciality area) — billinghurst sDrewth 02:11, 23 May 2021 (UTC)

@Billinghurst: I promise I knew how to link, I just forgot! Thank you. I'd like to keep the links; this is a very concise dictionary and we can include much more information by linking to Wiktionary. I'm familiar with Wiktionary's redirect practice (which is extremely sparing), and I didn't explain that these two links are special cases, but one is a typographical variation we don't use, and the other is a rare variation of a phrase possibly made in error. Ultimateria (talk) 02:45, 23 May 2021 (UTC)

@Ultimateria:Sweet. One of the things that we have been considering/exploring recently is our management of interwiki links, especially in the modern day of wikidata, managing rotlink; annotating v. linking. Areas in which we are all learning, and trying balancing the impact. Never certain where to start an answer. — billinghurst sDrewth 04:13, 23 May 2021 (UTC)

Tech News: 2021-21

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

Recent changes

• The Wikimedia movement has been using IRC on a network called Freenode. There have been changes around who is in control of the network. The Wikimedia IRC Group Contacts have decided to move to the new Libera Chat network instead. This is not a formal decision for the movement to move all channels but most Wikimedia IRC channels will probably leave Freenode. There is a migration guide and ongoing Wikimedia discussions about this.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 25 May. It will be on non-Wikipedia wikis and some Wikipedias from 26 May. It will be on all wikis from 27 May (calendar).

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

17:07, 24 May 2021 (UTC)

RfC: Nomenclature for categorisation of person portal pages

Back to the people categorisation nomenclature ...

Background

Two previous nomenclature conversations about authors, and biographical works/entries

• Wikisource:Scriptorium/Archives/2020-05#Time to talk nomenclature of author classification by occupation
• Wikisource:Scriptorium/Archives/2020-09#Nomenclature of occupations

so authors pages are now "occupation as authors" and "biographies of occupation"

Top of the this part of the tree is {{:Category:Occupations]]

So where does the community wish for person portal pages to be categorised? To their own subcategory tree?, eg.

• Category:Biologists
  • Category:Biologists as authors [Author ns:]
  • Category:Biographies of biologists [Main ns]
  • Category:(something about portals and biologists) [Portal: ns]

or is there a wish to combine them with an existing category? Not categorise? Or just leave them at the Biologists level? There are will never be a lot, though it maybe look a little unusual.

If it is its own category, what do you wish to have it called?

• Portals of biologists
• Biologists portals (grammatically incorrect or we can add grammar)
• (your suggestions)

At this stage people portals are only generally only categorised to Category:People in portal namespace currently sitting in the 180s, and most through use of template:person (special:whatlinkshere/Template:Person) though not all. Still some transfers to do by anyone interested (petscan:19073593).

Thanks for your feedback. — billinghurst sDrewth 12:41, 13 May 2021 (UTC)

I did some transfers. Didn't encounter too many problems. Is it wanted to retain the old class hierarchy? I've kept them, but it is only possible to override the main class and the first subclass. See Portal:Francesca Cuzzoni. There is no support in {{person}} to override subclass2 (see Portal:Zacarias Moussaoui), or "parent" for that matter. It is possible to link a related portal with "portal" though.

I've also encountered one that should probably be merged? See Portal:Marcus Whitman. --Azertus (talk) 12:43, 25 May 2021 (UTC)

@Azertus: Thanks. I don't know enough to even start talking classes, out of my pay grade. With regard to Whitman, just merge the content and then replace the portal page with a substituted {{dated soft redirect}}. — billinghurst sDrewth 15:01, 25 May 2021 (UTC)

Broken renewal links

Do records in https://exhibits.stanford.edu/copyrightrenewals get automatically removed after some time (or when the copyright/renewals expire)? Links to these records can be added to pages with the {{copyright renewal}} template, itself used by {{copyright-until}}. I've noticed that all those links on Author:Arthur Josephus Burks are broken, e.g. https://exhibits.stanford.edu/copyrightrenewals/catalog/R107985 Of course I realise that once the copyright *and* the renewal have expired, there's no point in keeping them, except for historical purposes and verification.

I've downloaded the full data set for the Copyright Renewals Database and there is no trace of the IDs from the Burks page (e.g. R107985). @Fenrix1958: do you know more about this? All in all, I'm just curious... --Azertus (talk) 13:29, 26 May 2021 (UTC)

The problem here is that the renewal is actually for a periodical (Weird Tales), so it's listed in a different part of the copyright register: https://archive.org/details/catalogofcopyrig372libr/page/182/mode/1up?view=theater. The Stanford database only includes books, so this link never worked, it's just added automatically by {{copyright renewal}}, which can't tell a book's R-number from a periodical's. Possibly {{copyright until}} needs a parameter to link directly to some other resource.

Other periodical renewal volumes are listed here. Inductiveload—talk/contribs 08:59, 28 May 2021 (UTC)

Duplicate words

I have posted a list of duplicate words I found on validated pages at User:Мишоко/Duplicate words. Much work to be done for those interested. Мишоко (talk) 16:37, 23 May 2021 (UTC)

@Мишоко: Interesting! Could I ask how you generated this list? Downloading text over the API or some sort of DB query? Inductiveload—talk/contribs 13:09, 24 May 2021 (UTC)

I used the latest dump. "All pages, current versions only." 12GB uncompressed. Мишоко (talk) 15:35, 24 May 2021 (UTC)

It seems that people are applying different solutions to these problems. If the duplciation is in the source, and is an error, then I suggest at the the top (for example) should be marked up as at {{SIC|the the|the}} top. Some people have been tagging similar cases as "not done", and leaving the duplication in situ. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:29, 29 May 2021 (UTC)

Sure, if it is duplicated in the work it should be left in situ. Doing nothing with the work and marking as "not done" on the list is accurate; adding {{SIC}} is an optional means of handling it and is also accurate. To my way of seeing it, attending to the list as raised, marking its review is the matter for addressing the list.

If you wish to talk about the mandating of {{SIC}} for such situations, that is probably a different discussion. It was had when we introduced the template, and went from the invisible {{sic}} to the overt {{SIC}}; as well as the second parameter usage of the latter template.

If we are wanting to talk about whether we want to leave something in place for Мишоко's searches, we could also leave {{sic}} in place for the bot to note and skip. — billinghurst sDrewth 04:49, 30 May 2021 (UTC)

Tech News: 2021-22

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

Problems

• There was an issue on the Vector skin with the text size of categories and notices under the page title. It was fixed last Monday. [16]

Changes later this week

• There is no new MediaWiki version this week.

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

17:05, 31 May 2021 (UTC)

"by nationality" categories

Seeking feedback on how many author "by nationality" categories are necessary, and then the lower spread beneath those.

Here is what we have

• Category:Authors by nationality
• Category:Diplomats by nationality
• Category:Biographies of people by nationality
• Category:Poets by nationality
• Category:Philosophers by nationality
• Category:Scientists by nationality by field
• Category:People by occupation by nationality
• Category:Explorers by nationality
• Category:Politicians by nationality
• Category:Scientists by nationality
• Category:Soldiers by nationality
• Category:Songwriters by nationality
• Category:Civil servants by nationality

I can see the value in some of these especially as all authors would normally be added to a category below "Authors by nationality", but all of these seems like duplication.

I will also preface the commentary that something like category:Scottish philosophers‎ and its kin are ambiguous in title as they are author: ns pages only, and if we keep them they either need to be policed or renamed to indicate author only. Taking biographical entries down that far is also seems somewhat exceeding requirements.

Anyway, asking what the community is trying to achieve with that categorisation, and where we want to go with it. Thanks. — billinghurst sDrewth 00:07, 12 May 2021 (UTC)

I think any literary occupation naming a form listed in the Lib of Congress catalog could be useful, e.g. Poets by nationality (from Poetry), Orators by nationality (from Orations), Dramatists by nationality (from Drama), Novelists by nationality (from Novels). But do we consider "nations" to be the modern entity or the one that existed at the time the author was alive? This will have implications in cross-linking categories with Commons and Wikipedia. --EncycloPetey (talk) 21:50, 9 June 2021 (UTC)

Dissapointed...

I'm wondering if I should continue doing things here at all right now:- https://en.wikisource.org/wiki/Special:Contributions/ShakespeareFan00

When you've checked templates carefully SEVERAL times, and they still break it's time to go back to the LAST stable version obviously, which is what I've now had to do TWICE, despite checking everything VERY CAREFULLY, and STILL having thing explode in spectacular fashion.

I do not like wasting my time, and having Mediawika, the intircate nature of some templates and my apparent inexperience hamper my efforts i not conducive to continued contributions here.

Perhaps someone else can review the train-wreck of revisions of the templates concerned and figure out what ACTUALLY went wrong, but at present I am wondering why I should bother continuing to contribute, if I am not going to be able to rely on the kind of support that such efforts and expertise such efforts would seem to apparently need.

I would also strongly suggest given their widespread uses that the block of templates concerned are put under some kind of protection, so that a PROPER code review can take place rather than my completely incomeptent efforts. ShakespeareFan00 (talk) 19:41, 31 May 2021 (UTC)

i admire your attempts to make sidenotes work after being a mess for a decade. [17] i would suggest finding someone with some serious CSS skills (as mentioned by billinghurst some time ago [18] ) until we get a wishlist , or summer of code, it will be very frustrating, best to put on hold and spare the emotional energy. Slowking4 亞 Farmbrough's revenge 23:16, 31 May 2021 (UTC)

It happens. Sometimes you can spend hours working on something only to make it even more broken. It's not your fault, just a sign of the complexity of the issue. I've really valued your work here and would be greatly saddened to see you leave. Hang in there. Languageseeker (talk) 02:23, 1 June 2021 (UTC)

Strongly agree with the sentiments expressed, and have benefited from ShakespeareFan00's contributions elsewhere. Many have tried to make it work and watch it explode, previous experiments are useful when looking for a solution :) CYGNIS INSIGNIS 02:46, 1 June 2021 (UTC)

We need to set our criteria for what it is that we want. Left and right? How it works in each in display layout, and how we want it to work. How we expect it to work in mobile. How we expect to act when the sidenotes overlap. Until the criteria is determined nothing can happen. I still think that this is one for the wishlist. What you need to have is all the features and functional specificatiosns developed and ready to go. Leaving it all until there is a call-out is too late. @Whatamidoing (WMF): is there a product manager we could work with, or approach, to scope these needs so we have a good proposal ready to go at some point resources allow?

It should never stop you from proofreading the works now, as if the base templates are used, they become sandboxes for the developers. We need someone css clueful and timeful, who is separated from the works and will tell us how it will just have to be. And stamp their feet at us when we vary. Also recommend stop developing more templates to do this, keep it simple. The more complicating the factors that keep being introduced makes any translation to something CSS plug-in just makes it harder to migrate. — billinghurst sDrewth 04:04, 1 June 2021 (UTC)

@Billinghurst:. The plan was to update the sidenotes to use CSS classes for the defaults, which could be overridden by defining additional classes on a per work basis. Things like depth, size and alignment could then be set across an entire document (or CSS selector) instead of indvidually for each sidenote, which is the current approach. I was prior to my update attempts using an override approach (on the outer wrapper) here: Page:1751_A_collection_of_all_the_public_acts_of_Assembly,_of_the_province_of_North-Carolina_now_in_force_and_use.pdf/28 the relevant classes being Index:1751_A_collection_of_all_the_public_acts_of_Assembly,_of_the_province_of_North-Carolina_now_in_force_and_use.pdf/styles.css.

1. The reason sidenotes end up overlapping, is that without the override, position:absolute fixes the vertical position. Given the limitations of HTML/CSS when the relevant templates were implemented this approach was entirely reasonable. The floated/clear approach clear:left/right clears the overlap, (and I will note that in mainspace, a floated approach is essential what {{OutsideL}} and {{outsideR}} implement.). As the floated/clear approach required fixed margins however, it's not a universal solution. (Especially for works that do not have them). The classes in the relevant index only apply in Page: namespace so far, because of the different layouts, I am not sure it could be made to work for {{left sidenote}} and {{right sidenote}} universally, given the very different dynamic layouts. I've moved my efforts into Sandbox versions, that way any typos shouldn't 'leak' and it gives someone else a chance to look at the code BEFORE it goes live. (Aside: Is there a reason why for layouts, the relevant styles are set directly from code in the Mediawiki namespace instead of the code choosing to apply a 'relevant' stylesheet, which could be defined independently.?
2. It's currently tricky to handle the situation of a nil parameter passed (or not pasesd) from a higher template. I'm in the process of trying to sandbox in my userspace a possible approach to this.
   A construction |{{if:{{align}}|align={{{align|}}|...}} does not always reliably workas parameter passing logic to a lower level template from a higher level wrapper. One typical way of solving this to do just set a default anyway |align={{{align|value}}} being a typical usage. What I'd like to eventually do is something like <syntax highlight inline=yes lang="html">|align=@std</syntaxhighlight> as the paramater passing logic in the higher value template.
   That approach however make the lower level template a lot more complicated, as a switch function has to be used, to handle 'absent' ,'nil' and '@std' values that eventually reach it. I have however implemented @std like handling logic as a sub page of my userspace and would appreciate someone with more experience figuring out if it could be simplified. (see User:ShakespeareFan00/@std, User:ShakespeareFan00/@val and the testcases at the bottom of User:ShakespeareFan00/foo/testcases.ShakespeareFan00 (talk) 06:36, 1 June 2021 (UTC)

Stop. Take a step back. Get out of the operations. Until you have a picture of what it is that is wanted and needed (functional specifications) you are wasting breath telling about coding of templates, it is just code. You need a strategy before you have tactics. Until we have steady and complementary LAYOUTS, and a picture of what happens with sidenotes in each form of layout. What the form for mobile: do we keep them? do we stick them in front of paragraphs. Is it a case by case situation? So please provide no further detail of the guts of things. And yes of course it is a CSS class and style solution, as it is a CSS problem. — billinghurst sDrewth 07:18, 1 June 2021 (UTC)

What Billinghurst said. ⬆︎

The problem you're attacking is a big and complex one that interacts with just about every conceivable complicating factor: MediaWiki's capabilities, the active skin and its styling, the capabilities and limitations of templates, of ProofreadPage, the limitations of HTML and CSS, our community practices, the other technical bits and bobs on the project (like the dynamic layouts script), and even culture and community and other such human factors. You are not going to solve this "from the bottom up" by keeping banging your head against it: if it were solvable that way in practice, one of the geekier members of the community would very likely have done so already.

And because it is a big complex issue, the benefits of solving it have not yet been seen as sufficient to outweigh the effort involved. If you want to make any actual progress on this, starting from that end is where you can make headway. It may be almost as frustrating (just for different reasons), but it at least has a chance of eventually leading to a solution somewhere down the line.

And just for the record: I very much doubt that there is any perfect solution for this. The fundamental difference between a fixed paged media like a book and a dynamic non-paged media like the web means we are only ever going to be able to achieve approximations of various degrees of verisimilitude. Hyper-precise positioning of sidenotes relative to portions of the text, and without interfering with other page elements, is probably only going to be doable for something like 80% of cases; the remaining edge cases are going to have to suffer one tradeoff or another. Xover (talk) 08:06, 1 June 2021 (UTC)

Not that I actually care at this point, in the absence of someone providing an actual specification, but I took the attempted re-write into a sandbox, and after some careful rewriting I managed to get this Page:Sandbox.djvu/257, which addressed many of the objectives I was trying to achieve namely:

1. Avoid generation of unnecessary inline styles, by moving the default values to an appropriate CSS class ( In respect of the outer 'layout' wrapper this classing of the defaults had already been implemented by another contributor.) and only generating inline styles for non-default values.
2. Allow the 'default' settings to be updated by changing only the core template/stylesheet, as opposed to every template that might call the basic templates, and without needing to redundantly specify those defaults in other templates.
3. Allow sidenote layout/formatting to be separately configurable via CSS selectors in Indexstyles or other TemplateStyles.
4. Allow for specific classes of sidenote layout/formatting to be defined across a work without needing to specify values inline or without affecting a generic sidenote layout/format.
5. Eliminate the Page/Main namespace distinction as this can be done with an appropriate namespace selector in CSS.

What I had not yet implemented (as there are other workarounds) was:-

1. Allow sidenotes to act as link targets, by providing a way to set a sutiable anchor or ID for them. (This is so that the cl-act like anchoting on

Onoging issues:

1. Overlapping sidenotes.
2. Limitation of {{outside}} and {{outside2}} to 'default' "Layout 2" due to how they are currently implemented.
3. Other sidenote like marginal templates such as {{Outside}}, {{margin note}} {{cl-act}}} etc...

But as no-one has stepped forward to write a specification, I am not holding my breath for these to be fixed any time soon. ShakespeareFan00 (talk) 08:53, 2 June 2021 (UTC)

@Billinghurst: I'm not sure which team would be best, but let's ping @SGrabarczuk (WMF) for now, since he's been working with New Vector and therefore appearance-related stuff, and I'll go poke a couple of PMs to see which team they think it ought to be. Whatamidoing (WMF) (talk) 23:55, 2 June 2021 (UTC)

Also, @ShakespeareFan00, which skin are you using? I think @Xover is correct about the possibility of skin-specific difficulties. Whatamidoing (WMF) (talk) 00:09, 3 June 2021 (UTC)

The issue is not necessarily related to Skins. ( I think I am using Vector) It's mostly related to

• 'Dynamic layouts', a feature that's specific to English Wikisource (The current Dynamic Layouts are implemented in mainspace via Mediawiki:PageNumbers.js.)
• the 'paged' nature of content that Wikisource uses the ProofreadPage extension for.
• The lack of 'native' support for sidenotes in wiki markup/HTML/CSS.
• The differences between old-style print and online content.
• The (Pre|as)sumptions certain contributors myself included, have made about what's possible to do.

A very high-level requirement might read something like this : "Provide a mechanism to support side-noted content in a clear and unobscured manner, consistent with the intent of an original work, desirably reflecting stylistic choices made by the original authors, and allowing readers with differing devices to view them in a manner consistent and appropriate to the requirements of those devices or reader preference."

ShakespeareFan00 (talk) 13:02, 3 June 2021 (UTC)

Eek! I need to get back to AKJV where sidenotes are used *extensively*, and I'm hung-up with such problems as mentioned above - sidenotes overrunning each other.

Please ping me when y'all have proposals and possible code to try. Basically, sidenotes have to work for AKJV - sidenotes solutions have to work for AKJV - or we're just creating a different solution that can't be used in important works. Shenme (talk) 04:37, 9 June 2021 (UTC)

Categories for CC-BY and CC-BY-SA

I noticed that licenses CC-BY (CC attribution) and CC-BY-SA are categorized in Category:Works by license differently:

• For CC attribution, separate categories have been created, each version of license has its own category: Category:CC attribution 2.0, Category:CC attribution 3.0 etc.;
• For CC-BY-SA works, one combined category exists: Category:Creative Commons BY-SA, undivided for different versions (2.0, 3.0, etc.).

Could someone explain — is there any specific reason for such distinction in categorizing of these types of licenses, or this difference has occured accidentally, without any intent? This information may be helpful for me, because I am intending to create category (or categories) for CC-BY on the multilingual Wikisource, currently it have category Creative Commons BY-SA, and I want to create similar category for CC-BY (CC attribution) as well.

Also, additional question: on the top of the Category:Creative Commons BY-SA there is a statement: "These works are released under a Creative Commons BY-SA license, including the Creative Commons Attribution-ShareAlike 2.0, Creative Commons Attribution-ShareAlike 2.5, and Creative Commons Attribution-ShareAlike 3.0 Unported licenses...", but license Creative Commons Attribution-ShareAlike 4.0 is not mentioned there; does it mean that CC-BY-SA 4.0 works are prohibited on the English Wikisource? --Nigmont (talk) 04:34, 20 May 2021 (UTC)

@Nigmont: I would think that it is an even simpler explanation, in that they have not been updated sincee 4.0 came out. We have and allow 4.0, see Template:CC-BY-SA 4.0. Feel free to update the text to be aligned with the reality. — billinghurst sDrewth 13:35, 20 May 2021 (UTC)

Alright, thanks! So I added an entry about CC-BY-SA 4.0 into the list of licenses of the category description. Meanwhile, the English Wikisource currently does not have a page describing CC-BY-SA 4.0 (which older CC-BY-SA licenses have, for example Creative Commons Attribution-ShareAlike 3.0 Unported), so I was forced to link to the Creative Commons page instead of linking to a Wikisource page. --Nigmont (talk) 03:10, 15 June 2021 (UTC)

In addition: why ever did I think that CC-BY-SA 4.0 might be prohibited on the En-WS: I had seen somewhere (maybe on the multilingual Wikisource, maybe on the Commons) that somebody said that only CC-BY-SA 3.0 was allowed (amongst CC-BY-SA licenses) on the Wikisource, and CC-BY-SA 4.0 is incompatible with 3.0 and so far it is prohibited, and a work licensed with CC-BY-SA 4.0 should be banned from the mul-WS. May be, that opinion ot that user had been inspired by absence of mentioning of CC-BY-SA 4.0 on the English Wikisource. :) So, such things as forgetting of mentioning of full sets of available licenses should not be taken too frivolous, because failing to do that may lead to dramatic conclusions. :) --Nigmont (talk) 03:29, 15 June 2021 (UTC)

Browser rendering question/survey

I have run into an issue which might indicate a browser compatibility issue with our most common font size templates. Could people please check the following against this screenshot:

foo
bar

Specifically, please comment if:

• you see the words "foo" and "bar" substantially closer together than in the screenshot, or
• you see the same thing as in the screenshot and you run Windows and use any version of Firefox.

You can report working combinations of OS + browser too if you want. Please include both OS and browser versions. If you want to upload a screenshot for reference, you can do so at Phabricator: https://phabricator.wikimedia.org/file/upload. Inductiveload—talk/contribs 13:07, 24 May 2021 (UTC)

If you have a screenshot you can typically just paste it and it creates the image. — billinghurst sDrewth 13:22, 24 May 2021 (UTC)

Seeing the same as the screenshot, using Firefox 89.0.1 (64 bit) on Windows 10 Einstein95 (talk) 08:17, 21 June 2021 (UTC)