User talk:Xover

From Wikisource
Jump to navigation Jump to search



Hello, and welcome to Wikisource! Thank you for joining the project. I hope you like the place and decide to stay. Here are a few good links for newcomers:

Carl Spitzweg 021-detail.jpg

You may be interested in participating in

Add the code {{active projects}}, {{PotM}} or {{CotW}} to your page for current wikisource projects.

You can put a brief description of your interests on your user page and contributions to another Wikimedia project, such as Wikipedia and Commons.

I hope you enjoy contributing to Wikisource, the library that is free for everyone to use! In discussions, please "sign" your comments using four tildes (~~~~); this will automatically produce your IP address (or username if you're logged in) and the date. If you need help, ask me on my talk page, or ask your question here (click edit) and place {{helpme}} before your question.

Again, welcome! Beeswaxcandle (talk) 06:57, 11 July 2011 (UTC)

The mysterious Header toggle button[edit]

When proofreading in the Page: namespace and you have your toolbar turned on in "my preferences" (Show edit toolbar (requires JavaScript)), then you will see the button Button category plus.png in your toolbar, and clicking it toggles the header/footer on and off. In this space we put the relevant components for top and bottoms of pages, usually by use of the template {{RunningHeader}}, so for example {{RunningHeader|Stanhope|3|Stanhope}} produces


Personally, I have my header/footer set to open in the Page: namespace and I achieved this by activating that option in my preferences (Show header and footer fields when editing in the Page namespace.)billinghurst sDrewth 06:02, 28 September 2015 (UTC)

@Billinghurst: Thanks. I do have the header/footer fields enabled, but I am deliberately ignoring them for now, in favour of getting all the main text finished. Once that's done I plan to go over it to clean up what needs cleaning up, and first among them is trying to figure out how the header/footer stuff works. I've had a quick look at some of the featured content on here, and some of the documentation, but still don't feel like I have a good grasp of how they work and what they're used for. A deep dive in the style guide is probably in order at some point.
One question that's been bugging me though: is my use of the page status "Proofread" correct? Given the unfinished state of them (cf. above), would it be more correct to set the pages to "Needs proofreading"? I had trouble understanding the finer details of their use (culture shock, used to enwiki and its terminology, sorry) so I somewhat guessed when I decided how to use it. For reference, the understanding I landed on was that "Proofread" here actually means "The automatic text has been corrected for any obvious OCR-artefacts". If instead it has broader meaning—like "Rough Draft" vs. "Draft" vs. "Final", or steps in workflow like "Ready for wider community comment", or whatever—then I may well be using it wrong and would appreciate correction.
Anyways, I appreciate you (and @Prosfilaes:) taking the time to look at this stuff over on the relevant work's index. I still don't quite understand where you're coming from, but I'll try to digest it and read some docs, and follow up further there. In the mean time, it would really help if you could point me at the relevant policy-type stuff that deals with this. Things that talk about "What Wikisource is" and its general principles, etc. If I were to sum up my understanding of our positions (short and without nuance, so only for illustration of my confusion), I would say you and Prosfilaes seem to be arguing that the project aims to produce a completely new edition of the work, with whatever improvements and emendations we think are good for our reader, while I lean more towards preserving the original to as large a degree as possible while still taking advantage of the modern platform. That seems like a pretty fundamental difference in approach, if I've understood the positions correctly, and seems the sort of thing the project ought to have copious guidance on. i.e. not the How of things, but the What and the Why.
Cheers, --Xover (talk) 07:14, 28 September 2015 (UTC)
Wikisource:For Wikipedians!!

We try to be a straight-forward and uncomplicated community. Proofread means that a person has been through that page and they believe that the text/formatting/image(s) represents the scan (the author's intent); and validation means that a second person has separately reached the same conclusion (Help:Page status). Headers/footers take the iterative/compositorial "book" construction (which I addressed at the Index talk: page). As book compositors and publishers changed styles over the last two hundred years, it has not been our goal to be bound to each book's style, instead having components of our style (per guide).

I don't think that Prosfilaes and I are arguing in the way that you indicate, we wish to reproduce the body of the text as published, but as we are in a web world, there has to be flexibility in output, otherwise there is no point to what we are doing, and you can just read the work as a scan. We want to interlink works, we want to link to authors, and we wish to make this a usable resource through the wikis. We don't wish to convert a book to be an interpretative guide, so we have guidance like Wikisource:Annotations, but we do wish to encourage translations of foreign works, so we do have Wikisource:Translations.

We try to be reasonable and practicable. We are strong on principles, we are guided by rules. — billinghurst sDrewth 10:09, 28 September 2015 (UTC)

A "completely new edition" could mean a lot of things. We're changing the line breaks and the font and dynamically retypesetting it at will (computer typesetting always blows my mind when I think about what it was like pre-computer). There is some disagreement about the long-s, which I would argue is a sub-orthographic feature to be lumped in with the font, but {{ls}} generally works to placate both sides. I would argue that what I'm doing is a reprinting, just in a different form factor and in more modern fonts, not a completely new edition.--Prosfilaes (talk) 23:50, 28 September 2015 (UTC)

Page:The Plays of William Shakspeare (1778).djvu/345, {{refn}}, {{ss}}[edit]

I hope you do not mind but noting your comment "Note, issue with the refn template and the |follow argument!" on the first above I had a bit of a go at the page and you can see the result.

As I note in passing you were the person who imported {{refn}} from WikiPedia no doubt you have also become aware that that community has no use for (and thus their templates never support!) the follow parameter. I briefly considered adding said support but the result would be even uglier than directly coding {{#tag:ref so I demurred.

Finally {{ss}} formerly rammed the result into any following characters: e.g. "poſſeſſion" becomes "poſſeſſion" (with my luck those two look identical on your browser; please believe me on mine only the latter case looks quite "normal.") so I took the opportunity of amending that as well. AuFCL (talk) 01:02, 17 November 2015 (UTC)

Hi AuFCL, and thanks for helping out here. Very much appreciated!
I'm still planning on trying to fix the {{refn}}, but since the solution didn't jump out at me on a quick glance I just put it aside until I'm through proofreading the text. I'm expecting lots of little issues (the stuff around the page breaks not least of all) that I figured would be best tackled when I could more easily see how the whole thing will look.
As for {{ss}}, I'm primarily concerned with marking these ligatures, and I'm still undecided on whether to try to mark all the other ligatures in the text (ffi, etc.). Displaying them isn't that critical to me in the short term, and it seems there are quite a few issues that should be addressed before that bubbles to the top of the list. For one, an easy switch to let each user decide whether they want to see these or not (not sure what's actually in place currently), and a consensus default for non-logged in users (which is probably "off", but I haven't located a relevant discussion yet). For another the use of CSS-positioning to emulate a font feature is kinda gross, and any typographer would soundly trout you before running away screaming if they saw that, but at the same time using the CSS 3 Fonts module seems premature, or at least requires skin support in Vector. Anyways, I'm basically only concerned with having them marked so they can easily take advantage of any future solution, if and when one becomes available. In the mean time I'm perfectly happy with displaying just plain "ss".
Aanyways… Very happy to see someone take an interest in this text, for all sorts of reasons, so feel free to mess about as you think best, and I'll be sure to quibble where I have any objection. --Xover (talk) 14:05, 17 November 2015 (UTC)
Oh well. General encouragement and all that (you can probably tell I'm currently—today at least—pressed for time.)

If there is anything I can help with please let me know. AuFCL (talk) 20:07, 17 November 2015 (UTC)

May I sound you out upon a slightly subversive issue? No pressure if you choose not to proceed.

I am a little annoyed that certain persons have been pretending that there was a discussion and consensus in 2014 to deprecate {{ct}} when in fact to the best of my admittedly limited researches the last discussion took place in 2011 and only agreed to dispense with {{st}} (long since deleted and since replaced by an entirely unrelated template)—{{ct}} was only ever mentioned as a side issue without conclusion. Discussion is here in case this is new to you (Also please set me straight if I have misread the argument.)

What I am proposing is that {{ct}} be modified to display (which I consider self-evidently merely representative of the typography and most certainly not a match to the page scan; on the other hand it is simple to generate using approved methods) in Page, Template and Index spaces; and as "ct" in all other name-spaces to keep the search-engine-side-of-the-argument people happy. (And there is always File:Latin_ligatures_ct_and_st.svg as backup or a reference point.)

If you consider this is a waste of time and I should drop the idea—or equally if you have any thoughts or a better idea—please say so!

Sincere apologies if any of this puts you on the spot if it is an issue in which you did not wish to become involved. AuFCL (talk) 08:01, 18 November 2015 (UTC)

@AuFCL: Well, I hadn't really planned on getting involved in any drama when I set out on my Wikisource-projects (I mostly edit on enwiki which has a seemingly endless supply of it), but I seem to have halfway stumbled into an area that is, for some reason I'm not quite grasping as yet, somewhat controversial.
To try to sum up my position: I very much care about maintaining as many aspects of the original work as is practically feasible by tagging it in a semantically structured way. I am, in the short term, not all that concerned with presentation and can happily live with whatever is the consensus default. When another editor insists on a change that is contrary to these goals I expect their position to be backed up by policy or community consensus, and I expect the discussions leading up to either to be easily findable and clear-cut.
As a concrete expression of these more general principles, I have searched in vain for any community discussion that deprecates typographical ligatures. I have found some that address technical limitations and problems with various specific limitations, but otherwise the discussions I have found suggest a consensus for preserving these to whatever degree is practical. The policies I've found that bear on this also point specifically to preserving such features wherever possible and to what extent it is possible do so (without addressing the question directly).
Thus I am quite concerned that individual editors' personal preferences are being applied as if they were project-wide policy supported by community consensus, and would engage myself in any process or discussion aimed at resolving this dissonance.
Now, all that being said, I have some opinions, more or less well considered, but not necessarily ultimate answers. There may well be factors I am not aware of that make my current conclusions naive or unworkable in practice. If so I would very much like to be made aware of that. I also have some personal preferences in some aspects, such as that I do not like the visual presentation of your proposed solution (I want the actual ligature and not a symbolic representation of it) and neither am I particularly happy about your implementation of it (using math markup). Thus, depending on what other alternatives are on the table, I would likely then fall down in favour of using just plain "ct" until a proper solution could be implemented (which, I think, will be using the CSS 3 Fonts module's support for historical ligatures; see [1], [2], and [3]).
In any case, I am sympathetic to your position, even if I do not predict agreeing with all details of its proposed implementation. --Xover (talk) 19:23, 18 November 2015 (UTC)


What is the purpose in beginning each line with {{gap}} on this page? If the poem is set inside {{block center}}, then I can't see what function the use of {{gap}} serves. --EncycloPetey (talk) 18:22, 21 February 2017 (UTC)

No purpose. They're a leftover brainfart. Thanks for the catch! --Xover (talk) 18:33, 21 February 2017 (UTC)

You could try ...[edit]

Hi, just noticed the frustration with the passage with a running left margin quote mark. If you want to set off the passage, you could try {{quote}}. An example where I've used it is Page:A Dictionary of Music and Musicians vol 3.djvu/86. Beeswaxcandle (talk) 09:31, 8 August 2018 (UTC)

@Beeswaxcandle: Thanks for the tip. I'll keep it in mind for future needs. But in this case the problem was mainly that after pages upon pages of block prose quotation, Hazlitt's reproduction of North's translation of Plutarch begins intermixing prose and dialogue. Since we can't sanely reproduce the row of single quote marks in the left margin, and the dialogue stuff is too long for just pairs of single quote marks at start and end, it needs some other typographic way to set it off. I don't particularly like using italics that aren't present in the original, but in this case I think it's a reasonable compromise when we can't be fully semi-diplomatic. --Xover (talk) 10:50, 8 August 2018 (UTC)

Henry IV Part 1[edit]

This one doesn't have the cover in the scan. It's a (blank) library binding and not the book's cover. --EncycloPetey (talk) 01:23, 12 January 2019 (UTC)

Also, {{serif}} is a very old and unnecessary template. The serifs are added in the page layout when the content is transcribed. Specifying fonts or font-styles is usually frowned upon, as it is restrictive and not necessary. --EncycloPetey (talk) 01:26, 12 January 2019 (UTC)

@EncycloPetey: Thanks. But I think you'll have to explain the serifs thing. I add the explicit serif formatting to the headings and such that look horrible and anachronistic in sans-serif, but only to those places. How would tranclusion into mainspace achieve the same thing? --Xover (talk) 08:48, 12 January 2019 (UTC)
Look at the transcluded versions; I have transcluded the Bibliography for instance. They have a layout applied to them that includes a serif-font preference. Applying that level of font-style in the Page namespace is redundant. --EncycloPetey (talk) 14:59, 12 January 2019 (UTC)
@EncycloPetey: Ok, I think I see. By specifying a layout when transcluding we're effectively also applying a set of styles, and since that style sets everything to serifs it is redundant to also do so in the Page: namespace? I'd not really considered the layouts as something other than an extra gadget for editors: are they active also for non-logged in users? Are the effects of the different layouts documented anywhere? --Xover (talk) 10:29, 13 January 2019 (UTC)
The only place I'm aware of is Help:Layout, but it's explanations are minimal. As far as I am aware, the Layouts, when applied, have effects visible for everyone. --EncycloPetey (talk) 15:03, 13 January 2019 (UTC)
Hmm, and further, why are you specifying a 320px width for the text here? Especially considering neither {{fine block}} nor {{smaller block}} actually support a |width= parameter. --Xover (talk) 09:06, 12 January 2019 (UTC)
The width shold have applied to the {{block center}} which wraps the font size. Templates like {{fine block}} or {{smaller block}} are simply there to adjust the size of the font; it's the enclosing template {{block center}} that sets the margins and placement of the text. Consider

This text is enclosed with a width limitation in a "block center template"

This text is enclosed without a width limitation in a "block center template"

The applied width limits the length of the text lines, which is the format present in the original image description present in the text. Without the limitation, the lines of text will be as wide as the screen allows. What you noticed was that I had failed to add the wrapping template, but have done so now. --EncycloPetey (talk) 14:59, 12 January 2019 (UTC)
Hmm. I'm not sure I particularly agree with the implication that non-wrapped text is undesirable. But that aside… Doesn't the layout (cf. the point above) also apply things like max-width, margins and text-indent, and block center? Or, at least, could and should it not do those things by the same reasoning as for a serif font-family? What's the reasoning for applying one in the Page: namespace and the other in a layout in mainspace? And whence the particular pixel width, not to mention why give it in pixels? --Xover (talk) 10:29, 13 January 2019 (UTC)
The purpose here is to make the block of text slightly narrower than the rest of the text, which it is in the original (being an image caption) and to reduce the chance of being a single long line, which would look very odd in the layout. No, this isn't a style, it's layout. I've used pixels because that's what I always use; if there's a better option that works well with the applied layout, then I'm open to suggestions. --EncycloPetey (talk) 15:03, 13 January 2019 (UTC)
Addendum: I guess part of the reason for using pixels in this instance is that it immediately precedes an image it describes. Since that image has its width given in pixels, it makes sense to do the same with the caption, so that both are measured in the same system and can be easily coordinated. But what I said before is still true. I use pixels because that is the measurement system I'm most familiar with, and is more closely tied to display size. --EncycloPetey (talk) 15:46, 13 January 2019 (UTC)
Pixels are usually a poor choice precisely because they are tied to display size: every other option is relative and scales to some degree, but pixels fall down when faced with the wide variety of pixel resolutions of devices out there. Even images are best sized using percentages of its containing context. But, of course, that's all on a general basis, and the specific needs on enWS may affect the calculus. In any case, I was mostly just wondering whether there was a specific reason for it. --Xover (talk) 07:18, 14 January 2019 (UTC)

A suggestion on workflow: I found it easier to set up all the Notes pages (with anchors) in advance, and transcluded the Notes section, so that I could check the "Cf. n." links as I worked through the Text pages. If a link showed up red, or didn't take me to the right endnote, then I was able to make that correction in the Text. --EncycloPetey (talk) 15:42, 12 January 2019 (UTC)

Good idea. I like approaches that give you extra ways to detect errors "free". But we'll see how I actually go; right now I'm more concerned with figuring out the technical stuff like formatting and partial transclusion and so forth. Lots of new and, to me, relatively advanced stuff on this one! --Xover (talk) 10:29, 13 January 2019 (UTC)
I'm working on Macbeth now (and it will take a while). You can watch to see my workflow if that helps. I work in stages to keep things clear in my own head as I work when a work is as complicated as these are. --EncycloPetey (talk) 15:03, 13 January 2019 (UTC)
@EncycloPetey: Thanks, I'll keep an eye on that. And, I may perhaps be so bold as to presume I may ask you further stupid questions as they arise? :) --Xover (talk) 07:18, 14 January 2019 (UTC)
  • @EncycloPetey: I think I've figured out all the twisty niggling bits, and completed proofreading Index:Henry IV Part 1 (1917) Yale.djvu. Could you take a look just to make sure I didn't mess up anything big? --Xover (talk) 21:42, 8 February 2019 (UTC)
    I haven't looked thoroughly, but I did notice that the right-hand page headers were missing a space after the period. I've corrected them all for Act V, but not the earlier acts. I'll look though at more things as I have time, and let you know if I spot anything. Do you plan to continue on to 2 Henry IV next? The file exists on Commons; I just hadn't set up the Index page. --EncycloPetey (talk) 21:50, 8 February 2019 (UTC)
    @EncycloPetey: Thanks. I do intend to move on to 2H4 next, yes. Regarding the right-hand headers, I'm not convinced there is actually a space there: the original typesetting (kerning) is too quirky and coarse to be able to say definitively, and act.scene is at least as common as act. scene and act, scene in general. But in any case, I've gone back over the earlier pages and inserted one in the interest of consistency. --Xover (talk) 09:28, 9 February 2019 (UTC)
    One formatting error I've noticed: You need to end formatting whenever a line is to be centered. Adjusted margins affect the centering, so: do this to avoid misaligned centering. --EncycloPetey (talk)
    @EncycloPetey: Thanks. I must admit that one is down to laziness rather than ignorance: the slight offset on centred lines seemed too small to bother with. Since it is apparently more noticeable than I thought I'll try to be more careful going forward. --Xover (talk) 19:44, 10 February 2019 (UTC)

Dash in Index pages[edit]

The dash (-) in Index pages is properly used for blank pages that lie outside the page numbering system.

See Index:Aeneid (Conington 1866).djvu. The opening pages are blank, and are outside the numbering system, and so are marked "-".

But pages iv and vi, which are blank, lie within the page numbering system, and so are numbered. The gray color indicates they are blank, so it is not necessary to double mark them with gray color and a dash. Doing so could also confuse people about the sequence and numbering of the pages, suggesting that pages had been omitted from the scan. This does sometimes happen with defective scans.

The "Errata" page is not numbered because it is a slip that was inserted into the volume, and was not a full page of the volume. The "page" following it is a scan of the back of the errata slip, which is also not a page, but the back of an inserted slip. Since it has no content ;;and;; is not part of the page numbering scheme, it is best represented as a "dash".

Page 450 is another blank page, but it is clearly part of the page numbering scheme for the volume, since the previous page is numbered 449 and the following page is numbered 451.

With the Yale Shakespeare series, there is a common set of eight pages in the from matter, none of which bear a page number in any of the volumes, but library catalogs assign these pages Roman numerals beginning with the half-title page[1] and continuing up to the first numbered page of the volume, or at least the page that appears in the position of "page 1" even if it is not numbered and the following page is "page 2".

With this in mind, I've set "page i" at the half-title page in accordance with standard practice. The back of that page, even if it is blank, is "page ii. --EncycloPetey (talk) 20:30, 26 January 2019 (UTC)

  1. But usually omitting a sheet that bears a frontispiece.
@EncycloPetey: Ugh. Confusing! But thanks for clarifying. --Xover (talk) 07:10, 27 January 2019 (UTC)

Header formatting[edit]

I don't usually bother trying to match font size in the headers. If the page numbers are a bit smaller, then there's little point in going to the trouble, since the header isn't transcluded in the final copy anyway. Some people like to go to a lot of trouble formatting the header text, but as it's not going to show up anywhere but the Page namespace, it doesn't seem worth the effort in most situations.

However, italic text in the header is easily done. For the Yale Shakespeare, I've been italicizing, but not concerned with making bits of the header larger or smaller. --EncycloPetey (talk) 22:03, 27 January 2019 (UTC)

@EncycloPetey: Yeah, I've been starting to have second thoughts about the level of and which detail to reproduce in headers (and the main text for that matter). As you say the formatting here generates a bit too much cognitive overhead, which in turn (among other factors) leads to me drop the ball on stuff like the italics. My starting point was very close to diplomatic (paleography and minor textual, even punctuation, details is a major issue in my field), but experience here is slowly nudging me back down that scale. Hopefully I'll arrive at a sensible middle path eventually! :) --Xover (talk) 07:30, 28 January 2019 (UTC)
@EncycloPetey: By the way, you may find some use in this list. It's in a sandbox that may change at some point in the future, hence the permalink, but I have no immediate plans to reuse it. I may at some point update it to fill in some of the missing bits, so feel free to browse the most recent version of the page. --Xover (talk) 21:31, 6 February 2019 (UTC)

PageLayout and MarginNote templates...[edit]

Can I ask you to look into documentin these and implement an lrpage and rlpage option for them?

The context being -;_or,_Chronicle_of_the_Kings_of_Norway_Vol_1.djvu/225&action=submit which has alternating margins..ShakespeareFan00 (talk) 19:18, 10 February 2019 (UTC)

@ShakespeareFan00: No promises as template syntax gives me as much of a headache as the next guy, but I can certainly take a look. However, I don't think I understand what it is you're asking. Template:MarginNote appears to have existing documentation; and judging by Page:The Heimskringla; or, Chronicle of the Kings of Norway Vol 1.djvu/225 you've already achieved the effect you're after using it and Template:PageLayout. What is it you're having trouble with and what would the lrpage and rlpage parameters do? --Xover (talk) 19:39, 10 February 2019 (UTC)

Page:The Heimskringla; or, Chronicle of the Kings of Norway Vol 1.djvu/225 which I've already been able to handle (which has a right-hand margin.) Page:The Heimskringla; or, Chronicle of the Kings of Norway Vol 1.djvu/226 which has a left hand.

In page namespace I can set up left or right hand margins for per the header. I can't currently setup a {{MarginNote}} that automatically changes a left-hand margin note to a right-hand one when the page is transcluded ( contrast the functionality of {{outside R}} {{outside LR}} for sidenotes. )

In main namespace by comparison, either a lefthand or right hand margin would be set up for an entire transcluded section, and at present the MarginNotes cannot be set to display differently depending on page (where the margin space for them alternates between pages) or mainspace use (where they would not.

lrpage and rlpage are shorthands that tell a template to behave differently in Page vs other namespaces:

  • lrpage means "left" in page namespace, "right" when transcluded
  • rlpage means "right" in page namespace, "left" when transcluded

the behaviour of the template changing accordingly.

(I can of course make an editorial decison to only use one 'margin' style, which is a reasonable medium term workaround.)

It is {{PageLayout}} that is undocumented, and some examples of how to use it conjunction with MarginNote would in general by useful anyway.

There are also some other limitations of {{PageLayout}} and {{MarginNote}} that are not applicable to the current work. ShakespeareFan00 (talk) 20:25, 10 February 2019 (UTC)

See also -Template:MarginNote/sandbox for a related issue I solved, on Page:The Heimskringla; or, Chronicle of the Kings of Norway Vol 1.djvu/230 ShakespeareFan00 (talk)

Henry V[edit]

Is it a conscious choice on your part to indent all the text as poetry, or did you not notice that the prose passages of the current pages you're doing use a different indentation to indicate they are prose? --EncycloPetey (talk) 16:15, 18 February 2019 (UTC)

@EncycloPetey: I didn't notice. Or rather, provided we're thinking of the same passages, I just figured they were inconsistent typesetting. Any suggestions for how to handle them? --Xover (talk) 16:42, 18 February 2019 (UTC)
It's simply a tweak of the {{dent}} template to accommodate the different indentation. The series is consistent about giving the prose an extra 1em of indentation. If you didn't notice this before, I can handle the Henry IV plays, if you'll do Henry V. --EncycloPetey (talk) 16:46, 18 February 2019 (UTC)
@EncycloPetey: That would be much appreciated. Thanks, and I'll try to get this right on H5. However, looking into it now I see what I'd noticed before wasn't actually the prose passages, but rather Pistol's spontaneous verse lines interspersed in them. These look like they have -1em margin when you've not noticed the actual prose lines. Sigh. I can tell already that I'm going to struggle getting this right. So doubly thanks, it seems, as I would never have noticed this on my own! --Xover (talk) 16:58, 18 February 2019 (UTC)


It isn't necessary to label sections on most pages in the Appendices. In the body of the plays, there are separate parts on each page (body text, footnotes) that must be separated from each other in the transclusion, so all the sections have to be labelled. But in the Appendices, there is usually just one section per page, so labeling the sections is not needful. The only exception being instances where one Appendix concludes and another begins on the same page. --EncycloPetey (talk) 18:27, 22 February 2019 (UTC)

@EncycloPetey: Thanks. Yeah, I was actually aware of that (but very much appreciate you checking up!); but one of the previous plays had appendices that ended and started on the same page, so here I added the section markers prophylactically for consistency-slash-lazyness. The extra markup should do no harm even if unused. --Xover (talk) 18:46, 22 February 2019 (UTC)
The problem I've found with using section markings when they're not needed is that proofreaders occasionally remove the section markup, either accidentally or without understanding their importance, so I avoid using them if they're not essential for transclusion. A single removed or altered section tag removes that page from the book. --EncycloPetey (talk) 22:57, 24 February 2019 (UTC)
Sure. But at a certain point there you're trading off robustness and convenience in a risk analysis with diminishing returns. The pages will be very rarely edited, and even more rarely by someone that messes up the section markers, and there are a whole host of other markup syntax errors that can mess up not just the one page but even all the following pages in the transclusion unit. --Xover (talk) 07:20, 25 February 2019 (UTC)

Final scans[edit]

I've set up half of the Yale Shakespeare comedies, and much more of the disambiguation and versions pages. At this point, there are only four volumes in public domain for which I haven't located a quality scan. For these I've located Google scans only, which are never great, and are occasionally awful.

  • Shakespeare's Sonnets - Google scan from the University of Minnesota that looks surprisingly clean.
  • Romeo and Juliet - I've found a Google scan from the University of California that looks OK on a first pass.
  • 2 Henry VI - I found a Google scan that was good enough for the Hathi Trust to host it. Again, looks reasonably clean.
  • The Tempest - The only Google scan I've found is a botched job with multiple "extra" pages, which may mean that pages are also missing or out of sequence.

I'm asking around to see whether someone can generate a DjVu for 2 Henry VI. If I find someone who can capably produce a usable file, then I'll see whether they can also do the Sonnets and Romeo and Juliet. I'll continue looking for a cleanly scanned Tempest, but might have to purchase a copy myself and find a nearby library with digitizing equipment. --EncycloPetey (talk) 22:55, 24 February 2019 (UTC)

2 Henry VI is up and started. You'll notice a few differences once you start proofreading:
  1. The scan resolution is lower, so some characters may be harder to distinguish; e.g. numbers such as "3" and "8" will look very similar.
  2. Different scan errors: "x" frequently becomes "r".
  3. Some hyphens will be missing from the text.
  4. Some quotes in the text layer will be curly quotes, and will need to be swapped to straight quotes, which doesn't happen with IA scans.
--EncycloPetey (talk) 02:35, 25 February 2019 (UTC)
Thanks. Yeah, I've been subjected to Google scans before. Especially when combined with 18th-century typography and page layout (Edmond Malone uses multi-page nested footnotes, obsessively formatted details that can't really be approximated: they have to either be reproduced exactly or replaced entirely. Sigh.). I'm sure Google Books started out with the very best of intentions, but their incompetent scanner operators, low general quality level, and subsequent turn to lock up and lock down public domain works… Meanwhile their crappy job made it that much harder to get proper scanning projects funded, much less any organised way to make the scans available. Thank heavens for HathiTrust, but their approach to copyright is way way too conservative.
In any case, it will probably be a pain, but we'll get there eventually. Thanks for all your work and care getting this set up! --Xover (talk) 07:29, 25 February 2019 (UTC)
@EncycloPetey: I took a stab at The Tempest based on the page images at HathiTrust (Google scanned), mainly as an experiment to test out my tooling. I've manually cleaned up the page images (there were more interleaved pages than original pages!) and generated new OCR text. So far as I can tell it looks reasonable, except that I wasn't aggressive enough in removing interleaved pages at the start of the book so that it has an excessive number of blank pages there relative to the rest of the series. I didn't feel that was worth going back and redoing the DjVu over, but if you disagree I can do so (it's not all that much work). Take a look and let me know what you think?
PS. I now have some rudimentary tooling for working with DjVu files set up (including generating a DjVu with hidden text from just page images), so if you need anything done feel free to ask (or just ping me when you post a request at the Scriptorium). I claim no particular expertise, nor make any promises regarding quality or response time, but I'm happy to help when I can so never hesitate to ask. --Xover (talk) 10:18, 13 April 2019 (UTC)
My feeling is always that "if it's worth doing, it's worth doing right". Besides the extra blank pages before page "i", you've left two extra pages between "i" and the Title page, which puts the title on page "v" instead of pages "iii", and also left two blank pages between the copyright and the Contents, both of which mean that the page numbering will be wrong for all of the front matter (relative to the original text). This has an impact on citations. There should also be the usual number of blank pages at the end of the book, since the "PRINTED IN..." really isn't the back cover of the book. I would recommend redoing the DjVu so that all of these issues are corrected and we have a proper reproduction of the original text. --EncycloPetey (talk) 14:25, 13 April 2019 (UTC)
@EncycloPetey: Hmm. Ok… I've removed the extraneous interleaved pages in the front matter. Since this scan is missing the outside cover I have omitted that page, but I've kept the inside (verso) cover plus one blank leaf between the cover and the series page. I have also kept the blank verso of the leaf with the series page. All other blank pages in the front matter have been deleted. For the end of the book there is little rhyme or reason to the scans, but it looks like the practice of the printer was that:
  • iff that page is included, it is always printed on the verso side of a leaf
  • if the last content page is a recto page, the Printed in… page is printed on its verso side
  • if the last page is a verso page, the Printed in… page is printed on the verso of its own leaf
  • there is usually at least one blank leaf between the Printed in… page and the back cover
So, for this work, I have added a separate leaf with the Printed in… page (since the last content page is a verso page), followed by one blank leaf (recto + verso pages). Neither side of the actual cover is included in the scan so I have left those pages out. It's very hard to tell from the scan, but it looks like this copy had one blank leaf inserted before the Printed in… page and two blank leaves after it; in addition to the blank recto of the Printed in… page itself and the original blank leaf following it. Without access to a physical copy or a better scan this is the best approximation we can get I think.
Incidentally, in looking into this I notice that for those editions where the Printed in… page appears on the verso of the last content page the pagelist tends to assign it a page number, which I do not think is warranted: that it appears following the last actual numbered page is mere happenstance, and when it appears on a separate sheet it is not numbered. --Xover (talk) 10:18, 14 April 2019 (UTC)


You clearly know what you're doing here, from what I've seen. Interested in having mop privileges? —Beleg Tâl (talk) 12:17, 21 March 2019 (UTC)

@Beleg Tâl: Well, I would certainly be happy to help where I can. But 1) I've not had +sysop on any project before so I'm not familiar with the tools, and 2) I've as yet not ran into any particular instances where I've needed that bit (except possibly interface admin, but I'm sure that could have been handled by proxy if needed). --Xover (talk) 15:12, 21 March 2019 (UTC)
I initially read that as a "yes" and posted the nom; now I'm not sure; is that a yes or no? If you read through Wikisource:Adminship it will tell you what tools are available and what you would be able/expected to do. The only tools of import are the ability to delete pages, and block users. In my opinion, in a small project like this, anyone who can be trusted with sysop should be offered sysop; you have clearly proven yourself trustworthy. —Beleg Tâl (talk) 15:18, 22 March 2019 (UTC)
@Beleg Tâl: It's a yes :) I'm just used to enwp's RfA and wanted to be up front about my experience and relative need for the tools in case that mattered here. --Xover (talk) 15:26, 22 March 2019 (UTC)
Great! I have re-posted the nom; if you could post at Wikisource:Administrators#Xover that you accept the nomination, then everything will be set for voting. —Beleg Tâl (talk) 15:29, 22 March 2019 (UTC)

Hi Xover, I have closed your nomination as successful, and assigned you the bit. I hope you enjoy the extra responsibility!

If you know any languages other than English, or have any special access, can you please update Wikisource:Administrators#Current administrators?

Hesperian 23:04, 31 March 2019 (UTC)

@Hesperian: Done. And thanks. --Xover (talk) 05:30, 1 April 2019 (UTC)

Nomination for Admin[edit]

I'm writing a story about your nomination for adminship. Can I get a quote for Wikisource:News? How do you feel about potentially being the first new admin on the project in more than a year? –MJLTalk 16:19, 31 March 2019 (UTC)

@MJL: While the attention is certainly flattering, I'm not sure that's particularly newsworthy. I probably won't be doing much admining, above some minor technical stuff, unless something urgent pops up that none of the experienced admins are available to handle. I am happy, though, to see your enthusiasm and efforts in the area of community building and cheerleading. enWS is a relatively small community where people are mostly plugging away at their own little projects. Anything that brings us closer together can only be good for the long-term health of the project. --Xover (talk) 05:38, 1 April 2019 (UTC)

Page number errors[edit]

Just bringing this to your attention. The page numbers in the Indices do need to be checked carefully. Numbers are more prone to scannos in this series than the text. --EncycloPetey (talk) 01:15, 7 April 2019 (UTC)

@EncycloPetey: Ugh. That's a pretty poor showing, alright. Thanks for letting me know! --Xover (talk) 04:55, 8 April 2019 (UTC)