From Wikisource
(Redirected from Wikisource:SCRIPTORIUM)
Jump to navigation Jump to search
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 369 active users here.


50% scan-backed[edit]

At some point in the past few days we have quietly reached 50% of our mainspace pages transcluded from proofread scans. This has been achieved through a combination of adding new works via the ProofreadPage process and finding scans to backup works that we have acquired through other means over the years. Beeswaxcandle (talk) 04:27, 5 January 2019 (UTC)

That's great news! Tweetworthy, I'd say. Is there somebody to nudge about that? (I see no recent tweets on either @wikisource or @wikisource_en.) It would be good to call attention to our scan-backed standards. A short blog post might be nice, too... -Pete (talk) 20:58, 15 January 2019 (UTC)
Terrific news. :) I've made a tweet: (And sorry for the recent silence on the Twitter front; been a busy few months.) Sam Wilson 22:26, 15 January 2019 (UTC)
a better milestone will be a million proofread pages, which will happen in a month or two. Slowking4SvG's revenge 04:56, 18 January 2019 (UTC)

3000 Validated Works[edit]

Late on Thursday 17 January 2019 (UTC) validation of Amazing Stories/Volume 01/Number 02 was completed. This was our 3000th work to reach this status. To see a list of the previous milestone works go to Portal:Proofreading milestones. Beeswaxcandle (talk) 17:59, 18 January 2019 (UTC)

Well done to all the editors involved. Your work is very much appreciated. —Beleg Tâl (talk) 18:51, 18 January 2019 (UTC)


audio works[edit]

I propose that works produced in an audio format be incorporated into our collection as separate versions and that inclusion be emphasised within the defined scope of wikisource. This would include works that are termed audio books, spoken word, talking books, and so on, but not necessarily limited to those products.

As I see it, the solution to making these works available is to link them from their title in mainspace. This allows more bibliographic data to be appended, rather than an icon appearing at the title and subpages of the text version. I will note this is not my solution, lest that damn the notion, this is how libraries provide access through their catalogues and the perspective we should be applying to a highly desired format. Aside from their separation and that more detail be added or transcluded from commons / wikidata, I would also prefer the integrity of these works be indicated; there is currently no process of verification for audio that is already served here. This proposal is intended to clarify and facilitate the contribution of these works, and eventually be applied the existing audio be provided here.

The consequence of this might be that an audio book is available when the text is absent or unprepared. Another effect may be that this provides another way to contribute to wikisource. CYGNIS INSIGNIS 02:55, 14 December 2018 (UTC)

So, if there is an audio version of a work that we also have as a written text, the user will have to go to another page to find it, instead of having the relevant audio linked from the text? --EncycloPetey (talk) 03:04, 14 December 2018 (UTC)
Correct. CYGNIS INSIGNIS 14:17, 14 December 2018 (UTC)
I am inclined to partially support this proposal in a limited way. Audio works are properly the scope of Commons, not enWS, so we should not treat them as "in scope" here. However, if a versions page exists for a work, it would be beneficial to include links to relevant versions on other wikis such as Commons, mulWS, wikibooks, and so forth. — I will also point out that a transcription of an audio file can definitely be considered in scope here, if the contents of the audio file satisfy WS:WWI. —Beleg Tâl (talk) 01:44, 9 January 2019 (UTC)

Bot approval requests[edit]

Repairs (and moves)[edit]

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

Antony and Cleopatra (1921) Yale[edit]

The File:Antony and Cleopatra (1921) Yale.djvu has two duplicated pages. Pages 13 and 14 of the DjVu file need to be removed so that the following pages (and OCR) are shifted to compensate for the removal. --EncycloPetey (talk) 00:11, 1 January 2019 (UTC)

Yes check.svg Done -Einstein95 (talk) 12:39, 5 January 2019 (UTC)

Pictures in Rhymes[edit]

Happy New Year.
Can this work be uploaded without the watermarks? Meaning can it be? And can someone do it? Thank you.
Pictures In Rhyme by Kennedy, Arthur Clark; Greiffenhagen, Maurice, 1862-1931

Publication date 1891
Usage Public Domain Mark 1.0
Topics Poetry
Collection folkscanomy; additional_collections
Language English
--Level C (talk) 16:07, 2 January 2019 (UTC)

Books aren't "uploaded" to Wikisource. Books this old, which are in public domain in their home country, are uploaded to Commons. And no, the watermarks cannot be stripped from the images. However, a Wikisource copy built from this scan would not transcribe the watermarks. --16:50, 2 January 2019 (UTC)
Thanks for the info! --Level C (talk) 23:49, 22 January 2019 (UTC)
ok here you go, i will fix up the index tomorrow. c:File:Pictures In Rhyme.djvu; Index:Pictures In Rhyme.djvu. -- user:slowking4 16:01, 17 January 2019 (UTC)
Thank you for your work. This is awesome. --Level C (talk) 23:49, 22 January 2019 (UTC)

Other discussions[edit]

Adapting Template:pd/1996 or a new template[edit]

As per previous conversation started by Prosfilaes, from next year US-published works published in 1923 will be out of copyright, and progressively year by year others will follow. We need to start working on whether we will adapt Template:pd/1996 to have wording that says that the work is out of copyright, and reconfigure that template to set triggers. Or whether we are going to implement a new template for post 1922 works. (Full coverage at copyright tags.) — billinghurst sDrewth 09:34, 5 August 2018 (UTC)

Don't the 1996-series of template primarily apply to works published outside the US? For works inside the US, we've been using the 1923-series of templates, and I would assume that it's the 1923-series that would need to be adapted to accommodate US-published works from 1923. It would be odd to have "published before 1923" to be a reason a work is in PD, if works published before 1924 is the actual set of works in PD. --EncycloPetey (talk) 15:55, 5 August 2018 (UTC)

You are correct that the pd/1996 has been non-US first publications to this point, and there would be complications in updating the template. Template:pd/1923 is set, and incrementing Template:PD/19xx is possible, though becomes a lot of templates. It is why I brought up the issue as we have to get the wording right, and look to the easiest means to progress through the years. As 1977 is the next US copyright milestone, maybe it is something like pd/1978 with both a year of birth AND year of publishing as parameters, where year of publishing flicks between copyright and not copyright.

billinghurst sDrewth 22:46, 5 August 2018 (UTC)

Let us keep watching for the rest of 2018 to be sure that the US copyright term is not extended. Then I may want to introduce "PD-pub-95" to mean "public domain for being published more than 95 years ago. Renaming Pd/1923 will probably be too disruptive, so making a new template may be better.--Jusjih (talk) 04:48, 9 September 2018 (UTC)
It's not going to happen, and part of the reason it's not going to happen is because we are going to rip the hell out of Congress if they try. Being able to say that are already preparing for this change will only help our case. And when the ball drops in New York, I will be uploading 1923 works, and will need an appropriate tag.
I'd like a single PD tag that takes publication year and author death year (if known), and it shouldn't mention in the name the exact rules, just applying all the rules that can be deduced clearly from publication year and author death year. Maybe just naming it PD-old would be too much?--Prosfilaes (talk) 06:35, 10 September 2018 (UTC)
I support the single-PD template idea. While it would be rather an in-depth template, I don't think it would be particularly difficult to implement (just a series of if-elsif-else conditions). Mukkakukaku (talk) 00:56, 13 September 2018 (UTC)
The US Copyright Office already considered the copyright terms too long. Mid-term election will be soon. Template:Pd/1923 is heavily used, so renaming will be harder than adding new template like "PD-pub-95". I will wait for the ball to drop in Times Square.--Jusjih (talk) 03:00, 18 September 2018 (UTC)
  • Pictogram voting comment.svg Comment Looking back at this and thinking again, I think that we should be building a template based on 1978 cutoff, aligning with 1923 and 1996 cutoff usage. We already have our subset of use templates (<1923; 1923<1996) that have a series of #if statements (well #ifexpr) that get implemented. At this stage we need to have some output templates that work in main ns that cover 1923 to 1977 at least
  • published in US between 1923-1963 with notice and renewal
  • published in US between 1964-1977 with notice
  • published outside of US between 1923-1977 (two scenarios)

where we will be incrementing per year. So we just use a #if expression for currentyear - 95 > publicationyear where it shows the PD template when true, and copyright violation when it fails. It is a few years until we need to worry about PD-old for post 1923, so we can work that bit out later. If someone uses this new license for a pre-1923 work, we can simply apply the {{pd/1923}} logic.

