# User talk:Xover

## Welcome

Welcome

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:

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

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

 StanhopeStanhope3

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)

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

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 ${\displaystyle {\overset {\frown }{\text{ct}}}}$ (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)

## gaps

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

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)

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

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)

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

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.
Ugh. Confusing! But thanks for clarifying. --Xover (talk) 07:10, 27 January 2019 (UTC)

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)

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

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

The context being - https://en.wikisource.org/w/index.php?title=Page:The_Heimskringla;_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)

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

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)