Wikisource:Scriptorium/Archives/2020-02

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 in , 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?

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

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

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 February. It will be on non-Wikipedia wikis and some Wikipedias from 5 February. It will be on all wikis from 6 February (calendar).

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

20:04, 3 February 2020 (UTC)

Img float: width in ems

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? 114.78.171.144 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. Inductiveload—talk/contribs 08:45, 5 February 2020 (UTC)

PD-anon-50

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”

Tracked in PhabricatorTask T240858

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

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)

Update 7 February

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)

Link back to Wikidata

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

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)❤T☮C☺M☯ 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

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

Problems

  • There was a problem with the new MediaWiki version last week. It deleted some messages by accident. The new version was late because it was stopped to fix things. [4]

Changes later this week

  • Advanced item The MediaWiki action API is used by various tools like bots and gadgets. Some error codes will change. Some parameter values that do not follow the standard will no longer work. [5]
  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 11 February. It will be on non-Wikipedia wikis and some Wikipedias from 12 February. It will be on all wikis from 13 February (calendar).

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

19:09, 10 February 2020 (UTC)

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

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

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

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 https://archive.org/details/in.ernet.dli.2015.148258/page/ , 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) -- Slowking4 ⚔ Rama'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)

Periodicals

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)

 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? Inductiveload—talk/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). Inductiveload—talk/contribs 19:38, 12 February 2020 (UTC)

Wikilivres is gone

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)

https://wikilivres.ru is still live. :/ —Justin (koavf)❤T☮C☺M☯ 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. Slowking4 ⚔ Rama'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.Slowking4 ⚔ Rama'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. Slowking4 ⚔ Rama'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)❤T☮C☺M☯ 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)❤T☮C☺M☯ 07:56, 2 February 2020 (UTC)

 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

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

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 "/"

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

Jus poking around to see if any weightless pound template names suggested themselves. Found these:
  • {{Lb.}} : ℔ ; (13 occ.) ⁠(uses &#8468; "℔")
(redirects)
  • {{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)

Hi There,

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

Thanks Jenni—unsigned comment by Bloomersgirl (talk) .

you could check out https://quod.lib.umich.edu/c/clementsead/umich-wcl-M-30ger?view=text or https://discovery.nationalarchives.gov.uk/details/c/F47690 but this would be arduous scholarship. Slowking4 ⚔ Rama's revenge 00:05, 17 February 2020 (UTC)

YYYY works

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

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

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

Changes later this week

  • Recurrent item The new version of MediaWiki will be on test wikis and MediaWiki.org from 18 February. It will be on non-Wikipedia wikis and some Wikipedias from 19 February. It will be on all wikis from 20 February (calendar).

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

16:16, 17 February 2020 (UTC)

External links in the header "next=" field

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

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

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

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

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

Future changes

  • There will be a reply button after each post on a talk page if you want one. This will soon be a beta feature on the Arabic, French, Dutch and Hungarian Wikipedias. You will have to turn it on if you want to use it. It will come to more wikis later. You can test the reply button. It was briefly shown earlier than planned by mistake on the four first wikis last week.

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

20:59, 24 February 2020 (UTC)

Additional interface for edit conflicts on talk pages

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

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 'https://tools.wmflabs.org/phetools/hocr_cgi.py?cmd=hocr&book=Centennial%20History%20of%20Oregon%201811-1912%2C%20Volume%201.djvu%2F628&lang=en&user=Ninovolador' because it violates the following Content Security Policy directive: "default-src 'self' data: blob: upload.wikimedia.org https://commons.wikimedia.org meta.wikimedia.org *.wikimedia.org *.wikipedia.org *.wikinews.org *.wiktionary.org *.wikibooks.org *.wikiversity.org *.wikisource.org wikisource.org *.wikiquote.org *.wikidata.org *.wikivoyage.org *.mediawiki.org wikimedia.org". 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)
Done It seems they have recover now. --Ninovolador (talk) 05:11, 27 February 2020 (UTC)

editing gone awry

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?

(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 Archive.org to have a 1921 date, which is clearly wrong; Wikipedia has 1924, agathachristie.com 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. Slowking4 ⚔ Rama'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

Tracked in PhabricatorTask T241889
Tracked in PhabricatorTask T188844

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?

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)

 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)

How to deal with copyrighted parts of otherwise PD works?