We still need a licence to display and the wording to use for US users, bottom half replicates pd/1996.billinghurst sDrewth 10:03, 25 September 2018 (UTC)

  • Pictogram voting comment.svg Comment what's the status of this discussion? Thousands of works will have their copyright expire in 3 days. Mathmitch7 (talk) 14:05, 28 December 2018 (UTC)
  • @Billinghurst: Have you been working on this issue? --EncycloPetey (talk) 01:29, 1 January 2019 (UTC)
  • Pictogram voting comment.svg Comment Commons has been having a similar discussion at Commons talk:Public Domain Day. The main consensus of which is to create a new template {{PD-US-expired}} to accommodate the new year's worth of expired renewals, as well as in future years (note the absence of a date in the name). --EncycloPetey (talk) 03:02, 1 January 2019 (UTC)
If I'm understanding what they're doing properly it looks like they moved their {{PD-1923}} etc. to {{PD-US-expired}} and modified it, I don't know if there are any problems associated with that, the redirecting previous name is still used all over the place but it doesn't appear to break things. If we want to follow suit I guess we just have to identify the changes we need to make a US expired tag that's applicable for all years of the old publication date based regime, as described above? Prosody (talk) 12:13, 1 January 2019 (UTC)
Took a stab at implementing the logic of a wrapper around the existing US PD templates, dunno if it'll be of any use. User:Prosody/pd-expired/test. Prosody (talk) 15:07, 1 January 2019 (UTC)
commons:Template:PD-old-auto-expired looks like a better one than Pd/1923, but doing away "1923" in all relevant templates in bulk should better have a bot.--Jusjih (talk) 23:09, 6 January 2019 (UTC)
Why would we need to do away with that template? The point of the above discussion is that we don't have to do away with it. And there are some templates where we want to keep the date of 1923. Also, Commons templates have to do double duty: PD in the US and PD in the country of origin for everything they host. On Wikisource, the rules are different, and we are concerned primarily just the former, though we note other licensing. --EncycloPetey (talk) 23:24, 6 January 2019 (UTC)
Keeping naming 1923 because many works published since 1923 would remain copyrighted in the USA due to the Copyright Term Extension Act in 1998 is simpler. It looks okay this year. Using {{#expr:{{CURRENTYEAR}}-95}} would get 1924 this year, but 1925 next year, so how about it in templates named "1923" to avoid massive renaming?--Jusjih (talk) 05:11, 7 January 2019 (UTC)
I don't understand what you are asking. The 1923 still works. The change in US law has different effects on different sources of copyright. For works registered for copyright in the US, the change is to works whose copyrights were renewed but have now expired. The cutoff for all publications that had such renewals was 1923. The proposal above was for a new template to deal with these cases of expired copyright, instead of having to check and replace everything. But for works that were already in the public domain because they were published without a copyright statement, or wre not renewed, the license is still correct, and does not need to be changed. --EncycloPetey (talk) 05:54, 7 January 2019 (UTC)
For the new template, how about Template:PD-US-expired? This does not require changing PD-1923 series.--Jusjih (talk) 02:40, 9 January 2019 (UTC)
We could tag works published before 1924 with PD-US-no notice and other such tags, but there's nothing special about 1923. We have never made a tag to say that a work was published outside the US before 1909 and thus was never in copyright. It is sufficient now to say that it was published more than 95 years ago, and new works should only be tagged as such, for simplicity and clarity.--Prosfilaes (talk) 06:24, 11 January 2019 (UTC)

Disambiguating Shakespeare[edit]

Anyone who has looked through our current coverage of Shakespeare's plays will have noticed that it's an execrable mess right now. Most of our copies are not backed by scans, and our Versions pages have lengthy titles, if they exist at all. Multiple transcription projects exist for some plays, but usually in various stages of neglect.

The 400th anniversary of the publication of the First Folio is 2023, and this date may bring interested individuals to Wikisource. It seems only right to at least organize what we have, and set things up to make it easier to find transcription projects and various editions of plays.

Toward that end I did some poking around last night to see where things stand. The first big hurdle is that our Disambiguation and Versions pages associated with titles like "Hamlet" and "Macbeth" are in bad shape and have not been edited in a long time. I am willing to put in the work to clean up these pages, but want to establish a standard for the naming of these pages. Because some of them have been around for a long time, and because of the high-profile nature of Shakespeare's plays, I am putting forward a proposal backed by a few case studies before proceeding.

Case studies for three of Shakespeare's tragedies
Title of Play (LoC) current versions page sample titles

Hamlet Hamlet (Shakespeare) The Tragedie of Hamlet, Prince of Denmarke

The Tragedy of Hamlet, Prince of Denmark
Hamlet, Prince of Denmark: A Tragedy
The Tragedy of Hamlet
Hamlet, Prince of Denmark

King Lear none The Tragedie of King Lear

The Tragedy of King Lear
The Chronicle History of the Life and Death of King Lear and His Three Daughters

Romeo and Juliet The Tragedy of Romeo and Juliet The Tragedie of Romeo and Ivliet

The Tragedy of Romeo and Juliet
The Most Excellent and Lamentable Tragedie of Romeo and Iuliet
Romeo and Juliet

As can be seen from the case studies, there is no uniformity of titles for these three plays. Not only is there significant variation in spelling and overall title length, but even structure and form of the titles vary. Therefore, it seems to me that selecting one particular spelling, or one specific title, to represent all forms of any given play would be neither helpful nor intuitive.

Furthermore, doing so would also eliminate the possibility of hosting an edition with that title at that location, and would preclude the possibility of a disambiguation or versions page for that title. That is, if there were more than one work titled "The Tragedy of Romeo and Juliet", possibly a work about the play in addition to editions of the play itself, we would have no means of disambiguating these titles if the Versions page for the play was located at that title.

I therefore propose that all of Shakespeare's plays be given versions pages of the form:

(1) Macbeth (Shakespeare), for most plays, where the simple title adheres to the common base name used for his plays in the Library of Congress database, instead of a longer title such as The Tragedy of Macbeth.
(2) Henry IV, Part 3 (Shakespeare) for the historical plays. For these latter plays, the Library of Congress includes "King" in the title and separates the "Part" with a period instead of a comma. The result of having this full stop within the play's name causes some odd rendering on VIAF. Wikidata avoids the problem by using a comma, which is standard for most bibliographic references I have seen, including the Pelican Shakespeare. The Cambridge Shakespeare uses neither a period nor a comma, and the Riverside Shakespeare uses the confusing form 3 Henry VI to abbreviate the same title. The Yale Shakespeare spells the title out in full as The Third Part of King Henry the Sixth.

This proposal has the additional advantage of not forcing a move of any existing copies of plays to make way for a Versions page.

I set up Hamlet (Shakespeare) yesterday as an example of how I imagine the Versions pages ought to look.

Support and comments are welcome. But if there are no serious objections, and a general positive view of my proposal, I will begin work this coming weekend to clean up the Versions and Disambiguation pages associated with titles of Shakespeare's plays. --EncycloPetey (talk) 02:54, 27 November 2018 (UTC)

Symbol support vote.svg Support, this is entirely reasonable and would be a great improvement. —Beleg Tâl (talk) 04:22, 27 November 2018 (UTC)
A question: are you proposing to standardise all of them with the (Shakespeare) disambiguator, or only those that share a title with other works on this site? —Beleg Tâl (talk) 04:24, 27 November 2018 (UTC)
We already have Reference works with entries for Shakespeare's plays (vide Characters of Shakespear's Plays as an example), and almost every play has at least one commentary, retelling, or derived work with the same or nearly the same title. It seems preferable to go ahead with (Shakespeare) now, rather than having to move those pages again later. Shakespeare's plays are of sufficient stature that I think we ought to select stable locations for the Versions pages. --EncycloPetey (talk) 04:32, 27 November 2018 (UTC)
Symbol support vote.svg Support, after seeing the example disambig set up, it saves everything from getting more and more cluttered and lost. -05:23, 27 November 2018 (UTC)
Symbol support vote.svg Support and take it on over to wikidata as well. (which i see you have dome) Slowking4SvG's revenge 17:16, 29 November 2018 (UTC)
Symbol support vote.svg Support. I've been holding off chiming in here for various reasons, despite otherwise having an opinion on almost anything related to Shakespeare, but having had a little bit of time to think about it I've landed on a tentative position. I definitely support a cleanup of this, and that's irrespective of the details of the approach. Any consistent approach is better than the existing mess. I'm less sure about the details of the new approach, both because I've not thought very deeply about it; because I am not sufficiently experienced with the needs and factors applying on Wikisource; and because I have a lot of enwp baggage that could easily lead me astray here. However, with those caveats, and having had the chance to try it out slightly, I tentatively also support the specific approach sketched above. I would only add that where (if) the LoC title differs from enwp's naming, it's a good idea to at least consider enwp's article title (they've been subject to lots of wide discussion; but with the downside that the discussions relate to enwp's needs and naming conventions). I would also suggest that the history plays have redirects at the title variants: Henry IV, Part 3 (Shakespeare), Henry IV. Part 3 (Shakespeare), Henry IV., Part 3 (Shakespeare), and 3 Henry IV (Shakespeare). All are common variant spellings for these (you'll even find "3HIV" in the literature). The full-stop isn't there really a separator, but a ordinal suffix for the regnal number: "Henry V." is essentially "Henry 5th". You'll find the full-stop used thus in running text: "Henry V. was king of England". --Xover (talk) 07:52, 19 December 2018 (UTC)
Agreed. Where there are title variants, I have been creating redirects except that Wikisource has a problem that Wikipedia does not have: the possibility of editions claiming one or more of those variant titles for a specific edition. Where this happens, I am using {{other versions}} to create a link back to the Versions page. And yes, I am familiar with the use of a full stop for regnal ordination; I've worked in several of our encyclopedic works which use that notation. But using Wikipedia article names would not be feasible. Wikipedia has very different criteria and processes for naming. For example, they have Hamlet at w:Hamlet, which would not work for Wikisource, as we need a disambiguation page for all works titled Hamlet, and they put Julius Caesar at w:Julius Caesar (play) on the assumption that there is only one play by that name. It is not that Wikipedia names have been dismissed out of hand, but they are working to a very different set of rules and expectations that simply do not translate to the needs of Wikisource. --EncycloPetey (talk) 16:09, 1 January 2019 (UTC)

Wikisource Community User Group representative vote[edit]

Dear all,

Sorry for writing in English and cross-posting this message.

Following the previous message, the vote for the representative of the Wikisource Community User Group to the Wikimedia Summit 2019 is now open.

There is two great candidates on page on meta to decide who will be the representative of the user group to the Wikimedia Summit. You can support a candidate now. All active Wikisource users can vote. The vote is ending on December 14, 2018.

Feel free to ask any question on the wikisource-I mailing list or on the talk page.

Thank you!

For the Wikisource Community User Group, Tpt (talk) December 8, 2018 at 18:53 (UTC)

Editing window woes (again)[edit]

Today, I find that I can no longer adjust the size of the header or footer window when side-by-side editing. Before today, I was able to drag the corner of either window to enlarge or shrink it. But today they now appear at a fixed size, and one that is much larger than they used to do.

I assume this is a side-effect of the latest update. --EncycloPetey (talk) 04:41, 13 December 2018 (UTC)

Appears to be due to phab:T209939Beleg Tâl (talk) 14:17, 13 December 2018 (UTC)
I've made a patch to fix this, by making the header/body/footer ratio 1:8:1. However, as Tpt pointed out, the earlier fix for the layout has meant that the resize handles (lower right corner of the textarea, for dragging to change the height) no longer work. My patch actually turns these off (instead of showing ineffective controls) but how should resizing work for these? It seems to me that if one makes the header bigger, then the body should get smaller: i.e. that the three textareas should always take up the same amount of space, but their relative heights can be adjusted easily. Comments welcome on phab:T209939. Sam Wilson 15:59, 15 December 2018 (UTC)

Esme Shepherd (talk) 15:04, 3 January 2019 (UTC) Is this the reason my header/body/footer ration is now 0:10:0 and has been ever since that time? I hope you can fix this soon as obviously headers and footers CANNOT be edited and, as you say, resizing is not available.

interwiki link wikilivres[edit]

Please redirect the interwiki link wikilivres to the new address S8w4 (talk) 08:19, 15 December 2018 (UTC)

@Billinghurst: could you do the honours? —Beleg Tâl (talk) 14:42, 18 December 2018 (UTC)

Is this related to the fact that the links on, for example, The Coming of Wireless are currently redirecting to a commercial site? This needs an urgent fix. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:31, 26 December 2018 (UTC)

It is, and I agree this is an "Unbreak now!" issue. Pinging all admins who've been active after the 24th: @Kathleen.wright5, @Ineuw, @Beeswaxcandle, @EncycloPetey, @BD2412:. Anyone with the right permissions (I'm assuming +sysop will do) should be able to edit the interwiki table at Special:Interwiki (normal users can only see the table). If the local table is missing the wikilivres: prefix then a new local entry for it should override the global setting, and a fix for the global prefix needs to be implemented on meta. --Xover (talk) 14:54, 26 December 2018 (UTC)
I don't see any option to edit the page on the page. BD2412 T 15:11, 26 December 2018 (UTC)
Crud. Then it probably requires the special bit +interwiki, or we need to get a steward to do it. On the other hand, the Wikilivres config appears to exist on Meta too per m:Special:Interwiki, and thus affects all wikis without a local override, so it may be that taking the issue there is the right approach in any case. Anyone familiar with the request venues at Meta and up to bringing it there? I can probably figure it out but it's exceedingly rare that I visit Meta so I'd have to do some digging first. --Xover (talk) 15:26, 26 December 2018 (UTC)
I have asked at MediaWiki. BD2412 T 15:40, 26 December 2018 (UTC)
I popped into the stewards' IRC channel to ask about this and it looks like the global interwiki map has already been fixed: m:Special:Diff/18733804. The problem is that the change won't propogate to other wikis until someone runs an actual deploy (ala new versions of the MediaWiki software), those with the right access are all off having a life and stuff, and the next scheduled deployment isn't until 7 january. The person I talked to (MarcoAurelio (talkcontribs)) is trying to raise someone with the right access, but odds are probably pretty poor until tomorrow at the earliest (and not unlikely to be a week from now, given the holidays). Incidentally, I learned that the interwiki map is currently global-only (no wiki has a local map), and the global map for all WMF wikis is at m:Special:Interwiki. Local admins on enWS won't have the permissions to edit it; you'd need to be an admin on meta (which only Billinghurst is among those mentioned in this thread). --Xover (talk) 20:32, 26 December 2018 (UTC)
Special:Interwiki is just the "pretty" face of m:Interwiki map. But it does not suffice to edit the Meta page as I explained to Xover (talkcontribs) on IRC and to BD2412 (talkcontribs) at mediawiki. I sent a message to the Wikimedia operations IRC channel but so far no reply yet. I'll send some emails and see if we can have the map updated soon, given the huge number of links that now point to the taken-over site. Best regards and Merry Christmas for those celebrating (otherwise Happy Hollydays). MarcoAurelio (talk) 20:37, 26 December 2018 (UTC)

I've made some temporary fixes at Template:Wikilivres page, hard-coding the links, to bypass the interwiki form. Those changes should be reverted, once the Interwiki map is working again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 26 December 2018 (UTC)

Hello. Good news. The change is now live (cfr. phab:T212650) and bibliowiki: should be working as expected now. Best regards, --MarcoAurelio (talk) 15:55, 27 December 2018 (UTC)
Awesome news indeed, MarcoAurelio. And someone needs to buy Bawolff a $BEVERAGE on behalf of the Wikisources. Above and beyond, both of you!
I see EncycloPetey has already reverted Andy's temporary workaround, so everything should be back to normal now. Big thanks to everyone involved! --Xover (talk) 20:20, 27 December 2018 (UTC)

Sub-disambig pages by author[edit]

It is a common practice to have works by the same title and by the same author on a separate disambig page from other works by that same title. You can see many such examples at Song, such as Song (Anne Brontë), Song (Burns), Song (Coates) and so forth. I don't think that this really makes sense, since all of those works on those sub-pages are called simply "Song" and should really be listed at Song directly.

Does anyone have substantial objections to me merging such sub-pages when I see them in the wild? @Londonjackbooks: you seem to have created some of these sub-disambig pages, so I'd value your opinion here. —Beleg Tâl (talk) 15:35, 18 December 2018 (UTC)

Yes, I object. Some of those are versions pages, not disambiguation. However, if they are indeed different works that merely share the same title and author, then I agree. --EncycloPetey (talk) 16:59, 18 December 2018 (UTC)
I am not talking about versions pages, those are completely different and have nothing to do with this. I am talking about separate disambig pages that are created to disambiguate between different works with the same title, but which for some reason have been split off into separate pages by author. —Beleg Tâl (talk) 17:27, 18 December 2018 (UTC)
I am also not talking about editions pages like Song (Aldington) or redirects like Song (Le Gallienne), for the record. —Beleg Tâl (talk) 17:29, 18 December 2018 (UTC)
@Beleg Tâl: your work with the music here has appeared in my watchlist, and is fairly wonderful. I must confess, however, that I find the list of works at Song to be confusing, even with the first lines. Also, I learned here that I am using the word disambiguate wrongly in my summaries. So, a thanks, an apology for being easily confused and another for being confusing.--RaboKarbakian (talk) 18:28, 18 December 2018 (UTC)

Apologies @Beleg Tâl:. I have been away and have just returned. I will read the above in more detail soon, try to think critically (ouch), and respond, unless your question has already been successfully answered. Thanks, Londonjackbooks (talk) 15:25, 20 December 2018 (UTC)

@Beleg Tâl:. Can you possibly point me to a couple Coates "sub-disambig" pages you would like to see "merged"? Is Song (Coates) one of them? I guess I'm not understanding why it would not be desirable to have such a disambig page, but I am not an expert in the science of organization. Are you saying you would like to see "Song (Coates)" deleted and the contents transferred directly to the "Song" disambig page? Londonjackbooks (talk) 21:40, 21 December 2018 (UTC)

@Londonjackbooks: yes, Song (Coates) is one example, as are the others listed in my original comment. Here are some of my reasons:
  • Main reason: all of the works listed at Song (Coates) are works entitled "Song". All works entitled "Song" should be listed at Song, because Song is supposed to be a list of all works entitled "Song". Therefore, all works listed at Song (Coates) should also be listed at Song. Once all these works are listed at Song, then Song (Coates) will contain only information already available at Song. Therefore Song (Coates) is redundant, and is therefore a candidate for speedy deletion.
  • Additional reason: A page that disambiguates works called "Song" but only if they are by Coates, is not in keeping with the Manual of Style or current practice.
  • Additional reason: Song (Coates) is, by force of our standards for disambiguation, a list of works called "Song (Coates)". None of the works at Song (Coates) are actually called "Song (Coates)", as all of them are called only "Song". We have no works on Wikisource entitled "Song (Coates)". Therefore there is no need for a list of works entitled "Song (Coates)".
I therefore propose that yes, all the contents of Song (Coates) (and Song (Anne Brontë) and Song (Burns) and all the other such pages) be transferred directly into Song, and that the same occur with sub-disambig pages for other titles whenever I encounter them. However, rather than delete Song (Coates) I would redirect it to Song, because it is likely that users will link or search for Song (Coates) to find a song called "Song" and written by Coates. If we are feeling generous, we can use an anchor or section header to redirect Song (Coates) to the specific location at Song that lists works by Coates with this title.
I also want to point out that the only contrary argument I can think of, is that Song is a massive list and merging will make it even more massive. My response to this is: firstly, it doesn't matter that Song is massive so long as it is functional; secondly, we have better, more standard methods for dealing with massive lists (such as {{TOC}} and alphabetical sections, for example; or in simpler situations a simple nested list) which are more in keeping with existing practices and expectations of readers; thirdly, we have lots of massive lists on Wikisource that are perfectly acceptable both from a user experience perspective and from a policy and consensus perspective; I am sure I could come up with more if I had time.
All of which is to say: Song (Coates) is an anomaly in our practices; consolidating all this on Song and redirecting Song (Coates) to Song is how it should be done in order to match with our practices and expectations. —Beleg Tâl (talk) 22:33, 21 December 2018 (UTC)
Makes sense to me, including the suggestion to make the long list more accessible by dividing it into alphabetical sections. --Jan Kameníček (talk) 23:35, 21 December 2018 (UTC)
Thank you for spelling things out. I understand some of your reasoning, and am trying to think through the logic in baby steps. So, if someone is viewing one of Coates' poems entitled "Song" at WS, they would currently see (via the use of the {{similar}} tag) that there are other works available here by the same title—not only by different authors, but also by the same author. That would not be the case were we to be rid of Song (Coates), and I am trying to get over my obtuseness and stubbornness to understand why having such a disambiguation would not be useful in the interest of research. Why is such a redundancy (in certain cases) necessarily a bad thing? And I can't find at the dab help pages exactly where it specifically goes against guidelines. More questions are in my head, but I'll leave it at this for now. Londonjackbooks (talk) 06:11, 22 December 2018 (UTC)
@Londonjackbooks: For an example of what I am proposing, see Song: "Lordly gallants!" by George Wither. You will notice that the hatnote says "For works with similar titles, see Song." Users that click on the link will see a list of works called "Song", some of which might be by Wither, and some of which might not be by Wither; which is exactly what users expect when they click on that link. More generally, I do not deny that pages like Song (Coates) are useful in the interests of research; I only deny that Wikisource is the place for them. We should not maintain lists of works called "Song" by Coates for the same reason that we should not maintain lists of works called "Song" published in the USA, lists of works called "Song" written in 1896, or for that matter, works called "Song" written by Coates in 1896 and published in the USA. Structured queries like this are better handled by Wikidata, which is designed explicitly for this purpose. On Wikisource, users already have two ways to find works by Coates called "Song": 1) search for "Song" at Author:Florence Earle Coates; or 2) search for "Coates" at Song. —Beleg Tâl (talk) 14:33, 29 December 2018 (UTC)
@Beleg Tâl: "We should not maintain lists of ... for the same reason that..." Thank you. I can wrap my head around that reasoning :) I only ask that I be permitted, if your proposal is agreed upon, to do the cleanup for Coates' works myself. Obviously, this request can't necessarily be regulated, but I'm at least putting it out there. Thanks :) Londonjackbooks (talk) 05:09, 30 December 2018 (UTC)
@Londonjackbooks: That works for me. Song would be the first one for me to tackle but I'll hold off until you take care of the ones by Coates. —Beleg Tâl (talk) 18:58, 2 January 2019 (UTC)
Will do. Thanks. I've not been very active here recently, but will make an effort. It may be after January's end. Should I wait until a general consensus is reached on the proposal? Londonjackbooks (talk) 20:26, 2 January 2019 (UTC)
I think we have sufficient consensus to proceed. I'll begin work on Song but I'll leave the Coates part for you. —Beleg Tâl (talk) 16:25, 11 January 2019 (UTC)
@Esme Shepherd: you've made a few of these for Landon, do you have any thoughts on this proposal? —Beleg Tâl (talk) 18:56, 2 January 2019 (UTC)
Esme Shepherd (talk) 20:56, 2 January 2019 (UTC) I did make such a page for 'Change' because I knew Landon had written six poems with that title. These were moved into the main disambiguation page, which didn't bother me although the result is a little confusing because Change (L. E. L.) still also exists as does Change (And this is what is left of youth!), which is for versions of the same poem.
I do have reservations with regard to "Song" because Song (L. E. L.) contains 92 poem entries and I cannot see any advantage in amalgamating these into one disambiguation page with all the other 'Songs'. Surely these pages are to make finding works easier for the user, not more difficult. On the other hand, maybe listing them both ways would be even better - catalogued by the first line, as well as by the poet.
@Esme Shepherd: I am not worried about versions pages at the moment, although I agree that Change (L. E. L.) is a confusing name for a versions page. I understand that merging Song (Letitia Elizabeth Landon) into Song will be very long, but I also intend to make the page easier to navigate as well, so I think it will work out in the end. —Beleg Tâl (talk) 21:15, 2 January 2019 (UTC)
Esme Shepherd (talk) 22:08, 2 January 2019 (UTC) Okay, ease of navigation is the main issue. I would like retention of first lines, as they are the principal identifier. The problem as far as I can see is that someone looking at a Landon song wishing to see other poems with a similar title will be redirected into Songs in general rather than specifically Landon songs. How are they to reach that specific subset if it is lost in a very long list?

