User talk:Zoeannl/2018

ARCHIVES: 2015, 2018

Welcome

Welcome

Hello, Zoeannl, 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:

• Help pages
• Style guide
• Inclusion policy
• Wikisource:For Wikipedians

You may be interested in participating in

• Proofread of the Month
• Community collaboration
• Requested texts

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:01, 5 September 2014 (UTC)

A Key to Uncle Tom's Cabin

Zoe, I must say you are doing an incredible job. Moondyne (talk) 14:57, 15 January 2016 (UTC)

Thanks. I've asked for help with the Sidenotes (problematic pages) in the Scriptorium Help but had no response… Do you have opinion of what to do? I'd just as well convert them to references since the sidenote template transcludes so ugly. Cheers, Zoeannl (talk) 08:52, 16 January 2016 (UTC)

Sorry that I didn't see your Scriptorium/Help request. I agree that the sidenotes template is ugly, or at least a way apart from what that text looks like. I have done something similar to what you need here, which would be quite easy to implement. However, what to do in a 2 column text rendered as a single column? — I think you'd want to place all the sidenotes on one side only, nominally left. What do you think? Moondyne (talk) 12:44, 16 January 2016 (UTC)

Yes it would make sense to put them all to the left. I happened to read today that {{float left}} causes text to wrap and have tried it on p 68. What do you think? I've used float left before, so for me, it has the comfort of the familiar. Shame it doesn’t offset like {{right}} does. Zoeannl (talk) 14:14, 16 January 2016 (UTC)

I think float left is more than adequate. Looks good. Moondyne (talk) 14:38, 16 January 2016 (UTC)

@Moondyne: Done proofreading! A bit of a marathon… Transcluding to do. And a list of referred books to look at doing (on Discussion page). For tomorrow (which is 45 minutes away) Cheers, Zoeannl (talk) 10:19, 31 January 2016 (UTC)

Congratulations and a big thankyou. Due to other stuff happening, I doubt I will be able to make significant contribution towards verifying, but I will try! Moondyne (talk) 10:42, 1 February 2016 (UTC)

Bots

If you're running bots, please make it clear to everyone at Index talk:The Hog.djvu. If you're not, my apologies for bringing this up. Outlier59 (talk) 05:13, 25 January 2016 (UTC)

Lol. I don't have a clue how to run a bot. Good job on "Evidence as to Man's Place in Nature". Cheers, Zoeannl (talk) 05:18, 25 January 2016 (UTC)

Origin of Vertebrates

The works I have copied from DP to WS were all ones I was post-processing myself. I have a program of my own which allowed me to work with a single master copy and generate both HTML and plain text for Gutenberg, and I extended this to produce wiki code at the same time. The works had all been proof-read at least twice in DP before I worked on them, and some, including O. of V., 3 times. I don't see any need for further proof-reading in WS!--Keith Edkins (talk) 12:02, 24 February 2016 (UTC)

@Keith Edkins::I've post-processed too. Mistakes can still be there. But the main thing is that PG texts are just texts, we can do so much more on WS and it is valuable and aesthetically pleasing to be able to see the original print copy.

I hadn't noticed you had inserted the images into the PG text. Very nice. So there goes my main objection; I have to admit I just have an aversion to unsupported texts. Cheers, Zoeannl (talk) 23:28, 25 February 2016 (UTC)

TOCstyle

Hello.

I note you seem to have caught some kind of mild addiction. (Happy to be the manufacturer of same.)

After dilly-dallying about this far too long I've finally added support to {{TOCstyle}} for row-level styling.

For example the {{gap}} leading "NOTES" (last line in Page:Various Forces of Matter.djvu/11) may now in principle be replaced with |row15style=margin-left:2em

(Not that this particular example really justifies such a change—I am merely using it as a simple demonstration.) AuFCL (talk) 01:15, 26 February 2016 (UTC)

(@AuFCL:I had been composing this on your talk page) Hi, as you've noticed I have finally got the courage to try and get my head around TOCstyle. After working through the template documentation, I looked at What links here and took notes. I had trouble working out the width parameter, had to drag my husband in to look, he told me to add an "em". The only thing I’ve come across, not specified by your documentation is how to do an indented section; so is nested TOCstyle like this OK? It looks neat, and I did work out it counted as one line eventually. But I couldn't get it to work here, of which there is another 18 pages of TOC to do… Is this because nesting will be problematic? I am more than willing to accept it didn't work because I did it wrong. (pause, fiddle with Anatomy, Oh I have mail…)

So can I use rowstyle for a range of lines?

P.S.The first page of Anatomy has centered dots page#. Can we have a |model=c.?— Zoeannl (talk) 01:29, 26 February 2016 (UTC)

Many apologies for tardy response. I had a minor panic when I realised there was an error in the LUA code where range comparisons were being made alphabetically instead of numerically. (My mental state is probably best assessed by the fact I could not even get the correction summary right!) In case that remark makes no sense; it has impact upon your very question above, in that row4-9style= affected rows 4,5,6,7,8,9 as intended, yet row4-10style= previously affected nothing at all. This (I hope) has now been addressed so that the formal answer to "can I use rowstyle for a range of lines?" is that you can use rowNtoMstyle or rowN-Nstyle to affect a range of lines. style still affects the whole {{TOCstyle}} enclosure and if you happen to use rowKstyle (where K falls inside the range [N-M]) this last will take precedence over the range version. I trust this makes at least some sense?

As it turned out my mentor "got too busy" just at the point where I originally constructed {{TOCstyle}} and as a result the documentation tended to be unreviewed. If I have put some things too obscurely and you can figure out a better way of expressing them please (oh please!) amend Module:TOCstyle/doc as you see fit, as that is where the basic commentary lives. And of course if it makes no sense at all please ask: either I hope I will be able to explain, or in any case you may well have uncovered a bug which needs to be addressed anyway.

With regards Anatomy's centred dots, something akin to {{TOCstyle|model=D.P|leadersym=·|Cytoplasm|35}} ought to already cover your requirement, viz:

1. Cytoplasm ································································································································································································································································································································································································

   35

AuFCL (talk) 04:01, 26 February 2016 (UTC)

Just back from the afternoon school run myself. Cool. I've had a lot of fun playing with leaders! But it is the text that is centered with dots to the right with a right-aligned page number so like a model c with dots and then pp. Cheers, — Zoeannl (talk) 04:17, 26 February 2016 (UTC)

Oops. I think I misunderstood before. I take it you were referring to the second column, which can be "bent" to fit the existing framework, unless you consider this to be too dodgy: {{TOCstyle|model=D.P|leadersym=·|leaderspacing=1em|row1style=font-style:italic;padding-left:calc(50% - 84px);|The Primitive Segments|52|row2style=font-style:italic;padding-left:calc(50% - 90px);|Separation of the Embryo}} which yields:

1. The Primitive Segments ································································································································································································································································································································································································

   52

2. Separation of the Embryo ································································································································································································································································································································································································

   53

3. The Yolk-sac ································································································································································································································································································································································································

   54

Now if you are wondering where the constants 84px, 90px and 44px are coming from, they are estimates of half of the display width of "The Primitive Segments", "Separation of the Embryo" and "The Yolk-sac" respectively. Half? Well the required offset is from the 50% centre-line…

Is this the behaviour you sought? AuFCL (talk) 04:53, 26 February 2016 (UTC)

That'll do the trick. How do you estimate the px width? I sort of know how wide an em is. — Zoeannl (talk) 05:00, 26 February 2016 (UTC)

