Wikisource:Scriptorium

Scriptorium
The Scriptorium is Wikisource's community discussion page. Feel free to ask questions or leave comments. You may join any current discussion or start a new one; please see Wikisource:Scriptorium/Help. Project members can often be found in the #wikisource IRC channel webclient. For discussion related to the entire project (not just the English chapter), please discuss at the multilingual Wikisource. There are currently 348 active users here.

AnnouncementsEdit

ProposalsEdit

Bot approval requestsEdit

Repairs (and moves)Edit

Designated for requests related to the repair of works (and scans of works) presented on Wikisource

Amazing Stories v01n12Edit

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)

Other discussionsEdit

Curating works for exportEdit

We have a lot of works that are considered "done", but they are quite hard to find as a mobile user interested only the end product:

  • We have Category:Validated texts, but not all validated works have this category set
  • That category is full of things like the XXX (DNB00) pages which makes it very unfriendly by itself, since those pages aren't really targets that you'd be likely to export.
  • For the works in that category, not all are well-suited for export. For example, they might not have a TOC on the front page, which kills the export tool's ability to gather all the pages.
  • Some works are perfectly exportable, but are only Proofread. Again the cat is not a perfect set of all proofread texts.
  • Both cats can also contain works and subpages of works, when you'd only really export the work. Eg. Aesthetic Papers and Aesthetic Papers/Correspondence