Wikidata vs Versions pages, part 2[edit]

I'm fighting a losing battle at Wikidata to get the admins there to respect Wikisource conventions... again... d:Wikidata talk:WikiProject Disambiguation pages/guidelines#Moved from the page section "Editions pages"Beleg Tâl (talk) 19:09, 18 December 2018 (UTC)

this is one problematic admin displaying some German drama. might have to provide him with an edition / work ontology solution wrapped in a bow. Slowking4SvG's revenge 17:52, 17 January 2019 (UTC)

Issue with the FI Template display.[edit]

I am not sure if this a new problem or a local issue with my system, but thought I'd better raise it.

I've been using template FI to add images in "A general history for colleges and high schools" for a while now and everything has been displaying as expected, however tonight, the images I have floated left or right have all appear centered when I save the page.

Looking at the image as transcluded in the chapters they still display as expected i.e. to the left or right side of the page.

i.e. a recently added image is Page:A general history for colleges and high schools (Myers, 1890).djvu/219

Could someone confirm if this a site issue?

Thanks Sp1nd01 (talk) 22:26, 19 December 2018 (UTC)

yes, it looks like another side effect of this change. Zdzislaw (talk) 20:03, 20 December 2018 (UTC)
FWIW {{img float}} is still working. --EncycloPetey (talk) 22:06, 20 December 2018 (UTC)
Only inside a single paragraph, not across paragraphs. See eg. here. Ankry (talk) 00:43, 21 December 2018 (UTC)
@Ankry: Thanks for the phabricator link. They should probably be made aware as well (explicitly) of the issues with image placement and unwanted paragraph separation. We have also noted (above) that padding on the left and right margins in the Page namespace has gone to zero, which is not desirable. Until now the focus has been on the window resizing, and not the other issues that are now surfacing. --EncycloPetey (talk) 00:53, 21 December 2018 (UTC)