Sometimes it may happen that most of a work is in the public domain, but some parts (typically the preface) are not. In such a case the work can be hosted here, only the subpage with the copyrighted part cannot. However, if we simply leave the link in the contents of the work to the copyrighted preface red, reader may not always understand the reasons, why the preface is missing here, and also the navigation between indiviual parts in the header is interrupted by the red link. Czech Wikisource has solved this by creating a template which enables to create the copyrighted part, only instead of the copyrighted text it includes information that the part is copyrighted and so cannot be hosted at WS, and at the same time lists the subpage in a category like e. g. Category:Copyrighted until 2050 (which also helps admins with renewing deleted parts of works after the copyright expires). For an example see cs:Ottův slovník naučný/Hamsun.

Are there any possibilities like this here? If not, do you think it would be a good idea to create a similar template? It could be used for example for Fumifugium: or, the Inconveniencie of the Aer and Smoake of London/Note which seems copyrighted until 2071, although the rest of the book is PD. --Jan Kameníček (talk) 11:31, 29 February 2020 (UTC)

[Admirable, but do you really see that we have a 2071 problem or the need to design a solution for then? Probably lucky to exist in any form.] To this point we have utilised the index pages for notations, and a work's talk page, and I would suggest that is the means to address the issue. Make notes, categorise as having pages removed, make notes on author page that utilise {{copyright until}} for the preface. — billinghurst sDrewth 06:50, 1 March 2020 (UTC)
OK, {{copyright until}} solves some of the concerns I mentioned, so I will go with it. After the subpage is deleted, I will make a notice on the work’s talk page too. It is true that there are not that many cases at en.ws where the PD date is based on the year of publication, as it is in wikisources with the PD date based on the author’s death (and thus different parts of a collective work often expire on different dates), so the need for some systematic solution is not so strong here. --Jan Kameníček (talk) 12:02, 1 March 2020 (UTC)
I have addressed this using {{text removed}}, for example AWK Language Programming/GPL —Beleg Tâl (talk) 13:15, 2 March 2020 (UTC)
commons:Commons:De minimis is for copyrighted parts of otherwise PD files, so we may be much less likely able to claim de minimis for copyrighted parts of otherwise PD texts.--Jusjih (talk) 01:38, 9 March 2020 (UTC)

PD-anon-1923 again

The discussion of Happy Public Domain Day! has slipped into the archives without getting into some conclusion, so I would like to remind that the last suggestion in the above mentioned discussion was to create {{PD-US|year of death}} and deprecate {{PD/1923}} and {{PD-anon-1923}}. Is this solution OK?

BTW: if we decide to keep calling the license templates for pre-1925 works {{PD/1923}} and {{PD-anon-1923}}, it would be necessary at least to adapt the latter one so that it could be used for 1924 anonymous works too. --Jan Kameníček (talk) 16:21, 20 February 2020 (UTC)

 Support the change — I don't really care but it makes sense —Beleg Tâl (talk) 16:36, 20 February 2020 (UTC)

 Comment If there is a consensus to act, my recommendation is that we just move/rename the templates

  • pd/1923|yyyy -> PD-US|yyyy, yyyy=YoD, displays two templates as now
  • PD-1923 -> PD-US, where no $1 parameter it displays the one template
  • PD-anon-1923 -> PD-anon-US|yyyy, year of publication