I suggest that we start a new category: "Work for export" or something (an analogue of fr:Catégorie:Bon pour export), which consists of works that are known to be set up correct for a functioning ws-export export:

  • They have a TOC that works to trigger exporting of the work in the right order
    • If there is no visible TOC (e.g. the TOC is on a subpages), then there is a class="ws-summary" to do this instead.
  • No valuable content (e.g. chapter headings) is hidden in the header templates, as this content doesn't get exported.
  • The formatting is suitable for e-readers:
    • Avoid fixed-width text containers
    • Avoid fixed column-based layout (e.g. {{div col}} often looks pretty bad when you're squeezing 4 columns into an e-reader)
    • Avoid over-indenting from either margin, eg by use of ::::::, etc
    • Avoid complex layouts that freak out e-readers (I don't have a really good baseline on what counts here).

Thoughts? Inductiveloadtalk/contribs 13:42, 21 January 2020 (UTC)

I don't think we should impose some complex formatting rules on exportable works. There's going to be exports to tiny phones and exports to large tablets, or even letter-sized PDFs for printing. We can discuss formatting separately, but there are going to be works where you have to do what you have to do. I've got mathematics books on Kindle right now that didn't come out well, but at least they're there.--Prosfilaes (talk) 17:48, 21 January 2020 (UTC)
Sure there's a lot of "best you can do, this wasn't designed for the format". I was thinking more of the easy things like avoiding fixed columns, fixed widths (e.g. use max-width rather than width) etc - generally avoid setting hard-coded horizontal positions where possible, and it'll come out "OK" on various media sizes. Some things like massive tables are just tough, they are what they are, the reader needs to scroll sideways.
I'd say the majority of "normal" works don't have any major formatting issues that interfere with export, and most of those that do are minor.
The reason I mention formatting is that it's something you should ideally at least consider before you declare a work is "good for export", especially as some remedies are trivial. Also, taking care of ebook formatting also fixes the mobile formatting for free. Inductiveloadtalk/contribs 18:04, 21 January 2020 (UTC)
@Inductiveload: I believe you mentioned that {{FreedImg}} is not good with e-readers. What image templates do you prefer instead? I’ve been using FreedImg constantly, but the initial choice was almost entirely because I like its default caption settings (centered, smaller text). If I have to add that formatting by hand to some other template, I will. I notice that {{Plain image with caption}} allows, and requires, almost unlimited handmade css, whereas FreedImg has lots of built-in parameters. Levana Taylor (talk) 19:15, 21 January 2020 (UTC)
I, too, have been using {{FI}} extensively, and share Levana's questions. @Kaldari: I want to make sure you see this topic too, as your recent efforts seem to overlap. -Pete (talk) 19:41, 21 January 2020 (UTC)
This I am not sure about. FreedImg uses the full-sized image from Commons, which can be hundreds of times the size of the image actually needed on the page (e.g. the iceberg image on the template doc page is 300 times the size a normal thumbnail would be). This results in exported files being up to and over 100MB, when they'd "normally" be 1 or 2MB. This is a bit unfriendly to mobile users on limited data plans, and also for people with limited e-reader storage.
It does this so it can scale up as needed to fill space, but it seems to be a rather heavy way to deal with it. I don't have any bright ideas to "fix" it, but I'm not quite sure of what FI is trying to achieve, since it seems to be trying to achieve everything at once.
If you find yourself with substantial work-specific formatting, I would probably suggest one or more "OAW img" templates to wrap a standard image template and handle it for you so you can avoid excessive markup on the content pages. Then you have a single place to keep formatting within the work consistent. Inductiveloadtalk/contribs 19:49, 21 January 2020 (UTC)
A wonderful idea, if someone would create the templates: I think the requirements are quite simple, & I’ve stated them at Wikisource:Wikiproject Once a Week/Layout talk#Image templates. There would be no need to use FI, since the images are never used here at a greater width than 800px, and there’s only a few parameters. Levana Taylor (talk) 20:49, 21 January 2020 (UTC)
I have come up with a solution to the {{FI}} situation: {{large image}}. It will use whatever pixel size you invoke if it has enough space, and if not, it will scale it down to fix the available space. Only the specified file size is ever loaded, which is a >10x reduction in the file size in the OAW images I tried it on.
The template is deliberately simple, it's not intended to be a kitchen-sink of options. 99% of large images are just a centred image. Captions and accoutrements can be done separately with their own formatting. If your use case is not a centred image that scales to fit smaller containers, this is not the template to use. But between this and {{img float}} (left and right only, centre is broken), that should cover nearly all images, I think? Inductiveloadtalk/contribs 17:19, 22 January 2020 (UTC)
Many of your "avoids" would preclude our poetic and dramatic works, as these works typically require a lot of formatting. --EncycloPetey (talk) 23:14, 21 January 2020 (UTC)
Not at all, the thing to avoid is fixed width manipulation, where then container cannot adjust to smaller screens. It's OK to have, say, a block-center, with an unspecified or maximum width, because this will be able to get smaller when the screen does. Having a fixed width ensures that the content will disappear off the right side of the screen if the device is small enough. For example, look at The Desecration of the Han Tombs: if you constrict the width, nearly all the content goes off the right side (because center-block set width, not max-width). Compare to, say, Venus and Adonis, where the center-block is not fixed, and this doesn't need the user to scroll right to read every single line, and then left to start the next line. If you need to constrict width (e.g. your poem has extremely long lines), use max-width.
Very occasionally, you may really require a fixed-width container, and if that's truly the only way, then it's how it is: the user will need to scroll. But it's unfriendly to expect them to scroll for every single line. Inductiveloadtalk/contribs 10:01, 22 January 2020 (UTC)
About how many pixels wide is the page display on typical mobile eaders, do you have any idea? Levana Taylor (talk) 11:19, 22 January 2020 (UTC)
It's a difficult judgement to make, because devices vary. Phones tend to have about 350-450 "effective" pixels (they often have 1080 or bigger screens, but they scale the content). Iphone 6/7/8 is 375, Galaxy S9 is 360. With the default settings on my phone's browser (effective screen size 1080/3=360), it looks to be about 23em: the line "Hunting he lov'd, but Love he laught to scorn:" just fits on one line.
E-readers vary too, but they also have user-set font size, so any assumptions about pixel-to-em sizes are void. On my phone e-reader app, my current settings are about the same as the mobile website: 23em to a line. But if I zoom the font size out, it's more, and in, it's less. A small tablet device would probably be closer to 40em because the screen is physically bigger, and a full-on iPad could be 50em or more. All depending on the users' settings, users with poor eyesight will likely have the font sizes larger, and the line lengths will be shorter in terms of ems. For reference, 30-50em is roughly the width of an average book's line (of course that depends on font size, page size, margins, etc).
Basically, if you were to make sure the page renders sanely at ~350px, with "normal" font scaling, I think you'd cover nearly all practical devices.
Also note, the mobile website scales images with CSS (max-width: 100% !important;), so though, for example, the image at The Education of the Deaf and Dumb Practically Considered is full-sized (655px), it will be scaled to avoid spilling out on mobile. My e-reader seems to also shrink images to fit the page too in the ePub, but my computer document viewer does not; there is nothing in the ePub that causes this, it's the app's own behaviour, it's not encoded in the ePub. Inductiveloadtalk/contribs 12:13, 22 January 2020 (UTC)
Right, I will try not to have any fixed widths greater than 350pxd then, although it’ll sometimes simply be inevitable. (Advanced way of handling things like tables and musical scores would be to create a thumbnail image of them, to be clicked if you wanted to see the real thing, but besides being too complicated, that really only makes sense in a mobile-only layout. We’re not going to have separate desktop and mobile versions anytime soon!) Levana Taylor (talk) 13:07, 22 January 2020 (UTC)
Generally, you shouldn't be specifying any width, fixed or otherwise for text in px anyway, because the px-em mapping is very variable. Someone with poor eyesight who has set a larger font size make only have 10 or 15em to a line.
For images specifically, it seems the mobile Wikisource site and at least some e-reader apps (I tried MoonReader+, Google Play Books and Overdrive) all seem to shrink images down, so even if they're over 350px, they come out just fine on mobile devices.
For scores, the mobile site does not (currently) force the size (so it spills off the right margin), but my e-reader apps do (in an ePub, the score is just another image).
Tables are often an example of "tough cookies", they often just require more width than a 350px screen can deal with. However, generally they are not scanned left-to-right, line-by-line like text, so having to scroll around is not such a burden. Smaller tables generally "just work". Sometimes adding a vertical-align can help when the cell contents wrap.
Do you have a page in mind where a fixed width is required? Inductiveloadtalk/contribs 13:42, 22 January 2020 (UTC)
Fixed width? Fair Drinking, because of how the image with the capital letter has to be next to the text, and the text column and image column really ought to be the same height, given that that's how the image is designed. Such cases are rare though! (And yes, I do specify text width in ems, always.) Levana Taylor (talk) 14:05, 22 January 2020 (UTC)
Hmm, yeah that's a tricky one. You could probably get away with just {{drop initial}}, but then the tail of the poem will jink left if the poem is taller than the image. Example of using drop initial. But I'd say as a one-off case, it's OK to just do it your way, and just be a bit too wide in this page. It's when entire slabs of works are unsuitable for e-readers for no good reason that we should worry.
BTW: This is a good example of where the FI template is loading huge things: the image as loaded is 1,123px wide and is 5,630kB in size (!). A 238px image rendered by the server is only 79kB. Inductiveloadtalk/contribs 14:25, 22 January 2020 (UTC)
That {{DI}} version of "Fair Drinking" utterly doesn't work on the mobile browser I checked, it makes the poem lines wrap badly as well as the end of the poem moving left below the image. Nah, we will have to just treat this poem+image as an unshiftable block. There are really not many like it, though. Levana Taylor (talk) 20:21, 22 January 2020 (UTC)
I think that's fair. I also can't see a way to make this work flawlessly on mobile devices. Almost as if they didn't have phone screens in mind when typesetting things in 1861! Inductiveloadtalk/contribs 21:54, 22 January 2020 (UTC)
Consider Swanwick's translation of the Eumenides, pages 147–149, & 154 or Henry_IV_Part_1_(1917)_Yale/Text/Act_II pages 50–52. The formatting in these plays likely won't tolerate narrow screens. There are dramatic works with much more complicated formatting than this, such as Electra_(Murray) page 81, where the complexity is simply unavoidable. --EncycloPetey (talk) 01:37, 23 January 2020 (UTC)
If it's unavoidable, then it's just how it is. Most of these works render pretty well on mobile and e-readers, exactly because they have not been typeset with fixed width columns, but with dynamic layouts in mind:
  • Swanwick: those pages are still readable on mobile (different minor flaws on mobile and e-reader), but it is still readable and it's a very short section. The rest is formatted OK.
  • Henry IV: seems pretty much OK. The 1em left margin applied throughout is a little annoying in mobile, but it's not terrible, and it does seem to exist in the original, though I kind of suspect it's only an artefact of the typesetting. pp50-52 don't seem any worse than any other?
    • Perhaps the biggest comment I have is the forced line wrapping of continued lines prevents justification (e.g. p47, first line and others). Compare to lines where the original was forcibly-broken because of the meter of the play, where there is a ragged right margin: p67. This isn't a mobile-only comment: it's impossible to tell continued text from line-broken text on all platforms, because it all presents with a ragged right margin. The same formatting (continuous is justified, verse is not) formatting is used in other Henry IV versions.
  • Electra: p81 looks OK on mobile (as good as plays ever look due to the ~23em line length), looks OK on Overdrive, but not great on Moon Reader+ (the headings end up in the right column prefixed to the lines with an empty void on the left). Again, a short section and still readable. The forced 4em left margin on p11 is a little bit unfriendly and I wonder if there's a better way to do that. It's only simulating the original typesetting (narrow centralised column, with right aligned text). But even then, at my normal font settings, it renders out fine on my phone, because the lines are short.
All three works are generally set (correctly, IMO) with width-agnostic layouts, and have {{default layout|Layout 2}} specified.
Far from "precluding our poetic and dramatic works", these works demonstrate that you absolutely can have such works for export, and (most of) the formatting will translate quite well. I'm not, and I never have been, advocating that we should dump formatting when it interferes with mobile, I'm simply saying when there's a possibility to get it right on mobile without screwing up the "normal" output, we should do so. Very few of my "avoids" above are necessary most of the time: probably under 1% of pages (warning: rear-end-sourced number).
For plays and poems with line breaks specifically, these can be a bit "wrappy" on phones, but that's just how they are, and they'll likely be just fine on tablets and "real" e-readers like Kindles, unless the font size is enormous.
I also do not advocate to make changes to satisfy quirks of individual e-readers: unless it's trivial and non-destructive for us to work around, we should output valid markup and expect devices to deal with it correctly. Inductiveloadtalk/contribs 07:43, 23 January 2020 (UTC)
If these works display reasonably well within the imposed conditions, then that's great. Note: the forced line wrapping is required in Henry IV Part 1 (1917) Yale, because of the line numbers. That section of the dialogue is prose, rather than metered, and for the Yale Shakespeare series, the prose sections are indented differently than the poetic lines. Setting it otherwise than it is would invalidate the line numbers from the edition. There is no other way to clearly indicate which bits of the text fall on a particular line if the text is allowed to flow continuously. --EncycloPetey (talk) 05:35, 2 February 2020 (UTC)

Amusements in mathematicsEdit

The following discussion is closed and will soon be archived:
Resolved.

I've been contributing a little to Index:Amusements in mathematics.djvu recently, but I have just stumbled on an older index which appears to be an identical duplicate version of the same book, but with considerably less work done on it. Index:Dudeney - Amusements in Mathematics.djvu I'm not sure if I should continue contributing to the newer Index or swap to work on the older Index? Or should one of these be removed? Thanks Sp1nd01 (talk) 15:14, 21 January 2020 (UTC)

They are both copies of the same book. I suggest deleting the index with almost no proofread pages. You needn’t be afraid to continute with the index that you have been contributing to so far. --Jan Kameníček (talk) 16:12, 21 January 2020 (UTC)
Thank you, I've gone ahead and placed a request for deletion on the Proposed deletions page. Sp1nd01 (talk) 19:39, 21 January 2020 (UTC)
  This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Xover (talk) 09:28, 15 February 2020 (UTC)

Wikisource Conference in WarsawEdit

Dear Wikisource Community,

Meeting the Wikisource community expectations, we are working with Wikimedia Polska and Wikimedia Foundation on organiziing the 2nd Wikisource Conference in Warsaw. We already had a survey that showed high interest in the Conference within the community. We also had recently a meeting on the conference organization process and its requirements. However, we are still at a very early stage of the Conference organization process. But we are hoping this event will happen in September this year.

In order to apply for Wikimedia Foundation support, we need some input from the community about the Conference goals and the community expectations. If you are a wikisourcian, you wish to participate the conference or you wish to help the Wikisource community that the conference take place, please fill the short survey linked below before January 29 (due to short deadline for grant applications). Please, also share this request among Your communities. Here is the link to the survey

https://docs.google.com/forms/d/e/1FAIpQLSf7FnFgMLPHeyWtBqjgXwLDYvh5vxeTnsZ0OIjTdSDrZlX0PA/viewform

Feel free to contact us, if you have any questions, suggestions, proposals, or if you wish to help us in any other way.

On behalf of the Organizing Commitee,

Nicolas Vigneron

Satdeep Gill

Ankry

This is a really important initiative! We can connect to the results of the previous Wikisource conference in Vienna (2015) in which we have discovered the power of cooperation between the different language versions of Wikisource and in which we have formulated a mission statement for Wikisource worldwide.
In general the most important feature of Wikisource (as compared with other "systems" like for instance Gutenberg, Internet Archive etc.) is the proofread-extension, and of course, the integration in the Wikimedia environment and community. We have a unique feature in our hands. But we are not able to use this tool to create a strong and worldwide known "brand".
What do we need?
a. Further integration and cooperation between different language versions of Wikisource worldwide, especially concerning the proofread-extension. Including: creating a worldwide pool of people with knowledge of the software and of the practical applications.
First aim: further development of the proofread-extension.
With the final aim to enhance the overall quality, to create an easy to use platform even for the smaller Wikisources and to make it easier for volunteers to start.
This includes: creating high quality tutorials for all the important tasks in different languages.
b. Further integration with Wikidata, (but also with Wikischolia, Wikicite etc. and finally of course with Wikipedia, Wiktionary etc.)
There is still a lot of work to be done in these fields. How can Wikisource as a worldwide community contribute to the overall goals of Wikimedia? Presentation of examples of integration.
c. Work on integration and cooperation with Gutenberg, Internet Archive, Open Library and other worldwide organisations that have things in common with us (like WorldCat / OCLC, BHL).
How can we use the experiences of other organisations and how can we influence them to build one integrated infrastructure of open digital sources.
Included in this for instance: how can we promote the use of djvu standard?
To my opinion it is really worthwile to discuss these issues in a conference. --Dick Bos (talk) 10:24, 28 January 2020 (UTC)

Index:Sally in our alley.djvuEdit

The following discussion is closed and will soon be archived:
Resolved.

This work needs only two pages to be validated. Any takers? (Warning: both pages are full of LilyPond markup.) —Beleg Tâl (talk) 16:19, 24 January 2020 (UTC)

  Done Beeswaxcandle (talk) 18:38, 24 January 2020 (UTC)
  This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Xover (talk) 09:29, 15 February 2020 (UTC)

{{KJVulgate}}Edit

The following discussion is closed and will soon be archived:
Resolved.

Just came across this template, but in September 2018, There'sNoTime deleted the subpages of la:Biblia Sacra Vulgata (Stuttgartensia) due to a copyright violation as it was first published in 1969 (and later editions also exist). Can this template be deleted and its lone use removed? -Einstein95 (talk) 09:54, 27 January 2020 (UTC)

  DeleteBeleg Tâl (talk) 21:45, 27 January 2020 (UTC)
  This section is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Xover (talk) 09:30, 15 February 2020 (UTC)

Tech News: 2020-05Edit

18:52, 27 January 2020 (UTC)

Versions of TranslationsEdit

TL;DR: Should different editions of a single translation of a non-English work be listed on the work's Translations page, or on the translation's Versions page?

In a recent discussion it was pointed out to me that "in a library catalog, translations of a work are still considered to be copies of the same work; only the language has changed." This got me thinking about a habit of mine which, I have realized, I do not know whether other editors follow, nor whether they would consider it desirable or not. I also couldn't find any previous discussion on the subject, though maybe I haven't looked hard enough.

When we have multiple editions of a single translation of a non-English work, I have been in the habit of creating a Versions page for the translation of which we have multiple editions, separate from the original work's Translations page (if it exists). Examples of this are as follows:

work with multiple translations translation with multiple editions
Adeste Fideles O Come All Ye Faithful (Oakeley)
Bible Authorized King James Version
Prometheus Bound Prometheus Bound (Browning)
The Rubaiyat of Omar Khayyam The Quatrains of Omar Khayyam

A full list is available here.

Anyway, I am wondering—what do other editors think of this? Is this a good practice that we should encourage? Should I stop doing this, and instead collapse all these versions page onto the single Translations page for the original work? —Beleg Tâl (talk) 17:46, 28 January 2020 (UTC)

I have not thought deeply about this, but for whatever that's worth, my first instinct on this is that translations are just different editions of the same work. I hold it possible that some translations can rise to the level of a work in its own right, but that these will be the inevitable exceptions and edge cases. But, again, that's not necessarily a considered opinion. --Xover (talk) 18:42, 28 January 2020 (UTC)
"Translations in library catalogs and on Wikidata are treated simply as editions of the source text," this is not a library, nor library catalog; wikidata does not have a consensus. we need to arrive at a version ontology consensus. we can be informed by library practice, but they made compromises, that we may choose not to do. it is all a symptom of the bibliographic metadata hairball. Slowking4Rama's revenge 23:03, 28 January 2020 (UTC)
I don't know what Wikidata does or needs here. For just us, not on a theoretical basis but a practical one, I'd merge them. I don't see the advantage in having multiple layers here. Also, your third example Prometheus Bound (Browning); are the two versions by Browning two versions of the same work, or are they two distinct translations by the same person? Merging them dodges that question.--Prosfilaes (talk) 04:06, 29 January 2020 (UTC)
@Prosfilaes: as far as I know the two translations on Prometheus Bound (Browning) are versions of the same translation. I didn't actually create that page, and it could be a poor example. However, there are instances where the distinction blurs. For example, we have two versions of Draw nigh, draw nigh Emmanuel, and two version of O come, O come, Emmanuel. Whether these are two different translations by the same author, or just versions of the same translation, is debated. —Beleg Tâl (talk) 13:15, 29 January 2020 (UTC)

20c   Comment Both are okay, and it more relies on what is happening in the broader environment.

Purity would say that the ultimate is multiple editions of a translation would have their own versions page (author and translator fields completed) which is linked through Wikidata, to the Wikipedia article about that specific translator's work of that specific author.

I don't think that we are going to have many occasions of this, so doing them on the translations page is okay, especially if there is no special reason to separate them, until we desire to move them off. So if we had two versions, and no requirement to separate, then we can keep them there. If someone wants to do them on their own page, then we go to that further and separate these disambiguation, and that is okay.

Simple case

  • Translations page (one author) — linked pages utilise {{other translations}}
    • Translation author 1
    • Translation author 2
    • ...
(links to WD/WP original work)

Medium case

  • Translations page (one author) — linked pages utilise {{other translations}}
    • Translation author 1
    • Translation author 2, version 1
    • Translation author 2, version 2
    • Translation author 3
    • ...
(links to WD/WP work)

Complex case

  • Translations page (one author, some translators have multiple versions — linked pages utilise {{other translations}}
    • Translation author 1
    • Version page translation author 2 — linked pages utilise {{other versions}} to this version page (do not utilise other translations)
      (links to WD/WP work about the translator's work of author's work)
    • Translation author 3
    • Translation author 4, version 1
    • Translation author 4, version 2
    • Version page translation author 5 — linked pages utilise {{other versions}} to this version page (do not utilise other translations)
      (links to WD/WP work about the translator's work of author's work)
    • Translation author 6
    • ...
(links to WD/WP work)

billinghurst sDrewth 03:59, 29 January 2020 (UTC)

@Prosfilaes, @Billinghurst: The two editions at Prometheus Bound (Browning) are different translations, not editions of the same translation. Browning heavily retranslated in the later edition. The difficulty faced in setting up this page was deciding whether it ought to be a disambiguation page, a version page, or a translations page, since it is a bit of all three at the same time. Ultimately, since it is disambiguating two derived works of the same name by the same author, I went with a Versions page setup. --EncycloPetey (talk) 05:25, 2 February 2020 (UTC)
My opinion on having (or not) a separate page for editions of a particular author's translations: It depends on the status of the translation and/or the author. I have separated out Prometheus Bound (Browning) and Cyclops (Shelley) because of the status of those translations and their translators (Elizabeth Barrett Browning and Percy Bysshe Shelley). However, I have not separated out any translations of Agamemnon (Aeschylus), even where we host multiple editions of the same translation, because translators like Swanwick and Morshead do not hold the same status as authors. Morshead's translation is significant, but only within the specialized sphere of English translations of Aeschylus; he holds no status outside that sphere, and so creating a separate page for the various editions of his translations do not seem warranted. If we had multiple editions of Robert Browning's translation of Agamemnon, that might be worth a separate page, but we are less likely to host additional editions because Robert Browning never produced a revised translation, and so there will be little or no difference between editions. With the translation by Elizabeth Barrett Browning, the differences between the first and second editions are substantial, and the editions of Shelley's translation of Cyclops were subject to the whims of editors, producing editions containing differences worth comparison. --EncycloPetey (talk) 17:17, 2 February 2020 (UTC)

Wikilivres is goneEdit

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

  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)

The Story of MankindEdit

The following discussion is closed and will soon be archived:
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 [7] 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 is considered resolved, for the purposes of archiving. If you disagree, replace this template with your comment. Xover (talk) 09:32, 15 February 2020 (UTC)

How many files should we load?Edit

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

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

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

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

"l" not "/"Edit

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

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

Please direct any responses to this page, not to my IP address. --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-}}Edit

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)