It seems that {{rule}} is also no longer displaying from the header in the Page namespace. E.g.: Page:Richard II (1921) Yale.djvu/120 --EncycloPetey (talk) 23:38, 21 December 2018 (UTC)

This last, at least is readily fixable. Simply replace
width: {{{width|{{{1|auto}}}}}};
in {{rule}} with flex-compatible
width: {{{width|{{{1|100%}}}}}};
I would do it myself except for it being protected114.74.46.230 05:22, 22 December 2018 (UTC)
  • there is no need to make any changes. {{rule}} (and many other) will be visible again after reverting the changes - see: phab:T209939#4840870. Zdzislaw (talk) 23:34, 22 December 2018 (UTC)
@Zdzislaw: Agreed. In fact I have some sympathy for the frustration of TheDJ over this change… but the fact he has not edited here for over four years implies the :flex proposal was based more on a theoretic basis than actually thought out and tested?
And while on the topic of untested alterations, have you (O.K. not you—no insult intended—more precisely somebody with editsitecss rights would be needed!) considered putting in place something like{display:block;}
into (maybe)MediaWiki:Common.css as a stop-gap until such time as the Phabricator patch is backed-out or sensibly resolved? 04:38, 23 December 2018 (UTC)

{{block right}} is also behaving oddly now. E.g. On this Page it displays to the left of the screen, but in Preview mode, the same code displays to the right (where it should). --EncycloPetey (talk) 19:18, 25 December 2018 (UTC)