Oh good enough! That is in fact what I did for a first estimate, and then ended up over-egging the example. (In point of detail I use Firefox a lot and there is a so-called "Box Model" utility hangs off "Web Developer" [sounding overly grand already!] which shows the dimensions occupied by a given HTML element. In further point of detail only in px—which can be rather a pest in of itself…) AuFCL (talk) 05:11, 26 February 2016 (UTC)

A query: Is rowRpageribbon like enclosing a line in <noinclude></noinclude>? Zoeannl (talk) 06:31, 27 February 2016 (UTC)

Yes, pretty much. Do it this way if you prefer. Just be careful about adding stray blank lines if you do: a couple of the more obscure models (the cross-page ones like CD.P/s and CD.P/e) proved to be a bit fragile in circumstances where a leading newline resulted in mediawiki inserting a <p> unexpectedly. AuFCL (talk) 07:12, 27 February 2016 (UTC)

Example—Page:Anatomy of the Human Body(Lewis-1918).djvu/15 Tarsus, row21 is a column continuing header that shouldn't transclude. Have I got it right?Zoeannl (talk) 05:44, 29 February 2016 (UTC)

Looks good to me. AuFCL (talk) 06:56, 29 February 2016 (UTC)

TOCstyle log

Anatomy 18 pages of TOC super fast. As above, centered description with dots and page numbers—solution not working for long descriptions.

Works Translated by William Whiston Easy. But the descriptions are not lining up, influenced by crooked Chapter numbers. Zoeannl (talk) 05:46, 29 February 2016 (UTC)

Leibniz Discourse on Metaphysics super easy. I use {{Table style}} as reference for Natural language code. Shorthand doesn't work. Zoeannl (talk) 06:06, 29 February 2016 (UTC)

History of the German people

Explorers and Travellers Contents, Illustrations Illustrations cont.

Benjamin Franklin italics, long s

Index:Principles of Political Economy Vol 1.djvu Multipages.

As a gross rule, may I suggest usage of model Hn.P (with adjunct |depth=) instead of D.P to handle long lines with hanging-indents?

Although not particularly pretty (in wikitext terms) substituting {{span|ar|dib|width:3em}} for {{spaces}} works better and is independent of whether proportional or fixed fonts are chosen. This is not perfect but works O.K. so long as the chosen width is slightly greater than the longest expected (here) Roman numeral expansion expected. AuFCL (talk) 07:26, 29 February 2016 (UTC)

