Wikisource:Scriptorium/Archives/2019-05

Visual works on Wikisource

I'm wondering if a chiefly visual work like Pepper&Carrot could be accepted into Wikisource. We already have works like Annual Haircut Day and The Pig and the Box. What do you think? NMaia (talk) 07:27, 2 May 2019 (UTC)

@NMaia: We do accept chiefly visual works, including comics. I see that this comic has also been published by various publishing companies, so it should satisfy our policy on what Wikisource includes. There are PDF editions of each episode at archive.org which can be used for proofreading. —Beleg Tâl (talk) 14:37, 2 May 2019 (UTC)

@Beleg Tâl: Do you have an example of a well-done work on Wikisource? While looking at those comics I only saw galleries of pages but not any transcription. NMaia (talk) 21:54, 2 May 2019 (UTC)

@NMaia: Zanele Situ: My Story is the most similar to a comic that I can think of, that has been "properly" proofread and transcribed. I used {{overfloat image}} for text bubbles, but this is optional for text that is part of an illustration (you can use alt text on the image instead). —Beleg Tâl (talk) 23:19, 2 May 2019 (UTC)

That's perfect, thank you! NMaia (talk) 23:21, 2 May 2019 (UTC)

Wikisource:News (en): May 2019 Edition

English Wikisource's monthly newsletter; Wikisource:News, which seeks to inform all about Wikimedia's multilingual Wikisource.

• Administrator confirmations for May 2019
• 2019 Wikimedia Summit to discuss movement strategy
• A lot of Newsletters
• Playing with m:Special:UrlShortener
• 2019 affiliate-selected Board seats process

Read this issue of Wikisource:News · Discussion · Unsubscribe · –MJL ‐Talk‐^☖ 19:58, 2 May 2019 (UTC)

Additional IDs for modern-day scientists