That is really strange: I have copied the code out of the page namespace to my Sandbox, where it is displayed correctly... --Jan Kameníček (talk) 18:54, 26 December 2018 (UTC)
Indeed. When the same content is placed in a different namespace, or transcluded to another namespace, it's fine. All of the issues appear to stem from use in the Page namespace when items are displayed side-by-side. --EncycloPetey (talk) 18:58, 26 December 2018 (UTC)

Related spacing issue?[edit]

If the extra blank line near the bottom of Page:Choëphoroe (Murray 1923).djvu/22 in the Page namespace a related issue? There should not be an extra blank line above the last line of the ending stanza, and there isn't one coded in the text, but the software inserts one anyway. --EncycloPetey (talk) 22:55, 1 January 2019 (UTC)

Most probably not related. It gets worse though: note just above Choëphoroe_(Murray_1923)/Text#19 the necessary blank line between stanzas is missing. Two thoughts: should <poem> have been utilised; and/or should each stanza have been forced into its own, individual, paragraph <p>/</p>? 00:30, 2 January 2019 (UTC)
The <poem> tag is notoriously unreliable and fussy, especially across page breaks. I stopped using it ages ago. --EncycloPetey (talk) 00:37, 2 January 2019 (UTC)
I've frequently seen the parser put the last line of a page in a separate paragraph, long before the above issues started. It doesn't happen when it gets transcluded so I've just ignored it. —Beleg Tâl (talk) 00:35, 2 January 2019 (UTC)
When I first began I was encouraged to always check preview before saving. Recently however I note that every time one previews, a blank line is added to the bottom of the page (yes, three previews equals three blank lines!). As I know about this, I always make sure to delete before saving. There may be some who have not noticed this. Esme Shepherd (talk) 10:49, 5 January 2019 (UTC)

Greek and polytonic templates[edit]

The templates {{Greek}} and {{Polytonic}} force the text to start a new paragraph when used in the Page namespace, see e. g. Page:The Labyrinth of the World and the Paradise of the Heart.pdf/18, but this issue does not occur in other namespaces. --Jan Kameníček (talk) 12:09, 4 January 2019 (UTC)

Not the same issue. Looks like the TemplateStyles plugin is causing the parser to split the paragraph in two. —Beleg Tâl (talk) 13:15, 4 January 2019 (UTC)
I found this problem affected not only in this wiki but also in Wikipedia. In w:Zhang-Zhung language I saw this problem also occur in main namespace. So I think TemplateStyles plugin has a regression. --Great Brightstar (talk) 16:10, 9 January 2019 (UTC)


Is this problem related? The template {{Chart2}} is no longer working reliably either. In some cases, the text and the connecting lines appear in different parts of the screen, in two separate diagrams instead of a single one. The effect does not seem to be limited to the Page namespace. --EncycloPetey (talk) 21:35, 5 January 2019 (UTC)

Or can someone see what's wrong in this chart?


--EncycloPetey (talk) 21:47, 5 January 2019 (UTC)

Wow that template is massively complex. What I've determined so far:
  • In between the two "separate" diagrams are hidden empty elements
  • The hidden empty elements are tagged as class=mw-empty-elt
  • The class mw-empty-elt is added by the parser to all empty elements in order to resolve some issues from when Tidy was retired [1]
  • The class mw-empty-elt is set to display:none, see phab:T129375, phab:T150742, phab:T172896, phab:T49673
  • When you disable the display:none rule, the chart displays properly.
Beleg Tâl (talk) 23:35, 5 January 2019 (UTC)
With that information, despite having no idea what's going on, I seem to have fixed it. —Beleg Tâl (talk) 23:48, 5 January 2019 (UTC)
Thanks. The really frustrating part was that the example on the Template consistently worked, but every other instance I located or tried myself wouldn't work. Glad it has been corrected. --EncycloPetey (talk) 00:22, 6 January 2019 (UTC)

Possible fix coming[edit]

Pinging some of the folks bitten by or who might otherwise be interested in this problem: Sp1nd01, Zdzislaw, EncycloPetey, Ankry, Jan Kameníček, Beleg Tâl, Esme Shepherd, Narky Blert.