and update the documentation around the place. Do any internal required tidying around internals of templates, and fixing double redirects. No need to deprecate anything, just move to the new nomenclature, and not worry about any of the old usage, or anyone continuing its use, as it matters not. — billinghurst sDrewth 11:15, 21 February 2020 (UTC)

  •  Oppose Firstly, because of the US emphasis. Yes, we follow US copyright law, but we also serve an international readership, not to mention contributors who are also bound by the copyright laws of other countries. Secondly, I think replacing "PD-1923" with "PD-US" is confusing. "PD-US" sounds like a generic template for "this work is PD in the US", but under this proposal it would mean "this work is PD in the US for the specific reason that it was published more than 95 years ago". BethNaught (talk) 22:16, 21 February 2020 (UTC)
    I do not understand in what way "the readership" is concerned in this… They see only the text of the template which is going to stay the same. --Jan Kameníček (talk) 23:08, 21 February 2020 (UTC)
     Comment I do not think that the suggested name of the template is more American-centred than the old one. E.g. {{PD/1923|1943}} has got two parts: "1923" is the American part referring to the American copyright laws, and the parameter "1943" is international referring to the countries where PD depends on the year of death. Nothing would change, only the American part would be called "US" instead of the nowadays non-sensical 1923, I really do not see any problem in that. --Jan Kameníček (talk) 23:08, 21 February 2020 (UTC)
    @BethNaught: The thing is that the only consideration we give to copyright compliance with regard to hosting is to the US copyright. Unlike Commons, we don't really care whether it is copyright in the country of origin. It is for this reason that I am reasonably comfortable with just stating PD-US and variants. The additional PD-old-70 and variants are for information only. — billinghurst sDrewth 00:43, 22 February 2020 (UTC)
  •  Comment I think this is an important issue, and I'd like to weigh in. I'm probably as familiar as (almost) any Wikimedian with the considerations around copyright law in various countries. But I do not see a clear statement of what the problem is that we're aiming to solve, or what the pros and cons are. I'm sure if I took an hour or two to dig through various archives, I could probably figure it out, but I'm not likely to have the time for that...nor should we expect every voter to do that. So given all that, I'm inclined to gently oppose, simply because I can't figure out what's going on, and it seems unwise to make a change that is difficult for community members to evaluate. Is it possible to sum up the issues more concisely so that I can give it more proper consideration, without having to do all the research myself? -Pete (talk) 22:44, 21 February 2020 (UTC)
    The problem I see is this: Until 1923 it made quite a good sense to have a template called PD-1923, because it referred to the fact that only pre-1923 works are in the public domain. However, the situation has changed, currently the time border is 1925-01-01 (or 1924-12-31) and it shifts every year. I perceive it as very confusing to call the template for pre-1925 works PD-1923 (why 1923???). At the same time it does not make sense to change the name of the template every year (PD-1923, …, PD-1925, …), it would be better to find a fitting universal name. --Jan Kameníček (talk) 23:16, 21 February 2020 (UTC)
    Ah, that's very helpful @Jan.Kamenicek:, thank you. I had misunderstood, I thought you were proposing a change to the functionality in addition to the name change.
    I agree that changing the name (a) such that it specifies "US" and (b) such that it references the 95 year rule, rather than the (now outdated) 1923 rule would be worthwhile. I agree with others that we should be cautious about US centrism; but the reality is, with a current title that assumes that it relates to US law, without stating it, we already have a high degree of US centrism in the title. In my view, it's better to state "US" as part of the name, to make it clear to editors (who are the primary audience for a template name) that it's about US law. So, my suggestion would be {{PD-US-95}} or similar. That conveys that it's about US law, and it's about the 95 year rule. Text on the template page/docs could clarify that the 1923 rule is now outdated, and subsumed under the 95 year rule.
    A related issue that I find confusing: I don't understand why we need two separate templates for {{PD-1923}} and {{PD/1923}}. I think this proposal only relates to the latter; would we be leaving PD-1923 intact? A decision on this is probably a matter for a separate discussion, but I'd like to know for sure what the intent of this proposal is. -Pete (talk) 23:45, 21 February 2020 (UTC)
    PD-1923 has no decision-making applies just a single template, it does not add the PD-old-nn variants. It has been utilised where we have been unable to determine a date of death, or for corporate publications which do not have PMA decisions. I addressed above that they would morph into PD-US, though we would need to handle them as parameterless. — billinghurst sDrewth 00:51, 22 February 2020 (UTC)
    Jan, that's not quite correct. Works published before 1923 are still in PD in the US for the same reason they were before. The 1923 date was a cutoff date beyond which we have never had to check. What has changed is that works that were under copyright later than that (from 1923 and 1924), and had their copyright renewed at one point, have now had that copyright protection expire. The works published before 1923 were not eligible for renewal and entered PD for a different reason than the works published in 1923 and 1924. It is one view to see the date as a shifting cutoff, but the cause of works from 1923 and 1924 entering public domain is actually different from those that were published prior to 1923. --EncycloPetey (talk) 03:13, 22 February 2020 (UTC)
    All works published more than 95 years ago are out of copyright because of the time since publication, no matter whether that's due to copyright notices, or renewals, or being in copyright for a full long term. For a work published before 1923, we've never been concerned about copyright notices or renewals, nor how long work published with copyright notice and renewal got in copyright. Why does it matter that a work published in 1924 may have got 95 years of copyright, whereas a work published in 1922 may have only got 75, when we don't really care about that 95 or 75 in the first place? We have no tag for "published abroad before non-US works got copyright in the US in 1891", because we don't care; it has always been sufficient for our purposes to say that it was published before 1923, and I don't see why it is not now sufficient to say that it was published more than 95 years ago.--Prosfilaes (talk) 04:59, 22 February 2020 (UTC)
    @Prosfilaes: I am presuming that this is in reference to the primary notice about copyright within the US, not the secondary notice for PD-old-nn which relates to copyright elsewhere in the world. The secondary notice can still apply for those of us not in the US, which is why we added it. — billinghurst sDrewth 05:08, 22 February 2020 (UTC)
    Yes, the primary notice. There's no need to worry about now-historical features of non-US countries, but certainly helpful to list the years since death.--Prosfilaes (talk) 05:18, 22 February 2020 (UTC)
    Yes and no. There are authors who have works published prior to 1925 who died late enough to still have works in copyright in their home country, so those notices are still very pertinent per Category:Media not suitable for Commons. — billinghurst sDrewth 05:30, 22 February 2020 (UTC)
    Right; I didn't mean to imply we should change the current secondary notices.--Prosfilaes (talk) 06:42, 22 February 2020 (UTC)
  •  Support U.S. copyright is of primary concern to Wikisource. Fixing the license so more 1923 and 1924 works appear on Wikisource even if still under copyright in other countries is so important. Abzeronow (talk) 19:46, 16 March 2020 (UTC)
  •  Support as this seems like the least problematic solution to the problem, and it doesn't make sense for us to keep delaying a resolution. Kaldari (talk) 18:09, 14 April 2020 (UTC)
  •  Comment It looks as though some people are hedging their bets: arguing for deprecating the template on the one hand but arguing for improving the template on the other. Since the template content has now changed, before this discussion has concluded, then proceduraily we should recast all votes, since the template named in this discussion thread no longer has the content it had at the start of this discussion. --EncycloPetey (talk) 20:42, 24 April 2020 (UTC)
    Hedging their bets? It is somehow improper to try and improve Wikisource for now, whether or not this template gets deleted? If we're going to get pedantic about policy, where is it written on the English Wikisource that we should recast all votes?--Prosfilaes (talk) 06:41, 25 April 2020 (UTC)
    No need to restart the votes, as the changes have been reverted. The template is the same as it was before the voting started. No changes should be made to any template if there is a discussion and voting ongoing about its future. If the changes were allowed and at the same time we would have to restart the voting after every change, we may never come to a conclusion; not everybody has time to vote about the same problem again and again. --Jan Kameníček (talk) 09:50, 25 April 2020 (UTC)
  •  Support If there must need a consensus to fix math wrongs, let it be. --Liuxinyu970226 (talk) 09:01, 7 May 2020 (UTC)
  •  Comment Please note that the new date, 1925, applies to all works except sound recordings (and maybe architecture). The date for sound recordings is 1923. That isn't shown in the local summary of the Hirtle chart, but is in the original. (I dropped a more detailed comment below.)--Sphilbrick (talk) 14:29, 20 July 2020 (UTC)
    Interesting point. If it is really so and if we need to show a license for sound recordings somewhere, we would probably have to create a specialized template for them.--Jan Kameníček (talk) 11:44, 2 December 2020 (UTC)
    Yeah. Sound recordings have a tortured history in US copyright law, but the end point is that the first recordings to have their copyright expire in the US will be in 2022, for those published before 1923. See w:Public_domain_in_the_United_States#Sound_recordings_under_public_domain.--Prosfilaes (talk) 00:51, 3 December 2020 (UTC)