Img float: width in emsEdit

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. Inductiveloadtalk/contribs 08:45, 5 February 2020 (UTC)

Tech News: 2020-06Edit

20:04, 3 February 2020 (UTC)

New error messages for the attribute “follow”Edit

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

 
Error message for follow attribute.

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

Hi Max. Thank you very much for the notice (and to Thiemo for doing the research I see in that Phab)! This kind of change is in general, IMO, a great improvement: much better to have such problems immediately obvious through an error message than to have to go hunting for them.
But I am a little concerned too: the ProofreadPage extension that is essentially the foundation for the Wikisourcen relies heavily on transclusion: texts are transcribed page by page from the scans in the Page: namespace, and are then transcluded together at the chapter or book level in mainspace (ns:0). That's why your example search above only finds 17 hits: the remaining 4.5k instances are all in the Page: namespace. Is this change going to mean big red error messages for all those pages? Because that would be… bad. And very likely to induce spontaneously elevated pitchforks-and-torches levels. :) --Xover (talk) 10:09, 4 February 2020 (UTC)
Considering that the "follow" attribute was created specifically to accomodate ProofreadPage, and that its use in Page namespace is literally the primary use case for this feature, it would be very bad for an error message to display when the feature is used by design. I have added a note on Phabricator and on the extension Talk page noting that the error message should not display in Page namespace for this reason. —Beleg Tâl (talk) 13:14, 4 February 2020 (UTC)
  • @Max Klemm (WMDE):   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" [8] and there will also be cases where {{#tag:ref|...|follow=whatever}} is used, as sometimes that has been required, though I have often subst: at the end to allow for clarity of the start and finish of the ref. — billinghurst sDrewth 23:17, 4 February 2020 (UTC)
    @Max Klemm (WMDE), @Thiemo Kreuz (WMDE): you may be interested in our local help at Help:Footnotes and endnotes#Footnotes that continue over page breaks. — billinghurst sDrewth