According to the latest Tech News from WMF (in the section #Tech News: 2019-02 below), they will deploy the 1.33/wmf.12 version of MediaWiki "on test wikis and from January 8. It will be on non-Wikipedia wikis and some Wikipedias from January 9. It will be on all wikis from January 10." As I understand it, that means we'll get this version on either January 9 (most likely) or January 10 (at the latest). The release notes for this version is at mw:MediaWiki 1.33/wmf.12, and for the ProofreadPage extension (the module that provides the Wikisource-specific functionality, including headers and footers and other special features in the Page: namespace) it lists "Avoids to use display: flex for now". This is the reversal of the change (deployed around December 15 last year) discussed in task T209939, which is the one that appears to have caused the majority of the issues discussed in this thread (and several other threads here and at /Help).

So, short version: it looks likely that these problems will go away today or tomorrow.

Which also means that any issues that still remain this coming weekend were not caused by this change and will have to be looked into and if necessary reported separately. Specifically, the whitespace / paragraph splitting issue discussed in #Greek and polytonic templates and #templatestyles inserting paragraph breaks does not appear to be fixed in the version under deployment now. --Xover (talk) 06:41, 9 January 2019 (UTC)

Based on phab:T208901, the devs are still debating how to address the paragraph-splitting issues with templatestyles. —Beleg Tâl (talk) 13:28, 9 January 2019 (UTC)
The 1.33/wmf.12 version of MediaWiki is now live here, and based on a quick check it fixes the missing horizontal rule issue, returns the header and footer fields to a reasonable size, and makes them resizable again. It would be a good idea for anyone who have experienced problems suspected to be related to this issue to test whether their problem is now resolved. Re-pinging previous list: Sp1nd01, Zdzislaw, EncycloPetey, Ankry, Jan Kameníček, Beleg Tâl, Esme Shepherd, Narky Blert. --Xover (talk) 20:54, 9 January 2019 (UTC)
I can now see and (I trust) edit the header and footer boxes in English WS in both PaleMoon and WaterFox, which I could not before. They are still absent from multilingual WS; but that's a lesser problem, and it's always possible that the fix will percolate through slowly. Narky Blert (talk) 21:28, 9 January 2019 (UTC)
Grrr. Problem solved. Preferences/Editing "Show header and footer fields when editing in the Page namespace" is disabled by default in multilingual WS. I've enabled it, and can now see and edit the header and footer boxes. Narky Blert (talk) 08:01, 11 January 2019 (UTC)
To confirm that I see the images are now floating left and right as expected, thanks. One other issue that I spotted on a random page proofread was that the blackletter font wasn't displaying, I thought it may have been related to this issue, but on just rechecking the page blackletter is still not displaying. i.e. Page:Vaccination a delusion.djvu/7 Sp1nd01 (talk) 22:03, 9 January 2019 (UTC)
@Sp1nd01: I can see the blackletter font from the computer I am currently using, so it may be a browser, OS, or personal skin issue, or something similar. Try a different browser or computer, I you can, and see if the problem persists. --EncycloPetey (talk) 22:56, 9 January 2019 (UTC)
Thanks for the suggestion, I should have thought of trying that before! I confirm that if I use the Edge browser it does show the blackletter fonts fine, but my default Firefox browser still does not. I'm 100% certain that it used to display fine, maybe its caused by a recent update either to the browser or OS. Sorry for the false alarm. Sp1nd01 (talk) 23:20, 9 January 2019 (UTC)
The blackletter font renders for me in both PM and WF. Oddly, in both browsers the blackletter line, unlike the other formatting, initially appeared in a plain font and only turned into blackletter at the very end of page loading. That suggests a coding issue of some sort. Narky Blert (talk) 04:53, 10 January 2019 (UTC)
Thank you. Now I can edit headers and footers again at my own desk - that's great! Esme Shepherd (talk) 22:33, 9 January 2019 (UTC)

Celebrating Public Domain Day[edit]

For the first time since Wikisource has existed, new works will enter the American public domain en masse on 2019-01-01. How are we going to celebrate? I have a queue of works to upload late on the 31st. —Justin (koavf)TCM 06:29, 20 December 2018 (UTC)

So far we have Wikisource:Requested texts/1923. I've got some stuff I need to scan; it'd be good to coordinate on uploading.--Prosfilaes (talk) 07:21, 20 December 2018 (UTC)
i may have to go to library to scan w:Tulips and Chimneys, and w:New Hampshire (poetry collection). Slowking4SvG's revenge 14:07, 20 December 2018 (UTC)
I have my eye on several dramatic works available at the Internet Archive, to upload to Commons on 1 January, and begin working on at least one of them. --EncycloPetey (talk) 01:00, 21 December 2018 (UTC)
Earlier this evening I was picking through old copyright discussions to find a few previously deleted works from 1923:
Of course it might be preferable to just start fresh from ProofreadPage'd facsimiles where available. Prosody (talk) 10:42, 1 January 2019 (UTC)

Invitation from Wiki Loves Love 2019[edit]

Please help translate to your language

WLL Subtitled Logo (transparent).svg

Love is an important subject for humanity and it is expressed in different cultures and regions in different ways across the world through different gestures, ceremonies, festivals and to document expression of this rich and beautiful emotion, we need your help so we can share and spread the depth of cultures that each region has, the best of how people of that region, celebrate love.

Wiki Loves Love (WLL) is an international photography competition of Wikimedia Commons with the subject love testimonials happening in the month of February.

The primary goal of the competition is to document love testimonials through human cultural diversity such as monuments, ceremonies, snapshot of tender gesture, and miscellaneous objects used as symbol of love; to illustrate articles in the worldwide free encyclopedia Wikipedia, and other Wikimedia Foundation (WMF) projects.

The theme of 2019 iteration is Celebrations, Festivals, Ceremonies and rituals of love.

Sign up your affiliate or individually at Participants page.

To know more about the contest, check out our Commons Page and FAQs

There are several prizes to grab. Hope to see you spreading love this February with Wiki Loves Love!

Kind regards,

Wiki Loves Love Team

Imagine... the sum of all love!

--MediaWiki message delivery (talk) 10:12, 27 December 2018 (UTC)

A suggestion related to main page[edit]

I have a small suggestion related to the sidebar of the main page (ie. this one). My suggestion is to collapse the list of 'In other languages' so that it doesn't go long down the page. For reference, you can see this.Adithyak1997 (talk) 07:19, 29 December 2018 (UTC)

Category:Index - File to check[edit]

It would be nice to "empty" the category before the end of January 2019.

Some of the works might be copyright encumbered for non US contributors, which is why I am asking here. ShakespeareFan00 (talk) 18:09, 29 December 2018 (UTC)

Language tagging[edit]

The documentation of the template {{Lang}} states that Texts on Wikisource should be tagged to specify the language in a machine readable format. All pages on English Wikisource are are automatically tagged as "English". Any piece of text that is not in English should be tagged as such with this template or one of its derivatives.

For this reason I started tagging non-English texts, but Mpaa noticed me that it is not good to use it to wrap text containing templates using <div> tags, such as {{center}} (see the discussion at my talk page). This can be a problem at pages like Page:Bedřich Smetana, The bartered bride, Die verkaufte braut.pdf/8. One possible solution might be not to use the lang template for the whole page but repeat it many times for every separate piece of the text in the page, which is not very user-friendly. Does anybody have any other idea how to solve it? --Jan Kameníček (talk) 16:11, 30 December 2018 (UTC)

This template was intended primarily for blocks of texts that do not use Roman script. So it is not necessary to tag Latin, German, or Czech. But it can be useful to tag Hebrew, Greek, Hindi, or other languages that might require a font for display that the user is not expecting. However, some of these languages, such as Greek, have dedicated templates. Thus {{Lang}} is really for languages in non-Latin scripts that do not have their own language-specific template. --EncycloPetey (talk) 17:01, 30 December 2018 (UTC)
I believe we should not care only about the visual side of the problem. Some people (not only blind ones) may read the text using various speech applications, for which it is important to know the language to be able to pronounce the text correctly.
I also went through the documentation in detail and it seems to me that the template is not intended only for non-Latin scripts, but for foreign languages generally: 1) It states that also Greek transcribed in Latin script should be tagged as Greek 2) It informs that all pages in English Wikisource are tagged as English language (not as Latin script), and it does not seem correct to have a page written in German tagged as being in English.
Although I need it for German and Czech parts of texts, somebody else may face the same problem with the whole pages written in non-Latin scripts as well (example here). --Jan Kameníček (talk) 18:17, 30 December 2018 (UTC)
Note that the documentation you refer to was created in 2012 by a single user. Before applying his ideas generally, I would recommend a community discussion. The response I gave previously may not appear in Adam's documentation, but it was the result of community discussion about the application of this template. --EncycloPetey (talk) 18:22, 30 December 2018 (UTC)
Maybe it would be good to know first if it is possible to rewrite the template so that it did not cause the above mentioned problems. If it is possible, than we can discuss whether it should be used in that way or not. I personally believe that it can be useful, especially for various speech applications. --Jan Kameníček (talk) 19:20, 30 December 2018 (UTC)

"This template was intended primarily for blocks of texts that do not use Roman script. So it is not necessary to tag Latin, German, or Czech. "

The former may or may not be true; the latter certainly is not. All text that is not in English should be marked up as such. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 1 January 2019 (UTC)

What effects would it have if the <span></span> tags were changed for <div></div> tags? --Jan Kameníček (talk) 18:41, 1 January 2019 (UTC)
That would be incorrect when used inline - the majority of its instances, I suspect. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:00, 1 January 2019 (UTC)
@Pigsonthewing: And would it work as expected when used in pages like Page:Bedřich Smetana, The bartered bride, Die verkaufte braut.pdf/8? If so, maybe we could have to language templates: one for inline usage and the other for larger parts of text... --Jan Kameníček (talk) 22:37, 1 January 2019 (UTC)
I would not want to see two templates; as that increases the maintenance workload. Better (if we need to go down this road at all) to have one, with a switch parameter depending on the context, which is set as, say |inline=yes, and make the default value whichever is the most common usage. We could then make a wrapper avaialable for the secondary usage. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:40, 4 January 2019 (UTC)
Note that, provided I understood you correctly, this is functionally equivalent to having two templates. --Xover (talk) 15:42, 4 January 2019 (UTC)
If we decided to have two templates, I can found the other one, as it requires just a minor change. If we decide to incorporate it into the existing template, I would be really appreciate if somebody more experienced did it. --Jan Kameníček (talk) 00:25, 6 January 2019 (UTC)
So I will keep using the template {{Lang}} as it is and it can be fixed any time later. --Jan Kameníček (talk) 10:55, 10 January 2019 (UTC)

