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

How many files should we load?[edit]

I have a tendency to like to upload files and prepare stuff more than I like to tediously proof them all out. I've been wondering about how problematic certain things are relative to that. I've got three slightly different examples:

  1. Index:Weird Tales v01n01 (1923-03).djvu. We have a whole new year of Weird Tales we could load, scans available, with Lovecraft and some still-reprinted authors like Clark Ashton Smith and Seabury Quinn. But as you can see, the very first issue that went PD last year is still largely a work in progress, with later 1923 issues looking worse. I see some of the decades later issues, loaded due to non-renewal, getting proofed today (1st of Feb.). Should I just load the 1924 Weird Tales; that'll give us clear sourcing for some works we have random Internet copies, and better to make them available if someone wants to proof them. Or we should try and get what we have proofed before we work on later material? (And are the 1930s issues, like Index:Weird Tales volume 32 number 05.djvu, at all relevant to this discussion?)
  2. Index:O Henry Prize Stories of 1924.djvu was loaded for scans of one story, The Most Dangerous Game. It is, however, a notable anthology in its own right, full of works by not-unnotable authors. We should finish it, and could go back to 1919, and forward as far as copyright will let us. Should we expect that this be completed before we load other works in this series?
  3. Index:Greatest Short Stories (1915).djvu was loaded because I was on a short story kick, and I plan on finishing the stuff we don't have other sources for. It's nice to see The Man in the Reservoir, something felt valuable at the time and mostly forgotten now. I don't see any point in working on this unnotable anthology's version of The Murders in the Rue Morgue, or other stories we have perfectly good copies of. (It's also unscholarly; no indication is made of editor(s) or sources.)
    Basically, is intent to but partially complete scans a stopping point for some people? There's a lot of anthologies and magazines where one article or story would be nice to have, and I don't expect the rest to ever be worth anyone's time to transcribe it. I hate it when one piece is separated into a PDF, though, because that strips it of its context, perhaps even from its proper sourcing, and often some other part may be valuable enough to someone else to work on.

I'm not looking for hard rules; I'd just like to understand community feeling and opinion on this matter.--Prosfilaes (talk) 22:50, 1 February 2020 (UTC)

I'm not quite clear what your worries are, which suggests that I'm not worried about them. It seems to boil down to "should we upload scans if we won't use all of it?" and "should we upload scans if previous works in a series have not been completed?"
In answer to those two questions, I'd say "sure, why not?" It doesn't hurt anyone. It doesn't help readers wanting the not-done texts either, but you should focus your energy on works you are motivated by, not struggle slowly through stuff you don't care about.
I would say that if you upload a scan and don't intend to fully use it yourself, you should make reasonably sure it's discoverable, such as on versions and author pages. This will help prevent duplication, but more positively, it presents a new, easier route for newbies to join. For example, I myself first got hooked on WS when I found an unstarted scan of The Rainbow. No complicated uploads, I just got on with proofreading! BethNaught (talk) 23:04, 1 February 2020 (UTC)
Okay. The one thing I'd point out is that I feel that if Weird Tales, Vol. 1, Issue 1 was the only incomplete issue available, it would much more likely to be complete now. I'm concerned that if we upload all dozen or so issues pre-1925, it might lead to people working arbitrarily and getting burned out because the field is hard and it feels so solo, instead of all the people working on Weird Tales being concentrated on one issue. All these examples were collections, but if there's a dozen novels by one author, we're more likely to accumulate unused work and lose people who feel overwhelmed if the seven interested users each tackled a different novel then just working on one at a time. That's my main reason for "why not".--Prosfilaes (talk) 23:32, 1 February 2020 (UTC)
You make a good point, particularly about the example of the novels. Different personalities will respond to that differently, and I've mostly taken a solo approach to transcriptions so I don't have that perspective.
But just because you have multiple scans uploaded, doesn't mean people can't collaborate; it just makes it less likely. I think this raises a broader question about encouraging and facilitating collaborative projects. We have PotM and the Community Collaboration, but that's rather top-down. Would it be helpful to have an easier forum for organising ad-hoc collaborations? Or, for example, a Weird Tales WikiProject—except that WikiProjects here seem a bit dead. BethNaught (talk) 23:54, 1 February 2020 (UTC)
  • Pictogram voting comment.svg Comment Have what you want is my thoughts. To me it is not about the incompleteness, but how and where is the incompleteness. Having a mess in the main namespace is problematic, as I see it, having things less tidy in the Page: ns is okay, it isn't our front facing space.

    I have had works that I have been working on for ten years. Some I get back to, some I do not. Some because the formatting is tedious, though the work is important; some because I get sick of doing tables; some because I get sick of speech and quotations; sometimes because of something bright and shiny.

    What I think that is important is where the work sits. If it is all in the Index: and Page: namespace and is incomplete, then no worries. If it is partially transcluded, then the bits work well, or are easily understood if someone want to continue with the work. What I hate is someone who transcribes some pages, and then trancludes the pages with redlinks. Or equally as bad is just load the text not proofread into Page: ns, and transclude it. Not having fully featured headers is equally icky, so I prefer redlinks for next/prev to be in place rather than left empty so you don't know where the part transcluded falls.

    @BethNaught: We need active Wikiprojects to push the projects, and that means a level of coordination for the project. We pulled back as people pulled back from that component. The infrastructure is there to propel any project individually or in conjunction with others when someone has one running. Anytime someone sticks there hand up we can swap a project into place inside collaboration or elsewhere. My comment is think of a good theme, and plan for it. Be it 200 years since XXXX born/died/created; the complete works of ... and a project should have a start and finish, at the moment, we have a cavernous empty end point so they just fade into (wherever). — billinghurst sDrewth 03:40, 2 February 2020 (UTC)

  • I generally agree with the thrust of billinghurst's comments above. In terms of policy / guidance / practice, we should have a high standard for both quality and completeness in mainspace, and a high standard for quality in Index:/Portal:/Author: space, but no particular standard for completeness for the Page: namespace. In particular, I would (generally) like to see our Author: pages (and, in this particular example, Portal: pages) be complete (fsvo) and high quality, with ready-made scans and Index: in place and linked. That makes it easier for others / new users to jump in, and to do a page here and there. Having incomplete or in-progress (raw OCR, say) pages in mainspace does nothing to encourage new users, and makes us look like a ghetto of bad copydumps. Having incomplete Author:/Portal: pages fall somewhere inbetween.
    However, I think your question was perhaps more in regards the optimal strategy for coordinating work? In the case of Weird Tales it is certainly possible that restricting what works are "available" to work on will lead to more efficient and focussed effort. But I think I would have argued that that is best handled through other means (discussion, advocacy, WikiProject coordination, etc.). I think having scans and Index:es all set up lowers the barriers to getting involved, and makes the task seem slightly less insurmountable. The absolute amount of work involved is the same, so over time even unfocussed and piecemeal effort will lead to the same goal.
    But I also have to add that I haven't looked at the specifics of Weird Tales, so I hold it entirely possible that there may be some factor or property at work that makes the above entirely beside the point. So "FWIW", is what I'm saying, I guess. :) --Xover (talk) 11:38, 2 February 2020 (UTC)
I think I don't agree on making author pages complete; adding all 240 works Wikipedia says he has to Author:Andrew Murray would make it hard to find what we actually have of his, and uploading scans for all of them would involve a lot of work, plus the invariable scan problems discovered on loading all of them, for something that could be done as need be.--Prosfilaes (talk) 21:23, 2 February 2020 (UTC)
I should stress that I'm speaking in very broad generalities here. For authors (or portals) with a large number of works the exigencies of the practical may certainly change the equation. And if we should end up with the luxury problem of such a page with a complete listing, we may have to investigate some technical or organisational means to aid the discoverability problem. --Xover (talk) 22:40, 2 February 2020 (UTC)
  • I didn't expect to be on the more restrictive side of the argument. Okay; I will put on my immediate plans to upload all of the PD Weird Tales volumes, and won't stress about whether I'm being premature in uploading more of the O'Henry Prize Stories or that Short Story series. I appreciate the opinions.--Prosfilaes (talk) 21:23, 2 February 2020 (UTC)
    Pictogram voting comment.svg Comment Portal:Weird Tales is our friend here. If we don't want a project, we can do some inviting and creative thinking about curating what we have, especially in the Index: space. — billinghurst sDrewth 22:11, 2 February 2020 (UTC)
    I think I've seen that page before, but it's not up to date, and it's somewhat redundant with Weird Tales, especially if you're talking about the PD-expired works, which are easily predictable.--Prosfilaes (talk) 02:12, 3 February 2020 (UTC)

Tech News: 2020-06[edit]

20:04, 3 February 2020 (UTC)

Img float: width in ems[edit]

I notice that currently {{Img float}} does not allow the image width to be specified in ems, only pixels. Is there a particular reason for that? If not, please add ems Levana Taylor (talk) 10:44, 3 February 2020 (UTC)