For people like Author:Andrew J. Pemberton, we would benefit from adding IDs like Semantic Scholar author ID (P4012) and ResearchGate contributor ID (P6023) to {{Authority control}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 3 May 2019 (UTC)

Feel free to add it to Module:Authority control —Beleg Tâl (talk) 21:09, 3 May 2019 (UTC)

Upload from Google Books

Do we have a tool for uploading PDFs from Google Books, like ia-upload, that are not on IA? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:22, 4 May 2019 (UTC)

there is url2commons, but you will need OAuth and format the book template, https://tools.wmflabs.org/url2commons/index.html -- Slowking4 ‽ SvG's revenge 12:29, 5 May 2019 (UTC)

Thanks, but AIUI, that won't strip the leading page (the none-free one, added by Google). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:55, 5 May 2019 (UTC)

If you need just one book, User:Koavf has the skills to pull a books.google and convert it to a DjVu on Commons. --EncycloPetey (talk) 16:00, 5 May 2019 (UTC)

And if you need many books, you can learn how to use pdf2djvu & djvulibre. Ankry (talk) 06:14, 6 May 2019 (UTC)

Tech News: 2019-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.

Problems

• Special:Watchlist can show the wrong information. It does not always show which edits are read and which are unread. The developers are working on solving the problem. [1]

Changes later this week

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

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 8 May at 15:00 (UTC). See how to join.

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

16:28, 6 May 2019 (UTC)

Mulitpage scores - a possible solution...

I asked User:Ankry about a solution they had implemented on plwikisource and they imported it here.

See Template:tscore and Module:mscore.

If the Wikisource contributors that have used the score extension would like to review... ShakespeareFan00 (talk) 21:14, 3 May 2019 (UTC)

The module is beyond my understanding at first glance. The template is possibly OK for some (minor) use cases. However, the restriction of not using | to mark bar-lines, and the loss of the work's page numbers, means that it is outside of my interest to pursue for anything I do with scores. I will continue to deal with scores that go over page boundaries in the ways I do now: a) short snippets get combined onto one page or the other (with an explanatory comment); b) longer examples are Lilypond coded to manage. Beeswaxcandle (talk) 21:41, 3 May 2019 (UTC)

it’s a nice template, but wikicode as the score code. i’m waiting for the reverse engineering of lilypond to give us a Visual score editor. until then my productivity is so low as to be off-putting. Slowking4 ‽ SvG's revenge 02:50, 10 May 2019 (UTC)

Zoe Dana Underhill - DoD?

We say that Author:Zoe Dana Underhill lived 1848-1908, but [2] gives 1847-1934, with the age of 87 (but not the dates) supported by a newspaper clipping. Are we wrong (I can't see a source for our dates), or are they different people? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:07, 8 May 2019 (UTC)

It looks as though the dates originated in 2010 with User:Ineuw creating the page. Mpaa then transferred the dates to Wikidata. Possibly Ineuw remembers the source for these dates, possibly not. --EncycloPetey (talk) 20:15, 8 May 2019 (UTC)

On rechecking, the 1847-1934 dates are supported by an image of the grave. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:32, 8 May 2019 (UTC)

The dates 1848-1908 belong to Uncle Remus, who may have appeared next to Underhill in an alphabetized list, hence the confusion. —Beleg Tâl (talk) 18:11, 9 May 2019 (UTC)

Good catch. Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:51, 9 May 2019 (UTC)

This section was archived on a request by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:51, 9 May 2019 (UTC)

Redirect The Music of Erich Zann to Famous Fantastic Mysteries/Volume 12/Number 3/The Music of Erich Zann?

The Music of Erich Zann is an copy from an unknown source of a work we have a transcription of. So normally we'd redirect it, right? There is also the concern that there is about 100 words in the unsourced copy that are not found in the new copy, possibly cut for space.--Prosfilaes (talk) 14:59, 10 May 2019 (UTC)

We don't generally redirect when the versions are different, which they are here. The unsourced copy appears to match this source from The National Amateur, so I would preserve it and then redirect it if/when the latter source is added. —Beleg Tâl (talk) 16:52, 10 May 2019 (UTC)

Wrong years

That black magic Wikidata that has added years of birth and death to Author:Friedrich Weber has gotten it wrong. Should be 1781-1823. --LA2 (talk) 23:42, 10 May 2019 (UTC)

An IP address changed it at Wikidata a few days ago. I wonder that IP adresses are allowed to edit Wikidata... I have restored the dates. --Jan Kameníček (talk) 23:58, 10 May 2019 (UTC)

The Condor volumes

All sub-pages are currently formatted as “The Condor/<volume number> (<issue number>)” (such as The Condor/1 (2)), and should be formatted as “The Condor/Volume <volume number>/Number (or Issue) <issue number>.” Also, a number of the older volumes existed under the title of the Bulletin of the Cooper Ornithological Club; should those earlier volumes be moved to that name? TE(æ)A,ea. (talk) 23:56, 12 May 2019 (UTC).

SOURCE for Wikisource

You would think that 'Wikisource' would be good with... hmm, I don't know... SOURCES??? But I'm finding that The Chance for Peace page presents itself as a verbatim transcription of Eisenhower's words, when in fact it is a revised and copy edited version of what Eisenhower said. I tried to correct the errors in transcription of the speech. I was reverted. On my talk page, I was told that we don't have to put THE　ＳＯＵＲＣＥ　of the transcription for the speech on the page proper, which is definitely a mistake- it leads you to get the impression that these are the words Eisenhower said, which they aren't if you listen to the tape. I recommend adding something to Wikisource where it can be made clear on the page itself what the source of the text given on Wikisource is. I am right. --Geographyinitiative (talk) 00:50, 11 May 2019 (UTC)

The source for this edition is identified on the Talk page, and is an authoritative version at the Eisenhower Presidential Library. As I let you know on your talk page, Wikisource accepts more than one edition of a work, if more than one edition has been published or is available. The issue we were having is that you wanted to replace one sourced copy with your own transcription from a different source. You are welcome to add other editions of works when they exist and are released under a suitable license. You also wanted to put a label on the current copy declaring that it is "horse shit", which I explained would not be appropriate. --EncycloPetey (talk) 01:04, 11 May 2019 (UTC)

The preference here is always a printed source. In cases when there is no printed source, the source used should be detailed on the Talk page using the {{Textinfo}} template. When there are alternate sources/editions for a document (using that word in it's widest context), then there should be more than version of the document created here. The {{versions}} template is used to indicate that there are alternate versions and a versions page (subset of disambiguation) is created that lists all of the alternate versions. The source is never stated on the mainpage, but is either on the Talk page, or is a scan of the printed source. All this is long-established here. See Help:Beginner's guide to sources as an inital point to explore our policy further. Beeswaxcandle (talk) 02:01, 11 May 2019 (UTC)

@Beeswaxcandle, @EncycloPetey: That's not good enough. The source needs to be stated on the page proper, not on the talk page. If the source is not made manifest on the page proper, readers like me might be lead to believe that the transcription is accurate- which it is manifestly not. Let me tell you a short story: I just changed the Wikipedia page for the US national motto from "In God We Trust" to "In God we trust". If you read the US Code, you will see that this is the correct capitalization. Whereas before Wikipedia was illiterate dogshit, now it is actually providing accurate information to the readers. That's the key: get the correct information to the readers. What I'm trying to tell you is that if we are going to go by other people's transcriptions without allowing editors to edit the transcriptions, then we're still not providing people with accurate information. Accurate information doesn't burden the reader by asking them to "click on the talk page". It comes out and tells you right there: "this is some bullshit transcript cooked up by the idiot librarians, believe it at your own risk." If you are just reposting whatever shit some illiterate at some library thinks qualifies as a transcription, the result will be a website full of "In God We Trust" instead of a website of precision and vitality- dedication to fact. Geographyinitiative (talk) 14:57, 12 May 2019 (UTC)

this is good "correct information to the readers", but this is not so good "That's not good enough", we in general believe in eventualism; there is a lot of older material not scan backed (gutenberg being a bad influence), that will require leg work to build links to a scan. and exhortations will not get the scanning done. we might want to think about a grant to work the "w/o scan" backlog. Slowking4 ‽ SvG's revenge 20:46, 12 May 2019 (UTC)

I've added the published source to The Chance for Peace. If there are better free published transcriptions it would be good to add them also. —Beleg Tâl (talk) 18:54, 12 May 2019 (UTC)

thanks, this clean typescript is from the presidential library. https://eisenhower.archives.gov/all_about_ike/speeches.html it’s a little web 1.0. we may need to go to Abilene to scan the manuscript. we work with the sources we have, not the sources as we might want them to do scholarship. Slowking4 ‽ SvG's revenge 20:59, 12 May 2019 (UTC)

1000000 proofread pages

It seems that Page:The_Eight-Oared_Victors.djvu/151 was the milionth proofread page in English Wikisource (according to this query). Ankry (talk) 11:23, 12 May 2019 (UTC)

great, waiting for daily update here https://tools.wmflabs.org/phetools/statistics.php (should this be an announcement? Slowking4 ‽ SvG's revenge 16:13, 12 May 2019 (UTC)

1 million proofread pages

In the last few minutes we have achieved 1 million proofread pages. Of these 395,451 are in Validated status. Beeswaxcandle (talk) 10:20, 12 May 2019 (UTC)

congrats - Page:The Eight-Oared Victors.djvu/151 ; [3] - see also Wikisource:Scriptorium#1000000_proofread_pages Slowking4 ‽ SvG's revenge 14:40, 13 May 2019 (UTC)

Commons no longer relaying information...

File:The_cutters'_practical_guide_to_the_cutting_of_ladies'_garments.djvu for an example.

Did they update something recently? ShakespeareFan00 (talk) 06:05, 13 May 2019 (UTC)

@ShakespeareFan00: Looks like a temporary hickup. It's back now. BTW, an issue like that looks more likely to be a Mediawiki issue (new version, or a change made by sysadmins/developers) than anything that the community of Commons could influence. --Xover (talk) 11:44, 13 May 2019 (UTC)

Tech News: 2019-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.

Changes later this week

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

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 15 May at 15:00 (UTC). See how to join.

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

00:49, 14 May 2019 (UTC)

John Cotton's Notebook

After much wrangling with the upload wizard, I have uploaded 44 tiff files, each over 50Mb, to commons:Category:John Cotton's Notebook. These show the pages of an artist's sketchbook.

How would we go about including such a work, with a mixture of sketches and hand-written text, on Wikisource? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:35, 11 May 2019 (UTC)

If they were bound together as a book, then the first step would be creating a DjVu from which to work. We would also want JPG versions of the images to link from within the work. --EncycloPetey (talk) 13:26, 11 May 2019 (UTC)

I would use https://tiff2pdf.com/ to bundle the images into a PDF, then http://djvu.org/any2djvu/ to convert the PDF into a DJVU for proofreading. Upload the DJVU, set up the Index page, and away you go. Handwritten text can be proofread like normal text; if you are fussy about layout you can play with {{overfloat image}} or {{figure}}. The sketches ideally could be extracted using GIMP or something. —Beleg Tâl (talk) 18:22, 11 May 2019 (UTC)

For illustrated manuscripts you have a lot of leeway for layout. If examples are helpful, I have worked on Alice's Adventures Under Ground, Zodiac Killer letter, April 20th 1970, Sumer is icumen in (MS Harley 978). —Beleg Tâl (talk) 18:32, 11 May 2019 (UTC)

@Beleg Tâl: Thank you. tiff2pdf allows the user to "select up to 20 images" only. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:51, 11 May 2019 (UTC)

In that case I'd probably do it in three batches, then merge them using https://www.pdfmerge.com/ or something similar. —Beleg Tâl (talk) 01:49, 12 May 2019 (UTC)

Why should you convert them to DjVu? What's so superior about DjVu that we should go from one lossy compressed format to another?--Prosfilaes (talk) 01:39, 12 May 2019 (UTC)

@Prosfilaes: see Wikisource:DjVu vs. PDF —Beleg Tâl (talk) 01:49, 12 May 2019 (UTC)

we prefer djvu for similar reasons that we prefer webm. Slowking4 ‽ SvG's revenge 10:59, 12 May 2019 (UTC)

WebM is a free format in a sea of unfree formats, supported by Google. PDF is a free format, internationally standardized (ISO 32000-2), whereas DjVu is supported by no one, not even the Internet Archive. Looking at Wikisource:DjVu vs. PDF, it seems like we should improve our PDF support and stop converting PDF to DjVu unless we absolutely have to.--Prosfilaes (talk) 12:14, 12 May 2019 (UTC)

you can draw a free line between WebM and mp4, but WebM may not play on some devices (it was only with some hacking genius that it works at all on apple products), and pdf is a product of adobe that some might not want to use. your file preferences may not be shared by others: you may not have a consensus to "stop converting PDF to DjVu unless we absolutely have to" Slowking4 ‽ SvG's revenge 15:57, 12 May 2019 (UTC)

I have not noticed an absence of djvu at IA. PDF sucks, but djvu is not a format for images, and that is what is needed to read the notes. The images also need rotation, but the user thought that identification (and maybe proof reading?) should be done without compromising the integrity of the file (or something, I never got an answer). CYGNIS INSIGNIS 17:38, 13 May 2019 (UTC)

WebM is a product of Google that some might not want to use. I don't claim that I have a consensus, but I still think it's a valuable question about why we should convert PDF to DjVu.--Prosfilaes (talk) 05:14, 14 May 2019 (UTC)

If the individual pages are already on Commons, then it is possible to proofread them directly, e.g. Page:John Cotton's Notebook - file 05 - page 02.tif. This has the drawbacks of a) needing to build the pagelist by hand (i.e. just a lot of links to the Page NS), and b) each page needs to be transcluded by itself, e.g. with {{page}}. It can still b e easier to do it this way sometimes; I have done sometimes for small works. Also, for creating a PDF, if you have imagemagik installed, you can run e.g. convert "John Cotton's Notebook*.tif" "John Cotton's Notebook.pdf" —Sam Wilson 00:40, 12 May 2019 (UTC)

Representative Women of New England indexes

Does anyone know what is happening between the two indexes (1, 2) of Representative Women of New England? The page histories seem to be problematic as well, with moves from respective index names. TE(æ)A,ea. (talk) 21:04, 15 May 2019 (UTC).

I assume Index:Representative Women of New England.djvu is abandoned due to poor quality scan, and existing work moved from there to Index:Sketches of representative women of New England.djvu. @Slowking4, @ShakespeareFan00: you may have more insight here. —Beleg Tâl (talk) 22:56, 15 May 2019 (UTC)

yeah, it is missing page 358 and 359. [4] i found better scan and completed. but it also has a bad page [5] Slowking4 ‽ SvG's revenge 01:21, 16 May 2019 (UTC)

Index:The cutters' practical guide to the cutting of ladies' garments.djvu

This has 2 missing plates, but apparently someone is selling a reprint of the original online:

https://www.forgottenbooks.com/en/books/TheCuttersPracticalGuidetotheCuttingofLadiesGarments_10848338

https://www.amazon.com/Cutters-Practical-Cutting-Ladies-Garments/dp/0282357262

Does anyone have the time or budget to check the print version for the missing plates?

(If it's digitised from the same source as archive.org used, I am thinking they may also be missing in the reprint.) ShakespeareFan00 (talk) 14:25, 14 May 2019 (UTC)

@ShakespeareFan00: HathiTrust has the 1899 edition, if that helps you any? --Xover (talk) 17:12, 14 May 2019 (UTC)

It's not , because it's from the same source as the archive.org scans (with the missing plates due to the physical copy held by the digitising insitution not having them either.), ( I checked hathi when I first found the missing pages in the scan Wikisource had.) ShakespeareFan00 (talk) 17:48, 14 May 2019 (UTC)

@ShakespeareFan00: The Forgotten Books reprint also is missing plates 2 and 3 as you can see from the online view and PDF downloads. The only hope is that someone can go to one of these libraries and scan the two plates for us: OCLC:55518654 at WorldCat -Einstein95 (talk) 08:46, 16 May 2019 (UTC)

The second entry is the institution that's digitised the one with missing pages, so we really need someone in Toronto possibly? ShakespeareFan00 (talk) 17:35, 16 May 2019 (UTC)

there is a GLAM wiki summit in Toronto May 23, https://ca.wikimedia.org/wiki/GLAMSummit2019, maybe we know someone going, or member of https://ca.wikimedia.org/wiki/Main_Page but i’m not seeing it at Ryerson.[6] -- Slowking4 ‽ SvG's revenge 19:59, 16 May 2019 (UTC)

Hmm, Maybe it needs someone to look into this "Work in more depth?" We have variously dated editions for Volumes 1, 13 and 6 (The Ladies one, found on archive.org as detailed.) It would be nice (but insanely difficult to get all the volumes) on English Wikisource, assuming a combination of Google, Hathitrust and other scan sources have them.

Other volumes (variously dated) are in JPG scans linked from here (of variable quality) here - https://web.archive.org/web/20030826152955/http://www.costumes.org/history/100pages/1893to1898cuttersguide.htm), I found some others by looking through different dates for archived pages..

Independently I found this as well - https://archive.org/details/b1108865 from an Australian source... I'm wondering if there was a Wikisource contributor that might be near to the digitising institution, to make enquires as to the possibility of other works by that author ending up with them... ShakespeareFan00 (talk) 20:42, 16 May 2019 (UTC)

Template:OTRS received

Template is broken. Relies on another template that has since been deleted. --EncycloPetey (talk) 14:59, 18 May 2019 (UTC)

@EncycloPetey: I think I've fixed it. It was broken because it tried to use the now-deleted Template:autotranslate to automatically translate the template's message into multiple languages. That makes sense on Commons (from which it has been copied), but not on enWS, and consequently it only had a single "translation" available: English. I've removed the translation plumbing and just inlined the message into the template. If there are no unintended side effects of this the two subpages (Template:OTRS received/en, Template:OTRS received/lang) can also be deleted. --Xover (talk) 05:45, 19 May 2019 (UTC)

Charinsert selection is no longer saved for the next session.

Some time ago WMF removed the Charinsert's user's selection from the Wikisource cookie. Is there a plan to re-implement this feature somehow? Perhaps as a Gadget? I ask because every page I open for edit, The preferred row must be re-selected. — Ineuw talk 00:15, 19 May 2019 (UTC)

I'm not seeing this behaviour. I always have the last one I used displayed—usually "User". [Do note though, that I'm using the MonoBook skin and I have no editing toolbar on since they turned off the only usable one.] Beeswaxcandle (talk) 00:33, 19 May 2019 (UTC)

I am using the Vector. This I was told on phabricator after filing a bug report that it needs to be a per wiki supported gadget. —unsigned comment by Ineuw (talk) 02:52, 19 May 2019‎ (UTC).

@Ineuw: That Phabricator task was about removing the old (2006) editing toolbar, but should not in itself otherwise affect the character insertion function. However there was another utility function removed in the same change that the character insert function depended on and which necessitated changes to it to keep working. But the symptom of that would have been that the character insertion function either didn't show up at all or showed up but simply did nothing. Provided I'm understanding you correctly, what you're seeing is that the function is there and works, but it just fails to remember which group of characters was selected last time.

I'm not seeing that problem either, so it is not a global problem with this feature. There was, however, a change made to the code on enwp around the same time as the changes discussed in that Phab ticket, and that change was copied here by Mpaa. The change switched from using regular web "cookies" to using the fancy new HTML5 localStorage/sessionStorage APIs. These are not quite as universally supported as cookies, so your web browser suddenly becomes a factor. All versions of Internet Explorer <=11 have various bugs related to this; and relatively old web browsers lack support completely (we're taking IE6, Safari 3/4; about that old). It also means the security settings in your browser come into play (if the script isn't permitted to save the data, for example). It can also conceivably be affected by installed antivirus products (I don't know whether these actually interfere in these kinds of operations, but it would not be surprising if they did).

And lastly there are some Mediawiki settings that can potentially play into this somehow. Which skin are you using (Vector, Monobook, etc.). Is "Enable the editing toolbar" in Special:Preferences#mw-prefsection-editing checked? Are you using the insert menu that shows up below the main text area or the one at the top of it? Have you tested in the main namespace or here, vs. Page: and Index:? If your web browser has developer tools / javascript console; does the console show any errors when you use the char insert function? --Xover (talk) 07:24, 19 May 2019 (UTC)

@Xover: Much appreciate your input and explanation. 90% of the time I use Firefox (currently 66.0.5) and the rest of the time, I use Vivaldi 2.5, a Chromium based browser. Both are the latest browser technology as far as I know. It's best if I reset my preferences to default and take it from there, and hoping to find the glitch. My thanks. — Ineuw talk 20:11, 19 May 2019 (UTC)

Disabling and then redefining most of the same local settings, and disabling the global preferences permanently, did the trick. My Charinsert "User" selection appears immediately in edit mode. Thanks to everyone. Ineuw (talk) 22:57, 19 May 2019 (UTC)

Index:Lanman's Sanskrit Reader.pdf

This seems to be confused as to publication dates, The front page says 1963, The Commons description says 1884, although the work itself contains a note on pp. x , as to a fourth edition of 1903.

The original author died in 1941, so the license on the file at Commons might need to be updated, if it is genuinely a later edition.

I am thinking the front page date is that of a reprint, as I can't find a specific copyright indication elsewhere, did someone check for it being a post 1923 revision as opposed to a reprint? ShakespeareFan00 (talk) 07:42, 19 May 2019 (UTC)

https://archive.org/details/in.ernet.dli.2015.284131 is a copy of the fourth issue of 1903 from 1912, if this needs replacing.--Prosfilaes (talk) 20:19, 19 May 2019 (UTC)

TOC entry with multiple page numbers on the same line

In this book, I am attempting to use Template:TOCstyle to generate a table of contents for illustrations. However, the template does not support having an entry in the TOC refer to multiple page numbers, thus breaking the code, as seen here. Could a more experienced user kindly point me to a workaround so that multiple pages can be on the same line? Thanks, Kges1901 (talk) 21:24, 19 May 2019 (UTC)

There is an extra }}| following the {{sc}} on that line. Remove that and you may be pleased with the result… 114.73.168.91 21:38, 19 May 2019 (UTC)