I missed your comment regarding use of {{Table style}} on my earlier reading. To be strict that template was designed with table formatting in mind, and {{TOCstyle}} is accepting modifications to a DIVision context (in point of detail the most basic internal element is: <div style="margin:0; padding:0;">…; and the |row…style= variants are similarly modifying list elements within an ordered list (<ol style="list-style:none;margin:0; padding:0;">) structure. The basic element being built upon in the latter case is <li style="margin:0; padding:0;">.

So as you see {{ts}} is not a terribly good choice both from this perspective and from the fact that the template constructs a full style="…" specification which is incompatible with both the style= and quotation marks already present.

Taking all of this on board it is however technically feasible to get access to suitable shorthand expressions via {{ts}}'s "helper function" {{table style/parse}}, so that things like

{{TOCstyle|style={{table style/parse|bad}}{{table style/parse|flr}}{{table style/parse|w25}}|model=CD.P|XLV|{{lorem ipsum}}|479}}

—will actually work—should you feel brave enough to so try. As you see here:

1. XLV

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   479

—just not very conveniently, due to {{table style/parse}} only accepting a single parameter value each time. AuFCL (talk) 09:56, 29 February 2016 (UTC)

So TOCstyle isn't table formatting, good to know. Maybe someday I will get what it is. Your example is of a TOC in a table? My question was a musing of: instead of |style=font-variant:small-caps; could we have |style=sc?Zoeannl (talk) 22:11, 29 February 2016 (UTC)

Oh good grief! (This not aimed at you.) Variants of TOCs seem endless and any attempt to contain them in a "standard" always finds a compelling case which "leaks outside the specification." Which I guess in a nutshell is what this is all about. After a great deal of angst about this, George Orwell III came up with an architecture which—after mangling through misunderstandings and compromises—sort of fits:

<div>	<ol>	$\scriptstyle {\left\{{\begin{matrix}\ \\\\\ \ \end{matrix}}\right.}$	<li>	<table>	…	</table>	</li>	$\scriptstyle {\left.{\begin{matrix}\ \\\\\ \ \end{matrix}}\right\}\,}$	</ol>	</div>
			…repeated for as many rows as required…
			<li>	<table>	…	</table>	</li>
$\scriptstyle {\underbrace {\quad \quad \quad \quad } }$			$\scriptstyle {\underbrace {\quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad } }$						$\scriptstyle {\underbrace {\quad \quad \quad \quad } }$
header=yes			continuing=yes						footer=yes
$\scriptstyle {\underbrace {\quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad } }$
starting=yes
			$\scriptstyle {\underbrace {\quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad \quad } }$
			completing=yes

I hope this diagram also makes it clear why options like |compact=, |style= and |width= must appear in the header section of |continuing= and |completing= cases. All of these options are effectively "chopped off" pending reassembly at final transclusion where the jigsaw is fitted together again.

So all universal settings on the starting page go into the header of subsequent continuing or completing pages? |leaderspacing=2em didn’t work from the header.— Zoeannl (talk) 01:29, 1 March 2016 (UTC)

"Universal" is kind of tricky once the fact is grasped that said "universe" has not been defined. Your list is O.K. except for "depth" which applies at the row level (all actual tables are independent so each has to be informed individually.) You appear to have already isolated "leaderspacing" correctly as being in the same category. AuFCL (talk) 01:54, 1 March 2016 (UTC)

So getting back to your earlier point: Yes, there is in fact a table created for each and every row. However as each table is independent that means that matching column widths is quite a task. They cannot be amalgamated into a single table because that runs counter to the never-quite-crystallised mobile specification—which is also about the point where my understanding dissolves into total static so please do not ask me about that!

My involvement was only as the sucker who got enthused enough to code the damned prototype. Which is all this really is at this stage. I am certainly not pretending it couldn't be done better, or that I did not half wish somebody else would have a go.

I shall put your style=short-cut idea aside for the moment. The idea is good but some means of reliably (programmatically) expanding shortcuts without simultaneously damaging genuine CSS fragments needs more consideration. Please remind me as necessary. AuFCL (talk) 00:07, 1 March 2016 (UTC)

Did I miss a hanging indent? I did. Twice. I'm fine with using Hn.P. But there is no nCHn.P to match: the description is also hanging. I suppose it is terribly naive of me to hope for a generic aCbDc?P model? (Joking.)

Glad you were joking. Of course nCHn.P is impossible. Needs to be mCHn.pP at least so that the documentation can refer to m,n unambiguously, and in any case no user request should not be generalised in an unasked fashion, should it? AuFCL (talk) 00:07, 1 March 2016 (UTC)

{{span}} is really ugly. I hope I never see a need for it again. Is the width for the chapter column adjustable? Zoeannl (talk) 09:14, 29 February 2016 (UTC)

I (thought) I did warn you. Apologies if I didn't. At present the Chapter columns is pretty much assumed to fit within 5em. This decision has more to do with proving the concept than necessarily being a good choice. Not tonight; but I'll put some thought into adding some kind of chapter column width. Any thoughts as to a sensible keyword? Is chapter-width too much to type? AuFCL (talk) 09:56, 29 February 2016 (UTC)

Chapter-width is fine. If we get a default that works for most TOCs then the technically able can adjust as they wish. My main hope is to enable technically challenged people to ease into using wikis. So Wikisource can be the nursery for Wikipedia; with the content provided, it's a lot easier for people to gain confidence working on a wiki at WS. And we're all nice here, cf. WP, of course. So a template that does as much of the thinking for the proofreader is the aim. I am so far appalled at the diversity of TOCs I have encountered. I have vague thoughts on what should be on a good help page and would include a page/tab "Examples and Exemplars" with a list of links to well-done examples. It took me 12 months and a personal tutorial with Beeswaxcandle to find template pages and Whatlinkshere. And I was looking. Most people would have given up, I think this is behind the dearth of proofreaders here. So I want to build help as a pathway from proofreading (which Distributed Proofreaders does so well) to wikified. Perhaps there is a way to do tutorials with a set piece of unproofread text where the edited (annotated) version is saved as/on a User page and can be compared with the "Correctly" proofread page? Then people could practice on "easy" examples. The TOC is critical as it is challenging formatting and in most books (cf. images, tables, references) so it provides the best opportunity from "just" proofreading to real wiki work. But first I have to figure out how to use it myself. And practice, lots of practice.Zoeannl (talk) 22:11, 29 February 2016 (UTC)

P.S. I don't need warning about ugly coding stuff. It's what I expect. I really appreciate your template making TOC "possible" and accessible. Really. Zoeannl (talk) 22:11, 29 February 2016 (UTC)

Thank you. I'll try to keep the complaining under control. Here is a trial of the new options:

---

{{TOCstyle|compact=yes|model=mCHn.pP|Introduction|{{lorem ipsum}}|1}}

1. Introduction

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   1

---

{{TOCstyle|compact=yes|model=mCHn.pP|Introduction|{{lorem ipsum}}|1|depth=2em}}

1. Introduction

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   1

---

{{TOCstyle|compact=yes|model=mCHn.pP|Introduction|{{lorem ipsum}}|1|depth=2em|chapter-width=10em}}

1. Introduction

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   1

---

{{TOCstyle|compact=yes|model=mCHn.pP|Introduction|{{lorem ipsum}}|1|depth=2em|chapter-width=10em|page-width=5em}}

1. Introduction

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   1

---

{{TOCstyle|compact=yes|model=mCHn.pP|Introduction|{{lorem ipsum}}|1|depth=2em|page-width=5em}}

1. Introduction

   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. ................................................................................................................................................................................................................................................................................................................................................................................................

   1

I hope this gives you some usable alternatives. AuFCL (talk) 00:07, 1 March 2016 (UTC)

Cool. What are the defaults? Zoeannl (talk) 06:55, 1 March 2016 (UTC)

Precisely as detailed in {{TOCstyle}}:

• depth: On models which make use of this, provides a user-specifiable hanging-indent factor. Default is 5em.
• chapter-width: On models which make use of this, provides a user-specifiable chapter width. Default is 5em.
• page-width: On models which make use of this, provides a user-specifiable page width. Default is 2em.

O.K.? AuFCL (talk) 07:02, 1 March 2016 (UTC)

Got it. Zoeannl (talk) 07:06, 1 March 2016 (UTC)

Are chapter-width and page-width in or out of the header for continuing pages? — Zoeannl (talk) 07:52, 6 March 2016 (UTC)

Out, because they affect row formatting. Hmm. may have to start compiling these relationships… (If the documentation is ever unclear to you, put the parameter in the header and preview the result: if it does not seem to have had an effect then transfer into the main body and repeat. That should be definitive in most cases?) AuFCL (talk) 08:05, 6 March 2016 (UTC)

Is it possible to set depth and chapter-width for a row?: Here the last entry would fit better with different settings (using mCHn.pP: C a blank field, shorter m, longer n?) — Zoeannl (talk) 09:59, 6 March 2016 (UTC)

Not as the system currently stands. Might be easiest in the short-term to make two separate TOCstyles? AuFCL (talk) 10:44, 6 March 2016 (UTC)

@AuFCL: This page is interesting (as in the curse) with the description overhanging the page number. Is it replicable? Zoeannl (talk) 02:42, 5 March 2016 (UTC)

Not as things stand at present. Thinking back I seem to recall this case getting pushed aside as "too simple to bother with initially"… and then was forgotten! It will require the creation of a new model type as (in table terms) the dot-leader must "live" in the same cell as does the page number (for example in D.P the description and leader share a cell but page stands alone in its own one.) Do you need this in a hurry? AuFCL (talk) 07:51, 5 March 2016 (UTC)

Pardon the delay—I was too tired last night to trust myself making changes. I have added a new model (CD.uP) (if you don't like the name now is the time to change it!) intended to be read as same as CD.P-with-page undercut. I have taken the liberty of reformatting Page:Historic Girls.djvu/245 as an example of use but deliberately left the page un-validated in case you don't approve of the result. AuFCL (talk) 02:21, 6 March 2016 (UTC)

I have also come across an hyphenated word across pages. From your patient explanation, I gather {{hws}} won't work with TOC style because the 2nd page will start a new table and we should manually join the word, as I do for references with words hyphenated across pages. Unless there is some trick to doing this, I haven't investigated really, I just haven't seen any alternative in action. With a reference I would put a <noinclude></noinclude> instead of an hwe on the second page with an explanation "united on previous page" or something. What would be an appropriate way to leave a note with TOCstyle? A note in the header? Using <!-- -->?

No, I have over-generalised, I think. Does your explanation covers what happens across pages if the description, D is split across pages? Zoeannl (talk) 02:42, 5 March 2016 (UTC)

I think it was me that did the over-generalising. In most models the above discussion is true, however models like 2H3P/s create a "split" cell which can be recombined with its continuation model 2H3P/e, and {{hws}}/{{hwe}} should work fine across such structures. Though it does not contain hyphenation a split cell is at the bottom of Page:Hakluytus Posthumus or Purchas His Pilgrimes Volume 12.djvu/12 continuing onto the following page, and the results of reassembly may be seen here: Hakluytus_Posthumus_or_Purchas_His_Pilgrimes/Volume_12#ToC_2 AuFCL (talk) 07:51, 5 March 2016 (UTC)

There wasn’t any rush. Just, as you can see, Kathleen had validated all the other pages and this was the last one. Which she has already done. Other than the heading that wasn't larger (it’s an optical illusion from being bold.) I have no problems with your reformatting—it makes sense to have it as one TOC. I do have trouble reading the Comparison between our edits though: what is with the highlighting where as far as I can see there isn’t any change? Flower Painting for instance. Did you remove the extra spaces manually or with some script or bot? Beeswaxcondle said he has some scripts on his sidebar that he clicks and they do their stuff; they’re on my to do as they sound very nifty.

Do other models have the /s /e option? I had noticed the 2H3P versions before but had forgotten them. Obvious answer to the problem no it’s pointed out.— Zoeannl (talk) 06:15, 6 March 2016 (UTC)

Thanks for picking up the over-enthusiastic "ART HAND-BOOKS." heading. I did have mild doubts and should have realised the precedent set earlier.

Wow, checking the change display certainly is confusing. I think the main point of difference was your technique was bolding the "Chapter" Roman numerals in one block but not the other; and I opted to bold none of them, just the descriptive text. Amend as you see fit—which was why I was less than amused by friend K.W. blanket validating.

As it turned out I manually removed the spaces more or less through habit. I do however have a script helper which seems to be too complicated for normal consumption. However you might have a look at installing Pathoschild's TemplateScript which appears to be very popular with the locals and includes this very function.

As for other /s,/e models there is CD.P/s paired with CD.P/e. I went through a phase of only adding models as cases came up which the prior set could not handle. This concept of split entries doesn't really occur all that frequently. As things stand each model is simply a unique label ordering a particular row structure to be built. Perhaps one day it might be handled in a more mechanical fashion but for now it isn't. (Something else to add to your short-cuts idea?) AuFCL (talk) 07:51, 6 March 2016 (UTC)

Index example: Is there a way to get TOCstyle to play nicely with {{di}}?— Zoeannl (talk) 10:03, 6 March 2016 (UTC)

Short answer: not a hope. Long answer Maaayyyyyybbbeeee? (see page: the solution (if you can call it that!) is to remember the drop-capital "lives outside" of the two lines; which I have quite horribly joined up and floated beside the capital. Unfortunately to get the page numbers to line up one has to estimate the width of the drop-capital and then subtract it from the 100% width allocated by the outermost compact=yes TOCstyle.... Worse yet the initial guess has to be made in terms of the fact {{di}} increases the font-size and adds... I am getting seasick just describing this stuff. Are you sure it is worth the effort? AuFCL (talk) 10:44, 6 March 2016 (UTC)

I don’t mind it underlined with dots. Someone might rather convert it to a straight capital but it is extremely trivial. Cheers Zoeannl (talk) 23:40, 6 March 2016 (UTC)

Pardon? Is it being underlined for you? My browser (firefox 44.0.2 currently) shows the drop-capitals unadorned. If that is not the case for you would it be possible to let me know your browser version and, ideally, a screen capture, please? AuFCL (talk) 01:55, 7 March 2016 (UTC)

As per the previous page which is how a mere proofreader would leave it. The alternative is to state that we don't di at all with TOCstyle and leave a plain capital. Quite reasonable I think. The di C on the example isn't working for me-due to above complications?Zoeannl (talk) 02:47, 7 March 2016 (UTC)

Thank you. I understand now. Although as the formatting does not remotely match the scan would this be considered adequate proofreading? This is entering the realm of: should the text proofing be fully divorced from the formatting?—argument. PGDP diverges from WS practice here, and perhaps has made the wiser choice?

Regarding the "di C on the example isn't working," how about now? I thought of a "looser" way of floating the components which might work a little more universally. AuFCL (talk) 03:35, 7 March 2016 (UTC)

Big question. I think it is in WS's interest to be very gentle with "mere" proofreaders and not overwhelm them with complications but being able to be faithful to the original page is a one of the major pluses for WS. [For "Quite reasonable", above, please read "As much as I can handle right now". Your solution is much better.] I'm thinking that WS is a great place to learn wiki-ing and that it could provide a pathway from "mere" proofreading to competent wiki-er. DP has stages of proofreading: so for someone on a P1 licence, a plain Di in a TOCstyle would be considered adequate but a P2 would be expected to notice it wasn’t true to scan and to investigate the template page for a solution and go to Scriptorium Help if not found there. I would like to see a list of books kept for beginners to proofread—books without references, tables or images. But of course they would all have TOCs so an easy to master template would be great, but TOCs do seem to have a lot of complications… Consider me your canary! I’ll sing (or squawk) if the template gets too complicated! I think there is still a bit of trialling to do. I tried a scenario of using mCHn.pP as a default on my user page. Quite pleased with myself that I could make it do what I wanted but I don't know that it isn't too intimidating. I shall carry on proofreading, Cheers, Zoeannl (talk) 10:20, 9 March 2016 (UTC)

Another variation here with a hanging indented description with underhanging pg number. Is the underhanging page number something that could be added to mCHn.pP? Considering above… Zoeannl (talk) 10:24, 9 March 2016 (UTC)

Please pardon once more my tardiness. I have added both a Hn.upP and a mCHn.upP model (the first applied to /254 per your mention; all size controls are at their default values). Was that more what you were looking for? I have not even written any documentation yet. I am afraid that will have to wait for a new day. AuFCL (talk) 10:06, 11 March 2016 (UTC)

User Guide

Not sure where this will fit but something might be worthwhile including in your draft guide:

Whenever a page ends in a quoted, hyphenated word or phrase the approach often utilised of ending with, e.g.:

"{{hyphenated word start|ac|acquired}}

followed on the next page, e.g.:

{{hyphenated word end|quired|acquired}}"

results after transclusion into the final text in the rather awkward result:

" acquired"

due to the initial quote mark being contributed from the first page, a space contributed by the transcluding <pages> tag, and finally the word contributed from the content of the appropriate parameter of the {{hyphenated word end}} template on the second page.

May I commend the following as more correct usage? On the first page, e.g.:

{{hyphenated word start|"ac|"acquired"}}

followed on the next page, e.g.:

{{hyphenated word end|quired"|"acquired"}}

resulting after transclusion into the final text:

"acquired"

In case you did not recognise the above it is based upon Page:Symonds - A Problem in Modern Ethics.djvu/56 and the subsequent page. I have been encountering this situation frequently recently and thought it perhaps worthy of bringing to your attention. Pardon if not of interest. AuFCL (talk) 17:17, 14 March 2016 (UTC)

That's really good to know. I was going to include the em-dash across pages as well. Are there any other similar scenarios? Zoeannl (talk) 00:42, 16 March 2016 (UTC)

Basically anything which ends up butted just in front of {{hws}}—certainly any kind of dash, quote (for sake of argument do you want to mention the &lsquo;-and-variants? Sleeping dogs?) or mathematical operation. Oh, and braces, brackets and parentheses (‹,«-guillemets?)

Things which are immediately adjacent to {{hwe}} are generally of lesser problem—maybe due to the fact that people are more conscious of the adjacency of the second parameter which is normally the full word to be rendered under transclusion; and also because the mechanism of expanding {{hwe}} does not result in adding spaces. That is basically my thought in a nutshell. Apologies I could not think of a less long-winded means of explaining above—maybe you should put in a bid for a pay rise? AuFCL (talk) 07:34, 16 March 2016 (UTC)

My additional comment is that split word joined by the template, appears in the main namespace as if the whole word is part of page 2. — Ineuw talk 18:10, 18 March 2016 (UTC)

In further passing I stumbled across this paired gem. It must be some kind of sacrifice to the god of cruelty to templates perhaps? Page:Poems,_Volume_2,_Coates,_1916.djvu/281 and Page:Poems,_Volume_2,_Coates,_1916.djvu/282. Please, oh please, don't recommend anything like this usage in your `Guide. AuFCL (talk) 11:14, 19 March 2016 (UTC)

Even better would be to offer an alt solution... or would that involve a complete reformatting of the Index of Titles? Londonjackbooks (talk) 11:57, 19 March 2016 (UTC)

@Londonjackbooks: Please don't worry, I am not having a go at you or this solution. In fact I am somewhat agog with horrified admiration for the technical success whilst simultaneously disregarding the "spirit" of the templates used (and that is an argument which has been had and lost by me elsewhere. Not with you though. I'm not going over that old ground again.) It is an exemplar of "good enough for government work," which is the main reason I was drawing the attention of our very own self-appointed "works process manual" compiler. AuFCL (talk) 12:15, 19 March 2016 (UTC)

Unconcerned. Merely open to suggestions. Londonjackbooks (talk) 12:19, 19 March 2016 (UTC)

Besides which, I did offer an improvement: if you were going to use this solution at least make it work in both Page: and transclusion; i.e. the |hyph= recommendation. AuFCL (talk) 00:05, 20 March 2016 (UTC)

@AuFCL: You may have misread my tone; I may be misreading yours. I was unaware of the |hyph= option back in 2011. You said you don't recommend the usage above; I assumed you meant {{hws}} use in general (in that particular instance), and really was genuinely seeking another option. RE: "SNB": has a familiar ring. Londonjackbooks (talk) 01:26, 20 March 2016 (UTC)

@Londonjackbooks: To be meticulously fair, one P.T. Aufrette introduced |hyph= about a month after your effort. And I apologise if "tone" was coming across. I was really delaying even seriously looking at the page formatting until Ineuw and Zoeannl had a chance to witness and/or make their own comments. There are really two levels of conversation going on here: between you and I regarding a better approach (and in all honesty there may not even be one!) and between Z., I., et al as to how to lay down "best practice" (gag!) for advising newcomer editors. So everyone has to carefully maintain that "innocence of mind" which, hoary old reprobates all we no doubt in reality are, is not quite "truth" either.

To specifically address your concern: no I don't really recommend the usage of a running {{block center/s}} enclosing <poem> enclosing {{sc}} enclosing {{hws}} for the purposes of plastering over the results of butting together the two pages. There is so much fundamental "wrong" going on there, not least of which much the same effect reduces to careful use of <noinclude>/<includeonly>. And I repeat I blame you for none of this: this is one of those cases where a chain of justifiable small deviations from legitimacy has resulted in a kind of Frankenstein's monster of an overall result (For Ineuw: is "szalamitaktika" appropriate?).

Poor Zoeannl, having to host all this! Please hang in: I truly hope it may one day may actually become more productive and less circus-like? AuFCL (talk) 01:56, 20 March 2016 (UTC)

I am amused. As an aside I have been having a similar conversation (which I sort of kept up with, technically) with Djr13 about (end of book) indexes and {{plainlist}} and making templates fit for purpose for WS. He mentioned italics: Why don’t we have an italics template that ignores hard returns? And then there is poetry and next month is poetry PotM. And I take a deep breath and do some sane proofreading and try to figure out where to focus my efforts… — Zoeannl (talk) 02:32, 20 March 2016 (UTC)

If I have learned (and may be permitted to pass on) two lessons in the wikisource world: when Londonjackbooks lays down the law with respects to poetry, listen! because she is usually correct. And in similar vein Djr13 is rarely wrong when pontificating upon accessibility issues. I do my best but will always defer to these two on those areas. All of us have certain skills and deficiencies but the delightful side of that truth is each one can become experts in a sufficiently well-defined niche area.

P.S. Was {{italic block}} what was desired? AuFCL (talk) 03:04, 20 March 2016 (UTC)

Had to think and check. So not usually, {{italic block}} only works for whole paragraphs, it forces a hard return at beginning and end.Zoeannl (talk) 03:25, 25 March 2016 (UTC)

Re Coates: As a mere proofreader I don't see the point of the block center. Would {{plainlist}} require the same sort of treatment (he) for the last listing? — Zoeannl (talk) 02:32, 20 March 2016 (UTC)

Ah well, in for a penny…: shall I explore the true horror that that {{plainlist}} represents, since I raised the concept of Frankensteinian creations earlier? This template wraps a (presumed unordered list, as it does little useful to any other construct bar indent control) and then applies CSS to the result of the form:

/* Unbulleted lists */
.plainlist ul {
	line-height: inherit;
	list-style: none;
	margin: 0;
}
.plainlist ul li {
	margin-bottom: 0;
}

Umm. What? It strips the bullets back off that would otherwise be present as generated by the leading-*'s list-style: none;? (Mind you to be fair {{TOCstyle}} internally pulls exactly the same sleight-of-hand.) So all-in-all I accept Djr13's point about this place being a laughing-stock on so many levels but then again so is this rather a good joke as well. AuFCL (talk) 03:36, 20 March 2016 (UTC)

So there isn't a template that just takes a list and produces—a list? That seems awfully silly.Zoeannl (talk) 03:25, 25 March 2016 (UTC)

Maybe I have missed the point somewhat but don't the two outstanding issues you pose have the same answer? Why have a special template when, for italics, there already exists <i>; and for lists of all persuasions, <ul>, <ol>, or <dl> (or even at a pinch *, # or ;…: forms)? AuFCL (talk) 04:18, 25 March 2016 (UTC)

Religio Medici

Hi. After a quick glance at the page histories of Index:The Harvard Classics Vol. 3.djvu it seems that you have completed the section[s] The Harvard Classics Vol. 3/Religio Medici. I haven't added those missing pages as I didn't want to rob you of that pleasure. CYGNIS INSIGNIS 18:22, 1 April 2016 (UTC)

Hi back. What missing pages? Cheers Zoeannl (talk) 06:23, 2 April 2016 (UTC)

Pages from 265 on of the index above, parts 1 and 2, everything but the introduction. CYGNIS INSIGNIS 06:51, 2 April 2016 (UTC)

Ah the transclusion. I hadn’t noticed. Thanks, done. Zoeannl (talk) 09:47, 2 April 2016 (UTC)

Vol 56 done?

@Ineuw: Shall I move on to vol 57? Mark 56 as proofread (though there are a missing symbol and image to be unproblemed)? I have been known to be in the mood for Ads so can return to them when it strikes. Cheers, — Zoeannl (talk) 11:33, 24 April 2016 (UTC)

Regarding your "missing symbol" sub-issue, is it too naughty to deliberately misinterpret the phrase "double plus sign in a circle" to mean <math>\oplus\!\!\!\oplus</math> (which looks like $\oplus \!\!\!\oplus$—try not to go cross-eyed looking at it)? In other words "double; plus-sign-in-a-circle" vs "double-plus-sign; in a circle."

Some other possibilities are: * <span style="position:relative;">{{Unicode|&#10797;}}<span style="position:relative;left:-0.7em;">{{Unicode|&#10798;}}</span></span>—looks like: ⨭⨮; or {{Unicode|⧺⃝}}—looks like: ⧺⃝ (frankly awful on my system: though in theory ought to be correct Unicode for double-plus-within-enclosing-circle.) AuFCL (talk) 02:57, 25 April 2016 (UTC)

One last try (yes it is mad): <math>\bigcirc\!\!\!\!\!\!\!\!\!+\!\!\!\!\!\!+</math> looks like: $\bigcirc \!\!\!\!\!\!\!\!\!+\!\!\!\!\!\!+$ which is pretty near acceptable here. AuFCL (talk) 03:12, 25 April 2016 (UTC)

These all look awful on my chromebook with Chrome except for * which is good. Should we look at how it presents on different browsers, or scan an image or …? — Zoeannl (talk) 09:46, 25 April 2016 (UTC)

Ironically though that one looks fairly O.K. under Firefox here; under Chromium it is barely distinguishable from the single plus-in-a-circle. On impulse I checked Commons: images and am sure somebody out there is teasing with . You might be more fortunate searching than was I. AuFCL (talk) 10:59, 25 April 2016 (UTC)

<math> on Page:Somerville Mechanism of the heavens.djvu/87

Hello. Just a quick note which I hope might save you some effort in future: In practice I have found there is no material benefit in adding \left or \right to the innermost parentheses of an expression. For example in your original coding on the above page you had:

$\scriptstyle r={\sqrt {{\left({x-a}\right)}^{2}+{\left({y-b}\right)}^{2}+{\left({z-c}\right)}^{2}}}$

—which at least to my eyes and browser is pretty much indistinguishable from:

$\scriptstyle r={\sqrt {{({x-a})}^{2}+{({y-b})}^{2}+{({z-c})}^{2}}}$

—now on the other hand outer braces, brackets and parentheses most definitely do look better with the \left, \right directives:

$\scriptstyle r=({\sqrt {{({x-a})}^{2}+{({y-b})}^{2}+{({z-c})}^{2}}})$

—don't they?

$\scriptstyle r=\left({\sqrt {{({x-a})}^{2}+{({y-b})}^{2}+{({z-c})}^{2}}}\right)$

—Happy experimentation! AuFCL (talk) 06:00, 26 April 2016 (UTC)

Partial vs. Delta

I just had a double-take moment regarding this same page, Page:Somerville Mechanism of the heavens.djvu/87 and thought I'd better check before "correcting" something you did intentionally (perhaps your browser makes no distinction?) Various formulæ on this page use partial(∂-$\partial$-&part;) whereas I believe delta(δ-$\delta$-&delta;) is the correct symbol in this context. The icing on the cake is two adjacent formulæ (third- and second- last on page) use alternate symbols, even though the same symbol is shown in the scan.

I shall hold off further validation pending your clarifying this. AuFCL (talk) 07:25, 26 April 2016 (UTC)

I started using the delta from the maths symbol menu and then realised, as you have, that it doesn't match the scan. I have been using the delta from the greek menu since and corrected some of the previous pages with find and replace—except when bleary-eyed and/or not paying attention, I have cut and pasted formula uncorrected. All up a bit of a mess, if you can run through with a bot or something that would be great. Otherwise I do intend to fix; I'm a bit formula-ed out right now. How to change the menus? The minus sign on the menu isn't -; maybe an en-dash? Cheers, Zoe — Zoeannl (talk) 11:08, 27 April 2016 (UTC)

Ah. I was looking on the wrong menu (Special Characters.) Presumably you meant the "Math & logic" menu on the "other" (technically CharInsert gadget—but just how somebody who does not already know that is to learn it as the d**mned thing never shows its name!?) Yes, you are right that menu is rubbish: loop-integration, nabla, partial-differential, upper-case Delta: where is the logic? And the one character you do actually want at this time is lower-case delta which is not even present (though as you observed is under the Greek selection—after climbing through all those accented characters.

In short sympathise with the tired eyes argument—suffer from same myself, which is why I'm not offering to review tonight, but will try to do so tomorrow perhaps?

Returning to the CharInsert menu in theory the "User" section is customisable (as in fact you have already done so: in User:Zoeannl/common.js the lines consisting of:

window.charinsertCustom = {
	"User": ' -  —  œ  £  §  ·  º  Æ  É  Ë  Ñ  Œ  Ö  à  á  â  ã  ä  æ  ç  è  é  ê  ë  î  ï  ñ  ó  ô  ö  ù  ú  û  ü '
};

—if working correctly ought to be reflected as the "User" charinsert menu selections. If this is working my recommendation would be to modify the set here build up a set to suit yourself. AuFCL (talk) 11:46, 27 April 2016 (UTC)

That's Inuew's User menu he added for me to help with Pop. Science proofing. It does do for almost everything. I was just feeling intrepid and having a go at maths inspired by Mrs. Somerville. This sort of thing (crap menus) discourages beginners… — Zoeannl (talk) 11:55, 27 April 2016 (UTC)

I understand. With regards your last "discourages beginners…" I could not agree more. However I have no clear ideas on how to better arrange any of these "pick and choose" special character selections: I am aware of more than a couple of attempts to rationalise them which have basically stalled due to intransigence/disinterest so my instincts are to just "do not go there." Everyone I know who takes this sort of thing seriously appears to have a personal solution which bypasses the mediawiki gadgets/utilities anyway to a greater or lesser extent (I certainly do!) AuFCL (talk) 18:05, 27 April 2016 (UTC)

Terence

There is no need to specify works "translated into English". On the English Wikisource, we only list English works anyway. But you need to go back through the list you added, since some of the additions are not in English, but in Latin, and some of the works aren't works by Terence. --EncycloPetey (talk) 15:02, 3 May 2016 (UTC)

Mediaeval Mind

Hi Zoë, I've been out of action for a couple of weeks and have come back to see you're charging through Mediaeval Mind. I hadn't written the style guidance for this because Tannertsf and I were doing the work between us and were thus keeping consistent. I've put together a few notes on the Volume 2 talk so that we can be consistent with the way we did the first 17 chapters. Could you please switch to following those notes? Cheers, Beeswaxcandle (talk) 09:21, 15 May 2016 (UTC)

Sure. Can you give me a page to refer to for the blockquotes? Re titles and authors, just the English books? Cheers Zoeannl (talk) 10:47, 15 May 2016 (UTC)

See Page:The Mediaeval Mind Vol 1.djvu/446 for a simple example, and Page:The Mediaeval Mind Vol 1.djvu/447 ff for a more complex one. For titles, anything in English or that is likely to be here in translation in the next x years. For authors, anyone who would reasonably have an author page here. Beeswaxcandle (talk) 04:46, 16 May 2016 (UTC)

Page:U.S. Government Printing Office Style Manual 2008.djvu/238

Don't forget that /s /e type template are paired :) ShakespeareFan00 (talk) 08:41, 28 June 2016 (UTC)

This was on my "later" list: Page:U.S. Government Printing Office Style Manual 2008.djvu/23? This continues on /25, there is an image on p 24. So I presume it will be transcribed 23,25,24? Cheers, — Zoeannl (talk) 08:54, 28 June 2016 (UTC)

Yes. ShakespeareFan00 (talk) 09:01, 28 June 2016 (UTC)

So… {{nd/GPO/c}} in footnote on first (and subsequent) pages; and in header on second to last page, with {{nd/GPO/e}} at end of paragraph on last page? — Zoeannl (talk) 09:39, 28 June 2016 (UTC)

2nd try. {{nd/GPO/c}} in header on second to last page, with {{nd/GPO/e}} in footnote on first (and subsequent) pages; and at end of paragraph on last page? — Zoeannl (talk) 10:24, 28 June 2016 (UTC)

If the paragraph is split..

{{nd/GPO/s}} at start of paragraph.

etc...

{{nd/GPO/e}} in footer

On next page: -

{{nd/GPO/c}}

... etc.

Mrs. Beeton's Book of Household Management/Chapter IV

The tables seem to span OK here... :) ShakespeareFan00 (talk) 22:54, 19 March 2017 (UTC)

Index:Army sanitary administration.djvu

I'm sorry for imposing, but in this work, I noticed that on pages you validated you converted ShakespeareFan00's {{smaller}} rendering of sidenotes to actual sidenotes. However Jasonanaggie did not do the same, leading to inconsistency. Since you seem to understand them better than I do, could you see your way to converting the remainder? Thank you very much. BethNaught (talk) 16:34, 29 March 2017 (UTC)

TOCstyle in the Forerunners

Hello Zoe,

Using TOCstyle in these two pages, 74 and 75, doesn't result in a smart transclusion. See XIV. Young Switzerland: bold style is applied to the following text. I'd be easier to use a simple table, as there is no page number nor dotted line. Bradype (talk) 07:32, 13 April 2017 (UTC)

span and div templates

To note that if using a centered template like {{asterism}} that it is a <div> template, so when we are sizing it with a <span> template like {{xx-larger}} it fouls up the html nesting (dashed html hierarchy!), and silently. [In short we can wrap DIV around SPAN, but not SPAN around DIV] So here we need to wrap a DIV template outside another DIV template, eg. use {{xx-larger block}} preferentially. Thanks. — billinghurst sDrewth 23:02, 13 April 2017 (UTC)

Similarly if we want to have a couple of paragraphs sized similarly, we should use {{smaller block}} (DIV) rather than {{smaller}} (SPAN) as when we add a couple of hard returns the wikitext will put in a paragraph <p> makrer and here, same thing happens to the nesting. DIV >> P >> SPAN — billinghurst sDrewth 01:16, 14 April 2017 (UTC)

@Billinghurst: So this prompts me to ask: 1. who designs these templates? It’s not proofreader friendly; it’s no wonder there is a dearth of proofreaders at WS with this sort of thing.

My number one pet hate is {{bar}} when {{bar|3em}} gives it’s outrageous red page of "Expression error: Unrecognized word "em""—this is the only template that doesn’t specify length by em and px.

2. How would I get a template changed? The inconsistency is extremely annoying; idiosyncrasies like this are barriers to participation for newbies and non tech literates.

For the original example: 3. why is larger not larger block i.e. why do we have larger if it doesn’t work in these circumstances? (I am anticipating you telling me that larger block has it’s problems; so 4. how do we get something designed to work generally?)

And while I am raging: 5. How to get a template for italics and bold that works across page breaks?

For proofreading (and what WS calls Validation) the edit page should remain corresponding to the scanned page. 6. I have been told there are objections to leaving "unnecessary" end-of-line page breaks but is this really a valid concern if it discourages serious proofreaders? Which it does, seriously.

These are SERIOUS questions because I feel like the only "proofreader" here. If in three years no one else has survived the trial of learning how things are done here, WS has a big problem and will continue to be a place for those with pet projects or who have migrated from WP. WS has the potential to provide a training ground for would-be Wikipedians as our content is provided. People who need to learn how a wiki works, wiki markup and wiki protocol would be much better off here before venturing into the shark infested waters at WP where their content is also scrutinised. So I have been trying to learn how things work to be able to make learning guides for people who, like me, aren’t technical. The above questions reflect about 80% of the frustrations I have here that I haven’t figured out. The more I learn, the more I realise the potential WS has. So much more than Project Gutenberg. I honestly think PG should be merged with WS, or be a front-end with PG teaching proofreaders to feed to WS. But WS wouldn’t survive scrutiny by proofreaders from PG as things stand now.

So that’s said… Cheers, Zoeannl (talk) 00:35, 18 April 2017 (UTC)

Wow; lost of questions. Let us see how we go. Can I start with some commentary that part of the issue is the evolution of html standards, and the evolution of cascading style sheets; couple with browser technology changes. There are games of catch-up, and the thruth is that most members of this community prefer to proofread and produce works, and not get bored with evolving inane evolving internet syntax.

Measurement templates. Our initial templates didn't have units, then it was found that only having "em" measured templates was restrictive, so we moved to having a default measurement, though leaving them unitless so people and having people add units. So {{gap}} is a good example, and something like {{right}} is another.

Changing the templates can be by the talk page initially, or talking to the whole community at WS:S. Some are possibly easily fixed, some not depending design, bot runs required to fix existing units, and how much behaviour we have to change in users. We all get used to the idiosyncrasies, and probably have our list of 10 std. templates that we utilise, so may not notice some of the differences.

{{tl|larger}} is a span template so can be used for a span of text which is usually a word, a few words, or something smaller than a paragraph, so it works for having '''{{x-larger|x-larger}}''' (x-larger) words. Where as look what happens with {{x-larger block|x-larger}} (x-larger block) words.

{{larger}} is a span template so can be used for a span of text which is usually a word, a few words, or something smaller than a paragraph, so it works for having x-larger (x-larger) words. Where as look what happens with

x-larger

(x-larger block) words.

Once your at a paragraph or several paragraphs a span won't work, so we would use {{larger block}}, and you have to use paragraph or division markers. We tend to just do division (or for use we call them "block" templates. Now if you want to centre words, you cannot do it with a span, it will be div. Remember you cannot just centre a few words from within a sentence, it is all of something. So I will always have the {{center}} on the outside of other formatting {{center|{{larger|''nested this way''}}}} div -> span -> span.

So your problem with ''Italic text'' and '''Bold text''' is that they are wiki syntax for italics and bold spans, so their formatting stops at the end of a line. So you can use continue the formatting on the next span by the same method. BUT if you just want one set of coding, we can sneak back to using traditional html, eg. <i>Italic text</i> and <b>Bold text</b> and it it continues over a page then closing tag can be moved into footer, and the opening tag put into the header. It isn't templated as we can use html, though if you think that it needs to be, then maybe we need to do it.

How to have things work? We have tried to label sizing and related div templates with "block" to make them overt, and the other sizing (span) as without. If something is centered, then it has to be a div (rule, asterism, center, ...). Usually we would fix up most newbies work where it is the other way around, for those who are more melded to the community we explain, and see how the conversation progresses. Any feedback that you have about what is needed to better explain, make evident, have easier, is most welcome. {Just like this conversation] My initial thoughts are that we need to look to better explain DIV > P > SPAN and their nesting, and then where we have templates that are a DIV that we probably need to better highlight their difference more evidently.

Line formatting/breaks. These line breaks are what breaks formatting on all span templates, wikilinks, etc. So in cases that any of those things span a line break they need to be removed. I am certainly one has the practice (guilty?) of removing all line breaks for such, and to dehyphen ends of lines. You are correct that there are two aspects to removing vs. leaving.

With regard to your comment about being the only proofreader, I am not sure that I get the gist of the comment. Yes, our tools are less than perfect. There has started the transition to give users the ability to use VisualEditor rather than the raw wikitext/markup, there is just lots of legacy to get through, and the WSes traditionally get less in resources (chicken and egg there). — billinghurst sDrewth 08:25, 18 April 2017 (UTC)

Good information. Often wondered why center and smaller needed to be in a certain order. A comment re line breaks; to leave them in or remove. I notice that some of us are coming from a DP community. Leaving line breaks in in that environment works very well. Not so much here. When I'm proofing/validating, I have to temporarily boost my Windows magnification from my default 150 to 200. This is so I can effectively see what is presented on the edit portion of the page. However, when I do that, the display I see is about 85% of the words on one line and the remaining words on the second line which makes it more difficult for my style of proofing. That's one thing I like about working here; fewer hard rules (only one being emdash space before/after). It would be a shame to start imposing a more DP-type environment here. Humbug26 (talk) 16:24, 18 April 2017 (UTC)

Note

Hello. Hope I didn't stop you in your tracks or cause a frustrating edit conflict by placing this note. I tried to leave note a couple pages ahead of you, but I am a slow typist, and you were too quick for me :) Feel free to remove my note and continue. I thought to tap you on the shoulder there rather than here, but now I have interrupted you twice. Apologies, Londonjackbooks (talk) 12:16, 10 July 2018 (UTC)

Well, I doubt there are many around here who will insist you remove end of line breaks... But I would still suggest adjusting the running headers when proofreading, and if characters are missing (such as Greek &c.), the page should be marked as problematic until resolved. This text was on my to-do list (I had only proofread one chapter), which is why it was on my watchlist, and why I am here at your talk page right now. Of course, we don't claim ownership here, so you are free to proofread. Thanks, Londonjackbooks (talk) 04:21, 11 July 2018 (UTC)

@Londonjackbooks: Hi no offense but I just proofread as I read. I got onto this book after it was referenced in The Origin of the Family, Private Property and the State which I just finished reading and enjoyed. You did interupt my proofing the other night but not in a bad way -I’m in NZ so it was past bedtime and I lost track of time trying to finish. I’ve had a year of disruption and am enjoying being back and reading books.

I have been doing this for a while and am over trying to persuade WSers to use Distributed Proofreading (Project Gutenberg) standards so we can get more proofreaders here. I am not an exceptional proofreader at DP but here I am because I’ve managed to pick up how to Wiki-sort of, and kept at it because I like working through a whole book I’m interested in which I can’t do at DP. I don’t remove hard returns as this assists proofreading by the validator. I don’t change the second header as I proofread as I’m lazy and it breaks the flow. I have gone back to copy and paste every second page in the past. I forgot with Origin though.

Cheers, Zoeannl (talk) 08:42, 11 July 2018 (UTC)

Thanks for the reply. In my opinion, it is worthwhile to seek to treat every work as though it will be nominated for Featured Text, for example. Also in my opinion, this includes the correctness of non-transcluded headers/footers. It is one thing to leave out a {{rule}} from the header, but where text information is concerned, it should be matching. In any case, formatting should be consistent throughout a text, to include header formatting, hard breaks, etc. That is my main concern. The chapter I proofread removes hard breaks and includes a rule in the header. If it is your wish to continue as you are, then either your formatting or mine should be adjusted for consistency's sake. Again, all my opinion. Thanks :) Londonjackbooks (talk) 09:21, 11 July 2018 (UTC)

CAPS

Hi. In the pages The Sphere and Duties of Government/Chapter 10 would you be okay with these being converted to lower case, or maybe some camel case. The upper case for prev/next/section is a little eye-catching. — billinghurst sDrewth 07:18, 4 September 2018 (UTC)

And I will hazard a guess that Coulthard is the one at Page:Alumni Oxoniensis (1715-1886) volume 1.djvu/326. I will span out from there to see what he does later in life. — billinghurst sDrewth 07:27, 4 September 2018 (UTC)

@Billinghurst: hi, can you tell me why the page numbers in the transclusions are blurred and in the text? Cheers, Zoe

I am not understanding to which text that you are referring. I am not seeing issues of blurring, in either text, so I am going to need a link and a little more info as I may be looking in the wrong spot. Thx — billinghurst sDrewth 21:13, 4 September 2018 (UTC)

So at The_Sphere_and_Duties_of_Government/Chapter 10 I have the page number [121] blurry and in the middle of the text. Is it just me? Zoeannl (talk) 22:21, 4 September 2018 (UTC)

Looks okay to me. Do you have all your page links in the running text? If so, then in your left sidebar, you can toggle to Page links within text -> Page links beside text. Hmm, that grey background does have them less clear. — billinghurst sDrewth 22:30, 4 September 2018 (UTC)

That’s it. Must have toggled it accidentally at some stage. Cheers, Zoeannl (talk) 22:45, 4 September 2018 (UTC)

Growth team updates #2

Welcome to the second newsletter for the new Growth team!  

The Growth Team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

Our plan for the next quarter is ready

After consulting with many communities on the best ways to increase retention, we will focus during the next 3 months on these projects:

• Understanding first day: to see what new editors do right after creating their accounts. We will be careful with user privacy, and we hope to share initial results in December.
• Personalized first day: this idea will also help us learn a lot about new editors by adding some optional questions to the new editor’s registration process. We hope to share initial results in December.
• Focus on help desk: we plan to invite or redirect people to the local help desks where they can ask questions to help them make their first edits. We hope to have an initial experiment running in December.

You can read about the details of this plan on our team page.

How did we get to this plan?

We have set up our plan based on the 8 ideas we were considering. You can read about our analysis in our team updates, and detailed discussion on each idea.

We are looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the projects we'll work on.

Growth team's newsletter prepared by the Growth team and posted by bot, 13:31, 4 October 2018 (UTC) • Give feedback • Subscribe or unsubscribe.

Novalis

Thanks for adding the author link. I had not as of yet looked into the identity of Novalis and the associated quotation, but will do so now :) Londonjackbooks (talk) 08:29, 16 October 2018 (UTC)

Growth team updates #3

Welcome to the third newsletter for the new Growth team!  

The Growth team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

Two Growth team projects to be deployed in next two weeks

We will be deploying the "Understanding first day" and "Personalized first day" projects on Czech and Korean Wikipedias in the coming weeks. See the new project pages below for full details on the projects, and our project updates page for their progress.

• Understanding first day: learn about the actions new editors take right after creating their accounts. We will be careful with user privacy, and we hope to share initial results in December.
• Personalized first day: learn about new editors' objectives by adding some optional questions to the new editor’s registration process, and personalizing their onboarding. We hope to share initial results in December.

Third Growth team project begins

• Focus on help desk: direct newcomers to the local help desks where they can ask questions to help them make their first edits. We hope to have an initial experiment running in December.

Best practices for helping newcomers

We are going to direct newcomers to help desks. But what's the best way to reply to a newcomer there? We have gathered some best practices for successful interactions, based on community experiences and some external documentation. The page has also been reviewed by some experienced community members who suggested some changes. That page is now open for translations. Comments and suggestions are still welcome!

We are still looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Also, please share this update with your community and interested people!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project page for detailed updates on the projects we'll work on.

Growth team's newsletter prepared by the Growth team and posted by bot, 13:30, 7 November 2018 (UTC) • Give feedback • Subscribe or unsubscribe.

Growth team updates #4

Welcome to the fourth newsletter for the new Growth team!  

The Growth team's objective is to work on software changes that help retain new contributors in mid-size Wikimedia projects.

We need your feedback!

We have two requests for community members:

1. Now that data is coming in for the welcome survey, we are planning how to use that data to personalize the newcomer's first day. See our current thoughts here, and join the conversation here.
2. Try out the help panel's interactive prototype, and read about how we're planning to roll it out, and post any thoughts or reactions here.

Two Growth team projects have been deployed (detailed updates here)

• Personalized first day (welcome survey) was deployed on November 20 on both Czech and Korean Wikipedias.
  • The survey is now being shown to half of new users (A/B test). Responses are being recorded in the database. We'll report on initial results during December.
  • We are planning to test a second version of the survey, called "Variation C", which we think will maximize the number of users who complete the survey and stay on the wiki.
  • The original objective of this project was to give newcomers the materials they need to achieve their goals, and so now we are currently planning how we will use the information collected in the welcome survey to personalize the newcomer's experience. We hope community members will read our current thinking and join the conversation here. Some of the plans we are considering include:
    • Making it easy for newcomers to see editing activity around the topic areas in which they indicated that they're interested.
    • Connecting interested newcomers to experienced editors.
    • Surfacing the help content most relevant to the reason for which the newcomers created their accounts.

• Understanding first day (EditorJourney) was deployed on November 15 on both Czech and Korean Wikipedias. It has been done after a longer security review and final testing than expected. Data is now being recorded for all new users on those wikis, and we've been auditing the data and preparing to make initial reports during December. Stay tuned for the next newsletter!

Help panel is under construction

• Focus on help desk (help panel) is planned to be deployed during the week of January 7 on both Czech and Korean Wikipedias.
• This interactive prototype is the best way to see the design and wording in the feature.
• We ran live user tests on the prototype, with results posted here.
• In addition to giving the ability to ask a question, the help panel will also contain a set of links to existing help content. Our ambassadors on Czech and Korean Wikipedias are determining the right initial set of most helpful links in this task.
• We encourage community members to try out the prototype and read about the rules for who will get the feature, and add any thoughts to this discussion.

We are still looking for volunteers

Do you want to participate to our experiments? We are looking for new communities to work with us (especially a new mid-size wiki), and people to become ambassadors to help us to communicate with the different communities. Discover how you can involve yourself or your community.

Also, please share this update with your community and interested people!

Learn more about us

You can visit our team page to find out why our team was formed and how we are thinking about new editors, and our project updates page for detailed updates on the projects we work on.

Growth team's newsletter prepared by the Growth team and posted by bot, 09:31, 7 December 2018 (UTC) • Give feedback • Subscribe or unsubscribe.