So it seems to me that there is a weak consensus for the change. If so, it might be better to make it before the end of the year, so that works newly entering public domain can already be added with new templates.

The less important change is renaming the templates from {{PD/1923|year of death}} and {{PD-anon-1923}} for {{PD-US|year of death}} and {{PD-anon-US}}. It is only a change of the names of the templates, what the readers see will not be affected by this.

The more important change is adapting the latter one so that it automatically counted the years as {{CURRENTYEAR}}-95, similarly as it has been done e. g. here.

--Jan Kameníček (talk) 11:44, 2 December 2020 (UTC)

Looks like an interesting, but a very long, discussion. Is there a way for a newbie to get involved without spending hours and hours? Thanks in advance, Ottawahitech (talk) 18:24, 10 December 2020 (UTC)

I have updated {{PD-anon-1923}} and moved it to {{PD-anon-US}}, and also moved {{PD-1923}} to {{PD-US}}, per discussion above. However, {{Pd/1923}} is locked and so I asked it to be moved to {{PD/US}} at the Admins' noticeboard. --Jan Kameníček (talk) 14:20, 26 December 2020 (UTC)

This section was archived on a request by: nothing new has been identified, I think we can call this complete — billinghurst sDrewth 01:20, 10 April 2021 (UTC)
Retrieved from "https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium/Archives/2020-02&oldid=11724664"