• Thanks for finding what I missed. Kges1901 (talk) 21:52, 19 May 2019 (UTC)

Tech News: 2019-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 report for phase 1 of the talk pages consultation 2019 has been published. Communities are invited to start phase 2 of the consultation on their wikis.

Problems

• File descriptions for files from Commons were not shown properly on other Wikimedia wikis for a few days. For example the image descriptions and license information were missing. This has now been fixed. [7][8]
• Some diffs show an error message when you try to see them. The developers are working on fixing it. It could be because of some edit comments. [9][10]

Changes later this week

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

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 22 May at 15:00 (UTC). See how to join.

Future changes

• The content translation tool on Wikipedia can use machine translations. There is a system to stop translations where the editors do not fix machine translation mistakes. This warns or stops them if they seem to just copy what the machine translation gives them. If this system is too strict or not strict enough you can tell the language team. [11]
• The Wikidata wbeditentity API endpoint will remove all aliases if the request includes an empty alias. This is how it supposed to work. It has not been working this way because of a bug. This will start on 12 June. [12]

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

13:04, 20 May 2019 (UTC)

Chapters in a different language

Hi—What's the appropriate procedure for transcribing chapters in a different language? In the book I'm working on there's a 30-page appendix in Latin (beginning here, I haven't created the pages yet), so in particular I'm wondering:

1. Should the pages in Latin be transcribed in the page namespace here?
2. Should the Latin appendix be given a page in mainspace here, or on the Latin Wikisource, or on both with a transclusion here from the Latin Wikisource?
3. If it goes on the Latin Wikisource, how do I present the appendix by itself there given that the rest of the book is in English?

I tried looking for a relevant help/policy page but couldn't find much. Cheers. —Nizolan (talk) 16:33, 21 May 2019 (UTC)

If it's a source material appendix, and it's short, then it is possible to transcribe it and include it here. We've done that sometimes for works such as The European Concert in the Eastern Question where sections of diplomatic documents are used to support the principal text. We typically would not include non-English text if the book was a parallel text, or a work primarily in a language other than English, or where the non-English portion was a complete work in its own right unconnected with the main (such as a German article in a multi-lingual periodical). That's not a comprehensive answer, but I hope it answers your particular question. --EncycloPetey (talk) 17:04, 21 May 2019 (UTC)

It looks like an integral part of the book. Not only the individual documents of the appendix are discussed in the previous English chapters, but there is also a contents page of the appendix, which should be transcribed (as it is in English language) and which would not make any sense if the the rest of the appendix were not transcribed too. --Jan Kameníček (talk) 17:15, 21 May 2019 (UTC)

Thanks both; in that case I'll proceed "as normal". The appendices in European Concert seem to be the same situation.—Nizolan (talk) 17:49, 21 May 2019 (UTC)

Don't forget to mark up the Latin text as such, like {{lang|la|Lorem ipsum}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:42, 24 May 2019 (UTC)

I wasn't aware of the {{lang}} template, but I will use it going forward, thanks. It'll be tricky to add to the works/pages I've already proofread since there are so many snippets of Latin (and some other languages) but I'll do a once-over and hopefully any others can eventually be caught in validation. —Nizolan (talk) 14:25, 24 May 2019 (UTC)

translator? co-author?

I have some doubts how to present the role of Lewis Stanton Palen in Beasts, Men and Gods. According to this article (in Polish) Ossendowski wrote this book initially in Russian and then translated it himself to English with help of Palen. Palen is also suspected to suggest some changes in the book plot. Frankly, Palen is nowhere named "translator"; he is called "collaborator". However, I have no idea how to express this in Wikisource in the header template as well as in the Palen's author page. Any hints?

English edition is the original one; all later editions (except Polish one, published a year later, which is significantly modified) were just translations of the English edition. Ankry (talk) 07:56, 24 May 2019 (UTC)

Since the English edition is the original one, I think either by Ossendowski, translated by Ossendowski and Palen or by Ossendowski and Palen would be correct, and you can explain further in the notes field —Beleg Tâl (talk) 12:46, 24 May 2019 (UTC)

Voting System

In addition to the existing criteria for for the editing and changes, major changes like article title change and such, there should a tool for voting. I am aware that a basic frame work exists, what I am speaking of is a simple, proper voting tool, once invoked it would collect data on two points, first which side to favour and why (references/supporting arguments this can be a simple comment box) to favour.

For instance: the article Basmala has a title that is very confusing for nearly all Muslims, because most do not use or even know this particular word. Most, nearly all, will recognise the word "Bismillah" instantly and that what is it referring to. Despite the fact the move has been proposed and voted for by a large number of people and editors it has not been executed. The grounds for not moving/changing the title is given (and logically so) is that in "English" language the word is predominant a few references have been provided as well, but in my opinion it does not make sense, as the article is about something exclusively related to Muslims and it should be presented as it should be "recognizable and usable" by the majority as it is the correct use as well.Moughera (talk) 15:10, 27 May 2019 (UTC)

@Moughera: I think that you meant to post this on Wikipedia rather than Wikisource, because we do not ave any article called Basmala here. Regarding a "proper" voting system, I think that is a good idea, and I recommend you post this request to w:Wikipedia:Talk pages consultation 2019/Phase 2 where improvements to the discussion processes of Wikipedia are being discussed. —Beleg Tâl (talk) 16:40, 27 May 2019 (UTC)

@Beleg Tâl: Yes I added the later para to the wikipedia as well, point of posting it here was to elaborate on what I was actually speaking about and what can be a basic mechanism for this tool. For now I think I am gonna post it on the page you've just recommended. Thanks. Moughera (talk) 17:21, 27 May 2019 (UTC)

Tech News: 2019-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.

Changes later this week

• Big changes to the replica database will happen on 3 June. Some tools on Cloud Services will stop working if the maintainers do not update them to use the new schema. This probably affects tools that query for revisions or log entries made by a user. [13][14]
• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 May. It will be on non-Wikipedia wikis and some Wikipedias from 29 May. It will be on all wikis from 30 May (calendar).

Meetings

• You can join the technical advice meeting on IRC. During the meeting, volunteer developers can ask for advice. The meeting will be on 29 May at 15:00 (UTC). See how to join.

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

15:34, 27 May 2019 (UTC)

EnycloPetey adminship vote of confidence

A vote of confidence has been triggered at EncycloPetey's annual administrator confirmation. All community members are invited to express their views at Wikisource:Administrators#EncycloPetey. Hesperian 02:12, 28 May 2019 (UTC)

Timely articles: Help with proofreading items that will likely receive local attention?

There is a statue called "The Pioneer" in Oregon which has attracted attention as potentially glorifying racist attitudes in the region's history, and may be dismantled. The Oregon Historical Quarterly documented the statue's installation in 1919, printing the addresses of its sponsor and of the then-president of the Oregon Historical Society. Since the attitudes reflected are the core subject of the current controversy, I expect there will be renewed interest in these articles; and as far as I know, Wikisource is the only place online where transcriptions of these addresses exist. Both have been transcribed; but I would love to have some additional eyes, perhaps for validation, on these texts (and potentially on neighboring articles in the 1919 volume of the OHQ).

• Oregon Historical Quarterly/Volume 20/Address Delivered by Joseph N. Teal
• Oregon Historical Quarterly/Volume 20/Qualities of the Oregon Pioneers
• Wikipedia article about the statue
• discussion and links to current news articles about the controversy

-Pete (talk) 20:50, 24 May 2019 (UTC)

I was really gratified by the response, and would like to thank the following for their contributions. I've been working on transcribing Oregon Historical Quarterly content for some years now, and I really appreciate the burst of assistance from several other editors. I tweeted about these specific articles here.

• @Pigsonthewing: and @Nizolan: for validating many of the specific pages for which I sought help
• @Kathleen.wright5: for validating neighboring content (both recently and in the past)
• @James500: for a truly mind-boggling effort importing the OCR'd version of nearly all the OHQ volumes for which we have a scan index.

This work is very important to me, and I think in the long run it will clearly demonstrate the value of Wikisource to an audience of history buffs in the Pacific Northwest. Your assistance is really gratifying. -Pete (talk) 19:42, 29 May 2019 (UTC)

Added text that condemns those who remove it

Here's an odd problem: while digging around IA for Portal:Church of the East, I came across this book. It's in the public domain but a text in Syriac and English has been affixed on the second page of the scan reading:

Anyone who asks for this volume, to read, collate, or copy from it, and who appropriates it to himself or herself, or cuts anything out of it, should realize that (s)he will have to give answer before God's awesome tribunal as if (s)he had robbed a sanctuary. Let such a person be held anathema and receive no forgiveness until the book is returned. So be it, Amen! And anyone who removes these anathemas, digitally or otherwise, shall himself receive them in double.

This seems to be added to all the books in the Beth Mardutho collection. As it happens there's another, better scan available in this case anyway, but I was wondering, given that there are many other public domain books in this collection, what the policy would be here: put it in the notes? Link it in the notes? Ignore it entirely? —Nizolan (talk) 23:50, 29 May 2019 (UTC)

We present the work as published. This text is not part of the work. It is an ex-libris that has been stuck in after publication. Some of us prefer to transcribe such pages as blank; others transcribe the ex-libris but exclude it from mainspace transclusion. Hesperian 00:44, 30 May 2019 (UTC)

And yes I understand that I will have to answer before God's awesome tribunal for the above comment. Hesperian 00:45, 30 May 2019 (UTC)

@Hesperian: I do understand it wouldn't be included in the work; I was mostly wondering about whether it should be noted anywhere in e.g. the header as a concession to Assyrian sensibilities. Nizolan (talk) 00:55, 30 May 2019 (UTC)

Oh, I see. I suspect the intent behind it was simply to stop people stealing library books; and that last sentence was intended to stop the thief from cutting the ex-libris and anathema out in order to sell it. I don't think it has anything at all to say about us putting a virtual copy online, or someone reading an online version of it. To the extent that it does, it would be contrary to our mission and the broader Free Cultural Works movement, to which we belong. So no, no concession. Hesperian 07:38, 30 May 2019 (UTC)

phab:T224355: bad quality in Page namespace

Maybe someone came across a similar situation... If so you can leave a comment on phabricator task. Ratte (talk) 10:33, 26 May 2019 (UTC)

I haven't experienced this particular issue, but there are frequent problems working with PDFs on Wikisource, which is why DjVu is the recommended format. --EncycloPetey (talk) 15:58, 26 May 2019 (UTC)

Unfortunately, djvu files may sometimes experience a similar problem (among others). --Jan Kameníček (talk) 16:42, 26 May 2019 (UTC)

+1 EncycloPetey. The above DjVu problem is easily fixable either by manual setting of higher scan resolution in index, or by replacing the first page with a higher resolution image (eg. scaled up). Unlike most PDF problems... Ankry (talk) 19:06, 26 May 2019 (UTC)

PDF is IMO more easily accessible than DJVU to most users (which is probably the reasons why many libraries started leaving DJVU), but unfortunately mediawiki is not very friendly to PDFs. I believe that it is mediawiki that should be improved. --Jan Kameníček (talk) 19:32, 26 May 2019 (UTC)

PDF is much more complex and not open format comparing to DjVu. So support for it in OpenSource software is sometimes problematic (eg. rendering of some PDFs using OS software is often worse than when using commercial software). And fixing a problem is harder. If PDF support could be completely separated from the rest of mediawiki or just done client-side, it would not be a problem. But I doubt it can (can you imagine transferring a 50+ MB PDF file to a client each time you wish to extract a single page?). I also think that lack of appropriate testing procedures during software upgrades may be a separate case (but how to test automatically whether an image is correctly extracted/displayed?). Ankry (talk) 11:43, 27 May 2019 (UTC)

lol, go talk to the admin above in Wikisource:Scriptorium#John_Cotton's_Notebook. just renewing support at IA would be an improvement. -- Slowking4 ‽ SvG's revenge 18:02, 27 May 2019 (UTC)

Meh. It's been 3 years since IA stopped creating DJVU files. I doubt they'll restart soon. Though, if anyone knows differently, feel free to correct me. Haz _talk 22:36, 6 June 2019 (UTC)

There is nothing I can comment🙄🙄 —unsigned comment by Yanga Blessing (talk) .

Wikidata:Property proposal/Harper's author IDs

I have proposed a new Wikidata property for Harper's /Harper's Bazaar author page IDs, like [15], with a view to including those IDs in {{Authority control}} on this project and others. Please see d:Wikidata:Property proposal/Harper's author ID. and express your views there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:28, 8 May 2019 (UTC)

Do you mean Harper's Magazine (= Harper's Monthly) or Harper's Bazaar? The former is a literature and culture magazine; the latter is a women's fashion magazine for which we have no content right now. --EncycloPetey (talk) 22:11, 8 May 2019 (UTC)

I mean https://harpers.org/ Apologies for the confusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:24, 8 May 2019 (UTC)

good, and before Teen Vogue, you should try The Atlantic i.e. [16]-- Slowking4 ‽ SvG's revenge 02:36, 10 May 2019 (UTC)

Done: d:Wikidata:Property proposal/The Atlantic author ID. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:06, 10 May 2019 (UTC)

thank you very much. it’s a stretch for wikisource, but we should be pushing out the voluminous magazine material. Slowking4 ‽ SvG's revenge 14:42, 10 May 2019 (UTC)

Now created, as d:Property:P6791. Please can someone update {{Authority control}} with both new properties? 12:01, 29 May 2019 (UTC)Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

Now created, as d:Property:P6784. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:49, 27 May 2019 (UTC)

I also added to the list d:Wikidata:Property proposal/Orlando person ID, which I proposed two months ago but apparently posted in the wrong place. Levana Taylor (talk) 11:53, 10 May 2019 (UTC)

The Orlando ID is now d:Property:P6745. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:13, 7 June 2019 (UTC)

Main namespace header interferes with a page number

The headers in individual chapters of the Abbott's Guide to Ottawa and Vicinity, for example at Abbott's Guide to Ottawa and Vicinity/Chaudiere Falls, overlap the page numbers (here the header "page 15" overlaps the number "[15]"). I am using Firefox Quantum 67.0. --Jan Kameníček (talk) 06:56, 27 May 2019 (UTC)

I am not experiencing this issue in Chrome 74.0.3729.169 .--Jan Kameníček (talk) 09:20, 27 May 2019 (UTC)

I can't see where the content of the Note field is coming from, given the use of a header field within the pages tag instead of a real header template. But the note is not required. Beeswaxcandle (talk) 09:57, 27 May 2019 (UTC)

It is being added there by some parameter "header" within the <pages />. Unfortunately, there is no information about this parameter and its usage at Help:Transclusion :-( The parameter was used by Beleg Tâl, so maybe he could explain it. --Jan Kameníček (talk) 10:42, 27 May 2019 (UTC)

And, I think, its use is defined here. Ankry (talk) 11:55, 27 May 2019 (UTC)

@Xover: you made some comments about offsetTop in Firefox at MediaWiki talk:PageNumbers.js; do you have any insight on this? The page number element has a top text-indent of -12.8px in Firefox only, and I don't see anything in MediaWiki:PageNumbers.js that would suggest to me why this is. —Beleg Tâl (talk) 12:18, 27 May 2019 (UTC)

@Beleg Tâl: It looks like the same issue biting us again that I've detailed previously here.

ProofreadPage emits the code defined in MediaWiki:Proofreadpage pagenum template at the beginning of each transcluded page. If you pare back the unrelated stuff, what you're left with is <span></span> (that is, an empty HTML span element). MediaWiki:PageNumbers.js then comes in and grabs all those spans, gets the offsets of their top left corner, hides the originals, and creates new spans containing the page numbers in the left gutter but at the vertical offset of the original. So far so good…

…but Firefox has a bug in calculating the offset for an empty inline element (which the original spans are). In the Abbot's Guide example, the value returned for $('#15').offset().top is 325 (value is in pixels from the top left of the browser's viewport). However, the actual (correct) position of its top left corner is 340 pixels (the difference is most likely equal to the line height in pixels). When PageNumbers.js creates the new page number spans it thus positions it 15 pixels (in this case) too high up, thus making it overlap whatever is there (in this case the header; completely irrespective of any notes or the syntax used to create it).

My conclusion the last time I dug into this—at WS:Scriptorium/Archives/2018-08#Page numbers borked with hyphenated words—is that the fastest and easiest, but also riskiest, way to avoid this problem is to stuff a Unicode Zero-width space character (​) into MediaWiki:Proofreadpage pagenum template. It would probably fix this problem, but might cause breakage elsewhere (try it and spot check a few hundred pages is the only way to find out).

The alternative is the long slow process of Gadget-izing MediaWiki:PageNumbers.js so it can be disabled per-user, and then cleaning it up and finding a JS-based workaround in a user sandbox, and then replacing the old one with that. That would let us manage risk of breakage and easily roll back in case of trouble, but it's a lot of work and sort of (in practice) hinges on getting Interface Admins in place (it's not the kind of thing you can make an edit request for and have Billinghurst come in and cut&paste it: it needs to be a step by step and iterative process over time). --Xover (talk) 19:14, 27 May 2019 (UTC)

@Xover: Fantastic explanation. Looks like Firefox is aligning the empty span by baseline, and since there is no content, the baseline is where you'd expect the top to be—but the top is bumped up further. Setting .pagenum.ws-pagenum { vertical-align:top; } in my common.css seems to resolve the issue for me. —Beleg Tâl (talk) 20:28, 27 May 2019 (UTC)

Indeed. And that can be set from either JS in MediaWiki:PageNumbers.js or in CSS in MediaWiki:common.css (or in MediaWiki:Gadget-Site.css to keep the other leaner). However, this has similar risks of breakage elsewhere as inserting a zero-width space and at the same time will not fix other breakage caused by empty inline elements (e.g. the Safari issue that prompted my investigation in the first place). Handling of empty inline elements is poorly defined in the specification, largely left up to each implementer (web browser), and exhibits bugs and inconsistencies in practice. Unless it turns out to cause unacceptable (non-edge case, hard to work around) problems elsewhere, my recommendation would be to avoid the issue entirely by making these spans non-empty (by inserting a ​). --Xover (talk) 05:40, 28 May 2019 (UTC)

 Comment This behavior is independent of the use of {{header}} (or not) and the use of a "note" (or not). I am seeing the same behavior at Euripides (Donne)/Chapter 3, where the header template is used and there is no note. --EncycloPetey (talk) 13:13, 27 May 2019 (UTC)

When using the standard two blank lines between the header and the pages tag, there is no problem. I suspect though that putting two blank lines before the pages tag when it's the only thing on the page would end up being swallowed automatically by the MediaWiki software. Beeswaxcandle (talk) 18:17, 27 May 2019 (UTC)

Can we try inserting a zws and see if it breaks? —Beleg Tâl (talk) 12:19, 28 May 2019 (UTC)

@Tpt: Will we destroy the server if we add a ​ to the span in MediaWiki:Proofreadpage pagenum template, or is that a reasonable thing to try and then revert if things break elsewhere? cf. the above discussion of various browser bugs tickled by empty inline elements. --Xover (talk) 16:06, 28 May 2019 (UTC)