I would assume that the reason is that images are measured in pixels and text is measured in ems. A pixel is a constant size, while an em varies depending on the pitch of the font. So, specifying a image in terms of an em will mean that the width will vary depending on the font size in play at the time.

e.g. M M M M M M M M

Each of these will give a very different image size. If our image is low resolution, but is set to the width of a 24-point font (for example), it will be a pixillated mess for the end user who is using the "big fonts" reading option in their browser. Beeswaxcandle (talk) 18:35, 3 February 2020 (UTC)

True. But Img float is used to insert images into the text flow so it sort of seems that they ought to vary along with the text. Levana Taylor (talk) 20:50, 3 February 2020 (UTC)
@Levana Taylor: The short answer is to substitute {{img float}} with something like {{FI}} and suitably amend parameters (I think I may just have made User:Inductiveload cry?)
The long answer (this may get boring) is that at heart mediawiki's image embedding mechanism [[File:…]] only parses out image-size information by looking for the "px" keyword. If it is absent then internally the full-sized image is always delivered - this is how {{FI}} always works, and then uses CSS and surrounding HTML to resize the image at the browser end. Is everybody asleep yet? 21:47, 3 February 2020 (UTC)
I didn't completely understand that but I do get that in the case of "Fair drinking" which depends on the image and the text-column being the same size, I need to use {{FIS}}. I am thinking I could create a not-so-enormous alternate version of the image to use here, for keeping the ebook size down (currently the original is 1,123 × 2,036 pixels!!) 400px wide should be enough, although the disadvantage is that then one wouldn’t be able to see the full-size thing just by clicking on it. Levana Taylor (talk) 23:39, 3 February 2020 (UTC)
The problem is {{FIS}} requests the image from the server with no pixel size specified at all, which prompts a return of the whole image in all it's 5MB glory, for presentation as a 238px image (scaled to fix by CSS). {{large image}} used a (user-supplied) pixel size for the "base" image and then using CSS to further scale it down if needed (e.g. if you said 600px, but your text column ends up only 30em/480px due to CSS constraints, if your text column ends up at 50em/800px wide, the image caps out at 600px). Thus, by choosing a "sane" pixel size that'll always be at least as large as the image can usefully be in context, you avoid loading megabytes of image data just to throw 98% of it away. Because the px/em mapping is a little bit fuzzy ("normally" it's 16px to 1em, but that's not guaranteed in all cases), you can never fully reason about exactly how big an image of, say, 400px will be in ems when shown in the browser/reader.
Perhaps {{FIS}} could get a img_width parameter or something, but it still seems like that whole template (and its brother) has problems if the default behaviour is to slam people's bandwidth. Inductiveloadtalk/contribs 08:45, 5 February 2020 (UTC)


Do we support the equivalent of the PD-anon-50 here at Wikisource? Anonymous works distributed outside the US 50 years or later. --Richard Arthur Norton (1958- ) (talk) 00:30, 5 February 2020 (UTC)

Works have to at least meet PD-1996 criteria. Use {{PD-anon-1996}} with a year of publication parameter and the appropriate license box will be generated (95,80,70,60,50). Beeswaxcandle (talk) 00:40, 5 February 2020 (UTC)
The aspect of anonymity doesn't make a difference when we are talking about the work and copyright, most likely if it is published outside of the US after 1925, then it is 95 years. [1]billinghurst sDrewth 04:48, 5 February 2020 (UTC)
"Published without compliance with US formalities, and in the public domain in its source country as of 1 January 1996" per Beeswaxcandle. It combines PD-anon-50 and PD-1996 at Commons here into one template at Wikisource. Thanks! --Richard Arthur Norton (1958- ) (talk) 05:01, 5 February 2020 (UTC)
A lot of nations are and especially were life+50, and a flat 50 years in some cases for anonymous works. That would be works from before 1946.--Prosfilaes (talk) 07:11, 5 February 2020 (UTC)

{{PD-anon-1996}} I think this covers it per Beeswaxcandle, it would be more helpful if it listed the countries that were covered or not covered, whichever is a shorter list. --Richard Arthur Norton (1958- ) (talk) 20:13, 5 February 2020 (UTC)

New error messages for the attribute “follow”[edit]

There are new error messages for some edge cases when the follow attribute is used incorrectly.
The follow attribute allows users to merge source material which spans over multiple pages. It only exists on Wikisource and works like this: You can merge the contents of two references into one footnote, e.g. <ref name="a">Text for source 1</ref> […] <ref follow="a">Text for source 2</ref> . In the reference section, this shows the footnote like this: Text for source 1 Text for source 2. More information about this attribute can be found here.

Error message for follow attribute.

For the follow-attribute to work it is important that the name of the reference is defined in the text before the follow attribute is called. Unfortunately, if this is not the case, the follow reference is shown on top of the reference list, with no footnote marker and unattached to the predecessor which it's supposed to follow. In the past, there was no error message for this edge case. This will change soon: In order to align this error behavior with error behavior in the rest of the Cite extension, an error message will be shown (see picture) for this edge case. If you want to find all pages in your wiki using the follow attribute, you can use this query.
This change was done in the context of developing the extends attribute, which caused the WMDE’s Technical Wishes team to rework big parts of the Cite extension. It’s planned to be deployed on February 5.
If you’d like to know more about this change, you can find more detailed information on this Phabricator ticket: T240858. If you have any feedback on this change, please let us know on this central feedback page. - For WMDE’s Technical Wishes Team: Max Klemm (WMDE) (talk) 08:36, 4 February 2020 (UTC)