Update: There will be no new error messages after all.Edit

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

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

Update 7 FebruaryEdit

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

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

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

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

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

PD-anon-50Edit

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. [9]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)

PeriodicalsEdit

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? Inductiveloadtalk/contribs 14:36, 11 February 2020 (UTC)

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

Link back to WikidataEdit

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 PressEdit

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

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

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

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 RecordEdit

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)

Tech News: 2020-07Edit

19:09, 10 February 2020 (UTC)

Move page to WikisourceEdit

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 [13] and an american 1949 edition first printed 1927. [14] maybe a chunked upload from the later is in order. (the pagination is exactly the same among all three) -- Slowking4Rama's revenge 19:30, 11 February 2020 (UTC)
Sorry for not paying attention before, but this says 1919, on the title page and a little later but both Wikipedia and CliffNotes are quite clear that The Magic Mountain was first published in German in 1924, and Wikipedia says in English in 1927. We may have to delete this until 2023.--Prosfilaes (talk) 22:20, 11 February 2020 (UTC)
Formality, but I've taken this to Wikisource:Copyright_discussions#The_Magic_Mountain.--Prosfilaes (talk) 22:54, 11 February 2020 (UTC)

Bad works on the Digital Library of India?Edit

(Continuing from above, but a different and less transient subject.) File:The Magic Mountain.djvu says 1919, on the title page and a little later but both Wikipedia and CliffNotes are quite clear that The Magic Mountain was first published in German in 1924, and Wikipedia says in English in 1927. I also found a copy of Poirot Investigates on the Digital Library of India on 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. Slowking4Rama's revenge 00:54, 17 February 2020 (UTC)