@Xover: Sorry for the late answer. No it won't break the server but it might introduce two spaces between words if you have the beginning of a paragraph on a page and the end of the other, especially for users with JavaScript disabled. I would rather modify MediaWiki:PageNumbers.js. Tpt (talk) 08:16, 5 June 2019 (UTC)

@Tpt: Thanks for taking the time to respond (and no worries about response time; I know you're busy). Modifying PageNumbers.js not optimal for a few reasons: it can't easily be modified iteratively because we have no local interface admins (all changes have to be done in pre-defined batches); and it is monolithic and loaded unconditionally from common.js so it is impossible to tweak+test+deploy (all changes affect all users immediately). In addition, the underlying cause for the weirdness we're seeing is browser inconsistencies, browser bugs, and lack of specification for empty inline elements, and those will still apply even if we somehow work around it case by case in PageNumbers.js. I am thus hoping we can find a general way to handle this that makes sure ProofreadPage pages do not depend on empty inline elements.

What would be the cause of two spaces between words? There is obviously any whitespace at the end or beginning of the page in the Page: namespace, and what we're proposing is to deliberately insert a zero-width space inside the span that ProofreadPage spits out, and which we're hoping will work as specified (i.e. that it will have zero width). Where would a second normal / visible space character come from that wouldn't be there if we left the span empty? --Xover (talk) 10:33, 5 June 2019 (UTC)

@Xover: Sorry, I confused zero width space and non breakable space code points. Having a zero width space looks a great idea to me and I hope it would not break anything. Feel free to try it. Tpt (talk) 08:15, 6 June 2019 (UTC)

┌───────────────────────┘
(outdent)  Alrighty then! @Jan.Kamenicek, @Beeswaxcandle, @Beleg Tâl, @Ankry: (and anyone else interested, obviously) Based on all that, I propose that we find a time when at least a couple of volunteers (can I get a few volunteers? ;D) can be available; then add a ​ to the span in MediaWiki:Proofreadpage pagenum template; and then try randomly checking a few hundred(?) mainspace pages to see if anything breaks. Unless any breakage is catastrophic, I would suggest we leave it in place for a while to enable testing out workarounds, identify any further breakage, etc. for a possible later new attempt; but that if there is any significant breakage that doesn't have an immediate and easy resolution we then revert to the status quo. I'm thinking it'd be good to let it sit over a weekend, but that may be over others' pain threshold for something like this. I would also like feedback on whether this is something that should be further publicised and put to the community for discussion before we try it? Any and all thoughts welcome: I'd like to do this, but not so much I want to step on anybody's toes to get it done! ;D --Xover (talk) 08:35, 6 June 2019 (UTC)

OK, I can take part in checking random pages. --Jan Kameníček (talk) 08:38, 6 June 2019 (UTC)

Go for it —Beleg Tâl (talk) 10:45, 6 June 2019 (UTC)

Ok, then absent objections before then (and do please feel free to object or yell "Wait!" for any reason!), I will make that change some time this evening UTC.

All volunteers checking works for signs of breakage would be welcome. Obvious areas of risk are getting visible extra spaces at page boundaries, the page numbers suddenly breaking in new ways or in browsers that used to work, various forms of breakage when using {{hws}}/{{hwe}} and {{linkable phrase start}}/{{linkable phrase end}}, and (less likely but still possible) multi-page formatting templates like {{dent/s}}/{{dent/e}}. The obvious components that might fail to work properly when we change this is the ProofreadPage extension itself, the PageNumbers.js script, and our various formatting templates.

Based on my knowledge of these and how they work I don't foresee any actual problems, but it is always a possibility. Please catalogue any problems (and workarounds, if found) here so we have better data for the future in case we have to revert this change. In addition to checking random works I plan on checking in periodically through the weekend (I won't be constantly online), and then try to sum up on Sunday afternoon or evening. I propose that we try to live with any relatively minor problems through the weekend, and then evaluate based on the sum of all issues identified on Sunday. For any major or catastrophic issues, or if the sum of smaller issues (modulo workarounds) by Sunday is too large, we revert the change (and anyone with the permissions to make the edit should of course feel free to do so if needed).