Hi Max. Thank you very much for the notice (and to Thiemo for doing the research I see in that Phab)! This kind of change is in general, IMO, a great improvement: much better to have such problems immediately obvious through an error message than to have to go hunting for them.
But I am a little concerned too: the ProofreadPage extension that is essentially the foundation for the Wikisourcen relies heavily on transclusion: texts are transcribed page by page from the scans in the Page: namespace, and are then transcluded together at the chapter or book level in mainspace (ns:0). That's why your example search above only finds 17 hits: the remaining 4.5k instances are all in the Page: namespace. Is this change going to mean big red error messages for all those pages? Because that would be… bad. And very likely to induce spontaneously elevated pitchforks-and-torches levels. :) --Xover (talk) 10:09, 4 February 2020 (UTC)
Considering that the "follow" attribute was created specifically to accomodate ProofreadPage, and that its use in Page namespace is literally the primary use case for this feature, it would be very bad for an error message to display when the feature is used by design. I have added a note on Phabricator and on the extension Talk page noting that the error message should not display in Page namespace for this reason. —Beleg Tâl (talk) 13:14, 4 February 2020 (UTC)
  • @Max Klemm (WMDE): Pictogram voting comment.svg Comment The commentary that it is the "wrong usage" is factually incorrect. The purpose of follow is two-fold. 1) to display differently on the page of use, ie. without a number but with the indent, and 2) to be able to append with the previously named component when the named component is available. So by definition for its design in the use in the Page: namespace it has to be expected that the prior component is not previously used on the page for the second half of a footnote [I mean that is the purpose of the "follow"!]

    Why have you not consulted with the Wikisource community prior to making this change? The fact that deWS doesn't use ProofreadPage may have inhibited your consultation. I ask that you pull that change, and not implement on the 5th until you have resolved the issue.

    Noting that I see about 7.4k uses of "ref follow" [2] and there will also be cases where {{#tag:ref|...|follow=whatever}} is used, as sometimes that has been required, though I have often subst: at the end to allow for clarity of the start and finish of the ref. — billinghurst sDrewth 23:17, 4 February 2020 (UTC)
    @Max Klemm (WMDE), @Thiemo Kreuz (WMDE): you may be interested in our local help at Help:Footnotes and endnotes#Footnotes that continue over page breaks. — billinghurst sDrewth

Update: There will be no new error messages after all.[edit]

Contrary to what was previously announced, the above change will not take place. There is a risk that as a result of the change, error messages would be displayed on many Wikisource pages, even when there is no error. More information can be found on Phabricator (T240858). Many thanks to everyone who pointed this out!
At this time it is not clear if the announced change can be removed from the general software update (scheduled for tonight) or if the Technical Wishes team will remove it promptly afterwards. -- For the Technical Wishes Team: Max Klemm (WMDE) (talk) 10:48, 5 February 2020 (UTC)

  • the error message is gone now, but the footnote content has changed into ⧼cite_references_no_link⧽, see: Page:Seventeen lectures on the study of medieval and modern history and kindred subjects.djvu/178, Zdzislaw (talk) 19:13, 6 February 2020 (UTC)
  • I am having trouble previewing a footnote continuation and get ⧼cite_references_no_link⧽ for the footnote content. Seems to be no problem with the help example (Page:Principles of Political Economy Vol 1.djvu/131), but shows up if I go into edit mode for the page and do a preview. Bob Burkhardt (talk) 20:07, 6 February 2020 (UTC) My interim fix will be just to temporarily lump all my multipage footnote text into the first citation. I don't see them very often, but there are some long ones in the current edition of Democracy in America I am working on. Thanks for efforts to fix this issue. Bob Burkhardt (talk) 23:25, 6 February 2020 (UTC)
    @Zdzislaw, @Bob Burkhardt: (and everyone else reading this) Something went horribly wrong with the deployment yesterday. The planned change referred to in Max's message above was pulled at the last minute, but something about that operation seems to have gone awry in such a way that all footnotes that use the |follow= parameter will show up as ⧼cite_references_no_link⧽. Due to other unrelated issues that are keeping key people busy, and no clear root cause for the problem we're seeing, there's no real ETA for a fix. It may resolve on its own during the next deploy (next Tuesday/Wednesday or so), and there are a couple of possibly faster ways that are being investigated, but nothing firm that I've been able to find. --Xover (talk) 21:50, 6 February 2020 (UTC)
    fwiw the ⧼cite_references_no_link⧽ component is the display tag for references when you don't want the list marker. Old code is at mw:Special:Code/MediaWiki/71157 so it would seem that output of one of the definitions got removed. — billinghurst sDrewth 22:06, 6 February 2020 (UTC)
    @Billinghurst: The message key is missing from Special:AllMessages, but it is definitely present in the i18n/en.json that was deployed yesterday. In other words, it seems like this is a problem related to the deployment, not the code as such. See phab:T240858 for details, including a possible temporary workaround (since a proper fix may potentially take a week+ if we're really unlucky here). --Xover (talk) 22:45, 6 February 2020 (UTC)

Update 7 February[edit]

The releng team had to roll back all wikis (including the Wikisources) to MediaWiki 1.35-wmf.16 for unrelated reasons, and as a side effect of that the above problems should now be gone. Some pages may still show ⧼cite_references_no_link⧽ due to the page cache, but these can be fixed by a null edit (maybe do a pywikibot touch edit run if there are a lot of them?) or purge.

@Zdzislaw, @Bob Burkhardt: It would be helpful if you rechecked the cases you saw previously to verify that it's now fixed.

There is a tiny and highly improbable chance that one of the two above problems (the incorrect error message and the subsequent missing message) may get reintroduced during next week's scheduled deploy, but it is extremely unlikely and the troubleshooting the devs did this week means they'll be able to pinpoint the cause and how to fix it much much quicker if it should still happen. I mention it only to make sure it gets reported promptly if by some stroke of bad luck it should happen again.

PS. Big big thanks to the developers and others that sprang into action to help us with this! Best of all would have been to avoid the problems altogether of course, but when things went sideways they really jumped on the issue and stuck at it until it was pinned down. And that was despite a baker's dozen of other fires going on at the same time (did you know all the Wikipedias and Commons was effectively down for half an hour last night?). --Xover (talk) 18:46, 7 February 2020 (UTC)

  • @Xover: I checked most of the pages on pl ws. Pages with ⧼cite_references_no_link⧽ look ok after purging. Thanks a lot for your help! Zdzislaw (talk) 19:18, 7 February 2020 (UTC)
  • @Xover: I checked Page:Principles of Political Economy Vol 1.djvu/131. I had to do a null edit to get rid of ⧼cite_references_no_link⧽ (previously it looked fine), and now I can preview it in edit mode and that works too. Thank you for fixing this. Bob Burkhardt (talk) 16:04, 8 February 2020 (UTC)

Link back to Wikidata[edit]

When I am at Wikidata and connect to a document here, do I automatically get a link here back to Wikidata, or do I have to form it manually? --Richard Arthur Norton (1958- ) (talk) 01:49, 8 February 2020 (UTC)

Any page interwikilinked at WD at any wiki will automatically get a [wikidata item] link in the left sidebar. Further, if you are using one of our header templates they have {{plain sister}} embedded and that will allow the linking to the xwiki links on the item. For categories we would apply plain sister template directly, there is no corresponding header template. — billinghurst sDrewth 03:42, 8 February 2020 (UTC)
I think the servers were just slow last night, since there were so many people editing. All the links back to Wikidata were in place by the morning. Thanks! --Richard Arthur Norton (1958- ) (talk) 18:00, 8 February 2020 (UTC)

Associated Press[edit]

Should we also have a page for Associated Press articles. They may be published in various newspapers, but I think we should have them on an Associated Press page in chronological order. Should it be Author:Associated Press? Portal:Associated Press or just "Associated Press" as if it were a newspaper? --Richard Arthur Norton (1958- ) (talk) 02:01, 8 February 2020 (UTC)

I say Portal:, as the AP are more like a publisher than an author. —Justin (koavf)TCM 03:27, 8 February 2020 (UTC)
The publisher is the subscribing newspaper. The AP sends out articles by telegraph and later by teletype to subscribing papers and they choose which ones to publish. But either way, Portal or Author works for me. Portal may be best since we reserve author for humans. --Richard Arthur Norton (1958- ) (talk) 17:55, 8 February 2020 (UTC)
"Portal may be best since we reserve author for humans"—this is exactly correct; Portal:Associated Press is where you want to go. —Beleg Tâl (talk) 13:53, 9 February 2020 (UTC)

Tech News: 2020-07[edit]

19:09, 10 February 2020 (UTC)

Index:History of the United States of America, Spencer, v1.djvu ready for transclusion[edit]

Hi all. Doing maintenance and we have Index:History of the United States of America, Spencer, v1.djvu in need of someone to give it its wings by transclusion. Available to anyone with a passion to do it. Otherwise I will stick it on my to do list. — billinghurst sDrewth 13:18, 9 February 2020 (UTC)

How shall it be transcluded? History of the United States of America/Vol I/Book N/Chapter X? Or? Mpaa (talk) 14:38, 9 February 2020 (UTC)
<shrug> I would have skipped the volume numbers—hate unneeded volumes—and gone straight to "Book n/Chapter n" I don't even know how many are in the series. I don't even know how useful a series it is, how many volumes there are. Sort of why I flagged it. — billinghurst sDrewth 08:21, 11 February 2020 (UTC)

The Record[edit]

We have The Record as a disambiguation page but there is also a newspaper called "The Record" so which should get moved and which occupy the space that now houses the disambiguation page? I have not added The Record news articles yet. --Richard Arthur Norton (1958- ) (talk) 03:12, 10 February 2020 (UTC)

There are multiple newspapers called The Record, so they would need to be disambiguated as well. I see enWP has used the town/locale/general area as the disambiguator. This would seem a reasonable way forward. Add the newspapers to the current dab page as you go. Beeswaxcandle (talk) 03:34, 10 February 2020 (UTC)
Disambiguation pages will never get moved away. Disambiguation pages occupy the base name, and everything else is disambiguated. See Help:Disambiguation. — billinghurst sDrewth 08:16, 11 February 2020 (UTC)

Move page to Wikisource[edit]

Can someone move File:The Magic Mountain.djvu to Wikisource? It looks to be deleted on Commons, because Thomas Mann died in 1955 and thus it's not PD in Germany. It's over 100 MB, so it's not easy to upload here. It comes from , so it shouldn't just disappear, even if they do delete it.--Prosfilaes (talk) 11:57, 11 February 2020 (UTC)

Cannot get it inhaled, and I am guessing that it will due to its size. Sounds like a phabricator job to get it moved. — billinghurst sDrewth 13:33, 11 February 2020 (UTC)
@Prosfilaes, @Billinghurst: Done. For files over 100MB or so the trick is to use Chunked Upload Protocol (which is what the UploadWizard on Commons uses behind the scenes). I'm a little pressed for time so the description page is a mess, sorry. --Xover (talk) 14:36, 11 February 2020 (UTC)
here is a later 1928 english edition with the missing pages [6] and an american 1949 edition first printed 1927. [7] maybe a chunked upload from the later is in order. (the pagination is exactly the same among all three) -- Slowking4Rama's revenge 19:30, 11 February 2020 (UTC)
Sorry for not paying attention before, but this says 1919, on the title page and a little later but both Wikipedia and CliffNotes are quite clear that The Magic Mountain was first published in German in 1924, and Wikipedia says in English in 1927. We may have to delete this until 2023.--Prosfilaes (talk) 22:20, 11 February 2020 (UTC)
Formality, but I've taken this to Wikisource:Copyright_discussions#The_Magic_Mountain.--Prosfilaes (talk) 22:54, 11 February 2020 (UTC)


If we only have a single article from a periodical, does the periodical get its own page. For instance we have a page for the New York Times that acts as an index to all the articles, but is it worth doing for one article from that periodical ... just to have a link back to Wikidata with info on that periodical? --Richard Arthur Norton (1958- ) (talk) 06:58, 5 February 2020 (UTC)

Are you asking about a periodical that only contained one article, or about a periodical for which Wikisource hosts just one article currently but from which many more articles might be added later? --EncycloPetey (talk) 15:36, 5 February 2020 (UTC)
We only have one article ... so far. For example where we have three articles I created page for the newspaper: Brooklyn Eagle and listed the articles we host in chronological order. Do we do it when we host just a single article so far ... so that we can create a link here from Wikidata? --Richard Arthur Norton (1958- ) (talk) 20:08, 5 February 2020 (UTC)
Yes, it's worth doing—even if we do only host a single article at present. Also, make sure that periodical gets listed in the Portal. Beeswaxcandle (talk) 20:33, 5 February 2020 (UTC)
Thanks, makes sense to me. --Richard Arthur Norton (1958- ) (talk) 22:13, 5 February 2020 (UTC)

Pictogram voting comment.svg Comment For newspapers the easiest way to set these up is the lazy {{header periodical}} which takes parameters, and can be used either at the root page, or at a year level if we have numbers of papers. One day they will give us a better means to control that output (maybe). — billinghurst sDrewth 22:21, 6 February 2020 (UTC)

Unfortunately, there is no information about the parameters in its documentation :-( --Jan Kameníček (talk) 22:43, 6 February 2020 (UTC)

I have a related question: should a "full" structure be created at the outset (Periodical Name/Year/Month/Day/Article Title, like The New York Times, as recommended by Wikisource:WikiProject Newspapers), or do we prefer to have a "condensed" structure (Periodical Name/Year/Article Title, like The Times) until the periodical in question has enough articles to start to bump into collisions? And if the latter, do you then disambiguate at the article level instead (i.e. Periodical Name/Year/Obituaries (19 March 1867)), or do you transition the whole periodical to the "full" structure? Or is it a "do whatever" situation and there is no best practice as such? Inductiveloadtalk/contribs 14:36, 11 February 2020 (UTC)

It depends, IMO this needs to be considered with every periodical separately. Title containing too many slashes looks very unfriendly and so I prefer condensing in cases when it is possible. --Jan Kameníček (talk) 14:46, 11 February 2020 (UTC)
Aside: Maybe we should emphasise the actual title field in the header template, rather than then page name, which is more of a combo unique identifier/hierarchical organiser/link target that generally only bear resemblance to a title (sometimes not, it's just "Chapter 2") than a title for use by the end reader. Tellingly, these titles are entirely absent from exported books. Perhaps we could reduce the visual impact of these titles, and maybe bulk up the header titles a notch in their place in the main namespace? Contributors will still know what to copy-paste for a link, but readers don't need to be slapped in the face with a 1.8em title font full of slashes (which have a practical purpose as sub-page delimiters). Inductiveloadtalk/contribs 19:38, 12 February 2020 (UTC)

Wikilivres is gone[edit]

Wikilivres no longer works. What will we do with works in the public domain in source countries yet copyrightable in the USA due to URAA?--Jusjih (talk) 05:16, 1 February 2020 (UTC) is still live. :/ —Justin (koavf)TCM 07:41, 1 February 2020 (UTC)
if it is >50 & <70, go to wikilivres. if is it >70 & <95, upload to commons and invoke WMF legal. Slowking4Rama's revenge 16:41, 1 February 2020 (UTC)
@Slowking4: Please do not deliberately encourage unsuspecting users to violate Commons policy. And if you want to argue against that particular policy, do it on Commons and not here. --Xover (talk) 18:28, 1 February 2020 (UTC)
please do not misrepresent commons policy. there is not a consensus about URAA, as demonstrated by the open discussion for a year [8] i guess if you leave it open, you can continue your fear uncertainty and doubt campaign, i gave the new user unvarnished advice; they can always transfer it here, if and when the commons deletionists come out several years later.Slowking4Rama's revenge 02:18, 2 February 2020 (UTC)
Commons policy is clear; that discussion is about how to apply it in practice (whether to proactively mass delete such files or not). You know full well that any user that started to upload lots of files affected by the URAA would be stepping into a quagmire, at best. Whether you want to do that yourself is between you and the admins on Commons; but please do not spread bad advice like that here. Especially not in a campaign-by-proxy to change Commons' policy. --Xover (talk) 07:13, 2 February 2020 (UTC)
For those who are confused by this contention, here's the three-point rough summary:
  1. Whether it is legal to host URAA works is disputable; there is no case law, only analysis.
  2. The Wikimedia Foundation's analysis is that it is likely okay -- so likely that they are do not object to individual sites choosing to host such works.
  3. Nevertheless Commons policy is not to accept such works at this time.
Hesperian 07:59, 2 February 2020 (UTC)
Actually, as both Carl Lindberg and Michael Maggs has pointed out in the linked thread, the first two of those points are now out of date. There was uncertainty regarding the validity of the URAA, and a (probably naïvé) hope that it would be struck down as unconstitutional, at the time when it first came to the attention of the Wikimedia community. This has, however, now been settled: works affected by the URAA are unquestionably in copyright in the US, and US courts are enforcing such copyrights.
What the advice from WMF Legal actually does do is suggest that in cases where there is insufficient information available to determine copyright status definitively, the mere allegation that the URAA applies should not be considered sufficient reason to delete despite the Precautionary Principle. For any work where there is sufficient information to determine that it is in copyright in the US—including through URAA copyright restoration—or to establish "significant doubt" about its public domain status, the ToU effectively requires it be deleted. Which all is what Commons policy reflects. --Xover (talk) 10:53, 2 February 2020 (UTC)
the TOU does not require anything of the sort. rather, you choose to delete items for which WMF legal advises mere speculation is not a deletion rationale. nevertheless you persist in your FUD deletion offensive despite real legal advice to not delete without real evidence. and you cannot produce a consensus for a policy. it is a toxic culture and a toxic campaign of repeated mendacity. Slowking4Rama's revenge 05:05, 11 February 2020 (UTC)
So Wikilivres exists in Russian site only now? It will not convince Chinese Wikisource that invokes WMF legal with caution.--Jusjih (talk) 04:40, 2 February 2020 (UTC)
The Russian Wikilivres split off to allow for CC NC/ND files a few years ago. —Justin (koavf)TCM 07:56, 2 February 2020 (UTC)
Is this a permanent situation? If so, should we begin identifying and deactivating the (now) dead links? --EncycloPetey (talk) 05:22, 2 February 2020 (UTC)
It seems like it will be that way for awhile: someone else owns the domain and he is radio silent. I paid for the old Canadian domain via Eclectiology's old account but I don't have hosting there. —Justin (koavf)TCM 07:56, 2 February 2020 (UTC)

Pictogram voting comment.svg Comment Identifying the works is an easy task where the interwiki links wikilivres or bibliowiki have been used:

billinghurst sDrewth 07:29, 11 February 2020 (UTC)

But are we then now at the point where we should systematically remove these links? And given we have been providing these links for a long time (and it has been down for periods before), do we need a formal proposal and vote on this? Or do we view this as a sufficiently technical / mechanical matter (site down → remove links) that a rough consensus in the discussion here would be sufficient?
My initial assessment is that this task would mostly be best handled by hand (i.e. not a good candidate for automation that I can see), and I would be happy to help churn through the list, but I'm uncomfortable doing so without a clear(er) mandate. --Xover (talk) 07:51, 11 February 2020 (UTC)
Wikilivres has been down before but never for this long. It's been offline since the middle of August 2019. That's six months now. It's obviously not coming back. Yes it won't be possible to remove all links to Wikilives with one click. They will have to be removed by hand and I will help with that. Unfortunately, it looks lie all of the pages with Template:Wikilivres page on them will have to be deleted individually. Simon Peter Hughes (talk)

Amazing Stories v01n12[edit]

The current scan for this (File:Amazing Stories Volume 01 Number 12.pdf) has pages 1113-7 blanked "as [Herbert Wells' Under the Knife] is not in public domain in the author's home country until January 1, 2017". As it has been 3 years since becoming PD, can we get these pages imported from the scan on IA? --Einstein95 (talk) 01:18, 13 February 2020 (UTC)

We should have done this locally in the first place, since this story was published in the 19th century and has probably never been in copyright in the US. They look like the same scans; page numbers match, minor copy-specific details match, but the IA one is half the size, so I'll leave it to someone else to merge.--Prosfilaes (talk) 01:10, 15 February 2020 (UTC)
@Einstein95, @Prosfilaes: Regenerated from the IA scans at File:Amazing Stories Volume 01 Number 12.djvu. Scan moved over and is now at Index:Amazing Stories Volume 01 Number 12.djvu (including the pages). Please check that the results are as expected. --Xover (talk) 09:20, 15 February 2020 (UTC)

The Story of Mankind[edit]

The following discussion is closed:
This seems to have been resolved.

I have noticed that in The Story of Mankind, List of Colored Pictures, a Picture "The Norsemen are Coming" should be facing page 156.

This is missing in the current wikisource edition of the book for some reason.

I have found a copy of the missing image in another copy of the book [11] and have uploaded a copy to commons. Would it be possible for someone to add this page and a following blank page into the book?

As far as I can tell that is the only missing page. Thank You. Sp1nd01 (talk) 10:55, 1 February 2020 (UTC)

@Sp1nd01: I can insert the missing pages in the DjVu for you, but that will then misalign the pages in the Page: namespace (the physical pages in the .djvu will shift by two, but the on-wiki pages will stay where they are). Fixing that requires tooling to mass move pages that I don't have, so you'd have to find someone else willing to that part of the job. --Xover (talk) 07:17, 2 February 2020 (UTC)
Can I ask why we would bother? Add the image to our representation. Job done. What is the value or need to fix the djvu file? It may meet some purity measure, but it does nothing for the work here. — billinghurst sDrewth 10:46, 2 February 2020 (UTC)
Mostly because it would make for a cleaner and more consistent setup. If all content of the work (in mainspace) is transcluded in the same way, we won't have special cases to worry about; including cognitively (vs. in mechanical terms). Every such exception has a cost, and if we can pay that once up front instead of repeatedly and for everyone exposed to it, that will be cheaper in the long run. *shrug* Since this is a single full-page plate it's probably six of one or half a dozen of the other (it has a caption that it would be nice to be able to validate against the scan though), but, personally, I would probably still recommend it be fixed in the DjVu if at all possible. --Xover (talk) 11:08, 2 February 2020 (UTC)
It is a single additional image, it can be added and transcluded in the same way any other image is added. It is still doing nothing for English Wikisource's presentation. Add it. Make a note on the Index talk: page. Put an in situ comment <!-- comment--> about what has been done. If someone wants to go to the effort of fixing it, then they can. I still haven't seen the value statement for why we would bother. — billinghurst sDrewth 12:31, 2 February 2020 (UTC)
Why we should bother:
  • If somebody does not find the picture in the scan some time later, they may come to conclusion that it does not belong there and remove it from our transcription of the work
  • The scan in Commons is a source and a lot of people may prefer this source to our transcription. That is why we should bother that the sources backing our transcribed works are complete.
  • Our readers are (hopefully) aware that transcribed works which are not backed by scans may not be reliable. If we mark some work as backed by scans they can trust it better. It is not fair to mark some work as backed by scans when some pages are not.
  • Although the sentence accompanying the picture is not problematic, somebody still may want to check it (for example to check whether there really should all the letters be capital…) and can be confused why they cannot find the picture in our scan. --Jan Kameníček (talk) 11:10, 2 February 2020 (UTC)
This is not a new issue, and it is not a problem that hasn't been addressed for years by alternate means. Comments can be on Index pages, on Index talk pages, and in situfor the page. Re Commons: I specifically was talking about enWS and said that. I would also challenge that people use us as a primary source for djvu files, so you are talking the most minimal number, and then a minute percentage of files that are fixed by us. The work is backed by scans, and the page can be added and imported as an image; or it can be transcluded as a separate and missed page.

It is a fight for a purity and a whole lot of work for zero value for enWS.

It is not our mission to try and have perfect files at Commons, it is our mission to present complete works here. I don't see anyone putting in perfected copies of images back into djvu works; or even then colour copies that I have seen placed into our works when they were black and white in the published version.

Note that I am not saying that someone may wish to fix the djvu file, I am saying that it is not our mission, our priority, and it comes with inherent risks, and can be achieve by much easier means. — billinghurst sDrewth 12:31, 2 February 2020 (UTC)

To me it seems that also "A New World......238" is misplaced, being in Page:Van_Loon--The_Story_of_Mankind.djvu/256, and not facing 238 as per List of Colored Pictures. Mpaa (talk) 22:59, 3 February 2020 (UTC)

If you also agree, I can move it where it is supposed to be (I have already fixed the djvu file for the other image) and realign everything. Mpaa (talk) 23:34, 3 February 2020 (UTC)
I have looked at the other copies of the book present on the Internet Archive page and they do have the image at the correct page, I think we have been unlucky and selected a faulty copy of the book to work against. I for one would agree that it should be relocated to its correct location. Thank you for taking the time in resolving the initial problem also. Sp1nd01 (talk) 10:39, 4 February 2020 (UTC)
In the end, I uploaded a different copy, with better quality. Everything should be ok now. Please let me know in case. Mpaa (talk) 21:29, 4 February 2020 (UTC)
I've just checked and I am seeing an offset following printed page 206 upto page 238. I see the pages out by two positions. i.e. page 221 has the image for page 223 etc, upto page 238 which shows a blank page (following the full page image for a new world.) Numbering then returns to normal. I have rechecked using a different browser in case it was a caching issue, but I still see the offset. Thank You. Sp1nd01 (talk) 10:25, 5 February 2020 (UTC)
Should be OK now. Thanks for the crosschecks. Mpaa (talk) 19:08, 5 February 2020 (UTC)
This section was archived on a request by: Xover (talk) 09:32, 15 February 2020 (UTC)

"l" not "/"[edit]

Over on the Wikipedia Reference Desk in this current thread (which will later be archived here, if I've worked out the link correctly), someone has figured out by reference to Google Books that in A Naval Biographical Dictionary/Falcon, Gordon Thomas the reference to "700,000/" (shillings) is supposed to be "700,000l" (pounds).

I would fix it myself, but (1) since the actual source page is referenced indirectly I don't know how to get to it, and (2) I'm concerned that the same error may very well exist in numerous other pages from this source, and I figure that someone interested in this material ought to check on that. So I'm just leaving this note here and I hope that someone else will be interested enough to deal with it.

Please direct any responses to this page, not to my IP address. -- 21:18, 2 February 2020 (UTC)

That is transcluded from Page:A Naval Biographical Dictionary.djvu/360. AFAICT it already is an l, not a slash—it's just confusing because of the font. BethNaught (talk) 21:49, 2 February 2020 (UTC)
Yes, it is an italicised lower case letter l ''l'' and how it displays will depend on your browser's font-face (we don't tend to push fonts). Explanation of its use in 19thC works is at w:Pound sign and unfortunately, it is a less than perfect representation I am guessing one would find tens of thousands, maybe a hundred thousand examples of this at enWS as it is rife through DNB and similar such works. "It is what it is".

There is no modern unicode variation of that symbol for representing pound. I did consider at one point whether "Mathematical Italic Small L" (𝑙) (𝑙) would do any good, however, we were pretty far gone, and trying to get it universally in place was not going to be easy at that time. Also that then becomes about representation based on look not reproduction based on characters as it not actually that symbol/letter just the closest visual representation. If the community reached consensus we could consider it, though we would need to remove the existing {{l}} redirect and do a little retraining. — billinghurst sDrewth 23:01, 2 February 2020 (UTC)

It is a lower-case letter L in italic: l. This was the common way to indicate amounts in pounds up until at least the mid-19th-century (iirc), so you'll find that in lots of books on English Wikisource. But we very much appreciate you making the effort to let us know when something relevant to our works came up! --Xover (talk) 22:31, 2 February 2020 (UTC)

{{lb.}} and {{lb-}}[edit]

Jus poking around to see if any weightless pound template names suggested themselves. Found these:
  • {{Lb.}} : ℔ ; (13 occ.) (uses &#8468; "℔")
  • {{Lb-}} : ℔ (~45 occ.) (uses &#x2114; "℔")
I'm thinking if a name is needed for the bare 'l' usage, a fuller spelling would avoid other 'l' usages. So maybe {{poundell}}?
Hmm, {{Lb.}} doesn't mention {{Lb-}} and vice versa. {{Lb.}} seems the lesser used. Should I just add mentions to each doc page, or redirect {{Lb.}} to {{Lb-}} ? Shenme (talk) 00:19, 3 February 2020 (UTC)
It has to be quick and easy, and it has to be easily rememerable. If it is going to be harder than ''l'' then it isn't going to happen. And noting that it isn't the weight symbol. — billinghurst sDrewth 00:27, 3 February 2020 (UTC)
&#8468; and &#x2114; are the same character: L B BAR SYMBOL (U+2114). Thus the differences between these two templates is that in the bare form {{lb.}} always outputs a leading &nbsp; (non-breaking space) where {{lb-}} does not; and that {{lb-}} supports a parameter that it will join to the symbol using a &nbsp;.
This seems like a pointless difference and proliferation of templates for no good reason. We should decide on one way to do this and merge these templates into one that behaves consistently. --Xover (talk) 10:17, 15 February 2020 (UTC)
And in fact, there were only about 5 actual pages that used {{lb.}} so I've replaced all those and redirected it to {{lb-}}. The only problematic instances where a few places where there was a need to output a bare ℔ for technical reasons. Those I replaced with the character entity reference (&#8468;) but if the need occurs often it may be useful to provide some way to output that (so far it does not appear especially needed). --Xover (talk) 10:54, 15 February 2020 (UTC)

George Germain Sackville, Germain,_George_Sackville_(DNB00)[edit]

Hi There,

would there be any records existing of employees of this Lord Sackville in London.

Thanks Jenniunsigned comment by Bloomersgirl (talk) .

you could check out or but this would be arduous scholarship. Slowking4Rama's revenge 00:05, 17 February 2020 (UTC)

YYYY works[edit]

Could explanation of the tag "YYYY works" be added to Special:Tags, please? --Jan Kameníček (talk) 07:46, 17 February 2020 (UTC)

@Jan.Kamenicek: done. It's a tracking tag added by the edit filter to keep track of edits that manually add a category of the form "YYYY works". These categories should be added automatically by {{header}}, but for some reason {{translations}} (which is a wrapper around {{header}}) is not adding it (which looks like a bug to me, but I'd have to dig a bit to say for certain). --Xover (talk) 11:08, 17 February 2020 (UTC)
I see, thanks! --Jan Kameníček (talk) 11:14, 17 February 2020 (UTC)

Validating Comenius' The Labyrinth of the World[edit]

It is 250 years’ anniversary of the death of Johan Amos Comenius this year and it would be nice if his work The Labyrinth of the World and the Paradise of the Heart (transcription project) could be featured on this occasion. May I ask for help with validating this work? --Jan Kameníček (talk) 15:57, 17 February 2020 (UTC)

Tech News: 2020-08[edit]

16:16, 17 February 2020 (UTC)

External links in the header "next=" field[edit]

Over the last few years a practice seems to have developed where State of the Union Addresses have an external link in the header, in the |next= parameter, to link to the opposition party response to the address. Examples can be seen at:

Given our linking policy does not even allow most sister-project links in works hosted here, I feel external links—unique to this subset of works—are definitely outside the spirit of the policy. I also feel that abusing the |next= parameter in this way is both misleading and confusing to our readers (it doesn't help that, for technical reasons, they are displayed as internal links rather than tagged as external links).

However, while the policy does say Links to non-Wikimedia pages are not acceptable, the policy does not directly address links in the header of a work (where we have quite a bit of variability in the |description= field). The header is notionally "outside" the work as such: it contains metadata and intra-work navigation, and is our addition to the work the same way the sidebar etc. (the "website chrome") are WMF / MediaWiki additions outside the content area.

It is thus not clear that the linking or annotation policies apply to this issue, and so I am asking for community input. Should external links in the |next=/|prev= fields be permitted? Should we allow external links anywhere in the header? Only in the |description= field? Only in exceptional circumstances? Not at all?

I imagine that for some contributors, linking to the response by the opposite party feels critical for fairness (to not let one side stand unopposed), and, I gather, the opposition response to the State of the Union is a well-established tradition in the US, so this might conceivably be one case for an exception if the general answer is "no external links". --Xover (talk) 07:41, 18 February 2020 (UTC)

IMO, the "prev" and "next" fields in this case should link to the previous and next "State of the Union Address" on enWS. Some of them will be redlinks, and that's okay because they'll get filled in. Also, the latest one cannot have a next, as it is unknown at present whether it will be Trump's Fifth Address, or someone else's First Address. If it is desirable that there is a link to the formal "Response", then that should be in the "Notes" field (not "Description") and should be a link to something hosted by us. If we are unable to host the Response due to some arcana of the PD rules, then we shouldn't link to it all.

It is my belief that the only external links (i.e. external to us and the MediaWiki sisters) on works that we host, should be on the Talk Page indicating the source of the material where there are no scans. And links to the sisters should be in their fields within the header—with the standard exceptions of links to wiktionary for obscure word definitions. Beeswaxcandle (talk) 08:32, 18 February 2020 (UTC)

It has always been my understanding that the "previous" and "next" links in the header were intended solely to navigate to the previous and next part within a work or volume, such as the next chapter, or the previous article. Linking to a different work the way it is described here should be done using a Portal, with a list of all the Addresses. --EncycloPetey (talk) 23:15, 19 February 2020 (UTC)
Agree, headers should be only for internal navigation through Wikisource. --Jan Kameníček (talk) 09:41, 20 February 2020 (UTC)
I agree about the "next=" parameter, but the opposition party response is well worth including somehow. I think it should be mentioned in the "notes=" field. -Pete (talk) 19:40, 20 February 2020 (UTC)
Pictogram voting comment.svg Comment next links are internal reference works per "next = name of next part of work, relative links on subpages, full links otherwise". One cannot describe a reply as next, next what? It definitely is not next in in the series. It is a speech in reply, but it is not from the work's perspective. — billinghurst sDrewth 05:48, 21 February 2020 (UTC)
@Dash9Z: It occurs to me that I really should have pinged you when I opened this thread, since it was prompted by an issue in a work with which you were involved. My apologies! Please feel free to express your opinion here. --Xover (talk) 08:52, 21 February 2020 (UTC)

File:Once a Week, Series 1, Volume II Dec 1859 to June 1860.pdf[edit]

The local page of this file still suffers from the decimal pixel issue with pdf. Commons version is OK, as expected. I have no idea how to resync the local page so that the correct number of pixels is used. Display of pages in Page: ns is affected for me. Am I alone? Mpaa (talk) 21:53, 18 February 2020 (UTC)

I can’t get the images to load in Page ns either. Levana Taylor (talk) 00:18, 19 February 2020 (UTC)
No issues for me. Purge the Commons file from the Index page. — billinghurst sDrewth 05:41, 21 February 2020 (UTC)

versions of Wikisource with non-US PD status[edit]

I recently had a desire to add some works by an author who is public domain in Canada and Australia/NZ etc. And I remembered years ago coming across one or more Wikisource-like projects that operated in those jurisdictions. It seems now that I'm interested in contributing, they are all down! I found the link from WS's home page to Wikilivres, which has been down for months, according to the talk page dates. Moreover, that site was apparently the replacement for the longer-gone Canadian version. Is it safe to say that I'm out of luck? (Not to go off-topic, but Wikisource is losing out on so much by operating under the US jurisdiction, I feel; I'd be a regular participant, likely, if I could work with materials that date into the 40s, 50s and 60s.) Thank you, Outriggr (talk) 09:11, 21 February 2020 (UTC)

Canadian/NZ Wikilivres is dead. Russian Wikilivres is still around, though I know nothing about their policies. English Wikisource is subject to US copyright law because our servers are located in the USA. —Beleg Tâl (talk) 13:10, 21 February 2020 (UTC)

Tech News: 2020-09[edit]

20:59, 24 February 2020 (UTC)

Additional interface for edit conflicts on talk pages[edit]

Sorry, for writing this text in English. If you could help to translate it, it would be appreciated.

You might know the new interface for edit conflicts (currently a beta feature). Now, Wikimedia Germany is designing an additional interface to solve edit conflicts on talk pages. This interface is shown to you when you write on a discussion page and another person writes a discussion post in the same line and saves it before you do. With this additional editing conflict interface you can adjust the order of the comments and edit your comment. We are inviting everyone to have a look at the planned feature. Let us know what you think on our central feedback page! -- For the Technical Wishes Team: Max Klemm (WMDE) 14:14, 26 February 2020 (UTC)

All OCR tools are failing[edit]

Both "phetools" and "google" OCR tools are currently not working. A series of error appears at the console, such as load.php?lang=en&modules=jquery%2Coojs-ui-core%2Coojs-ui-widgets|jquery.ui&skin=vector&version=b2vhm:133 [Report Only] Refused to connect to '' because it violates the following Content Security Policy directive: "default-src 'self' data: blob: * * * * * * * * * * *". Note that 'connect-src' was not explicitly set, so 'default-src' is used as a fallback. and five other errors, similar to this one. --Ninovolador (talk) 18:33, 26 February 2020 (UTC)

CropTool is also failing; I guess that Toolforge is having some server trouble. The CSP directive error in the console is probably unrelated, because I noticed that message a while ago and there weren't any problems with the tools at the time. —Beleg Tâl (talk) 19:29, 26 February 2020 (UTC)
Regarding the CSP message: this appears to be by design for the time being. It is easy for a malicious user to create an account at Toolforge to bypass CSP, so Toolforge is not whitelisted from CSP. However, CSP is notify-only at the moment, and they have plans to allow Toolforge via opt-in before actually blocking anything. —Beleg Tâl (talk) 19:50, 26 February 2020 (UTC)
The CSP messages are definitely not related. But there was a scheduled maintenance that started about 3 hours ago (18:00 UTC) that made some changes affecting Toolforge-hosted tools in such a way that some of them will need manual intervention to recover. --Xover (talk) 21:06, 26 February 2020 (UTC)
Yes check.svg Done It seems they have recover now. --Ninovolador (talk) 05:11, 27 February 2020 (UTC)

editing gone awry[edit]

I did something while using my keyboard/mouse when editing, and now I have two editing windows present, and wiki markup is in different colors. Everything is awry, I have no idea how to get out of this. Can someone please help me troubleshoot? I can explain things in more detail when prompted. Apologies ahead of time!! [the tildes used for my signature are blue...] Londonjackbooks (talk) 19:56, 28 February 2020 (UTC)

@Londonjackbooks: First step is to delete everything you have in your common.js. If the problem goes away, start re-adding things one at a time until the problem reappears. That's an awfully big and complex common.js and I would in general suggest you do some triage there to see if you really need all the stuff there. It'll be prone to breaking even if that's not the cause in this particular instance.
Other useful things to test is to test this while logged out in your usual web browser, and then when logged in in an alternate web browser. When logged out we eliminate your personal settings and gadgets etc.; and when logged in with a different browser we get a pointer about whether the web browser is the problem.
The weird colors might be simply that you've turned on syntax highlighting in the editor. It's the toolbar button that looks kinda like a marker pen, and, frankly, it's buggy as all nevermind. --Xover (talk) 20:27, 28 February 2020 (UTC)
Ah, it was the syntax highlighting button... Thanks. I must have inadvertently clicked it. Things are back to normal now. Admittedly, I could probably eliminate much that is in my common.js... But maybe I'll save that for a future spring cleaning. Thanks much! Londonjackbooks (talk) 20:39, 28 February 2020 (UTC)

Bad works on the Digital Library of India?[edit]

(Continuing from above, but a different and less transient subject.) File:The Magic Mountain.djvu says 1919, on the title page and a little later but both Wikipedia and CliffNotes are quite clear that The Magic Mountain was first published in German in 1924, and Wikipedia says in English in 1927. I also found a copy of Poirot Investigates on the Digital Library of India on to have a 1921 date, which is clearly wrong; Wikipedia has 1924, has 1924, and I'm sure at some point in the last 20 years, if either work had been fair game, Project Gutenberg and Dover Publications would have been all over them. I'm curious if Dover Publications is working on their translation of The Magic Mountain, or waiting until 2023, but if the German edition of The Magic Mountain had been PD, Stanley Appelbaum would have whipped up a translation for them. This may be a problem we have to worry about, that the Digital Library of India, despite looking reputable and the books not obviously having been tampered with, is releasing works via the Internet Archive that have altered publication dates in them making them look printed earlier.--Prosfilaes (talk) 22:20, 11 February 2020 (UTC)

WS:CV#The Magic Mountain for further conversation — billinghurst sDrewth 22:59, 11 February 2020 (UTC)
It's not just scans from the Digital Library of India that have incorrect dates. I find incorrect dates on scans at IA all the time. It's always a good idea to check (a) the date printed in the work, (b) independent sources, and (c) internal ads, front matter, and end matter, because sometimes "new" material gets added to later copies. --EncycloPetey (talk) 16:28, 15 February 2020 (UTC)
Really? There's a lot of cases where publishers will update the internal ads and not the date (which, for American publishers, is not a problem, since the printed copyright date is the starting point of copyright if it's earlier than the actual publication date), or I've seen a lot of British publishers be unclear about editions versus printings while making tweaks to the main body or end matter, but I've never seen a problem with the scans themselves before. And these changes are particularly problematic, because they're designed to make works in copyright in the US appear as if they're out of copyright; sample woefully insufficient, but the examples are moving publication dates (doesn't matter legally for India or most of the world, except for a short publication right in some countries that would have expired on these works) back before 1923.
Or are you talking about bad metadata, and having to look at the scans? Because that is a problem, but resolvable by looking at the scans.
If this is a bigger problem, I'd like to see any examples you can remember, so we can figure out what to look for.--Prosfilaes (talk) 00:25, 16 February 2020 (UTC)
Sorry, I should have been clearer. Most of the problems I find on IA are metadata issues, but I have found "doctored" scans there as well and not from India. --EncycloPetey (talk) 01:59, 16 February 2020 (UTC)
yeah, we need a metadata improvement round trip process. we have a liaison with Mark Graham. maybe we should set up a maintenance category or project. Slowking4Rama's revenge 00:54, 17 February 2020 (UTC)
Poirot Investigates was published in the UK in 1924 but the American edition which had more short stories was published in 1925. So you'd have to make sure it's not the American edition as well. Abzeronow (talk) 16:55, 2 March 2020 (UTC)

Possibly fixed: the newline proliferation issue when previewing edits in Page space[edit]

See phab:T241889 (and also phab:T188844). If you see this issue crop up when previewing edits in Page space, please update the Phabricator ticket and let them know.

@Ineuw, @BethNaught, @Christoph Jauera (WMDE):Beleg Tâl (talk) 20:20, 26 February 2020 (UTC)

It's resolved for me. Thanks to all who was involved. — Ineuw (talk) 03:07, 3 March 2020 (UTC)

Is this a problem?[edit]

The Great Irony of the Impeachment Trial is the only document linked to Rand Paul. It is also, and this is almost certainly not a coincidence, the speech in which he names the speculated whistleblower - something that mainstream media and the Chief Justice have consistently refused to do. We've had an edit filter on enWP for some months to prevent attempts to add the name, and we have had a lot of abuse around that (lookalike spellings, offsite links etc). This article is likely to be abused to try to weasel the speculated name into various Wikimedia projects in the absence of any reliable independent sources that do so. JzG (talk) 10:47, 29 February 2020 (UTC)

  • Note: Out of an abundance of caution I have deleted and salted this page. It contains personally identifiable information that may put the individuals concerned at risk of harassment or physical harm. Please do not recreate or repost this content unless a firm community consensus is established that hosting this content is appropriate under both local project policy and the WMF Terms of Use. --Xover (talk) 12:28, 29 February 2020 (UTC)
    This user is making an absurd allegation, @Xover:. I've created several pages related to the impeachment, as it's an issue of great historical import. We shouldn't blindly be censoring history. That's certainly the consensus of this project and the WMF, and you shouldn't be injecting a new consensus here. -- Kendrick7 (talk) 01:23, 1 March 2020 (UTC)
    Where are these "several pages" you've created? I can find only one. --EncycloPetey (talk) 02:53, 1 March 2020 (UTC)
    @Kendrick7: I did not act on, or comment on, the allegations of motive; I only acted to reduce the risk of real world harm stemming from the text itself. If my actions had been directed at your behaviour or based on the implied accusation against the contributor, I would have addressed you specifically (and typically on your talk page rather than here). Please do not take the one to imply a complaint about the other: none such was intended. --Xover (talk) 07:04, 1 March 2020 (UTC)

WS:PD#Undelete The Great Irony of the Impeachment Trial. Hesperian 04:18, 1 March 2020 (UTC)

Note that I did not see this discussion or that there had already been a page created for it, and had created a page about the speech myself under a more descriptive title rather than conjuring one up. I have given my reasons why I think this speech should be allowed at the undeletion discussion.--The Devil's Advocate (talk) 05:36, 1 March 2020 (UTC)

The WS:PD discussion on undeletion was closed as "not done" because a new copy had already just been created at Senator Paul on Impeachment of President Trump. If you think this new copy should be deleted, please initiate a community discussion at WS:PD. Hesperian 06:21, 1 March 2020 (UTC)

If there is the requirement to redact a name, then redact a name, it doesn't put the remainder of the document out of scope. — billinghurst sDrewth 06:53, 1 March 2020 (UTC)
@Hesperian, @Billinghurst: I must say I am rather disappointed with your actions in this matter. The cautious approach would have been to leave this text hidden while the community discussed how to handle it (and I absolutely applaud Hesperian's initiative in starting that discussion; it's the subsequent shutting down of it I have issues with), and at the same time there was absolutely no pressing need why this text must be visible here in the meantime. Instead you have both acted unilaterally to overrule me, to change the status quo for such a discussion, and short-circuited the community discussion. No harm would have been done by letting that play out for a week or two, and it would have provided us with a precedent to apply in future cases (at worst it would have demonstrated a lack of consensus on such issues). And whatever the outcome it would have been the community's decision rather than one or two administrators acting by fiat.
Instead we have a situation where we are hosting a text that may put someone at increased risk of real-world harm on your say-so. I cannot justify going in and deleting the new copy of the same text that was created because then I'd just be wheel-warring with you two, but at the same time you had no compunctions about doing that to me. I find this both unconstructive and unhealthy for the community and I hope you will reconsider this approach for the future. --Xover (talk) 07:34, 1 March 2020 (UTC)
Xover, please withdraw your allegations that I have "acted unilaterally to overrule [you]", that I have "short-circuited the community discussion", that I have "wheel-warred". These are very serious allegations and they are false. All I did was start a discussion (which you applauded), and then come back later and update this thread with the situation as I found it. Hesperian 11:50, 1 March 2020 (UTC)
@Hesperian: Are you then disputing that after Billinghurst closed the discussion you proceeded to assert that a new discussion was needed before deleting the same text? Do you disagree that this combination of actions 1) stopped the community discussion in progress, and 2) prevents other administrators from deleting the new copy of the text (as I absolutely would have done otherwise) to avoid wheel-warring? Do you disagree that the net effect of this series of actions is that we are hosting this text without a community discussion to justify that this is in fact a responsible course to take? Do you disagree that this in net effect constitutes overruling the call I had made on this (right or wrong, doesn't matter)? Should you not in fact rather have deleted the new copy of the text yourself with reference to the ongoing discussion?
I have not "alleged" much of anything beyond observable effects: I have criticised the actions you and Billinghurst have taken on this issue and pointed out the (negative) effects those actions have. I have expressed disappointment at these actions, and I will readily reiterate that disappointment if needed. There was absolutely no reason why this issue should have become one of the kind where a participant should feel it both appropriate and necessary to demand retractions. Especially if one is certain of what the outcome of that community discussion would be (which I am certainly not).
And, yes, I absolutely acknowledge and applaud your initiative to discuss it. That was indeed the outcome I was seeking to facilitate, and your argument put forth there neatly got to the essence of what I see as the main one in favour of keeping it. There are however several and strong counter-arguments, that are now not being advanced, and the outcome of that discussion is by no means obvious in advance. --Xover (talk) 13:38, 1 March 2020 (UTC)
WS:PD#Senator Paul on Impeachment of President Trump. Hesperian 22:52, 1 March 2020 (UTC)
The person's name is already widely reported as allegedly being that of the whistleblower. A number of widely-read publications now routinely refer to this person by name as the alleged whistleblower unlike in this speech where Paul explicitly states he does not know the identity of the whistleblower and is not suggesting any person he named is the whistleblower. It is a name that has been out there for months as allegedly being the whistleblower's name, including in a couple sources that would be considered reliable on Wikipedia. Some social media sites have blocked the name, but Twitter is one major exception where the name is still generally allowed to be mentioned as being allegedly of the whistleblower. Reality is that if this person were ever at any genuine risk of real-world harm, the cat is so thoroughly out of the bag now that it really doesn't matter how we handle it here on WikiSource. As noted in the discussion, Paul's remarks without any redactions are already available in the Congressional Record and the video of the speech can be viewed right now on C-SPAN's website.--The Devil's Advocate (talk) 07:53, 1 March 2020 (UTC)
Yes, that is exactly the sort of discussion we should be having about how to handle this work. --Xover (talk) 08:12, 1 March 2020 (UTC)
When you say "widely reported", that comes with a caveat. It's on Breitbart, but not the New York Times, Washington Post, Wall Street Journal or any other mainstream source. Faccebook and YouTube are blocking it. In fact, that is the reason Rand Paul went to such extraordinary lengths to try to publicise it. Even most Republican lawmakers are not saying it, Paul is only saying it in the chamber (where he has the legal shield of the speech and debate clause), and for any of them to mention the speculated name in public might well lead to consequences under applicable whistleblower protection statues. The fact that naming the speculated whistleblower puts them in danger is not something conjured out of thin air here. Most mainstream sources covering the issue note the risk to the speculated whistleblower from outing (e.g. [14]) and there are reports that they have been provided with armed protection. So this is one of those cases where we are doing something because we can do it, despite a robuist consensus in the real world that we should not do it. JzG (talk) 10:02, 1 March 2020 (UTC)
@Xover: This information is published on the website as text and as video on your government's congressional website, and as such it is not outside of our immediate scope. Don't set up strawmen; if you have concerns over trust and safety, then ask WMF, stop farnarkling.

@Kalliope (WMF), @JSutherland (WMF): Joe and Kalliope can you please give us your impressions over this matter with your WMF hats in place, and whether you see the hosting of this work is against the terms of use; or something that you view as problematic. Thanks. — billinghurst sDrewth 10:53, 1 March 2020 (UTC)

Whether they consider it problematic doesn't really matter, only whether it goes against the Terms of Use. As far as I can tell, the only part of the Terms of Use that would be considered here is "Infringing the privacy rights of others under the laws of the United States of America" and there are no such rights being violated. The question has been reviewed by many fact-checking organizations and media outlets. All of them have concluded no law actually prohibits naming the alleged whistleblower, unless it is the ICIG and his staff doing the naming. Some have tried to argue for other laws applying, but they wouldn't apply in this context as they involve trying to block truthful testimony, which is the opposite of what those naming the whistleblower want.--The Devil's Advocate (talk) 18:19, 1 March 2020 (UTC)
New York Post is generally considered a mainstream source, though some may not consider it reliable, and they too have reported the whistleblower's alleged name. The Dallas Morning News is generally considered reliable and is a mainstream source, which has also reported the whistleblower's alleged name. UNIAN, Ukrainian state media and generally considered reliable, has also reported the whistleblower's alleged name. Washington Examiner, The Federalist, RealClearPolitics, Gateway Pundit, Heavy, and PJ Media, are all outlets that give out this name. Many or all of those may not be considered "reliable" on Wikipedia, but it is also pretty clear this name is out and it is out with the audience who would supposedly be the greatest threat to the alleged whistleblower. Hell, the President of the United States himself has repeatedly shared comments on Twitter naming this alleged whistleblower. We have a Senate speech that is in the Congressional Record of a Senator talking about something reported in a media outlet about someone alleged to be the whistleblower, but the speech itself never suggests a specific person is the whistleblower. If none of the other things I have mentioned have put the named person in real danger, rather than perceived danger, then it is hard to imagine how republishing something from the Congressional Record that never even alleges that a specific named person is the whistleblower will suddenly make the perceived danger real.--The Devil's Advocate (talk) 17:19, 1 March 2020 (UTC)

Pictogram voting comment.svg Comment @Xover: You have now had two free swings at me, and I don't see that you have reflected on your actions at all.

  1. You unilaterally speedy deleted a work based on a criteria outside of any existing speedy criteria, including oversight rationale.
    • The claims made by the proposed in the opening of the discussion are problematic and not evidence-based, and you let them stand, or you accepted them unchallenged without obvious reflection.
    • You immediately came forward with an opinion that is not neutral, and made unilateral pronouncements of what should occur, and that you salted the target.
    • The work at first look is within scope—though came from a deleted transcription which definitely throws doubt on veracity
    • You made unsupported claims of the consequences of personal identifying information, and imminent harm, for a person's name—a name that I will note that I had heard from Australia weeks ago from lightly following congressional event; and a name that was suitably known to be in a Wikipedia abuse filter
    • You made no attempt to discuss the matter of the contribution or the deletion with the contributor, and one who has been editing here since 2006.
    • It is not evident that you reached out to any other administrator, privately or publicly, to see if they were in agreement with your action
    Did any of your fellow admins swing at you?
  2. What happened subsequently.
    • An undeletion conversation was started
    • Another user said that they had put up a copy of the work from an authoritative and very publicly available source
    • The undeletion conversation was closed as that version of the work was not coming back in any form, as it wasn't; comment was made that users could progress with the alternate copy of the work. My determination was solely on the work under review.
      • Did you consider that this discussion was open and continuing and the appropriate place for the conversation of scope, not an undeletion conversation.
      • Did you consider that a new (vanilla) deletion discussion has occurred that was always going to fail as it will be addressed on traditional terms, and the aspects that you introduced were never going to be strongly presented as it is going to solely come down to scope.
  3. Have you considered what other options existed for you to manage the work that seems within scope?
    • Blank the page
    • Use of style="display:none;" as we do with copyvios
    • redacting the problematic section, and revdel'ing the earlier edits (all undo-able)
  4. So I would ask for you to reflect on where your personal opinions and actions have contributed to this position.
    • Was your first action the right one, or maybe with some consultation and consideration there was a better choice.
    • You have riled against others as they have not done as you have unilaterally prescribed, is that reasonable?
    • That other admins with suitable experience don't do as you prescribe, is it reasonable to swing as you have swung?
    • Have other administrators not acted in an intermediate way due to how this seems to have been escalated the issue into a binary option, despite that intermediate means being suggested. — billinghurst sDrewth 12:51, 2 March 2020 (UTC)
@Billinghurst: Try as I might—and I have indeed tried—I am able to take nothing from this message beyond the essence that you feel you know better than me and therefore felt justified in overruling my call on this. Without any consultation. As I believe both you and Hesperian have advocated previously, had you commented in this thread to say you felt immediate salting was an overreaction and the text should be undeleted while the community discussed, I would have seriously considered it. Had you both commented to that effect I would almost certainly have done so, despite my own misgivings. Instead your (combined) actions have had the same net effect as if you had gone in and directly undeleted the page and removed the protection. And I have yet to find any indication that you are even willing to acknowledge this on a purely factual basis, much less admit that it could have been handled better. I feel very discouraged by this. --Xover (talk) 12:31, 3 March 2020 (UTC)