George Germain Sackville, Germain,_George_Sackville_(DNB00)Edit

Hi There,

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

Thanks Jenniunsigned comment by Bloomersgirl (talk) .

you could check out 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. Slowking4Rama's revenge 00:05, 17 February 2020 (UTC)

YYYY worksEdit

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 WorldEdit

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-08Edit

16:16, 17 February 2020 (UTC)

External links in the header "next=" fieldEdit

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

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)

PD-anon-1923 againEdit

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)
  •   Support likewise —Nizolan (talk) 01:54, 21 February 2020 (UTC)
  •   Oppose because the name emphasizes US. The point of the templates is to cover both US status and international status. A template that names the US will cause confusion, especially to newcomers. --EncycloPetey (talk) 02:02, 21 February 2020 (UTC)
  •   Support. We are US-centric in our copyright approach. Given the number of times I've had to look up these type of templates here and on Commons, I might buy the idea that we should copy them, but otherwise, I think this is going to be as non-confusing as we get.--Prosfilaes (talk) 04:35, 21 February 2020 (UTC)
  •   Comment In your proposal, how do we code the year of the author's death for anonymous works? --EncycloPetey (talk) 04:38, 21 February 2020 (UTC)
    I am afraid I do not understand the question: anonymous works do not have any known author. I propose that for anonymous works we would have a template with similar wording as {{PD-anon-1923}}, but it would be called {{PD-anon-US}}. --Jan Kameníček (talk) 09:42, 21 February 2020 (UTC)
    That's also problematic, because the US is just one place that we display license information for. The current template displays that information for both the US and for countries with 95 years pma. --EncycloPetey (talk) 19:46, 21 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)

versions of Wikisource with non-US PD statusEdit

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-09Edit

20:59, 24 February 2020 (UTC)