And just to be tediously clear: the change in question is in the template that ProofreadPage uses between pages when it transcludes them into mainspace: MediaWiki:Proofreadpage pagenum template. The current version uses <span class="…" id="…" data-page-number="…" title="…"></span> (the attribute values are generated so I've replaced them with "…" here), and the change will be to insert a zero-width space inside the span tag: <span class="…" id="…" data-page-number="…" title="…">&#8203;</span>. --Xover (talk) 06:07, 7 June 2019 (UTC)

@Jan.Kamenicek, @Beleg Tâl: Done. Will start checking pages now. --Xover (talk) 17:13, 7 June 2019 (UTC)

Detected problems

• I do not know whether it is connected with the above described change, but I have detected a minor problem at R. U. R. (Rossum's Universal Robots)/Act 1: When I hover with the mouse pointer over the page number [17] in Firefox, the transcluded page is highlighted correctly, i.e. from the word "simplest" to the word "soul". However, when I do the same in Chrome, the transcluded page is highlighted incorrectly, beginning at "That's good". --Jan Kameníček (talk) 17:50, 7 June 2019 (UTC)
  • It is even more visible at The Labyrinth of the World and the Paradise of the Heart (1901)/Introduction when hovering over page numbers [14] and [15], which highlights completely non-sensical parts of text in Chrome. --Jan Kameníček (talk) 18:02, 7 June 2019 (UTC)
  • I'm pretty sure this is an existing bug in PageNumber.js with WebKit/Chromium-based browsers (Safari, Chrome, the next version of Edge). I routinely see that kind of thing in Safari, annd it's one of the reasons I'd like to Gadget-ize and rework PageNumber.js. --Xover (talk) 18:17, 7 June 2019 (UTC)
• At R. U. R. (Rossum's Universal Robots)/Act 2 the page number [62] still interferes with the header in Firefox. --Jan Kameníček (talk) 17:55, 7 June 2019 (UTC) (Ping Xover --Jan Kameníček (talk) 18:06, 7 June 2019 (UTC))
  • @Jan.Kamenicek: Could you try reloading the page and not click any of the pagenumbers options in the sidebar (don't switch layout etc.)? --Xover (talk) 18:23, 7 June 2019 (UTC)
    • To expand on this… What I'm seeing in Firefox is that on initial page load the page number displays fine and without overlapping the header (this is default layout set to 2). But if I use the portlet links to switch layouts, the page number starts overlapping the header. It happens in all layouts you activate (modulo other intentional layout differences) but for illustration you can toggle it around until you're in layout 2 again. Same layout, different rendering. The same happens if I toggle off and on again page number display. I haven't traced this precisely yet, but MediaWiki:PageNumbers.js contains code like page_span.innerHTML = self.proofreadpage_numbers_inline ? '' : '';. That is, it seems too assume the page number span is empty, and forcibly sets its contents to empty in some circumstances (the quoted code is an if…else statement that assigns the empty string in all cases). In other words, it looks like PageNumbers.js is undoing our would-be fix if you touch its options. Argh! --Xover (talk) 18:51, 7 June 2019 (UTC)

      @Xover: Hm, it is strange. When I open a page, e. g. R. U. R. (Rossum's Universal Robots)/Act 2 the page number does not ovelap with the header. Then I go to another subpage using a link in the navigation bar, e. g. to Act 3, and there I see the page number overlapping. Then I return back to Act 2 (again using a link in the navigation bar), and suddenly the page number overlaps the header here too, although it looked good before. --Jan Kameníček (talk) 20:20, 7 June 2019 (UTC)

      Very strange. I can't reproduce that here, and I can't immediately think what might explain that behaviour. Can there be some caching going from previous visits to those pages? (PS. heading off to bed soon, but will be looking into it further tomorrow.) --Xover (talk) 20:57, 7 June 2019 (UTC)

      Even stranger: it is not happening today! However, I doubt it was a caching problem, e. g. CTRL+R did not help. What is more, it behaved the opposite way than caching problems do: initial loading was OK, but after clicking to the following page the problem appeared and when returning back it appeared in that page too... Anyway, now it seems OK. --Jan Kameníček (talk) 07:39, 8 June 2019 (UTC)

Try the purge controls in the "More" list located left of the Search box. If that doesn't work, it may mean heavy server traffic, or it's being maintained. I added a {{Dhr}} on top of the page and that solved the problem. Browser purge is also affected by not being able to access the server at the time. Otherwise, don't bother with it. Ineuw (talk) 08:04, 8 June 2019 (UTC)

I know these possibilities but as Xover did not see the problem, I supposed it could not have been a problem of the server's cache. What is more, cache problem would appear immediately upon displaying the page, not as I have described. --Jan Kameníček (talk) 08:38, 8 June 2019 (UTC)

┌─────────────────────────────────┘
You are overthinking the issue. If it bothers you, bookmark the page and check it next day. Or, visit this talk page and post the question. Ineuw (talk) 09:11, 8 June 2019 (UTC)

So far as I know, the purge options all operate server-side; meaning any issues there should have shown up equally for Jan and myself. That they didn't suggest a high probability that whatever was going on was client related. That it disappeared overnight lends credence to it being some sort of caching issue. But that being said, I can't come up with any actually plausible explanation for how that might have caused the symptoms we observed.

Adding {{dhr}} doesn't actually solve anything, it just hides the problem. "dhr" inserts vertical whitespace, so the page number is still mispositioned by a number of pixels equal to the line height (as Beleg Tâl figured out) it's just that since it now hangs over an empty background instead of the header you don't notice it by just looking.

But overall, since the problems Jan saw went away overnight, I'd say our experiment so far is actually a success. We haven't fixed everything, but what has changed is all an improvement. On a fresh load of a page the page number displays correctly where it didn't before. And I have hopes PageNumbers.js is possible to change in such a way that it doesn't reverse our fix the second you start fiddling with its options.

With the world's worst timing I seem to have caught some kind of flu, so my ability to reliably debug javascript is a bit… compromised; but based on what I've seen so far, and what's been reported here, it looks very promising. --Xover (talk) 10:39, 8 June 2019 (UTC)

Summary after a couple of days of testing

Somewhat later then planned due to the undersigned being curled up under a blanket munching paracetamol like candy…

The change to MediaWiki:Proofreadpage pagenum template has been live for several days with some improved results and no obvious ill effect. Some pages that were misrendered before are now rendered correctly on first page load, but go back to the original incorrect rendering under certain circumstances. In other words, while the change does not solve everything it is a clear net improvement and I see no reason to revert back to the prior status quo.

My debugging so far has been a bit hampered, but I'm reasonably certain that all or a significant part of the lingering issues are caused by MediaWiki:PageNumbers.js. It loads unconditionally from MediaWiki:Common.js but in such a way that it does not always run predictably on all page loads (it is timing-dependent), and when it runs it makes incorrect assumptions about the contents of MediaWiki:Proofreadpage pagenum template that ends up undoing the change we made. I am currently looking into ways we can debug it in a sane way and thus enable us to fix the bug hampering this fix. (as a bonus, that might also enable us to turn it into a gadget and more easily fix bugs, add or tweak layouts, etc.). If the problem is what I think it is, the fix would be a relatively small change and should be easy for someone with the right permissions to add (*cough*billinghurst*cough*).

All in all I'd call this a qualified success. Big thanks to everyone that helped out at all stages of this! And please continue to be on the lookout for problems that might be related to this that we might have missed. --Xover (talk) 08:28, 11 June 2019 (UTC)

Talk pages consultation: Phase 2

The Wikimedia Foundation is currently conducting a global consultation about communication. The goal is to bring Wikimedians and wiki-minded people together to improve tools for communication.

Phase 1 of the consultation is over – thank you to everyone who participated! – and we've published the Phase 1 report. The report summarizes what people have said and what we've learned, proposes a direction for the project, and asks specific questions to explore in Phase 2.

Very briefly, the proposed direction is that wikitext talk pages should be improved, and not replaced. We propose building a new design on top of talk pages that changes the page's default appearance, and offers key tools like replying, indenting and signing posts. To keep consistency with existing tools, the new design will be a default experience that existing users can opt out of. We also propose building features that experienced contributors want, including the ability to watchlist a single discussion, and the ability to move, archive and search for threads. Building these features may require some loss of flexibility, or small-to-medium changes in wikitext conventions. The goal is to only make changes that directly enable functionality that users really want.

You can see more information and discussion about the proposed direction in the Phase 1 report, including the results of new user tests and some of the quotations from Phase 1 discussions that led to this proposal.

Now it's time to start Phase 2!

We have six questions to discuss in Phase 2, asking for reactions to the proposed direction, and pros and cons for specific changes that we could make.

You can help by hosting a discussion at your wiki. Here's what to do:

1. First, sign up your group here.
2. Next, create a page (or a section on a Village pump, or an e-mail thread – whatever is natural for your group) to collect information from other people in your group.
3. Then start the conversation with the six questions listed in the Questions for Phase 2 section of the report.
4. When the conversation is concluded, the host should write a summary of the discussion on the Phase 2 community discussion summaries page, and report what you learned from your group. Please include links if the discussion is available to the public.

You can read more about the overall process on MediaWiki.org. If you have questions or ideas, you can leave feedback about the consultation process in the language you prefer.

Thank you! We're looking forward to talking with you. DannyH (WMF) (talk) 17:49, 17 May 2019 (UTC)

Discussion of Phase 2

Please proceed to discuss the following points:

1. What do you think of the proposed product direction?

Context: The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.

Question: What do you think of this product direction?

I think this is the only reasonable solution. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

This will only be feasible it if results in valid and correct list markup. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:23, 18 May 2019 (UTC)

The way this proposal is phrased makes me think this will be implemented only on Talk pages, not all pages used for discussion. If this is the case (and I can't tell) then the proposal will have little impact on this project, since en.WS uses the Talk pages very little and prefers a few centralized discussion pages. --EncycloPetey (talk) 14:09, 18 May 2019 (UTC)

2. Marking separate discussions

Context: People want to watch individual sections on the talk page. They want better notifications, archiving, and search. To do any of this, we may need to create a more structured definition of what counts as a single discussion. This may mean making changes to the wikitext conventions on a talk page. For example, we may create a new way that discussion headings look in wikitext, or a new link that you need to use to create, rename or split a thread.

Question: What are the advantages and disadvantages of that approach?

The best way to accomplish this currently is to have a page for each discussion, and transclude all the discussion pages onto a single main page. Commons does this with deletion proposals for example, and Wikidata does this for property creation proposals. On Wikisource we use this approach for transcluding works, but not for discussions. I think that this would be a good approach for accomplishing this particular goal, but it would have to be streamlined. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

3. Helping newcomers find the talk pages

Context: Newcomers have difficulty finding talk pages. During user tests, only one person out of ten found the Discussion tab. Most testers looked for a Discussion tab on the opposite side of the page, where all of the other tabs and links are. Many people also expected to see links to discussions about specific sections in the article. We may want to move the link to the talk page to the opposite side of the article page. We might add discussion functionality connected to individual sections.

Question: What are the advantages and disadvantages of making the connection between article content and discussions more visible?

Improving the ability of newcomers to find the right location for a discussion is always a good thing. Experienced editors will get used to such a change (or a gadget or preference can allow them to disable the change for themselves personally). However, having discussions for every single section of content would only add to our problem of having way too many talk locations, and doesn't really make sense on Wikisource anyway. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

yeah, i’m finding new editors don’t know what a talk page is, where to find it, how to use it, or why bother. they do not respond to wikilove, or pings. the new generation of editors will edit only at meetups, and then collaborate on etherpad, or twitter, or telegram, never a talk page. it is all become "dark forest", might have to promote talk page interaction as fun, or moderated, in order to get some functional discussion on talk pages. Slowking4 ‽ SvG's revenge 21:26, 27 May 2019 (UTC)

4. Where to show discussion tools

Context: Currently, many wikis have community discussion spaces in the project namespace (Wikisource or Wikipedia:), rather than in a talk namespace (Wikisource talk or Wikipedia talk:). The project namespace is often used for village pumps/cafés, noticeboards, and some workflows, such as Articles for deletion. The system will need to know where discussions happen, so that it can display the new tools in those discussions, and not display them on other pages. There are several potential ways to do this. One of them is to move all discussions to a talk namespace.

Question: What are the advantages and disadvantages of doing that?

I have no opinion on this —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

need to streamline tools and talk templates, so they do not break talk pages as being too large. the custom templates will need a re-code to transclude if linked to. Slowking4 ‽ SvG's revenge 21:15, 27 May 2019 (UTC)

5. History tradeoffs

Context: Sometimes, you need to see the history of the entire page. Other times, it would be more helpful to see the history of only a single discussion thread. It would be ideal if we could provide both, but we're not sure how to do that.

Question: What are the advantages and disadvantages of having a complete page history or a specific thread history?

In some places (like the Scriptorium or WS:PD) the history of a single discussion is more important than the full page history, but it's necessary to also see the full page history in order to deal with (for example) vandals who modify the whole page. — This problem could be dealt with by having each discussion on its own subpage, transcluded onto the main page, and then implementing some sort of "include subpages" functionality in page history? —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

thanks are for a single talk diff. veterans use diffs for history, to reduce the confusion of who said what when. confusion in many conversations is widespread. Slowking4 ‽ SvG's revenge 21:15, 27 May 2019 (UTC)

6. Metadata location

Context: Some wikis place templates at the top of article talk pages. These may show instructions, warnings, or FAQs. They may hold page quality information, link to relevant WikiProjects, or identify past activities. Many new users are confused by finding non-discussion material at the top of an article talk page. It would be helpful to move some or all of that content somewhere else on the page, or under a different tab.

Question: What are the advantages and disadvantages of that approach? Which templates are crucial for the proper use of a discussion page, and which could be moved somewhere else?

On Wikisource, this would only be {{TextInfo}} for content pages. We also list sources for biographical info on Author talk pages, and style guides on Index talk pages, but we generally structure these as discussions anyway. —Beleg Tâl (talk) 11:04, 18 May 2019 (UTC)

A separate tab would be good (I have already suggested this for Wikidata), provided that relevant content may be transclued to the top of the talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 18 May 2019 (UTC)

Wikisource uses Talk pages only seldom for any discussion; we use them to store significant source information instead. A separate tab for discussion would be of little to no value.

Is this really a Wikimedia-wide problem, or is this just a problem on the Wikipedias? Perhaps only the Wikipedias need a separate tab/namespace for their pages. The other projects I work on don't have this issue. --EncycloPetey (talk) 14:11, 18 May 2019 (UTC)

It's not "just" the Wikipedias, but it is only some wikis, and the English Wikipedia is the biggest example.

One way of doing this might let us move the wikitext codes for categories out of the page, too. Imagine if Category:1887 works was attached to a page as its own property (like, e.g., the page title already is) and didn't have to be specified via category or template.

I would really appreciate it if one of you would summarize Wikisource's general views on these questions at the page linked in the message below. Whatamidoing (WMF) (talk) 05:01, 2 July 2019 (UTC)

Consultation is over

Hello

First of all, thank you for hosting that conversation on your wiki. We really value the work you've done!

The consultation is now over. We have received a lot of feedback, that require a lot of work and time to be summarize. We have decided to postpone communities summaries' due date to Monday June 24.

A page has been created to host communities summaries. Please add yours there.

If you have any question, please contact me.

On behalf of the Talk pages consultation team, Trizek (WMF) (talk) 08:57, 17 June 2019 (UTC)

Questions

Two questions re: [17]:

• Since when are we prohibited from including links to PDFs of sources?
• Since when are admins allowed to use their admin tools in content disputes in which they are involved?

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 18 May 2019 (UTC)

The BHL link is not a link to a PDF, it is a link to a database that also has a PDF. This information and link is stored on the data item for the work at Wikidata. There is no reason to duplicate the information here; Wikisource is not a link farm.

You have been resisting advice on Author pages since you arrived here, and have declined repeatdly to discuss the issue each time it was brought to your attention. You instead chose to communicate only through repeatedly reverting. This is a basis for blocking an editor, but I chose instead to merely protect the page. --EncycloPetey (talk) 19:16, 18 May 2019 (UTC)

perhaps this link [18] or this [19] is "allowable" ? but do not see the point of reverting links rather than uploading to commons and replacing. do you really want to say "see how restrained i am, i did not block you?" Slowking4 ‽ SvG's revenge 10:45, 20 May 2019 (UTC)

Direct link to an external PDF is better than a link to a page at Wikidata with the link to external PDF (as many people are not familiar with WD). The form of the link introduced at [20] was not very good, much better is the form of external links e. g. at Author:Max Stirner, but this can be solved in a better way than a simple revert. Locking the page as a mean of forcing one's own version in a content dispute is generally harmful. If necessary (which was not our case) it should always be done by an independent admin.
As for the "basis for blocking an editor": I can see there 2 reverts by User:Pigsonthewing and 3 reverts by User:EncycloPetey. Wikisource policy regarding this issue is described at Wikisource:Blocking policy#Excessive reverts. --Jan Kameníček (talk) 12:38, 20 May 2019 (UTC)

Direct link, yes, to a scanned file, but not to a database where the reader must then follow additional links to reach the scan. The BHL link is a link to a database, not to a PDF. So any objection to a Wikidata link would apply equally to a BHL link. The Wikidata link has the advantage of providing all the links, whereas BHL is only BHL, and the user must still follow additional links to reach the scan, and the user must be familiar with BHL to do so. The preference is to upload a file to Commons and host a copy here.

External scan links on an Author are always a temporary thing or a secondary level. The goal of Wikisource is to host works in the Mainspace. The Author pages are a secondary tier of content to support the Mainspace, and external links are temporary links to sources of content, in preparation for hosting that content here. We have in the past allowed links to Google scans or to Internet Archive scans using {{Ext scan link}}, but not links to databases such as BHL, or adding DOI links, or other database identifiers (which should be hosted at Wikidata), for this is a misuse of what the Author pages have always been intended to do.

Andy Mabbett has been abusing external linking on Author pages, such as at Author:Alexander Reid Urquhart and Author:Marcus Ward Lyon (1875-1942), with excessive external linking to multiple databases. This isn't linking to a scan; it is adding multiple remote database identifiedrs for a single work to an Author page on Wikisource, instead of placing them on the work's data item at Wikidata, which is where the data belongs.

See further the Help:Author pages and Wikisource:Style Guide, which explain what the Author page is intended for: listing the works and linking to the main page of the work. Neither page recommends the addition of external linking as a function of the Author pages. You can see my attempt to discuss this issue, but no discussion was forthcoming. This is not the first time I have gotten no reply when starting a discussion; you can see that most of the previous discussions which I started (missing images, house style, ...) received no replies either. Disputes cannot be resolved through discussion when one party habitually refuses to discuss.

In this situation, the problem should now be resolved as I have uploaded the desired work to Commons and set up a transcription Index. No external links to the work are now required. --EncycloPetey (talk) 13:46, 20 May 2019 (UTC)

@EncycloPetey:I agree with many points you have mentioned, though with several buts.

You are absolutely right that it was a link to a database and not to the scan. However, the scan was just one click farther, so the contributor might have been asked to replace the link for a more accurate one instead of removing it and following with an edit war.

You are also right that external links are just temporary. I understand that their main purpose is to show contributors where the work is available to be added to Wikisource.

I was reacting only to this specific case, I know nothing about other Andy Mabbetts contributions.

It is true that the mentioned help pages do not say anything about external links in Author pages. However, current practice is different and external links showing where the work can be obtained to be added here are frequently used and nobody seems to be removing unless they are substituted at least by a downloaded scan. IMO, they can be useful, although the scan or even the proofread work instead of the link are much better.

Your final solution by uploading the work to Commons is perfect. --Jan Kameníček (talk) 17:24, 20 May 2019 (UTC)

"You have been resisting advice on Author pages..." I note that this allegation is made without any supporting diffs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 20 May 2019 (UTC)

Do you deny the allegation, or simply question its delivery for the purpose of wiki-lawyering? If I thought the diffs would result in a change in your editing practices, I would trawl through for them. But up to this point, you have failed to respond to discussion (see your Talk page), or have hedged, or have turned to ad hominem (again, see your own Talk page). This being the case, there seems little point in providing the diffs, as I cannot believe it will improve your editing. --EncycloPetey (talk) 16:36, 20 May 2019 (UTC)

Diffs, please. And I'm happy to respond to discussions: you have yet to initiate one on my talk page; mostly posting instructions. As for wiki-lawyering, having been caught with your fingers in the admin-tool-abuse cookie jar, it is you and you alone who is doing that; and resorting to ad hominem.. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 20 May 2019 (UTC)

You didn't answer my question. --EncycloPetey (talk) 17:10, 20 May 2019 (UTC)

i’m sad that you are engaging in this way. you very well know PotW is stubborn; why then are you edit warring, and locking pages? this is how admins act over on commons, i expected better here. we should be modeling good behavior and showing deep link or wikisource link, not reverting a general list link, these can be added to a work list. we need some admin faciltators; is that a style of leadership you are prepared to try? Slowking4 ‽ SvG's revenge 18:31, 20 May 2019 (UTC)

I tried offering alternatives, but was unacknowledged. I demonstrated setting up an Index page for transcription, which is the Wikisource goal. --EncycloPetey (talk) 19:36, 20 May 2019 (UTC)

why don’t you offer an alternative to locking an author page? what is the justification for a one month admin lock on an author page? do you want only admins to edit this site? Slowking4 ‽ SvG's revenge 17:18, 24 May 2019 (UTC)

I did offer alternatives. Twice. And I initiated dialog on the issue, to which the response was being told to go away and reverts. Also, the page was locked for only 14 days, not a month, which I had hoped would be sufficient time for a dialog to begin on the issue of database linking, which was the crux of the disagreement. Perhaps unsurprisingly, that dialog has still not happened, except for the replies by Jan.Kamenicek above. Did you have any comment to offer on that issue?

In any event, Wikisource:Protection policy advises the protection of pages which become host to an edit war "until the users resolve their dispute through discussion". At this point, Andy Mabbett has not participated in the discussion of the issue, and has refused to do so. --EncycloPetey (talk) 20:59, 25 May 2019 (UTC)

i’m sorry, i do not find that response adequate. i do not see a "issue of database linking" consensus standard of practice. you should expect more "non-participation" when you roll out the lock tools to stop discussion. should your standard of practice become the norm here, i would reconsider my participation. Slowking4 ‽ SvG's revenge 23:38, 25 May 2019 (UTC)

How can there be consensus if you will not discuss it, and Andy will not discuss it? I have initiated discussion several times. The issue is also one of the two points upon which this very thread was started, yet only Jan.Kamenicek and I have discussed that issue. --EncycloPetey (talk) 23:47, 25 May 2019 (UTC)

I note that diffs have still not been provided. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:14, 22 May 2019 (UTC)

I note that diffs have still not been provided. I also note that this review is still open. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:59, 25 May 2019 (UTC)

I find it ironic that an editor is demanding diffs in a thread he started by making unsubstantiated accusations. If you believe some Wikisource policy has been violated, then please identify it. Otherwise, please apologize. --EncycloPetey (talk) 23:02, 25 May 2019 (UTC)

i find it ironic to critique the participation of an editor, while denying participation. Slowking4 ‽ SvG's revenge 23:46, 25 May 2019 (UTC)

Diffs

Since diffs have been requested…

On 18 May Andy added a new work to Author:Lyman Belding in this series of edits: 1, 2, 3. In addition to listing the work itself the edits add a DOI using {{DOI}} and a bare URL to biodiversitylibrary.org. A few minutes later EncycloPetey, presumably while patrolling the recent changes feed, removes the links with the edit summary BHL and DOI links belong on Wikidata item for the work, not on the Author page. Four minutes later they open a thread on Andy's talk page explaining their reasoning and suggesting alternate methods to achieve the apparent goal. 16 minutes later Andy reverts EncycloPetey's change to Author:Lyman Belding with the edit summary BHL provide a PDF of the full work. EncycloPetey then reverts and instead adds a {{wikidata edition}} as they had previously suggested on Andy's talk page. Two minutes later Andy reverts with the summary restore link to page containing PDF of full work. EncycloPetey now reverts and protects the page, and posts the addendum Wikisource is not a link farm. Please use Wikidata for metadata links. on Andy's talk page. At this point—22 minutes and 2 reverts after they received the first message on their talk page, but just 2 minutes after the author page was protected—Andy responds on their talk page with Work on improving your tone; and assume good faith.. EncycloPetey responds with Feel free to follow your own advice.. One minute later Andy opens this thread questioning EncycloPetey's conduct, and then replies on their talk page with Don't post here again until you have sufficiently addressed the above.. Four minutes later EncycloPetey responds to this thread explaining their reasoning and their complaint with Andy's actions.

At no point during these edits do I see any attempt by Andy to discuss this issue or the related actions, despite EncycloPetey's attempt to start such a discussion on their talk page. The two replies on their talk page are not responsive to the issue raised, and this thread is a complaint regarding EncycloPetey's conduct rather than addressing the actual issue in disagreement.

The full list of diffs (all times in UTC):

• Pigsonthewing@18:36, 18 May 2019: /* Works */: Land Birds of the Pacific District
• Pigsonthewing@18:38, 18 May 2019: /* Works */: c
• Pigsonthewing@18:39, 18 May 2019: DOI
• EncycloPetey@18:41, 18 May 2019: BHL and DOI links belong on Wikidata item for the work, not on the Author page
• EncycloPetey@18:45, 18 May 2019: /* DOI and BHL */: new section
• Pigsonthewing@19:01, 18 May 2019: Undo revision 9262075 by EncycloPetey (talk) BHL provide a PDF of the full work
• EncycloPetey@19:01, 18 May 2019: Reverted edits by Pigsonthewing (talk) to last revision by EncycloPetey
• EncycloPetey@19:01, 18 May 2019: /* Works */: WD edition
• EncycloPetey@19:02, 18 May 2019: /* Works */:
• Pigsonthewing@19:03, 18 May 2019: restore link to page containing PDF of full work
• EncycloPetey@19:04, 18 May 2019: Reverted edits by Pigsonthewing (talk) to last revision by EncycloPetey
• EncycloPetey@19:05, 18 May 2019: Protected "Author:Lyman Belding": Counter-productive edit warring ([Edit=Allow only administrators] (expires 19:05, 1 June 2019 (UTC)) [Move=Allow only administrators] (expires 19:05, 1 June 2019 (UTC)))
• EncycloPetey@19:05, 18 May 2019: /* DOI and BHL */:
• Pigsonthewing@19:07, 18 May 2019: /* DOI and BHL */: c
• EncycloPetey@19:09, 18 May 2019: /* DOI and BHL */:
• Pigsonthewing@19:10, 18 May 2019: /* Questions */: new section
• Pigsonthewing@19:12, 18 May 2019: /* DOI and BHL */: c
• EncycloPetey@19:16, 18 May 2019: /* Questions */:

I'll also note that EncycloPetey has previously attempted to discuss, assist, and facilitate on Andy's talk page with no apparent response. --Xover (talk) 08:00, 26 May 2019 (UTC)

The accusation for which diffs were requested was "You have been resisting advice on Author pages since you arrived here". Which of your collection of diffs do you suppose supports that allegation?

One of my earlier questions was "Since when are admins allowed to use their admin tools in content disputes in which they are involved?". What's your answer to that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 26 May 2019 (UTC)

Your first question is a matter of moving the goalposts. You started this thread over two questions, and both have been answered satisfactorily. Yes, your second question has already received a reply above. You asked: "Since when are admins allowed.." and the answer is that it has never been disallowed. You were challenged to present policy that says otherwise, or to apologize for your unsupported accusations of misconduct. You have not responded to that reply, but have simply stated the original question again. It is not clear yet whether you are dodging the issue or begging the question. --EncycloPetey (talk) 23:36, 27 May 2019 (UTC)

My second question has indeed received a reply above; Jan wrote Locking the page as a mean of forcing one's own version in a content dispute is generally harmful. If necessary (which was not our case) it should always be done by an independent admin. However, in this case, I was - quite clearly - asking Xover for their response. And still no diffs to support your allegaton... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 28 May 2019 (UTC)

So you are now accepting a person's opinion as if it were true and policy, without supporting evidence? Will people's post facto opinions be the deciding factor for you, rather than Wikisource policy? And will you accept these opinions without supporting evidence or diffs? If so, then why are you asking for diffs? --EncycloPetey (talk) 01:11, 29 May 2019 (UTC)

 Comment

1. This argument has elements of two people trying to defend their actions and such will always be combative. Could we focus on a discussion on what we need for Wikisource, and the readers. This is in terms of information available, and readable pages, and something that is maintainable. I reckon that you two will agree on a lot, so let us tease apart where we disagree.
2. Administrators operate on the consensus of the community. It has been my intended practice (though probably imperfect) that where I am getting into a reasoned dispute, that I look to bring the matter to the community. Difficult at times, though useful for broader opinion.
3. I would like to think that we can resolve our disputes with less (no?) vitriol if we are focusing on what is the best output for users and editors. — billinghurst sDrewth 21:44, 30 May 2019 (UTC)

i agree. i regret i do not see any sign either of these editors will drop the stick long enough to come to a consensus about a way forward. (you very well could have a guideline about deeplinks on author pages) what then is the community going to do about community health? trouts all around does not seem to work. and rest assured this lack of civility will fester, if we do not deal with it. Slowking4 ‽ SvG's revenge 17:05, 31 May 2019 (UTC)

Ongoing issues

EncycloPetey is now removing (and has done so three times, so far: [21], [22], [23]; each time with the edit summary "cleanup") publisher details which I have included in a list of works at Author:Frederick W. Lanchester, a page I recently created.

I note that publisher details are often included in author pages without drama, for example: Author:Henry Eliot Howard; Author:Brooks Adams; Author:Choudhary Rahmat Ali.

I note also that diffs supporting the accusation he made about, above, me have still not been provided, nor has that accusation been withdrawn. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:19, 9 June 2019 (UTC)

The fact that other pages have not been cleaned up is not a valid reason for preventing the cleaning up of pages. Metadata belongs at Wikidata, or can be placed in the header of a work's Mainspace page. It should not be stored on Author pages. Note that comparing data for books with data for journal articles is not an equivalent comparison; journal articles require data that books do not. --EncycloPetey (talk) 14:25, 9 June 2019 (UTC)

Removing anything but the title, which many others including myself have deliberately and purposefully added. Where and when was that decided, or are you just announcing that this is "better" now? CYGNIS INSIGNIS 19:37, 9 June 2019 (UTC)

See Help:Author pages#Works by the author. --Jan Kameníček (talk) 20:01, 9 June 2019 (UTC)

Hi Jan, thanks I suppose, but note I am not new here. The page provides a helpful suggestion, not a consensus of unilateral decision to define what goes there: are we seeing different things? Nevertheless, that is a help page that has been edited with a view, in my view, to retroactively applying a consensus of one as if that were policy anywhere else but in a users head; the history shows that one's admins view is contested by another. These are the pages I should be watching after a decade of sporadic contributions. CYGNIS INSIGNIS 20:40, 9 June 2019 (UTC)

@Cygnis insignis: Misrepresenting the issue does not help. --EncycloPetey (talk) 20:37, 9 June 2019 (UTC)

Is that not what is happening, then I apologise. CYGNIS INSIGNIS 20:40, 9 June 2019 (UTC)

@EncycloPetey: user complained that publisher info was removed, that it what I see in the history and current page. CYGNIS INSIGNIS 21:10, 9 June 2019 (UTC)

[edit conflict] You may not have noticed two relevant points in the issue: (1) The metadata was added to the page as part of a copy-paste of information at Wikipedia. No attempt was made to reformat the data for Wikisource by the original contributor at that time; it was just copy-paste. (2) One of my alterations was to select a much higher quality scan at IA in place of the one copy-pasted from WP. The original link was to a low-quality Google scan from which all the images had been stripped. Part of my cleanup was to link to a much higher quality scan made from the Univ. of California collections, and which included the missing images. I noted this in my edit summaries, but had my selection reverted [24] [25] to the low-quality scan missing its images.

Only the edition-specific information of publisher and city of publication for four books were removed; and a higher-quality scan was selected. Some publication information, such as "Limited ed. of 640 copies", was left in place, as a kind of explanation to the reader as to why no scan was linked and also might be difficult to locate. Where it is relevant, information specific to particular editions can be included, such as in the header notes of a work to clarify the source, or on a versions page where it is necessary to distinguish between editions, but in most cases edition-specific metadata is clutter on an Author page.

The primary function of the Author page is to direct the reader to works by the Author that are hosted on Wikisource, as well as to works about the Author. Metadata specific to editions is not data about the Author, and belongs on the work's Mainspace page (in the header notes) or on Wikidata in the data item for that edition. --EncycloPetey (talk) 21:17, 9 June 2019 (UTC)

"Misrepresenting the issue does not help", says EncycloPetey, then goes on to do just that. He claims "Part of my cleanup was to link to a much higher quality scan... but had my selection reverted... to the low-quality scan...", but neglects to show the diff where, after reverting his removal of publisher data, I reinstated the link to the better scan: [26] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 June 2019 (UTC)

He also says "[publisher metadata] belongs on the work's Mainspace page (in the header notes) or on Wikidata in the data item for that edition", neglecting to mention that, for the works in question, neither of those things yet exist. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:27, 9 June 2019 (UTC)

That is because it is bluff, you are a newb here aren't you :) EP is not the king, I am. CYGNIS INSIGNIS 22:32, 9 June 2019 (UTC)

Ja, this is the point I came to make, and forgot to note when told I was misrepresenting what I could see Andy was doing. I also have an allergy to that sort of thing. CYGNIS INSIGNIS 22:21, 9 June 2019 (UTC)

@Pigsonthewing: please don't thank me, I'm not especially sympathetic and not aware why I would value that response. Its worth noting my last interaction with this user: I responded to a request to help with ids of some birds at commons, the requests for rotation were met with reverts and notification at a notice board (to the astonishment of myself and others). Petey makes exceptional contributions that I read and value, which I think it also worth repeating. CYGNIS INSIGNIS 21:06, 9 June 2019 (UTC)

I wasn't thanking you for any perceived sympathy, but for making a cogent point. I'm not sure how your baseless umbrage-taking over a commons issue is relevant here, but I recall that maintaining the original orientation of the images in question was already being discussed at Common's Village Pump (not a "noticeboard"), starting at 11:30 am on 11 May, well before you proposed rotating them, at around 9pm that day. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:04, 9 June 2019 (UTC)

Not much patience for tire kicking mate, not when a user has over a decade of wiki contributions and comes to this library making noise. Maybe your request at wikipedia should have noted rotation was unwelcome, or you could have hit on the solution of non-rotated versions, instead of insisting that that anyone reading that authors handwritten personal notes sideways and birdies with their legs in the air. CYGNIS INSIGNIS 22:18, 9 June 2019 (UTC)

I've no idea to which "request at wikipedia" you refer, but on Commons, my edit summaries referred you directly to the discussion on Village Pump, where the matter - including the possiblty of hosting rotated duplicates - was already under discussion, as your own comment there confirms. This is still not relevant to Wikisource, and if you wish to persue it I invite you to pick a more suitable venue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 9 June 2019 (UTC)

The bird project, if I recall correctly. Don't be insubordinate. CYGNIS INSIGNIS 22:35, 9 June 2019 (UTC)

I have just added to an author page this markup: * {{DNB link|Logan, William Edmond}}, which renders as:

• "Logan, William Edmond," in Dictionary of National Biography, 1885-1900, London: Smith, Elder, & Co. (1885–1900) in 63 vols.

in particular: London: Smith, Elder, & Co., (1885–1900) in 63 vols, which seems to be at odds with the claim that "Metadata belongs [only] at Wikidata..."; and the reverts linked above, especially as (unlike in those examples) the target Wikisource page and Wikidata item each already exist. Perhaps our widely-used DNB template needs "cleaning up"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:37, 14 June 2019 (UTC)

No, it doesn't. CYGNIS INSIGNIS 19:37, 14 June 2019 (UTC)?

Right. So can the publisher details be restored to the works on Author:Frederick W. Lanchester? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 14 June 2019 (UTC)

Of course, Mr. Mabbett, because it was obviously well intentioned and not vandalism, but restoring this example is arguably not allowed if EP says otherwise. Attempts to alter that situation, tacitly endorsed in the documentation, were resisted. The inaction of others in formulations of a verifiable consensus is a concern, but in the absence of that any action is fraught with unintentional consequences. And you, of course, recognise all this without me restating it, and there are few good options when being accused of vandalism. Your sincerely, CYGNIS INSIGNIS 17:10, 15 June 2019 (UTC)

"arguably not allowed if EP says otherwise" go on, then, let's hear the arguments for that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:57, 15 June 2019 (UTC)

I think you have heard them, such as they are, others find them unpersuasive. Would you like me to ping those I am aware of who have expressed views on this? @Xover: is currently holding the talking stick, by disputing the changes made to the only relevant page, but there are others who hold clearer views on where authority lies in relation to 'established' and sysop access users. CYGNIS INSIGNIS 20:31, 15 June 2019 (UTC)

My apologies Cygnis insignis, your ping did not generate a notification for me for some reason and my available on-wiki time has been consumed elsewhere the last few days. I'm afraid I do not know what you mean by "… currently holding the talking stick, by disputing the changes made to the only relevant page." I attempted to participate in one policy-related discussion, but as you characterised my contribution there as "… rude af in your assumptions and aspersions, also discouraging to any solution." I opted to step away. If there is some other issue for which my input is holding up progress I am not aware of it. --Xover (talk) 06:52, 17 June 2019 (UTC)

"If there is some other issue..." Well, you haven't answered the questions I asked you on 26 May. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 06:53, 18 June 2019 (UTC)

@Pigsonthewing: Personally, I don't think it makes sense to mention publishers when listing an author's works. It's a list of works, not a list of publications. For example, it wouldn't make sense to list the 50+ editions of On the Origin of Species at Author:Charles Robert Darwin. Instead, we link from his author page to a list of the editions: On the Origin of Species. That is where the publisher information belongs (and on the index pages, e.g. On the Origin of Species (1859)). At the author level, we don't deal with specific editions or specific publications of a work, we're just dealing with the works themselves, i.e. the intellectual creations of the authors. Of course, we typically link to specific editions from the author page (especially when only one edition has been published), but that is just giving an example of the work. It doesn't represent the work definitively, as other editions may be published in the future. We also shouldn't list the publisher at the author level because it can be misleading, implying that the work was only published once by a single publisher (which often isn't true). FWIW, Wikidata seems to sometimes, but rarely, acknowledge a separation between works and editions, e.g. wikidata:Q20124. Kaldari (talk) 14:32, 2 July 2019 (UTC)

That's a reasonable viewpoint, though others clearly disagree with you; and "published once by a single publisher" apparently applies in at least one of the cases at hand. But this is discussion of abusive admin behaviour, not styles. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:52, 2 July 2019 (UTC)