Download a book[edit]

Hi, is there any feature to download the validated books in English wikisource? I could see download option for the featured text displayed in homepage. How can i get a similar option for other books?

In my local community, I have a friend who holds a doctorate degree in English Literature. He wants to read a wider range of books, but he is visually challenged. Since the books in Braille language are limited in our locality, he uses a software which would read out the digital content.

He can read the wikisource pages directly using the software, however it would read out the entire page including menus and headers. It would be easier for him if these books are available in word/pdf/epub format, as it would be comlicatd for him to navigate the webpages. Can anyone please help me? --Cyarenkatnikh (talk) 11:39, 31 December 2018 (UTC)

You should see "Download as *" links in the left sidebar in the main namespace. I'd recommend EPUB, as Wikimedia's PDF generation is notoriously shoddy. BethNaught (talk) 11:50, 31 December 2018 (UTC)
With that option, I would be able to download that particular chapter/page. How can I get the whole book, like the one in featured texts of community home page? --Cyarenkatnikh (talk) 12:27, 31 December 2018 (UTC)
To the contrary, you get the whole book, at least if you use the link on the work's root page. Go to Aaron's Rod (Lawrence) and try it: I get the whole book as an EPUB.
That's not to say that the converter tool works in all cases, but it's worth trying. BethNaught (talk) 20:38, 31 December 2018 (UTC)
see also m:Community Wishlist Survey 2017/Wikisource/Improve export of electronic books; m:Community Wishlist Survey 2019/Wikisource/Improve export of electronic books; it is a perriennial wishlist, but not much interest among the devs. Slowking4SvG's revenge 22:40, 1 January 2019 (UTC)

Occult books digitized[edit]

FYI: "1,600 Occult Books Now Digitized & Put Online, Thanks to the Ritman Library and Da Vinci Code Author Dan Brown". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:59, 3 January 2019 (UTC)

Anything "masonic" amongst that? ShakespeareFan00 (talk) 17:44, 4 January 2019 (UTC)
@ShakespeareFan00: You mean like these?
-Einstein95 (talk) 10:41, 5 January 2019 (UTC)
Yes. assuming they are out of copyright globally. ShakespeareFan00 (talk) 10:42, 5 January 2019 (UTC)
@ShakespeareFan00: Having lost my original edit where I went into detail about the copyright status on each item, I'll give a brief summary:
  • The religious and masonic symbolism of stones - {{pd/1923}}
  • Freemasonry: its outward and visible signs - {{pd/1923}}
  • Knight Templar Masonry - {{pd/1923}}
  • Some deeper aspects of masonic symbolism - {{pd/1923}}
  • Cabul, or Christian symbolism in freemasonry - Unknown, no year given
  • An encyclopedic outline of masonic, hermetic, cabbalistic and rosicrucian symbolical philosophy - {{PD-US-no renewal}} (a later edition was renewed, but not this one)
-Einstein95 (talk) 20:42, 7 January 2019 (UTC)
Okay, did you check author dates for 70 pma jurisdictions? ShakespeareFan00 (talk) 22:52, 7 January 2019 (UTC)

My researches say:-

  • William Wynn Westcott (d. 1925) British.
  • Unknown author, publication of British origin?
  • Unknown author, (Note in fly-leaf sheets given an 18th century date)..Transcription, as this appears to be a handwritten manuscript..
  • Arthur Edward Waite (2 October 1857 – 19 May 1942)
  • Cristopher C. Gill, No date on publication
  • Manly Palmer Hall (March 18, 1901 – August 29, 1990) (So not yet out of copyright per 70 p.m.a rules.)

So that to me says only one of those could be reasonably uploaded on commons.. Oh well. ShakespeareFan00 (talk) 23:06, 7 January 2019 (UTC)

{{Author}} and multiple images[edit]

Come across Author:Edward Carpenter which has 2 images in their Wikidata item: File:Carpenter1875.jpg and File:Day, Fred Holland (1864–1933) - Edward Carpenter.jpg. The current {{Author}} template interprets this as one image: File:Carpenter1875.jpg, Day, Fred Holland (1864–1933) - Edward Carpenter.jpg. As the Author template is locked to admin-only editing, can this be fixed so only one of these images gets shown rather than a red link? -Einstein95 (talk) 10:11, 5 January 2019 (UTC)

Change the "image" (P18) priority. Reverse this if you prefer the other picture! 11:17, 5 January 2019 (UTC)

Public Domain tags[edit]

Is there any plan to move/rename Template:PD/1923 and friends to "PD/US" or something similar since the static 1923 date is now obsolete? Phillipedison1891 (talk) 16:27, 5 January 2019 (UTC)

