User talk:Xover/Archives/2015

Please do not post any new comments on this page. This is a discussion archive first created in 2015, although the comments contained were likely posted before and after this date. See current discussion or the archives index.

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

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

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 ${\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)