No. Refer to the discussion near the top of this page, with linked discussion on Commons. --EncycloPetey (talk) 16:41, 5 January 2019 (UTC)
I think you mean #Adapting Template:pd/1996 or a new template, yes? -Pete (talk) 20:17, 5 January 2019 (UTC)
Yes. As the discussion points out, it's not that the 1923 date is "obsolete", but that there is an emergent new group of works in PD through expiry of copyright renewals this year. --EncycloPetey (talk) 20:21, 5 January 2019 (UTC)
I have gone ahead and edited Help:Public Domain to use a {{#expr:{{CURRENTYEAR}}-95}} expression in place of the 1923 date. This is consistent with both the Hirtle chart and the apparent plain meaning of 17 USC §304(b). I understand that EncycloPetey is wary about doing this, but I'm afraid I do not understand. Is there someone else who does? Phillipedison1891 (talk) 16:29, 10 January 2019 (UTC)
The pre-1923 date applies to works regardless of all other considerations. Works published in 1923, that entered public domain this year were works that had registered a US copyright, and renewed, but the renewal has now expired. The end result is public domain, but the reasons are very different, so we have discussed using a new template to mark these cases instead of adjusting an existing template.
But any conversation on this topic should happen in the previously existing thread instead of here. There is no reason to run two simultaneous threads on the same topic. --EncycloPetey (talk) 17:24, 10 January 2019 (UTC)
I am continuing this section just so I can try to clarify and understand what you are saying. For the past several decades, works first published before 1923 have been in the public domain because their copyright renewal had already expired before the act of 1976 took effect. That act, taking into account the 1998 extension, effectively extended the term of 1923 and later works under the old pre-1976 regime to 95 years after publication. It then took 20 years for the 95 year term to "catch up" with the pre-1923 works which were already in the public domain. As of now, however, all works published more than 95 years ago are public domain, and for the same reason - their copyright may have been renewed, but the renewal has subsequently expired.
Given this, I am unclear what you think the benefits would be of separate templates - one for pre-1923 works and one for 1923-[current year - 96] works. Also note that someone (not me!) has already changed Template:PD/1923 and friends to use a dynamic {{#expr:{{CURRENTYEAR}}-95}} date - only reference to a hard-coded 1923 at this point is in the name. Phillipedison1891 (talk) 18:04, 10 January 2019 (UTC)
I agree; all works published more than 95 years ago are now public domain in the US. Those 1923 works now entering the public domain are no different than the 1922 works that entered the public domain in 1998. They may have had different histories, but that's of no importance to us.--Prosfilaes (talk) 23:34, 10 January 2019 (UTC)
Given this, would anyone object to updating Help:Public Domain to at least reflect the correct criteria to determine whether a work is public domain in the US? EncycloPetey mentioned that appropriate template names are still being discussed, but this seems like an issue that could be addressed separately. Phillipedison1891 (talk) 02:24, 11 January 2019 (UTC)
What do you mean by "reflect the correct criteria"? If you mean "make the same edit" you previously made, then I do object. --EncycloPetey (talk) 02:28, 11 January 2019 (UTC)
I don't understand your objections; 1923 is completely irrelevant to US copyright law now. It was only a line because works published between 95 years ago and 1923 were grandfathered out of the copyright extensions; there's no reason to count them separately now.--Prosfilaes (talk) 02:52, 11 January 2019 (UTC)
But some your edits include works published in 1924, which is still relevant for US copyright, yes? Changing the recommendations and changing the templates will affect some works we previously hosted. So what is your plan for identifying and correcting the templates on those works to meet the recommendation changes?
It is astounding to me that a thread on this topic has sat around virtually un-commented upon for months, and suddenly everyone thinks a crisis has arrived and immediate action must take place. How about we discuss and do things right the first time for a change? --EncycloPetey (talk) 03:04, 11 January 2019 (UTC)
What works are you talking about? If you want to discuss, you need to discuss. I'm not worried about getting things perfectly right the first time; that's often how things never get done.--Prosfilaes (talk) 03:18, 11 January 2019 (UTC)
Any time you want to read the discussion on this topic, and join in, feel free to do so. I'm not going to duplicate the discussion here. But it's pretty hypocritical to tell me I need to discuss, not participate in the discussion, and act without discussion yourself. --EncycloPetey (talk) 03:39, 11 January 2019 (UTC)
This is the only place on this page that mentions Help:Public domain. The discussion about that page aren't completely dependent on other changes to the templates.--Prosfilaes (talk) 06:17, 11 January 2019 (UTC)
"But it's pretty hypocritical to tell me I need to discus" = welcome to typical wikimedia admin behavior: abrupt, censorious, non-consensus. Slowking4SvG's revenge 03:55, 12 January 2019 (UTC)
  • Bucket of cold water time. Be very careful. Out of copyright in USA does not mean out of copyright worldwide.
w:Siegfried Sassoon's 1923 poetry collection Recollections may be about to lose copyright protection in USA, but it will remain in copyright in life+70 countries until the end of 2037. Narky Blert (talk) 22:59, 13 January 2019 (UTC)
Yes, we know that. The English Wikisource only worries about status in the US. Users need to check the details if they are worried about copyright status outside of the US.--Prosfilaes (talk) 03:07, 14 January 2019 (UTC)

templatestyles inserting paragraph breaks[edit]

I've found that {{nowrap}}, after being edited to implement the <templatestyles /> extension, now inserts a paragraph break on Page:Chesterton--The Napoleon of Notting Hill.djvu/63 in the text:

"Auberon! for goodness' sake {{...}}" cried Barker

If the template is rolled back to before this change, it displays fine. -Einstein95 (talk) 04:20, 7 January 2019 (UTC)

@Einstein95: This looks like the issue tracked in Phabricator (linked in the box above). The problem seems to be that TemplateStyles is spitting out a <style /> or <link /> element that isn't actually permitted inside a <p></p>-paragraph. The HTML parser therefore closes the paragraph, inserts the styles, and then opens a new paragraph for the following content.
This is going to affect all templates using TemplateStyles whose notional role is "inline", but will only be visible in some contexts. For example, using {{nowrap}} at the natural end of a paragraph will technically exhibit this problem, but it will be invisible because the erroneous end of the paragraph will coincide with the actual end of the paragraph. Uses of {{nowrap}} in text that, for whatever reason, is wrapped in <div></div> insead of <p></p> will work just fine. And so forth.
The only immediate solution I see is to revert {{nowrap}} to the previous revision which uses inline styles until the WMF developers come up with something more permanent (I've suggested a few possible solutions in Phab, but they may be unworkable and will certainly take a while to implement even if they work and the devs like them). And absent loud protests I've reverted the template for now. --Xover (talk) 11:41, 7 January 2019 (UTC)
Thank you very much for that, I was unaware that there was an open Phabricator bug. I'm guessing there's a number of templates that should hold off having these. -Einstein95 (talk) 20:37, 7 January 2019 (UTC)

Tech News: 2019-02[edit]

18:30, 7 January 2019 (UTC)


Some works called "Another" refer to the title of a previous work. Example: "A Letter to Her Husband, Absent upon Public Employment" is followed by "Another", i.e. another letter to her husband. Another example: "(To His Book) Another" is a poem called "Another" but which was originally preceded by a poem called "To His Book".

In disambiguating poems called "Another", is it wise to use the name of the preceding work as the disambiguation, as the editor of "(To His Book) Another" has done? Is it wise to refer to the name of the preceding work at all? Or should we ignore this unusual feature of works called "Another", and merely disambiguate by first lines as is normally done for poems that share the same name, author, and year of publication? —Beleg Tâl (talk) 22:18, 8 January 2019 (UTC)

Changes to Australian copyright law[edit]

From outreach:GLAM/Newsletter/December_2018/Contents/Australia_report, by User:Pru.mitchell, President of Wikimedia Australia:

2019 Australia's Year of the Public Domain

What a happy new year! Changes to Australian copyright law taking effect from 1 January 2019 (Copyright Amendment (Disability Access and other Measures) Act 2017) mean at last we have new material entering the public domain. A key change is that unpublished materials such as diaries, letters and shipping manifests will be subject to the same copyright term as their published counterparts, and orphan works have been given a term of 70 years.

Wikimedia Australia looks forward to working with GLAM partners and copyright organisations through the year to maximise awareness and use of these resources.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 12 January 2019 (UTC)

Note, this does not seem to affect either {{PD-Australia}} nor {{PD-AustraliaGov}} —Beleg Tâl (talk) 16:19, 12 January 2019 (UTC)
the change to unpublished, would suggest a review of deleted australian files over 70 years old. and search for unpublished at internet archive, and at GLAMs. Slowking4SvG's revenge 15:50, 14 January 2019 (UTC)

Missing document in series — Acceptable solution?[edit]

I have been adding a serialized set of U.S. government documents to WS: the weekly announcement of listings in the National Register of Historic Places. The source of scans for this is a set of PDFs available on the National Park Service website. In the header template for each issue, I have been providing appropriate links to the previous and next issues in the series.

Recently I came to a gap in the series, where it appears that the original paper document from 1984 did not get scanned with the others. I know this is a gap in the series because:

  1. The body of each issue states a date range covered by that issue. I have the issues with the previous and next date ranges, and a gap between.
  2. I have identified from other databases some of the content that would almost certainly have been in the missing issue.

I do not at this time know how to find the missing issue, or if a copy even exists any more.

I have been unable to find any WS style guidance covering this circumstance. To cover the gap in the sequence, I created this item in the mainspace: a placeholder providing the editorial comment that a document is probably missing from WS's reproduction of the series. I felt this was preferable to giving the impression that WS is providing a complete series by linking directly from the previous issue to the next issue with no acknowledgement in between. IF the missing document is ever located, I assume the placeholder will be deleted and replaced with an appropriate transcription.

Does this solution work for the community? Is there some contrary style guidance that I missed? Ipoellet (talk) 01:02, 13 January 2019 (UTC)

@Ipoellet: Well, I won't speak for anyone but myself, but this approach seems eminently reasonable to me. However, why not simply contact the NRHP and ask about the missing list? They clearly intend to publish it, and it is both public information, in the FOIA sense, and public domain (in the licensing sense). They'll probably appreciate being made aware of the gap. --Xover (talk) 10:35, 13 January 2019 (UTC)
I probably will contact them, but I don't hold out a ton of hope. I've contacted them about missing pages (not whole issues) before, and their response was dismissive of finding copies of the Weekly List in particular. They simply referred me to a different publication series (the Federal Register) where I should be able to find the same content but in a different format. I have developed the vague sense that the original paper Weekly Lists are simply lost, or so deeply buried in archived files as to amount to nearly the same thing, and that the posted PDFs are all they have now. Ipoellet (talk) 21:14, 13 January 2019 (UTC)
i agree. we are living with open government = pdf. and we care about the data more than they do. we have not had events with NPS yet. NPS records are at NARA, maybe we could do some legwork and find it. [6]; [7] they are closed now but we could add it to the list, and ping dominic. -- Slowking4SvG's revenge 16:14, 14 January 2019 (UTC)
@Ipoellet: The usual practice is to simply omit the missing document, leaving red links to the place where the document will be added when a source is found. —Beleg Tâl (talk) 14:12, 13 January 2019 (UTC)

FileExporter beta feature[edit]

Johanna Strodt (WMDE) 09:41, 14 January 2019 (UTC)

Files can also be transferred to Commons with FTCG. It contains original upload log, but not original edit history. Original file also gets deleted if user has admin privilege in source wiki. Hrishikes (talk) 08:40, 19 January 2019 (UTC)

Tech News: 2019-03[edit]